Re: [Python-Dev] windows file closing race condition?

On Fri, 06 Sep 2013 06:50:07 +0100 Chris Withers wrote: > > So, from my perspective, I'm either looking at a bug in shutil.rmtree > (which would be trying to delete a directory before deleting its content > or failing to delete a file but ignoring an error) or the file object, > when being use

Re: [Python-Dev] windows file closing race condition?

Le Fri, 06 Sep 2013 08:58:06 +0100, Tim Golden a écrit : > > What should Python do? Maybe using FILE_SHARE_DELETE could help? http://bugs.python.org/issue15244 Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.o

Re: [Python-Dev] DTRACE support

Le Fri, 06 Sep 2013 17:08:23 +0200, Jesus Cea a écrit : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > As far as I know, Erlang, Ruby, PHP, Perl, etc., support Dtrace. > Python is embarrasingly missing from this list. > > Some examples: > >

Re: [Python-Dev] Details of "import lock" in 3.3

On Fri, 06 Sep 2013 18:02:32 +0200 Jesus Cea wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 06/09/13 17:43, Antoine Pitrou wrote: > > Quick summary here: > > http://docs.python.org/3/whatsnew/3.3.html#a-finer-grained-import-lock > > > > O

Re: [Python-Dev] DTRACE support

On Fri, 06 Sep 2013 18:14:26 +0200 Jesus Cea wrote: > > > Right now, I agree with Charles-François: your patch is too > > intrusive. > > It is intrusive. Yes. I think it must be, by its own nature. Probably > room for improvement and code transparency. But... are Python-DEVs > interested in the

Re: [Python-Dev] DTRACE support

On Fri, 06 Sep 2013 18:14:26 +0200 Jesus Cea wrote: > > It is intrusive. Yes. I think it must be, by its own nature. Probably > room for improvement and code transparency. But... are Python-DEVs > interested in the project?. That is the point :) As a concrete data point: - here are Dave's modifi

Re: [Python-Dev] inspect and metaclasses

On Fri, 06 Sep 2013 08:14:09 -0700 Ethan Furman wrote: > On 09/06/2013 07:47 AM, Armin Rigo wrote: > > > > Are you suggesting that inspect.getmro(A) would return (A, object, > > type)? That seems very wrong to me. > > Currently, `inspect.getmro(A)` returns `(A, object)`. > > Considering that Py

Re: [Python-Dev] Details of "import lock" in 3.3

Le Fri, 06 Sep 2013 17:08:28 +0200, Jesus Cea a écrit : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > With importlib and other recent changes, what are the current details > of "import lock"?. That is, the lock/locks held when Python code does > "import", specially in the case of multithr

Re: [Python-Dev] DTRACE support

On Sat, 7 Sep 2013 08:57:07 +0200 Xavier Morel wrote: > > On 2013-09-07, at 05:40 , Jesus Cea wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > On 06/09/13 20:33, Antoine Pitrou wrote: > >> On Fri, 06 Sep 2013 18:14:26 +0200 Jesu

Re: [Python-Dev] cpython: Issue #18904: test_socket: add inheritance tests using fcntl and FD_CLOEXEC

On Sun, 8 Sep 2013 11:54:00 +0200 (CEST) victor.stinner wrote: > http://hg.python.org/cpython/rev/b7f6f6f59e91 > changeset: 85619:b7f6f6f59e91 > user:Victor Stinner > date:Sun Sep 08 11:53:09 2013 +0200 > summary: > Issue #18904: test_socket: add inheritance tests using fcntl

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

On Sat, 31 Aug 2013 12:58:39 +1000 Steven D'Aprano wrote: > Hi all, > > > I think that PEP 450 is now ready for a PEP dictator. Perhaps Mark would like to apply? Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.pyth

Re: [Python-Dev] PEP 447: add type.__locallookup__

On Mon, 09 Sep 2013 09:05:57 -0700 Ethan Furman wrote: > On 09/09/2013 08:43 AM, Mark Shannon wrote: > > I would like time to investigate this further, but at the moment I think it > > will either make attribute lookup poorly > > defined or slow. > > > > Of the top of my head, the problem as a I

Re: [Python-Dev] cpython (2.7): Clarify mmap.close method behavior. Addresses issue #18815

On Tue, 10 Sep 2013 07:40:21 +0200 (CEST) senthil.kumaran wrote: > http://hg.python.org/cpython/rev/443d12b61e5b > changeset: 85653:443d12b61e5b > branch: 2.7 > parent: 85639:740bd510a888 > user:Senthil Kumaran > date:Mon Sep 09 22:38:58 2013 -0700 > summary: > Clari

Re: [Python-Dev] Offtopic: OpenID Providers

