Re: [Python-Dev] PEP 446: Open issues/questions

Le Tue, 30 Jul 2013 09:09:38 +0200, Charles-François Natali a écrit : > > > > Perhaps this advocates for a global flag, e.g. > > sys.set_default_fd_inheritance(), with False (non-inheritable) being > > the default for sanity and security. > > This looks more and more like PEP 433 :-) > > And hon

[Python-Dev] PEP 442 aftermath: module globals at shutdown

Hello, PEP 442 has now been committed in time for testing in Alpha 1. This paves the way for the removal of another well-known annoyance: the behaviour of module globals at shutdown. Now that reference cycles aren't a barrier to object finalization anymore, we shouldn't need to set module global

Re: [Python-Dev] PEP 442 aftermath: module globals at shutdown

le's globals, and with it other modules Regards Antoine. > > --Guido > > On Tue, Jul 30, 2013 at 11:42 AM, Antoine Pitrou wrote: > > > > Hello, > > > > PEP 442 has now been committed in time for testing in Alpha 1. > > > > This paves the way for

Re: [Python-Dev] PEP 442 aftermath: module globals at shutdown

On Wed, 31 Jul 2013 13:30:58 +1200 Greg Ewing wrote: > Antoine Pitrou wrote: > > - it is held alive through builtins: the site module patches builtins > > with additional objects, which themselves keep references to the site > > module's globals, > > The mod

Re: [Python-Dev] to rename or not...

Le Wed, 31 Jul 2013 08:15:50 +0200, Ronald Oussoren a écrit : > > Because of this I'd like to introduce a new API in plistlib that > fixes both problems. In particular: > > * Add 'load', 'loads', 'dump' and 'dumps', those use "bytes" for > binary data by default > > * Keep and deprecate "readPl

Re: [Python-Dev] PEP 8 modernisation

Le Thu, 1 Aug 2013 22:44:12 +1000, Nick Coghlan a écrit : > 4. Lines up to 99 characters are now permitted (but 79 is still the > preferred limit) Something magic about 99? cheers Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mai

Re: [Python-Dev] PEP 8 modernisation