Ok, can this discussion go off python-dev, please? This has been terribly off-topic for a long time (arguably from the beginning, actually). Thank you Antoine. Le Tue, 10 Sep 2013 00:21:28 -0700, Glenn Linderman a écrit : > On 9/6/2013 10:22 AM, Dan Callahan wrote: > > On 9/5/13 12:31 PM, Je

[Python-Dev] Add a "transformdict" to collections

Hello, In http://bugs.python.org/issue18986 I proposed adding a new mapping type to the collections module. The original use case is quite common in network programming and elsewhere (Eric Snow on the tracker mentioned an application with stock symbols). You want to have an associative container

Re: [Python-Dev] Add a "transformdict" to collections

Le Tue, 10 Sep 2013 04:42:46 -0500, Skip Montanaro a écrit : > > (case-insensitive but case-preserving, as the best filesystems > > are ;-)) > > > I have a sweet spot for "transformdict" myself. > > Antoine, > > "Transform" does not remind me of "case-insensitive but > case-preserving". That w

Re: [Python-Dev] Add a "transformdict" to collections

Le Tue, 10 Sep 2013 22:00:37 +1000, Nick Coghlan a écrit : > Is this just syntactic sugar for recursive lookup of a transformed > version in __missing__? Nope. For one, it doesn't use __missing__ at all. I think using __missing__ would be... missing the point, because it wouldn't working properly

Re: [Python-Dev] Add a "transformdict" to collections

Le Tue, 10 Sep 2013 13:24:29 +0100, Paul Moore a écrit : > On 10 September 2013 13:00, Nick Coghlan wrote: > > Is this just syntactic sugar for recursive lookup of a transformed > > version in __missing__? Or a way of supplying a custom "key" > > function to a dictionary? > > Not quite, because

Re: [Python-Dev] Add a "transformdict" to collections

Le Tue, 10 Sep 2013 09:49:28 -0400, Barry Warsaw a écrit : > On Sep 10, 2013, at 12:04 PM, Victor Stinner wrote: > > >The http.client and email.message modules convert headers to lower > >case, but keep the original case. > > As RDM pointed out on the tracker, email headers aren't a great use >

Re: [Python-Dev] Add a "transformdict" to collections

Le Tue, 10 Sep 2013 07:18:41 -0700, Eli Bendersky a écrit : > On Tue, Sep 10, 2013 at 5:22 AM, Antoine Pitrou > wrote: > > > Le Tue, 10 Sep 2013 22:00:37 +1000, > > Nick Coghlan a écrit : > > > Is this just syntactic sugar for recursive lookup of a transforme

Re: [Python-Dev] Add a "transformdict" to collections

Le Tue, 10 Sep 2013 15:09:56 +0200, Hrvoje Niksic a écrit : > On 09/10/2013 02:24 PM, Paul Moore wrote: > td['FOO'] = 42 > td['foo'] = 32 > list(td.keys()) > > > > ['FOO'] or ['foo']? Both answers are justifiable. > > Note that the same question can be reasonably asked for dict its

Re: [Python-Dev] Add a "transformdict" to collections

Le Tue, 10 Sep 2013 16:15:56 +0200, Armin Rigo a écrit : > Hi Richard, > > On Tue, Sep 10, 2013 at 3:42 PM, Richard Oudkerk > wrote: > > I guess another example is creating an "identity dict" (see > > http://code.activestate.com/lists/python-ideas/7161/) by doing > > > > d = transformdict(id

Re: [Python-Dev] Add a "transformdict" to collections

On Tue, 10 Sep 2013 14:44:01 +0200 "Martin v. Löwis" wrote: > Am 10.09.13 14:35, schrieb Antoine Pitrou: > >> ['FOO'] or ['foo']? Both answers are justifiable. Both are possibly > >> even useful depending on context... > > > > I

Re: [Python-Dev] Add a "transformdict" to collections

On Tue, 10 Sep 2013 17:38:26 -0300 "Joao S. O. Bueno" wrote: > On 10 September 2013 16:08, Paul Moore wrote: > > If you provide "retain the last", I can't see any obvious way of > > implementing "retain the first" in application code without in effect > > reimplementing the class. > > Which remi

Re: [Python-Dev] Add a "transformdict" to collections

On Tue, 10 Sep 2013 18:44:20 -0300 "Joao S. O. Bueno" wrote: > On 10 September 2013 18:06, Antoine Pitrou wrote: > > On Tue, 10 Sep 2013 17:38:26 -0300 > > "Joao S. O. Bueno" wrote: > >> On 10 September 2013 16:08, Paul Moore wrote: > >>

Re: [Python-Dev] Add a "transformdict" to collections

Le Tue, 10 Sep 2013 21:40:36 -0500, Raymond Hettinger a écrit : > > On Sep 10, 2013, at 4:28 AM, Antoine Pitrou > wrote: > > > In http://bugs.python.org/issue18986 I proposed adding a new mapping > > type to the collections module. > > I would *really* like

Re: [Python-Dev] Add a "transformdict" to collections

Le Wed, 11 Sep 2013 12:38:13 +0300, Serhiy Storchaka a écrit : > 2. Subclassing. > > class CaseInsensitiveDict(TransformDict): > def transform(self, key): > return key.casefold() > d = CaseInsensitiveDict(Foo=5) I thought about this first, and then I remembered that python-dev isn'

Re: [Python-Dev] Add a "transformdict" to collections

Le Wed, 11 Sep 2013 13:37:53 +0300, Serhiy Storchaka a écrit : > > Actually the defaultdict is just simple wrapper around existing > functionality of the __missing__ method. We can add the __transform__ > method directly in the dict class. I think it will significant (2-3x) > decrease a size o

Re: [Python-Dev] Need testing audio files

Le Wed, 11 Sep 2013 13:09:36 +0300, Serhiy Storchaka a écrit : > I work on enhancement of audio modules testing [1], and I need free > (in both senses) small sample audio files in different formats. We > already have audiotest.au (mono, and sunau has a bug in processing > multichannel files [2]) a

Re: [Python-Dev] Add a "transformdict" to collections

Le Wed, 11 Sep 2013 22:47:12 +1000, Nick Coghlan a écrit : > > I'll join the chorus requesting that this live on PyPI for a while > first. > > I think this is a case similar to what happened with > contextlib.ExitStack: I'm not sure if anyone actually *used* > contextlib2 for anything significan

Re: [Python-Dev] Add a "transformdict" to collections

Le Wed, 11 Sep 2013 22:50:08 +0900, "Stephen J. Turnbull" a écrit : > Antoine Pitrou writes: > > > ExitStack was quite a new thing, API-wise. The proposal here is to > > generalize something which already exists in various forms all > > over the Interne

Re: [Python-Dev] Add a "transformdict" to collections

Le Wed, 11 Sep 2013 07:48:56 -0700, Ethan Furman a écrit : > On 09/11/2013 06:58 AM, Victor Stinner wrote: > > > > The os.environ mapping uses a subclass of MutableMapping which > > accepts 4 functions: encoder/decoder for the key and encoder/decoder > > for the value. Such type is even more gener

Re: [Python-Dev] Add a "transformdict" to collections

On Wed, 11 Sep 2013 19:31:56 +0200 "Martin v. Löwis" wrote: > Am 11.09.13 15:04, schrieb Antoine Pitrou: > > There are not many possible APIs to create case-insensitive dicts, or > > identity dicts. > > That is certainly not true. Most obviously, you have the

Re: [Python-Dev] cpython (merge 3.3 -> default): merge from 3.3

On Thu, 12 Sep 2013 07:57:25 +0200 (CEST) senthil.kumaran wrote: > > +<<< local > Optional argument random is a 0-argument function returning a > random float in [0.0, 1.0); if it is the default None, the > standard random.random will be used. > +=== > +

Re: [Python-Dev] Add a "transformdict" to collections

Le Thu, 12 Sep 2013 07:08:47 -0700, Ethan Furman a écrit : > On 09/11/2013 02:39 PM, Tim Delaney wrote: > > > > I would think that retrieving the keys from the dict would return > > the transformed keys (I'd call them canonical keys). > > The more I think about this the more I agree. A canonical

Re: [Python-Dev] Add a "transformdict" to collections

Le Thu, 12 Sep 2013 08:05:44 -0700, Ethan Furman a écrit : > On 09/12/2013 07:43 AM, Antoine Pitrou wrote: > > > > Yeah, so this is totally silly. What you're basically saying is "we > > don't need TransformDict since people can re-implement it > > the

[Python-Dev] PEP 455: TransformDict

tionary to collections Version: $Revision$ Last-Modified: $Date$ Author: Antoine Pitrou Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 13-Sep-2013 Python-Version: 3.4 Post-History: Abstract This PEP proposes a new data structure for the ``collections`` modu

Re: [Python-Dev] PEP 455: TransformDict

On Fri, 13 Sep 2013 22:31:02 +0300 Serhiy Storchaka wrote: > 13.09.13 21:40, Antoine Pitrou написав(ла): > > Both are instances of a more general pattern, where a given > > transformation function is applied to keys when looking them up: that > > function being ``str.lower``

Re: [Python-Dev] PEP 455: TransformDict

On Fri, 13 Sep 2013 16:54:01 -0300 "Joao S. O. Bueno" wrote: > I see the PEP does not contemplate a way to retrieve the original key > - like we've talked about somewhere along the thread. Indeed. If that's important I can add it. I was hoping to keep very close to the MutableMapping API, to make

Re: [Python-Dev] PEP 455: TransformDict

On Fri, 13 Sep 2013 23:16:10 +0300 Serhiy Storchaka wrote: > 13.09.13 21:40, Antoine Pitrou написав(ла): > > Alternative proposals and questions > > === > > Yet one alternative proposal is to add the dict.__transform__() method. > Actu

Re: [Python-Dev] PEP 455: TransformDict

On Fri, 13 Sep 2013 16:09:10 -0400 "R. David Murray" wrote: > On Fri, 13 Sep 2013 20:40:58 +0200, Antoine Pitrou > wrote: > > Rationale > > = > > > > Numerous specialized versions of this pattern exist. The most common > > is a case-inse

Re: [Python-Dev] PEP 455: TransformDict

On Sat, 14 Sep 2013 00:05:27 +0300 Serhiy Storchaka wrote: > 13.09.13 23:21, Antoine Pitrou написав(ла): > > On Fri, 13 Sep 2013 23:16:10 +0300 > > Serhiy Storchaka wrote: > >> 13.09.13 21:40, Antoine Pitrou написав(ла): > >>>

Re: [Python-Dev] PEP 455: TransformDict

On Fri, 13 Sep 2013 23:18:39 +0300 Serhiy Storchaka wrote: > 13.09.13 23:02, Antoine Pitrou написав(ла): > > On Fri, 13 Sep 2013 16:54:01 -0300 > > "Joao S. O. Bueno" wrote: > >> I see the PEP does not contemplate a way to retrieve the original key > >>

Re: [Python-Dev] PEP 455: TransformDict

On Sat, 14 Sep 2013 10:49:52 +1000 Steven D'Aprano wrote: > > Is it more common to want both the canonical key and value at the same > time, or to just want the canonical key? My gut feeling is that I'm > likely to have code like this: > > d = TransformDict(...) > for key in data: > key =

Re: [Python-Dev] PEP 455: TransformDict

On Fri, 13 Sep 2013 15:32:55 -0700 Ethan Furman wrote: > On 09/13/2013 02:45 PM, Antoine Pitrou wrote: > > Serhiy Storchaka wrote: > >> > >> I think that's important. As OrderectDict has additional methods besides > >> the MutableMapping AP

Re: [Python-Dev] PEP 455: TransformDict

On Fri, 13 Sep 2013 21:59:11 -0700 Ethan Furman wrote: > > > I mean - given no function to retrieve the canonical key, > > one would have to resort to: > > > > my_key = data.__transform__(given_key) > > for key, value in data.items(): > > if data.__transform__(key) == my_key: > > ..

Re: [Python-Dev] PEP 455: TransformDict

On Sat, 14 Sep 2013 14:33:56 +0900 Larry Hastings wrote: > On 09/14/2013 03:40 AM, Antoine Pitrou wrote: > > Hello, > > > > Following the python-dev discussion, I've written a PEP to recap the > > proposal and the various arguments. It's inlined below, and it

Re: [Python-Dev] PEP 455: TransformDict

On Sat, 14 Sep 2013 09:43:13 -0700 Ethan Furman wrote: > On 09/14/2013 03:27 AM, Antoine Pitrou wrote: > > On Fri, 13 Sep 2013 21:59:11 -0700 > > Ethan Furman wrote: > >> > >>> I mean - given no function to retrieve the canonical key, > >>> one wo

Re: [Python-Dev] PEP 455: TransformDict

On Sat, 14 Sep 2013 22:07:50 +0300 Serhiy Storchaka wrote: > 14.09.13 20:41, Antoine Pitrou написав(ла): > > On Sat, 14 Sep 2013 09:43:13 -0700 > > Ethan Furman wrote: > >> Still, I think it would be useful to expose the transform function. > >> Any good reas

Re: [Python-Dev] PEP 455: TransformDict

On Sat, 14 Sep 2013 12:31:36 -0700 Guido van Rossum wrote: > On Fri, Sep 13, 2013 at 11:40 AM, Antoine Pitrou wrote: > > > Following the python-dev discussion, I've written a PEP to recap the > > proposal and the various arguments. It's inlined below, and it will

Re: [Python-Dev] PEP 455: TransformDict

On Sun, 15 Sep 2013 00:55:35 +0300 Serhiy Storchaka wrote: > 14.09.13 20:41, Antoine Pitrou написав(ла): > > No good reason. What's the name? transform_func? > > transform_func looks... truncated. Why not transform_function or trans_func? The stdlib commonly uses "fu

Re: [Python-Dev] PEP 455: TransformDict

On Sun, 15 Sep 2013 13:56:26 +0900 Larry Hastings wrote: > On 09/14/2013 07:30 PM, Antoine Pitrou wrote: > > On Sat, 14 Sep 2013 14:33:56 +0900 > > Larry Hastings wrote: > >> Whenever I read a discussion about the dict, I always wonder whether the > >> same

Re: [Python-Dev] PEP 455: TransformDict

On Sun, 15 Sep 2013 16:14:24 +0300 Serhiy Storchaka wrote: > 15.09.13 14:23, Antoine Pitrou написав(ла): > > On Sun, 15 Sep 2013 13:56:26 +0900 > > Larry Hastings wrote: > >> On 09/14/2013 07:30 PM, Antoine Pitrou wrote: > >>> On Sat, 14 Sep 2013 14:33:

Re: [Python-Dev] PEP 455: TransformDict

On Sun, 15 Sep 2013 17:45:00 +0300 Serhiy Storchaka wrote: > 15.09.13 16:57, Antoine Pitrou написав(ла): > > I don't really care. What's the point in the end? TransformDict is > > non-trivial to implement, while the so-called "TransformSet" is just a > >

Re: [Python-Dev] PEP 428: Pathlib

Le Sun, 15 Sep 2013 06:46:08 -0700, Ethan Furman a écrit : > I see PEP 428 is both targeted at 3.4 and still in draft status. > > What remains to be done to ask for pronouncement? I think I have a couple of items left to integrate in the PEP. Mostly it needs me to take a bit of time and finalize

Re: [Python-Dev] PEP 428: Pathlib -> stat caching

On Mon, 16 Sep 2013 19:06:37 +0200 Charles-François Natali wrote: > 2013/9/16 Antoine Pitrou : > > Le Sun, 15 Sep 2013 06:46:08 -0700, > > Ethan Furman a écrit : > >> I see PEP 428 is both targeted at 3.4 and still in draft status. > >> > >> What r

Re: [Python-Dev] PEP 428: Pathlib -> stat caching

On Mon, 16 Sep 2013 15:48:54 -0400 Brett Cannon wrote: > > > > So I would like to propose the following API change: > > > > - Path.stat() (and stat-accessing methods such as get_mtime()...) > > returns an uncached stat object by default > > > > - Path.cache_stat() can be called to return the sta

Re: [Python-Dev] PEP 428: Pathlib -> stat caching

On Mon, 16 Sep 2013 16:14:43 -0400 "R. David Murray" wrote: > On Mon, 16 Sep 2013 15:48:54 -0400, Brett Cannon wrote: > > On Mon, Sep 16, 2013 at 3:45 PM, Antoine Pitrou wrote: > > > So I would like to propose the following API change: > > > > > >

Re: [Python-Dev] License() release list is imcomplete; intentional?

Le Tue, 17 Sep 2013 11:37:48 -0400, Terry Reedy a écrit : > On 2.7, >>> license() return a text that includes a complete list of > releases from 1.6 to 2.7 and stops there > Release Derived YearOwner GPL- > fromc

Re: [Python-Dev] License() release list is imcomplete; intentional?

On Tue, 17 Sep 2013 09:47:48 -0700 Guido van Rossum wrote: > > IIRC this table was added when a few core Python developers including > myself left CNRI in 2000. We had a bit of an argument about the license > (not too much though -- in the end things came out alright). Some lawyer at > CNRI thoug

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

Le Tue, 17 Sep 2013 14:40:21 -0700, Ethan Furman a écrit : > On 09/17/2013 02:21 PM, Guido van Rossum wrote: > > Congrats, I've accepted the PEP. Nice work! Please work with the > > reviewers on the issue on the code. > > Congratulations, Stephen! Or Steven even ;)

Re: [Python-Dev] PEP 428: Pathlib -> stat caching

Le Tue, 17 Sep 2013 18:10:53 -0700, Philip Jenvey a écrit : > > On Sep 16, 2013, at 1:05 PM, Antoine Pitrou wrote: > > > On Mon, 16 Sep 2013 15:48:54 -0400 > > Brett Cannon wrote: > >>> > >>> So I would like to propose the following API change: &

Re: [Python-Dev] Compiler for the Mac OS X version of Python 3.4

Le Wed, 18 Sep 2013 14:54:32 +0200, "Martin v. Löwis" a écrit : > Am 18.09.13 08:43, schrieb Gregory P. Smith: > > Just drop support for 10.6 with Python 3.4. Problem solved. People > > on that old of a version of the OS can build their own Python 3.4 > > or do the right thing and upgrade or just

Re: [Python-Dev] PEP 453 Round 4 - Explicit bootstrapping of pip in Python installations

Le Thu, 19 Sep 2013 09:27:24 -0400, Donald Stufft a écrit : > We've updated PEP453 based on some of the early feedback we've gotten > from -dev and Martin. > > Major changes: > > * Removal of the option to fetch pip from PyPI in order not to modify > the trust model of the Python installers > *

Re: [Python-Dev] sys.intern should work on bytes

Le Fri, 20 Sep 2013 13:19:24 +0200, Jesus Cea a écrit : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > """ > sys.intern(b'12121212') > Traceback (most recent call last): > File "", line 1, in > TypeError: must be str, not bytes > """ > > I wonder why. From http://docs.python.org/3.3/l

Re: [Python-Dev] sys.intern should work on bytes

Le Fri, 20 Sep 2013 15:14:37 +0200, Jesus Cea a écrit : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 20/09/13 14:04, Victor Stinner wrote: > > What would you be the use case of interned bytes objets? > > Performance and memory. Pickle sizes (my particular issue now). sys.intern is a

Re: [Python-Dev] sys.intern should work on bytes

Le Fri, 20 Sep 2013 15:36:45 +0200, Jesus Cea a écrit : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 20/09/13 15:31, Antoine Pitrou wrote: > > sys.intern is an internal interpreter optimization and should be > > orthogonal to pickling. If pickle can

Re: [Python-Dev] sys.intern should work on bytes

Le Fri, 20 Sep 2013 15:33:05 +0200, Jesus Cea a écrit : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 20/09/13 14:15, Antoine Pitrou wrote: > > From http://docs.python.org/3.3/library/sys.html#sys.intern > > > > """sys.intern(string) &g

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

On Sat, 21 Sep 2013 19:55:05 -0400 Terry Reedy wrote: > > > In the general case it represents a bug in > > the code that should be fixed. Most such errors arise from the vagaries > > of module finalization (such as your issue 19021), > > Lets call that a buglet ;-). Not really harmful, but anno

Re: [Python-Dev] Best practice for documentation for std lib

On Sun, 22 Sep 2013 13:13:04 +1000 Steven D'Aprano wrote: > Hi all, > > I have a question about how I should manage documentation for the > statistics module for Python 3.4. At the moment, I have extensive > docstrings in the module itself. I don't believe anyone has flagged that > as "too muc

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

On Sun, 22 Sep 2013 10:48:33 +0200 Georg Brandl wrote: > On 09/22/2013 10:19 AM, Antoine Pitrou wrote: > > On Sat, 21 Sep 2013 19:55:05 -0400 > > Terry Reedy wrote: > >> > >> > In the general case it represents a bug in > >> > the code that s

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

Le Mon, 23 Sep 2013 18:17:51 +1000, Nick Coghlan a écrit : > > Here's what I suggest changing that error to: > > >>> del x > Unraisable exception suppressed when calling of <__main__.C object at 0x7f98b8b61538>> > Traceback (most recent call last): > File "", line 3, in __del__ > RuntimeError

Re: [Python-Dev] Best practice for documentation for std lib

Le Mon, 23 Sep 2013 15:51:27 +0200, Walter Dörwald a écrit : > On 23.09.13 15:38, Fred Drake wrote: > > > On Mon, Sep 23, 2013 at 7:27 AM, Walter Dörwald > > wrote: > >> It would be great if the docstring contained a link to the online > >> documentation. > > > > The docstring itself, or the pre

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

On Mon, 23 Sep 2013 18:51:04 +1000 Nick Coghlan wrote: > On 23 September 2013 18:45, Antoine Pitrou wrote: > > Le Mon, 23 Sep 2013 18:17:51 +1000, > > Nick Coghlan a écrit : > >> > >> Here's what I suggest changing that error to: > >> > >

Re: [Python-Dev] Best practice for documentation for std lib

On Mon, 23 Sep 2013 08:57:01 +0100 Larry Hastings wrote: > On 09/23/2013 03:44 AM, Guido van Rossum wrote: > > On Sun, Sep 22, 2013 at 7:25 PM, Terry Reedy > > wrote: > > > > I am gradually changing Idle docstrings, though only Idle > > developers will ever see th

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

On Tue, 24 Sep 2013 07:19:14 +1000 Nick Coghlan wrote: > On 24 Sep 2013 01:24, "Antoine Pitrou" wrote: > > > > On Mon, 23 Sep 2013 18:51:04 +1000 > > Nick Coghlan wrote: > > > On 23 September 2013 18:45, Antoine Pitrou wrote: > > > > Le Mon,

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

On Mon, 23 Sep 2013 14:38:48 -0700 Ethan Furman wrote: > > But that's because you already know what it's supposed to convey. The > > average user doesn't, and only sees "unraisable". > > All the more reason to have text in the error message that is easily > searchable. Then I propose "CA6yuaYV6

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

On Tue, 24 Sep 2013 17:25:10 +1000 Nick Coghlan wrote: > > You are setting the bar unreasonably high for an error message that > has to convey a complex concept in as few words as possible. There is > *NO* wording that can concisely express the concepts involved without > resorting to jargon, bec

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

On Tue, 24 Sep 2013 18:06:15 +1000 Nick Coghlan wrote: > > How is it wrong? At the point where the interpreter says "This > exception is now unraisable", what, precisely, is it saying that is > wrong? > It isn't saying "this has never been raised". It is saying, "where it > is currently being pro

Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?

On Wed, 25 Sep 2013 16:50:22 -0400 Barry Warsaw wrote: > On Sep 23, 2013, at 09:15 PM, Nick Coghlan wrote: > > >With the last round of updates, I believe PEP 453 is ready for > >Martin's pronouncement. > > I want to raise an objection to PEP's proposal to add this as a new feature to > Python 2

Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?

On Wed, 25 Sep 2013 19:15:05 -0400 Barry Warsaw wrote: > On Sep 25, 2013, at 07:08 PM, Donald Stufft wrote: > > >On Sep 25, 2013, at 7:04 PM, Barry Warsaw wrote: > > > >> So, why shouldn't we add enum to the Python 2.7 stdlib? > > >Because with PEP453 you can just ``pip install enum34`` it :) >

Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?

Le Thu, 26 Sep 2013 14:54:49 +1000, Nick Coghlan a écrit : > On 26 September 2013 14:30, Nick Coghlan wrote: > > That said, there are changes that I think are definitely worth > > making due to the concerns you raise: > > > > - the module name should be "_ensurepip" in all versions > > - the PEP

Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?

Le Thu, 26 Sep 2013 10:22:55 -0400, Donald Stufft a écrit : > Ideally people won't be typing either of them because it'll be > installed automatically. They might in some cases (accidentally > uninstalled pip?) Installing from source perhaps. > I agree that it seems there is paranoia going on he

Re: [Python-Dev] asdl.py and Python-ast.[hc]

On Thu, 26 Sep 2013 11:46:07 -0700 Eli Bendersky wrote: > > >> 2013/9/26 Eli Bendersky : > > >> > Hi All, > > >> > > > >> > Earlier this morning I had a slight tackle with a couple of the 3.4 > > bots > > >> > (sorry everyone!). I fixed some problems in asdl.py - > > >> > http://hg.python.org/cpy

Re: [Python-Dev] asdl.py and Python-ast.[hc]

On Thu, 26 Sep 2013 14:43:48 -0400 Benjamin Peterson wrote: > 2013/9/26 Eli Bendersky : > > > > > > > > On Thu, Sep 26, 2013 at 7:28 AM, Benjamin Peterson > > wrote: > >> > >> 2013/9/26 Eli Bendersky : > >> > Hi All, > >> > > >> > Earlier this morning I had a slight tackle with a couple of the 3.

Re: [Python-Dev] asdl.py and Python-ast.[hc]

On Thu, 26 Sep 2013 14:19:59 -0700 Eli Bendersky wrote: > On Thu, Sep 26, 2013 at 2:00 PM, Antoine Pitrou wrote: > > > On Thu, 26 Sep 2013 14:43:48 -0400 > > Benjamin Peterson wrote: > > > 2013/9/26 Eli Bendersky : > > > > > > > > > &

Re: [Python-Dev] asdl.py and Python-ast.[hc]

Le Thu, 26 Sep 2013 10:28:46 -0400, Benjamin Peterson a écrit : > 2013/9/26 Eli Bendersky : > > Hi All, > > > > Earlier this morning I had a slight tackle with a couple of the 3.4 > > bots (sorry everyone!). I fixed some problems in asdl.py - > > http://hg.python.org/cpython/rev/21d46e3ae60c - and

Re: [Python-Dev] asdl.py and Python-ast.[hc]

Le Fri, 27 Sep 2013 16:34:41 +0200, "Martin v. Löwis" a écrit : > Am 26.09.13 23:00, schrieb Antoine Pitrou: > > > Here you are: > > http://buildbot.python.org/all/builders/AMD64%20Snow%20Leop%203.x/builds/28/steps/compile/logs/stdio > > > > Of course, w

Re: [Python-Dev] Getting Tulip (PEP 3156) into the 3.4 stdlib, marked provisional, named asyncio

On Sat, 28 Sep 2013 15:59:05 +1000 Nick Coghlan wrote: > It sounds like a reasonable approach to me. > > In terms of naming, would you consider "concurrent.asyncio"? When we > created that parent namespace for futures, one of the other suggested > submodules discussed was the standard event loop

Re: [Python-Dev] Getting Tulip (PEP 3156) into the 3.4 stdlib, marked provisional, named asyncio

On Sun, 29 Sep 2013 09:54:39 -0700 Guido van Rossum wrote: > So, with the naming settled (asyncio it is), and lots of other things still > to do, I need a BDFL for PEP 3156. Any volunteers? If no-one volunteered > I'll have to accept my own PEP at some point, but I don't really *want* to > do that

Re: [Python-Dev] cpython (2.7): Add fake buildbottouch target.

On Mon, 30 Sep 2013 16:18:57 +0200 (CEST) martin.v.loewis wrote: > http://hg.python.org/cpython/rev/c1a294bbb4fa > changeset: 85882:c1a294bbb4fa > branch: 2.7 > parent: 85877:dd55d54b2a15 > user:Martin v. Löwis > date:Mon Sep 30 16:18:31 2013 +0200 > summary: > Add f

Re: [Python-Dev] peps: document requirements

On Mon, 30 Sep 2013 17:08:00 +0200 (CEST) christian.heimes wrote: > + > +* It should return ``0`` for zero length input. (Note: This can be handled as > + special case, too.) What is this required for? The main requirement is that equal stuff hashes equal, but there's no reason for zero-length i

Re: [Python-Dev] cpython: Close #10042: functools.total_ordering now handles NotImplemented

On Tue, 1 Oct 2013 16:02:26 +0200 (CEST) nick.coghlan wrote: > http://hg.python.org/cpython/rev/ad9f207645ab > changeset: 85913:ad9f207645ab > user:Nick Coghlan > date:Wed Oct 02 00:02:03 2013 +1000 > summary: > Close #10042: functools.total_ordering now handles NotImplemente

Re: [Python-Dev] cpython: Use cached builtins.

On Wed, 2 Oct 2013 18:16:48 +0200 (CEST) serhiy.storchaka wrote: > http://hg.python.org/cpython/rev/d48ac94e365f > changeset: 85931:d48ac94e365f > user:Serhiy Storchaka > date:Wed Oct 02 19:15:54 2013 +0300 > summary: > Use cached builtins. What's the point? I don't think it

Re: [Python-Dev] Make str/bytes hash algorithm pluggable?

On Thu, 03 Oct 2013 20:42:28 +0200 Christian Heimes wrote: > > I haven't actually benchmarked how a faster hash algorithm > affects the a real program, though ... Chances are it doesn't. Only a "slow enough" hash algorithm might have an impact, IMHO. > On which level should Python support a plu

Re: [Python-Dev] Make str/bytes hash algorithm pluggable?

Le Fri, 4 Oct 2013 11:15:17 +0200, Victor Stinner a écrit : > 2013/10/4 Armin Rigo : > > The current hash randomization is > > simply not preventing anything; someone posted long ago a way to > > recover bit-by-bit the hash randomized used by a remote web program > > in Python running on a server

Re: [Python-Dev] Make str/bytes hash algorithm pluggable?

Le Fri, 04 Oct 2013 17:13:32 +0200, mar...@v.loewis.de a écrit : > > Whether this is a serious threat or not depends on what other threats > the system being attacked is vulnerable to. Maybe there is something > even simpler, or maybe the hash attack is the only hope of bringing > the system to it

Re: [Python-Dev] PEP 455: TransformDict

Good evening, On Fri, 4 Oct 2013 13:38:05 -0700 Raymond Hettinger wrote: > > You can also add to the discussion by trying out your own usability > tests on people who haven't been exposed to this thread or the pep. I think "usability tests" should be conducted on people who actually have a nee

Re: [Python-Dev] Make str/bytes hash algorithm pluggable?

On Sat, 5 Oct 2013 08:25:01 -0700 Guido van Rossum wrote: > > A good defense combines multiple techniques -- e.g. common sense about when > and where you park your bike together with a mediocre lock might make the > theft risk acceptably low. (just remember to park it under a shed with an approp

Re: [Python-Dev] Optimization

On Sat, 05 Oct 2013 22:11:43 +0200 Georg Brandl wrote: > Am 05.10.2013 21:42, schrieb Serhiy Storchaka: > > Please remember me, what was common decision about CPython-only > > optimizations which change computation complexity? I.g. constant > > amortization time of += for byte objects and string

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