Le Thu, 1 Aug 2013 23:21:49 +1000, Nick Coghlan a écrit : > On 1 August 2013 23:10, Antoine Pitrou wrote: > > Le Thu, 1 Aug 2013 22:44:12 +1000, > > Nick Coghlan a écrit : > >> 4. Lines up to 99 characters are now permitted (but 79 is still the > >> preferr

Re: [Python-Dev] PEP 442 aftermath: module globals at shutdown

Le Thu, 01 Aug 2013 17:03:03 +0200, "Martin v. Löwis" a écrit : > Am 30.07.13 23:32, schrieb Antoine Pitrou: > > - it is held alive by a C extension: the main example is the locale > > module, which is held alive by _io and in turn keeps alive other > > Python

Re: [Python-Dev] PEP 446: Open issues/questions

Le Fri, 2 Aug 2013 13:30:56 +0200, Victor Stinner a écrit : > Is it possible to implement atfork on Windows? > > A Python lock would be ignored by other C threads. It is unsafe if > Python is embedded. It is unsafe if Python is embedded *and* the embedding application uses fork() + exec(). Rega

Re: [Python-Dev] PEP 446: Open issues/questions

Le Fri, 2 Aug 2013 02:27:43 +0200, Victor Stinner a écrit : > 2013/7/28 Antoine Pitrou : > >> (A) How should we support support where os.set_inheritable() is not > >> supported? Can we announce that os.set_inheritable() is always > >> available or not? Does such plat

Re: [Python-Dev] unittest.TestSuite holding references to unittest.TestCase instances too long

Le Fri, 2 Aug 2013 18:13:13 +0300, Michael Foord a écrit : > > On 2 Aug 2013, at 14:51, Matt McClure > wrote: > > > It seems unittest.TestSuite holds references to unittest.TestCase > > instances after the test runs, until the test suite finishes. In a > > large suite, where the TestCase instan

Re: [Python-Dev] Inherance of file descriptor and handles on Windows (PEP 446)

On Mon, 5 Aug 2013 14:56:06 +0200 Victor Stinner wrote: > 2013/7/27 Nick Coghlan : > >> Do we even need a new PEP, or should we just do it? Or can we adapt > >> Victor's PEP 446? > > > > Adapting the PEP sounds good - while I agree with switching to a sane > > default, I think the daemonisation th

Re: [Python-Dev] PEP 442 clarification for type hierarchies

Hi, On Sun, 04 Aug 2013 09:23:41 +0200 Stefan Behnel wrote: > > I'm currently catching up on PEP 442, which managed to fly completely below > my radar so far. It's a really helpful change that could end up fixing a > major usability problem that Cython was suffering from: user provided > deallo

Re: [Python-Dev] PEP 442 clarification for type hierarchies

On Sun, 04 Aug 2013 17:59:57 +0200 Stefan Behnel wrote: > > I continued my implementation and found that calling up the base type > > hierarchy is essentially the same code as calling up the hierarchy for > > tp_dealloc(), so that was easy to adapt to in Cython and is also more > > efficient than

Re: [Python-Dev] PEP 442 clarification for type hierarchies

On Mon, 05 Aug 2013 21:03:33 +0200 Stefan Behnel wrote: > I think the main problem I have with the PEP is this part: > > """ > The PEP doesn't change the semantics of: > * C extension types with a custom tp_dealloc function. > """ > > Meaning, it was designed to explicitly ignore this use case.

Re: [Python-Dev] PEP 442 clarification for type hierarchies

On Mon, 05 Aug 2013 21:32:54 +0200 Stefan Behnel wrote: > > >> Hmm, it seems to me by now that the only safe way of handling this is to > >> let each tp_dealloc() level in the hierarchy call tp_finalize() through > >> PyObject_CallFinalizerFromDealloc(), instead of calling up the stack in > >> tp

Re: [Python-Dev] PEP 442 clarification for type hierarchies

Le Mon, 05 Aug 2013 22:30:29 +0200, Stefan Behnel a écrit : > > Hmm, it's a bit unfortunate that tp_finalize() maps so directly to > __del__(), but I think this can be fixed. In any case, each > tp_finalize() function must only ever be called once, so if a subtype > inherited the tp_finalize() sl

Re: [Python-Dev] PEP 442 clarification for type hierarchies

Le Tue, 06 Aug 2013 17:18:59 +0200, Stefan Behnel a écrit : > Antoine Pitrou, 06.08.2013 14:12: > > Le Mon, 05 Aug 2013 22:30:29 +0200, > > Stefan Behnel a écrit : > >> > >> Hmm, it's a bit unfortunate that tp_finalize() maps so directly to > >> _

Re: [Python-Dev] PEP 442 clarification for type hierarchies

On Tue, 06 Aug 2013 18:38:51 +0200 Stefan Behnel wrote: > Antoine Pitrou, 06.08.2013 17:49: > > Le Tue, 06 Aug 2013 17:18:59 +0200, > > Stefan Behnel a écrit : > >> If a Python class with a > >> __del__ inherits from an extension type that implements > >

[Python-Dev] Our failure at handling GSoC students

Hello, I would like to point out that we currently fail at handling GSoC projects and bringing them to completion. One cruel example is the set of PEP 3121 / PEP 384 refactorings done by Robin Schreiber: http://bugs.python.org/issue?%40columns=id%2Cactivity%2Ctitle%2Ccreator%2Cassignee%2Cstatus%

Re: [Python-Dev] Our failure at handling GSoC students

On Tue, 6 Aug 2013 12:43:40 -0700 Eli Bendersky wrote: > On Tue, Aug 6, 2013 at 12:26 PM, Antoine Pitrou wrote: > > > > Hello, > > > > I would like to point out that we currently fail at handling GSoC > > projects and bringing them to completion. > > >

Re: [Python-Dev] The Return Of Argument Clinic

On Mon, 05 Aug 2013 16:53:39 -0700 Larry Hastings wrote: > > On 08/05/2013 02:55 AM, Nick Coghlan wrote: > > On 5 August 2013 18:48, Larry Hastings wrote: > >> Question 0: How should we integrate Clinic into the build process? > > Isn't solving the bootstrapping problem the reason for checking i

Re: [Python-Dev] a Constant addition to enum

On Tue, 6 Aug 2013 14:36:27 -0700 Eli Bendersky wrote: > On Tue, Aug 6, 2013 at 1:42 PM, Ethan Furman wrote: > > > A question came up on stackoverflow asking about the Planet example and > > the need to have the constant G defined in the method instead of at the > > class level: > > > > http://s

Re: [Python-Dev] Our failure at handling GSoC students

Le Wed, 07 Aug 2013 10:09:16 +0200, mar...@v.loewis.de a écrit : > > > Robin has produced many patches that seem to reach the stated goal > > (refactor C extension modules to take advantage of the latest PEPs > > about module initialization and extension types definition). > > Unfortunately, tackl

Re: [Python-Dev] PEP 442 clarification for type hierarchies

On Thu, 08 Aug 2013 06:08:55 +0200 Stefan Behnel wrote: > Stefan Behnel, 06.08.2013 18:38: > > Antoine Pitrou, 06.08.2013 17:49: > >> Le Tue, 06 Aug 2013 17:18:59 +0200, > >> Stefan Behnel a écrit : > >>> If a Python class with a > >>> __de

Re: [Python-Dev] xml.etree.ElementTree.IncrementalParser (was: ElementTree iterparse string)

Hi, Le Thu, 08 Aug 2013 06:33:42 +0200, Stefan Behnel a écrit : > [from python-ideas] > > Antoine Pitrou, 07.08.2013 08:04: > > Take a look at IncrementalParser: > > http://docs.python.org/dev/library/xml.etree.elementtree.html#incremental-parsing > > Hmm, that se

Re: [Python-Dev] xml.etree.ElementTree.IncrementalParser

Le Fri, 09 Aug 2013 13:11:11 +0200, Stefan Behnel a écrit : > > I attached it to the ticket that seems to have been the source of this > addition. > > http://bugs.python.org/issue17741 > > Please note that the tulip mailing list is not an appropriate place to > discuss additions to the XML libr

Re: [Python-Dev] Buildbot failure puzzle

On Sat, 10 Aug 2013 20:25:04 -0400 Terry Reedy wrote: > At least the following 3.4 buildbots have failed today with an error I > do not understand: AMD64 FreeBSD, PPC64, x86Ubuntu, x86 WinServer 2003. http://bugs.python.org/issue18706 ___ Python-Dev

Re: [Python-Dev] Strange artifacts with PEP 3121 and monkey-patching sys.modules (in csv, ElementTree and others)

On Sat, 10 Aug 2013 18:06:02 -0700 Eli Bendersky wrote: > This solution has problems. For example, in the case of ET it would > preclude testing what happens when pyexpat is disabled (remember we were > discussing this...). This is because there would be no real way to create > new instances of su

Re: [Python-Dev] Green buildbot failure.

On Sat, 10 Aug 2013 21:40:46 -0400 Terry Reedy wrote: > > This run recorded here shows a green test (it appears to have timed out) > http://buildbot.python.org/all/builders/x86%20Windows7%203.x/builds/7017 > but the corresponding log for this Windows bot > http://buildbot.python.org/all/builders/

Re: [Python-Dev] Strange artifacts with PEP 3121 and monkey-patching sys.modules (in csv, ElementTree and others)

Hi Eli, On Sat, 10 Aug 2013 17:12:53 -0700 Eli Bendersky wrote: > > Note how doing some sys.modules acrobatics and re-importing suddenly > changes the internal state of a previously imported module. This happens > because: > > 1. The first import of 'csv' (which then imports `_csv) creates > m

Re: [Python-Dev] Strange artifacts with PEP 3121 and monkey-patching sys.modules (in csv, ElementTree and others)

On Sun, 11 Aug 2013 12:33:16 +0200 Antoine Pitrou wrote: > So, the PEP 3121 "module state" pointer (the optional opaque void* > thing) should only be used to hold non-PyObjects. PyObjects should go > to the module dict, like they do in normal Python modules. Now, the &g

Re: [Python-Dev] Strange artifacts with PEP 3121 and monkey-patching sys.modules (in csv, ElementTree and others)

On Sun, 11 Aug 2013 07:04:40 -0400 Nick Coghlan wrote: > On 11 August 2013 06:33, Antoine Pitrou wrote: > > So code can be written like: > > > > PyObject *dialects = PyState_GetModuleAttr( > > &_csvmodule, "dialects", &PyDict_Type); >

Re: [Python-Dev] Strange artifacts with PEP 3121 and monkey-patching sys.modules (in csv, ElementTree and others)

On Sun, 11 Aug 2013 14:16:10 +0200 Stefan Behnel wrote: > > > We > > just need to devise a convenience API for that (perhaps by allowing to > > create both the subclass *and* instantiate it in a single call). > > Right. This conflicts somewhat with the simplified module creation. If the > module

Re: [Python-Dev] Strange artifacts with PEP 3121 and monkey-patching sys.modules (in csv, ElementTree and others)

On Sun, 11 Aug 2013 06:26:55 -0700 Eli Bendersky wrote: > On Sun, Aug 11, 2013 at 3:33 AM, Antoine Pitrou wrote: > > > > > Hi Eli, > > > > On Sat, 10 Aug 2013 17:12:53 -0700 > > Eli Bendersky wrote: > > > > > > Note how doing some sys.modu

Re: [Python-Dev] Strange artifacts with PEP 3121 and monkey-patching sys.modules (in csv, ElementTree and others)

On Sun, 11 Aug 2013 08:49:56 -0700 Eli Bendersky wrote: > On Sun, Aug 11, 2013 at 6:40 AM, Antoine Pitrou wrote: > > > On Sun, 11 Aug 2013 06:26:55 -0700 > > Eli Bendersky wrote: > > > On Sun, Aug 11, 2013 at 3:33 AM, Antoine Pitrou > > wrote: > > >

[Python-Dev] NULL allowed in PyErr_SetString and friends?

Hello, It seems NULL is allowed as the first argument of PyErr_Format, PyErr_SetString and PyErr_SetObject. Moreover, it means "clear the error indicator". However, this is not mentioned in the docs. I was wondering if we should officialize this behaviour or change it. Regards Antoine. __

Re: [Python-Dev] SSL issues in Python stdlib and 3rd party code

Hi, On Mon, 12 Aug 2013 19:18:17 +0200 Christian Heimes wrote: > related issue: Mozilla's certdata.txt and CKT_NSS_MUST_VERIFY_TRUST > - --- > > Recently I found bugs in curl's mk-ca-bundle.pl script, its cacert.pem > and in the CA

Re: [Python-Dev] Deprecating the formatter module

On Mon, 12 Aug 2013 14:22:01 -0700 Eli Bendersky wrote: > On Mon, Aug 12, 2013 at 12:22 PM, Brett Cannon wrote: > > > At the PyCon CA sprint someone discovered the formatter module had > > somewhat low code coverage. We discovered this is because it's tested by > > test_sundry, i.e. it's tested

Re: [Python-Dev] cpython (merge 2.7 -> 2.7): Clean merge

On Tue, 13 Aug 2013 00:42:25 +0300 Ezio Melotti wrote: > > To avoid these big merges you can do: > # check the two heads that you are going to merge and their csids > hg heads . > # update to the other head (the one you pulled, not the one you committed) > hg up csid-of-the-other-head > # merge y

Re: [Python-Dev] Dealing with import lock deadlock in Import Hooks

On Tue, 13 Aug 2013 11:06:51 +0900 Arnaud Fontaine wrote: > Hi, > > Armin Rigo writes: > > On Mon, Aug 12, 2013 at 9:39 AM, Arnaud Fontaine > > wrote: > >> Thread 1 is trying to import a module 'foo.bar' (where 'foo' is a > >> package containing dynamic modules) handled by Import Hooks I >

Re: [Python-Dev] Dealing with import lock deadlock in Import Hooks

Le Tue, 13 Aug 2013 17:28:42 +0900, Arnaud Fontaine a écrit : > Antoine Pitrou writes: > > On Tue, 13 Aug 2013 11:06:51 +0900 Arnaud Fontaine > > wrote: > >> I suggested the same in my initial email, but I was wondering if > >> there could be any issue by relea

Re: [Python-Dev] Dealing with import lock deadlock in Import Hooks

Le Wed, 14 Aug 2013 14:17:59 +0900, Arnaud Fontaine a écrit : > Antoine Pitrou writes: > > > Le Tue, 13 Aug 2013 17:28:42 +0900, Arnaud Fontaine > > a écrit : > >> Yes. Actually, I was thinking about implementing something similar > >> to what has been d

Re: [Python-Dev] Deprecating the formatter module

Le Wed, 14 Aug 2013 11:08:29 -0400, Brett Cannon a écrit : > > > > You know, there may be one or two Python programmers who didn't go > > to PyCon CA... :-) > > > > Sure, but you would assume at least *one* person would have known of > the module in a room of sprinters. Not necessarily. There ar

Re: [Python-Dev] Deprecating the formatter module

On Thu, 15 Aug 2013 11:28:52 +1000 Steven D'Aprano wrote: > > These are all very good arguments, for both sides, and it is a balance > between code churn and bit rot, but on balance I'm going to come down firmly > in favour of Nick's earlier recommendation: PendingDeprecation (and/or a move >

Re: [Python-Dev] Deprecating the formatter module

On Thu, 15 Aug 2013 11:16:20 +0200 Victor Stinner wrote: > 2013/8/15 Antoine Pitrou : > > We don't have any substantial change in store for an eventual "Python > > 4", so it's quite a remote hypothesis right now. > > I prefered the transition between Lin

Re: [Python-Dev] When to remove deprecated stuff (was: Deprecating the formatter module)

On Thu, 15 Aug 2013 08:29:35 -0400 "R. David Murray" wrote: > On Thu, 15 Aug 2013 11:22:14 +0200, Antoine Pitrou > wrote: > > On Thu, 15 Aug 2013 11:16:20 +0200 > > Victor Stinner wrote: > > > 2013/8/15 Antoine Pitrou : > > > > We don'

Re: [Python-Dev] PEP 450 adding statistics module

On Thu, 15 Aug 2013 14:24:50 -0400 "R. David Murray" wrote: > On Thu, 15 Aug 2013 14:10:39 -0400, "Eric V. Smith" > wrote: > > On 08/15/2013 01:58 PM, Mark Dickinson wrote: > > > On Thu, Aug 15, 2013 at 2:08 PM, Steven D'Aprano > > > wrote: > > > > > > > > > -

Re: [Python-Dev] PEP 450 adding statistics module

On Fri, 16 Aug 2013 12:44:54 +1000 Steven D'Aprano wrote: > On 16/08/13 04:10, Eric V. Smith wrote: > > > I agree with Mark: the proposed median, median.low, etc., doesn't feel > > right. Is there any example of doing this in the stdlib? > > The most obvious case is datetime: we have datetime()

Re: [Python-Dev] Tracker meta-issue

On Sun, 18 Aug 2013 03:02:28 +1000 Steven D'Aprano wrote: > Is this the right place to request somebody look at an issue in the > meta-tracker? > > http://psf.upfronthosting.co.za/roundup/meta/issue517 Officially, I suppose the "right place" should be the tracker-discuss mailing-list, but both

Re: [Python-Dev] cpython: Use a known unique object for the dummy entry.

On Sat, 17 Aug 2013 11:32:00 +0200 (CEST) raymond.hettinger wrote: > http://hg.python.org/cpython/rev/2c9a2b588a89 > changeset: 85218:2c9a2b588a89 > user:Raymond Hettinger > date:Sat Aug 17 02:31:53 2013 -0700 > summary: > Use a known unique object for the dummy entry. > > T

Re: [Python-Dev] cpython: Use a known unique object for the dummy entry.

On Sun, 18 Aug 2013 09:03:56 +0200 Armin Rigo wrote: > Hi, > > On Sat, Aug 17, 2013 at 8:42 PM, Antoine Pitrou wrote: > >> summary: > >> Use a known unique object for the dummy entry. > > Another issue with this change: the dummy object should be of a dum

Re: [Python-Dev] cpython: Use a known unique object for the dummy entry.

On Sun, 18 Aug 2013 17:31:24 +0100 Mark Shannon wrote: > > By giving the dummy object a custom type, the dummy object can be > recognised by testing that its type equals PySetDummy_Type (or > whatever it is called) > > See dictobject.c for an implementation of a suitable dummy object. The most

Re: [Python-Dev] Status of 3.2 in Hg repository?

Hi Tim, Le Mon, 19 Aug 2013 23:25:58 -0500, Tim Peters a écrit : > > hg log -r 3.2 > changeset: 83826:b9b521efeba3 > branch: 3.2 > parent: 83739:6255b40c6a61 > user:Antoine Pitrou > date:Sat May 18 17:56:42 2013 +0200 > summary: Issue #1

Re: [Python-Dev] Status of 3.2 in Hg repository?

On Tue, 20 Aug 2013 13:16:05 -0400 "R. David Murray" wrote: > On Tue, 20 Aug 2013 10:43:57 -0500, Tim Peters wrote: > > [Tim] > > >> > hg log -r 3.2 > > >> changeset: 83826:b9b521efeba3 > > >> branch: 3.2 > > >&

Re: [Python-Dev] Status of 3.2 in Hg repository?

On Tue, 20 Aug 2013 12:47:46 -0500 Tim Peters wrote: > > [Antoine] > > Ah, now I remember indeed: > > http://mail.python.org/pipermail/python-committers/2013-May/002580.html > > Which says: > > I asked about this on IRC and was told that 3.2 is now a > standalone branch like 2.7. Secur

Re: [Python-Dev] When to remove deprecated stuff

Le Thu, 22 Aug 2013 14:00:06 +0300, Petri Lehtinen a écrit : > Terry Reedy wrote: > > On 8/15/2013 8:29 AM, R. David Murray wrote: > > > > >A number of us (I don't know how many) have clearly been thinking > > >about "Python 4" as the time when we remove cruft. This will not > > >cause any backw

Re: [Python-Dev] Pre-PEP: Redesigning extension modules

Hi, Le Fri, 23 Aug 2013 10:50:18 +0200, Stefan Behnel a écrit : > > Here's an initial attempt at a PEP for it. It is based on the > (unfinished) ModuleSpec PEP, which is being discussed on the > import-sig mailing list. Thanks for trying this. I think the PEP should contain working example cod

Re: [Python-Dev] please back out changeset f903cf864191 before alpha-2

On Sat, 24 Aug 2013 00:57:48 +0200 Stefan Behnel wrote: > Hi, > > ticket 17741 has introduced a new feature in the xml.etree.ElementTree > module that was added without any major review. > > http://bugs.python.org/issue17741 As I've already indicated on the tracker, I'm completely saturated wit

Re: [Python-Dev] please back out changeset f903cf864191 before alpha-2

On Sat, 24 Aug 2013 15:57:50 +1000 Nick Coghlan wrote: > On 24 August 2013 15:32, Stefan Behnel wrote: > > So, to put it more nicely, I think this feature was added without the > > amount of review that it needs, and now that I've given it that review, I'm > > asking for removal of the feature an

Re: [Python-Dev] Pre-PEP: Redesigning extension modules

On Sat, 24 Aug 2013 21:36:51 +1000 Nick Coghlan wrote: > On 24 August 2013 15:51, Nick Coghlan wrote: > > My current plan is to create an experimental prototype of this > > approach this weekend. That will include stdlib test cases, so it will > > also show how it looks from the extension develop

Re: [Python-Dev] please back out changeset f903cf864191 before alpha-2

On Sat, 24 Aug 2013 14:46:32 +0200 Stefan Behnel wrote: > > As I said, the only reason why the current implementation is there is > "because it's there". No. It works, it's functional, it fills an use case, and it doesn't seem to have any concrete issues. Get over it, Stefan, and stop trolling

Re: [Python-Dev] Pre-PEP: Redesigning extension modules

On Sat, 24 Aug 2013 14:51:42 +0200 Stefan Behnel wrote: > Antoine Pitrou, 24.08.2013 13:53: > > This would also imply extension module have to be subclasses of the > > built-in module type. They can't be arbitrary objects like Stefan > > proposed. I'm not sure

Re: [Python-Dev] please back out changeset f903cf864191 before alpha-2

On Sun, 25 Aug 2013 00:03:01 +1000 Nick Coghlan wrote: > If Stefan's "please revert this" as lxml.etree maintainer isn't > enough, then I'm happy to add a "please revert this" as a core > committer that is confused about how and when the new tulip-inspired > incremental parsing API should be used

Re: [Python-Dev] please back out changeset f903cf864191 before alpha-2

Le Sat, 24 Aug 2013 14:42:24 -0400, Terry Reedy a écrit : > > > > And these for IncrementalParser: > > > > data_received(data) > > Feed the given bytes data to the incremental parser. > > Longer, awkward, and to me ugly in comparison to 'feed'. Since it > seems to mean more or less

Re: [Python-Dev] please back out changeset f903cf864191 before alpha-2

Le Mon, 26 Aug 2013 08:24:58 -0400, Tres Seaver a écrit : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 08/26/2013 04:36 AM, Antoine Pitrou wrote: > > event-driven processing using network librarie > > Maybe I missed something: why should considerations fro

Re: [Python-Dev] please back out changeset f903cf864191 before alpha-2

Le Mon, 26 Aug 2013 17:44:41 +0200, Simon Cross a écrit : > On Mon, Aug 26, 2013 at 2:51 PM, Antoine Pitrou > wrote: > > Because this API is mostly useful when the data is received (*) at a > > slow enough speed - which usually means from the network, not from a > > h

Re: [Python-Dev] please back out changeset f903cf864191 before alpha-2

Le Mon, 26 Aug 2013 09:14:38 -0700, Eli Bendersky a écrit : > > Antoine, you opted out of the tracker issue but I feel it's fair to > let you know that after a lot of discussion with Nick and Stefan (*), > we've settled on renaming the input methods to feed & close, and the > output method to rea

Re: [Python-Dev] please back out changeset f903cf864191 before alpha-2

Le Tue, 27 Aug 2013 09:58:57 +0200, Simon Cross a écrit : > On Mon, Aug 26, 2013 at 5:57 PM, Antoine Pitrou > wrote: > > What do you mean, "all events have to be ready"? > > If you look at the unit tests, the events are generated on-the-fly, > > not at the end

Re: [Python-Dev] hg.python.org is slow

Le Tue, 27 Aug 2013 08:00:09 +0200, Charles-François Natali a écrit : > Hi, > > I'm trying to checkout a pristine clone from > ssh://h...@hg.python.org/cpython, and it's taking forever: > """ > 07:45:35.605941 IP 192.168.0.23.43098 > > virt-7yvsjn.psf.osuosl.org.ssh: Flags [.], ack 22081460, win

Re: [Python-Dev] hg.python.org is slow

Le Tue, 27 Aug 2013 10:37:00 +0200, Charles-François Natali a écrit : > 2013/8/27 Antoine Pitrou : > > Sounds a lot like a network problem, then? > > If I'm the only one, it's likely, although these pathological timeouts > are transient, and I don't have a

Re: [Python-Dev] please back out changeset f903cf864191 before alpha-2

On Mon, 26 Aug 2013 23:45:55 -0400 Scott Dial wrote: > On 8/26/2013 8:51 AM, Antoine Pitrou wrote: > > Le Mon, 26 Aug 2013 08:24:58 -0400, > > Tres Seaver a écrit : > >> On 08/26/2013 04:36 AM, Antoine Pitrou wrote: > >>> event-driven processing using networ

Re: [Python-Dev] PEP 446 (make FD non inheritable) ready for a final review

Hi, I have a small comment to make: > On UNIX, the subprocess module closes almost all file descriptors in > the child process. This operation requires MAXFD system calls, where > MAXFD is the maximum number of file descriptors, even if there are > only few open file descriptors. This maximum ca

Re: [Python-Dev] cpython: Issue #18571: Implementation of the PEP 446: file descriptors and file handles

Hi, On Wed, 28 Aug 2013 01:20:56 +0200 (CEST) victor.stinner wrote: > http://hg.python.org/cpython/rev/ef889c3d5dc6 > changeset: 85420:ef889c3d5dc6 > user:Victor Stinner > date:Wed Aug 28 00:53:59 2013 +0200 > summary: > Issue #18571: Implementation of the PEP 446: file desc

Re: [Python-Dev] cpython: Issue #18571: Implementation of the PEP 446: file descriptors and file handles

On Wed, 28 Aug 2013 21:43:00 +0200 Victor Stinner wrote: > 2013/8/28 Antoine Pitrou : > > I don't want to sound too demanding, but was this patch actually > > reviewed? I can't find a single review comment in > > http://bugs.python.org/issue18571 > > No, it

Re: [Python-Dev] devguide: Issue #18871: make it more explicit that the test suite should be run before

On Wed, 28 Aug 2013 20:05:25 -0400 Terry Reedy wrote: > On 8/28/2013 5:51 PM, antoine.pitrou wrote: > > > +Does the test suite still pass? > > There are several assumptions packed in that question. > > 0. The test suite is relevant to the patch. > > Not true for doc patches, some idlelib patch

Re: [Python-Dev] Coverity Scan Spotlight Python

On Fri, 30 Aug 2013 00:10:27 +0200 Christian Heimes wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Hello, > > Coverity has published its "Coverity Scan Spotlight Python" a couple > of hours ago. It features a summary of Python's ecosystem, an > interview with me about Python core

Re: [Python-Dev] Add function to signal module for getting main thread id

Le Fri, 30 Aug 2013 12:24:07 +0300, Andrew Svetlov a écrit : > Main thread is slightly different from others. > Signals can be subscribed from main thread only. > Tulip has special logic for main thread. > In application code we can explicitly know which thread is executed, > main or not. > But f

Re: [Python-Dev] Add function to signal module for getting main thread id

Le Fri, 30 Aug 2013 12:24:07 +0300, Andrew Svetlov a écrit : > Main thread is slightly different from others. > Signals can be subscribed from main thread only. > Tulip has special logic for main thread. > In application code we can explicitly know which thread is executed, > main or not. > But f

Re: [Python-Dev] Add function to signal module for getting main thread id

Le Fri, 30 Aug 2013 11:36:57 +0200, Victor Stinner a écrit : > > If we expose the identifier of the main thread, something should be > added to the threading module, not the signal module. Agreed. > Is it possible that the main thread exit while there are still other > live threads? "exit" in

Re: [Python-Dev] Add function to signal module for getting main thread id

Le Fri, 30 Aug 2013 22:09:37 +1000, Nick Coghlan a écrit : > On 30 August 2013 20:27, Andrew Svetlov > wrote: > > I've filed http://bugs.python.org/issue18882 for this. > > I don't actually object to the addition, but is there any way that > "threading.enumerate()[0]" *won't* be the main thread?

Re: [Python-Dev] Add function to signal module for getting main thread id

Le Fri, 30 Aug 2013 14:06:11 +0200, Christian Heimes a écrit : > Am 30.08.2013 11:39, schrieb Antoine Pitrou: > > > > Le Fri, 30 Aug 2013 12:24:07 +0300, > > Andrew Svetlov a écrit : > >> Main thread is slightly different from others. > >> Signals

Re: [Python-Dev] EINTR handling...

On Fri, 30 Aug 2013 12:29:12 +0200 Charles-François Natali wrote: > > Furthermore, the stdlib code base is not consistent: some code paths > handle EINTR, e.g. subprocess, multiprocessing, sock_sendall() does > but not sock_send()... > Just grep for EINTR and InterruptedError and you'll be amazed

Re: [Python-Dev] cpython: Issue #17741: Rename IncrementalParser and its methods.

Hello, On Fri, 30 Aug 2013 14:51:42 +0200 (CEST) eli.bendersky wrote: > diff --git a/Doc/library/xml.etree.elementtree.rst > b/Doc/library/xml.etree.elementtree.rst > --- a/Doc/library/xml.etree.elementtree.rst > +++ b/Doc/library/xml.etree.elementtree.rst > @@ -105,37 +105,42 @@ > >>> root

Re: [Python-Dev] error in test suite

On Sat, 31 Aug 2013 10:23:27 -0700 Ethan Furman wrote: > Am I the only one experiencing this? http://bugs.python.org/issue11798 perhaps? Regards Antoine. > 262 tests OK. > 93 tests failed: > test___all__ test_abc test_array test_ast test_asynchat > test_asyncore test_bisect test_buf

Re: [Python-Dev] Pre-PEP: Redesigning extension modules

On Sat, 31 Aug 2013 21:16:10 +0200 Stefan Behnel wrote: > > Our experience is very different - my perspective is that the normal case > > either eschews C level global state in the extension module, because it > > causes so many problems, or else just completely ignores subinterpreter > > support

Re: [Python-Dev] Pre-PEP: Redesigning extension modules

On Sun, 1 Sep 2013 11:28:36 +1000 Nick Coghlan wrote: > * PEP 3121 with a size of "0". As above, but avoids the module state APIs > in order to support reloading. All module state (including type > cross-references) is stored in hidden state (e.g. an instance of a custom > type not exposed to Pyth

Re: [Python-Dev] Pre-PEP: Redesigning extension modules

On Mon, 2 Sep 2013 00:10:08 +1000 Nick Coghlan wrote: > > $ ./python > Python 3.4.0a1+ (default:575071257c92+, Aug 25 2013, 00:42:17) > [GCC 4.7.2 20121109 (Red Hat 4.7.2-8)] on linux > Type "help", "copyright", "credits" or "license" for more information. > >>> import atexit > >>> atexit.registe

Re: [Python-Dev] 'Subinterpreter' (was Re: Pre-PEP: Redesigning extension modules)

On Sun, 01 Sep 2013 16:02:33 -0400 Terry Reedy wrote: > > > Speaking of which, it also doesn't work (well) with subinterpreters: > > Could someone briefly explain 'subinterpreter' or point me somewhere in > the docs? It appears throughout this thread but there is no index or > glossary entry.

Re: [Python-Dev] cpython (merge 3.3 -> default): Merge fix from 3.3 into default.

On Sun, 1 Sep 2013 23:02:17 +0200 (CEST) tim.peters wrote: > http://hg.python.org/cpython/rev/25211a8b > changeset: 85495:25211a8b > parent: 85493:267e09700978 > parent: 85494:8efcf3c823f9 > user:Tim Peters > date:Sun Sep 01 16:01:46 2013 -0500 > summary: >

Re: [Python-Dev] Pre-PEP: Redesigning extension modules

Le Sun, 1 Sep 2013 02:19:48 +1000, Nick Coghlan a écrit : > On 1 Sep 2013 00:10, "Stefan Behnel" wrote: > > > > *bump* > > > > Does this sound like a viable solution? > > This isn't likely to progress until we have Eric's PEP 451 to a point > where it's ready for python-dev discussion and pronou

Re: [Python-Dev] Add a new tracemalloc module to trace memory allocations

Le Sun, 1 Sep 2013 11:36:51 +1000, Nick Coghlan a écrit : > +1 from me for both tracemalloc and failmalloc in the same vein as > faulthandler (and using similar API concepts to faulthandler). > > While I like the flat top level naming structure, we should clearly > document these as implementatio

Re: [Python-Dev] SEEK_* constants in io and os

Le Sun, 1 Sep 2013 18:02:30 -0700, Eli Bendersky a écrit : > Hello, > > I was looking at the possibility of replacing the SEEK_* constants by > IntEnums, and the first thing that catches attention is that these > constants are defined in both Lib/os.py and Lib/io.py; both places > also recently s

Re: [Python-Dev] SEEK_* constants in io and os

Le Mon, 2 Sep 2013 06:18:31 -0700, Eli Bendersky a écrit : > On Mon, Sep 2, 2013 at 1:24 AM, Antoine Pitrou > wrote: > > > Le Sun, 1 Sep 2013 18:02:30 -0700, > > Eli Bendersky a écrit : > > > Hello, > > > > > > I was looking at the possib

Re: [Python-Dev] SEEK_* constants in io and os

Le Mon, 2 Sep 2013 15:45:22 +0200, Antoine Pitrou a écrit : > Le Mon, 2 Sep 2013 06:18:31 -0700, > Eli Bendersky a écrit : > > On Mon, Sep 2, 2013 at 1:24 AM, Antoine Pitrou > > wrote: > > > > > Le Sun, 1 Sep 2013 18:02:30 -0700, > > > Eli Bendersky

Re: [Python-Dev] Offtopic: OpenID Providers

On Thu, 05 Sep 2013 19:31:59 +0200 Jesus Cea wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > I just received an email from my OpenID provider, "myOpenID", saying > that they drop OpenID service next February. I wonder what other > OpenID providers are used by other python-dev fellows

Re: [Python-Dev] Offtopic: OpenID Providers

On Thu, 5 Sep 2013 14:50:44 -0400 Donald Stufft wrote: > > On Sep 5, 2013, at 2:43 PM, Oleg Broytman wrote: > > > On Thu, Sep 05, 2013 at 02:35:16PM -0400, Donald Stufft > > wrote: > >> Persona is the logical successor to OpenID. > > > > OpenID lived a short life and died a quiet death. I'

Re: [Python-Dev] Offtopic: OpenID Providers

On Thu, 05 Sep 2013 19:31:59 +0200 Jesus Cea wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > I just received an email from my OpenID provider, "myOpenID", saying > that they drop OpenID service next February. I wonder what other > OpenID providers are used by other python-dev fellows

Re: [Python-Dev] Offtopic: OpenID Providers

On Thu, 5 Sep 2013 15:40:44 -0400 Barry Warsaw wrote: > On Sep 05, 2013, at 09:07 PM, Antoine Pitrou wrote: > > >Which sites exactly? I can login to BitBucket and *.python.org using > >OpenID, not Persona. > > I think Persona is just too new to see it around much yet.

Re: [Python-Dev] Pre-PEP: Redesigning extension modules

On Thu, 5 Sep 2013 23:26:31 -0600 Eric Snow wrote: > On Sat, Aug 24, 2013 at 7:07 AM, Stefan Behnel wrote: > > > PEP 3121 would no longer be necessary. Extension types can do all we need. > > No more special casing of modules, that was the idea. > > > > One nice thing about PEP 3121 is the addi

<    11   12   13   14   15   16   17   18   19   20   >