Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections ready for pronouncement

Guido van Rossum wrote: Beware, deleting an item from an OrderedDict (in the current implementation) is O(N). Am I correct in presuming that that would not be true of .popitem? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org

Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections ready for pronouncement

Perhaps the terminology should be ordereddict -- what we have here sorteddict -- hypothetical future type that keeps itself sorted in key order +1 FIFOdict ? Yeah, that blows the capitalization scheme, way, way out. Issues: * The popitem() method is LIFO. * In a non

Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections ready for pronouncement

On approximately 3/3/2009 4:51 PM, came the following characters from the keyboard of Greg Ewing: Terry Reedy wrote: I almost agree, except that the API uses the dict, not list, API. Yes, as long as the API is dict-like, it really needs to be thought of as a kind of dict. Perhaps the termino

Re: [Python-Dev] asyncore fixes in Python 2.6 broke Zope's version of medusa

On 3 Mar, 10:20 pm, gu...@python.org wrote: On Tue, Mar 3, 2009 at 1:17 PM, wrote: At the very least, this might serve as a basis for an abstract API for asyncore: http://twistedmatrix.com/documents/8.2.0/api/twisted.internet.interfaces.IProtocol.html I hope we have learned from asyncor

Re: [Python-Dev] Adding PEP consistent aliases for names that don't currently conform

2009/3/3 Brett Cannon : > > > On Tue, Mar 3, 2009 at 17:30, Eric Smith wrote: >>> >>> We need a really long lead time before we can remove these. I >>> recommend starting with a *silent* deprecation in 3.1 combined with a >>> PR offensive for the new names. >> >> I think the old names basically ha

Re: [Python-Dev] Adding PEP consistent aliases for names that don't currently conform

Brett Cannon wrote: > > > On Tue, Mar 3, 2009 at 17:30, Eric Smith > wrote: > > We need a really long lead time before we can remove these. I > recommend starting with a *silent* deprecation in 3.1 combined > with a > PR offensive for t

Re: [Python-Dev] Adding PEP consistent aliases for names that don't currently conform

On Tue, Mar 3, 2009 at 17:30, Eric Smith wrote: > We need a really long lead time before we can remove these. I >> recommend starting with a *silent* deprecation in 3.1 combined with a >> PR offensive for the new names. >> > > I think the old names basically have to live forever in some way, due

Re: [Python-Dev] Adding PEP consistent aliases for names that don't currently conform

We need a really long lead time before we can remove these. I recommend starting with a *silent* deprecation in 3.1 combined with a PR offensive for the new names. I think the old names basically have to live forever in some way, due to loading old pickles. Remember the problems we had when we

Re: [Python-Dev] Adding PEP consistent aliases for names that don'tcurrently conform

It may be too late to rename the existing accidents, but why not add consistently-named aliases (socket.Socket, datetime.DateTime, etc) and strongly encourage their use in new code? Or make the old names aliases for the new names and start a PendingDeprecationWarning on the old names so they c

Re: [Python-Dev] Adding PEP consistent aliases for names that don't currently conform

On Tue, Mar 3, 2009 at 5:15 PM, Brett Cannon wrote: > > > On Tue, Mar 3, 2009 at 05:13, wrote: >> >> On Tue, 3 Mar 2009 at 06:01, Ivan KrstiÄ~G wrote: >>> >>> On Mar 2, 2009, at 7:08 PM, Steve Holden wrote: > >  PS.: so is datetime.datetime a builtin then? :) > >  Another historic

Re: [Python-Dev] Adding PEP consistent aliases for names that don't currently conform

On Tue, Mar 3, 2009 at 05:13, wrote: > On Tue, 3 Mar 2009 at 06:01, Ivan KrstiÄ~G wrote: > >> On Mar 2, 2009, at 7:08 PM, Steve Holden wrote: >> >>> > > PS.: so is datetime.datetime a builtin then? :) >>> > > Another historic accident. Like socket.socket. :-( >>> > >>> A pity this stuff wasn't

Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections ready for pronouncement

On Tue, Mar 3, 2009 at 3:05 PM, Scott David Daniels wrote: > Forest wrote: >> >> On Tue, March 3, 2009 11:20 am, Forest wrote: >>> >>> Okay, but I'd also like a convenient and fast way to find the oldest >>> entry >>> in an OrderedDict, which I think I'd need for an LRU cache.  Skimming the >>> cu

Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections ready for pronouncement

Terry Reedy wrote: I almost agree, except that the API uses the dict, not list, API. Yes, as long as the API is dict-like, it really needs to be thought of as a kind of dict. Perhaps the terminology should be ordereddict -- what we have here sorteddict -- hypothetical future type that k

Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections ready for pronouncement

Forest wrote: On Tue, March 3, 2009 11:20 am, Forest wrote: Okay, but I'd also like a convenient and fast way to find the oldest entry in an OrderedDict, which I think I'd need for an LRU cache. Skimming the current patch (od7.diff), I didn't notice one. Perhaps I simply missed something. Sho

Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections ready for pronouncement

Greg Ewing wrote: Giovanni Bajo wrote: Just today, I was talking with a colleague (which is learning Python right now) about "ordered dict". His first thought was a dictionary that, when iterated, would return keys in sorted order. I wonder whether "indexed list" would be a more appropriate

Re: [Python-Dev] asyncore fixes in Python 2.6 broke Zope's version of medusa

On Tue, Mar 3, 2009 at 1:17 PM, wrote: > > On 08:46 pm, gu...@python.org wrote: >> >> This seems to be the crux of the problem with asyncore, ever since it >> was added to the stdlib -- there's no real API, so every change >> potentially breaks something. I wish we could start over with a proper

Re: [Python-Dev] asyncore fixes in Python 2.6 broke Zope's version of medusa

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Guido van Rossum wrote: > On Tue, Mar 3, 2009 at 12:23 PM, Tres Seaver wrote: >> How is anybody supposed to >> write a package which sits atop a library like asyncore in a fashion >> portable across Python versions? The changes to the implementation

Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections ready for pronouncement

Raymond Hettinger wrote: > [Forest] >> Perhaps a new method like getfirst() would be worth while here? > > Guido already gave you a way to access the first item using the existing > API. > Using next(iter(d)) also works. Yep. I think messages are arriving out of order. -1 on my own suggestion.

Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections ready for pronouncement

Giovanni Bajo wrote: Just today, I was talking with a colleague (which is learning Python right now) about "ordered dict". His first thought was a dictionary that, when iterated, would return keys in sorted order. I wonder whether "indexed list" would be a more appropriate name for what we're

Re: [Python-Dev] asyncore fixes in Python 2.6 broke Zope's version of medusa

On 08:46 pm, gu...@python.org wrote: This seems to be the crux of the problem with asyncore, ever since it was added to the stdlib -- there's no real API, so every change potentially breaks something. I wish we could start over with a proper design under a new name. Might I suggest "reactor"..

Re: [Python-Dev] asyncore fixes in Python 2.6 broke Zope's version of medusa

On Tue, Mar 3, 2009 at 12:23 PM, Tres Seaver wrote: > How is anybody supposed to > write a package which sits atop a library like asyncore in a fashion > portable across Python versions?  The changes to the implementation in > 2.6 (there is no real API) can't be reconciled, AFAICT. This seems to

Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections ready for pronouncement

[Forest] Perhaps a new method like getfirst() would be worth while here? Guido already gave you a way to access the first item using the existing API. Using next(iter(d)) also works. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://

Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections ready for pronouncement

On Tue, March 3, 2009 11:20 am, Forest wrote: > Okay, but I'd also like a convenient and fast way to find the oldest entry > in an OrderedDict, which I think I'd need for an LRU cache. Skimming the > current patch (od7.diff), I didn't notice one. Perhaps I simply missed > something. Shouldn't po

Re: [Python-Dev] draft 3.1 release schedule

2009/3/3 Daniel (ajax) Diniz : > Benjamin, I'd like to nominate a couple (minor) RFEs[1] and bug > fixes[2] for 3.1. By 'nominate' I mean 'group related issues together, > offer tests, docs, patches and/or reviews as needed and > ask-pretty-please-for-inclusion' :) > > Would early post-3.1a1 versus

Re: [Python-Dev] asyncore fixes in Python 2.6 broke Zope's version of medusa

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tres Seaver wrote: > Guido van Rossum wrote: >> On Wed, Oct 8, 2008 at 6:39 PM, Bill Janssen wrote: >>> Josiah Carlson wrote: >>> But yes, zope needs to be changed to reflect the updated asyncore/asynchat semantics. Trust me; it's faster,

Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections ready for pronouncement

I recommend that you either make this a __private variable (signalling strongly that people shouldn't ever reference it), Will do. We want to make sure we can substitute a C implementation that has a completely different underlying structure (hash table plus a doubly linked list). Raymond

Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections ready for pronouncement

On Tue, Mar 3, 2009 at 12:02 PM, Raymond Hettinger wrote: > > [Forest] >> >> Okay, but I'd also like a convenient and fast way to find the oldest entry >> in an OrderedDict, which I think I'd need for an LRU cache.  Skimming the >> current patch (od7.diff), I didn't notice one.  Perhaps I simply m

Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections ready for pronouncement

On Tue, March 3, 2009 11:54 am, Guido van Rossum wrote: > On Tue, Mar 3, 2009 at 11:20 AM, Forest wrote: >> Okay, but I'd also like a convenient and fast way to find the oldest >> entry >> in an OrderedDict, which I think I'd need for an LRU cache.  Skimming >> the >> current patch (od7.diff), I d

Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections ready for pronouncement

[Forest] Okay, but I'd also like a convenient and fast way to find the oldest entry in an OrderedDict, which I think I'd need for an LRU cache. Skimming the current patch (od7.diff), I didn't notice one. Perhaps I simply missed something. Shouldn't popitem() allow the caller to choose which e

Re: [Python-Dev] draft 3.1 release schedule

Mitchell L Model wrote: > Would whoever is responsible for IDLE please take a look at the patches > I submitted for Python 2 & 3 [tracker IDs 5233 and 5234 respectively]. [...] > I would really like to see them in 3.1. The patch is already there; > someone just has to do whatever gets done with pat

Re: [Python-Dev] draft 3.1 release schedule

Hi, Benjamin Peterson wrote: > 3.1a1 March 7 > 3.1a2 April 4 > 3.1b1 May 2 > 3.1rc1 May 30 > 3.1rc2 June 13 > 3.1 Final June 27 Benjamin, I'd like to nominate a couple (minor) RFEs[1] and bug fixes[2] for 3.1. By 'nominate' I mean 'group related issues together, offer tests, docs, patches and/or

Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections ready for pronouncement

On Tue, Mar 3, 2009 at 11:20 AM, Forest wrote: > I'm looking forward to an ordered dictionary in the standard library, > especially for things like LRU caches.  I was just reading the PEP, and > caught this bit: > > "Does OrderedDict.popitem() return a particular key/value pair? > Yes. It pops-off

Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections ready for pronouncement

I'm looking forward to an ordered dictionary in the standard library, especially for things like LRU caches. I was just reading the PEP, and caught this bit: "Does OrderedDict.popitem() return a particular key/value pair? Yes. It pops-off the most recently inserted new key and its corresponding v

Re: [Python-Dev] ABCs and MRO

On Mon, Mar 2, 2009 at 1:14 PM, Paul Moore wrote: > 2009/3/2 Jeffrey Yasskin : >> I tend to think it's a bug in ABCs. You seem to have thought of >> several possible ways to fix it, and I don't have strong preferences >> between them. > > I've discussed ways of fixing simplegeneric, but not of fix

Re: [Python-Dev] ABCs and MRO

Nick Coghlan wrote: Terry Reedy wrote: OK, that suggests that the new feature should only be committed, if ever, to 2.7 after 3.1, when it can also be committed to 3.2 at the same time. Not really - there's already stuff in 3.0 that wasn't backported the first time around. Irrelevant. It

Re: [Python-Dev] Adding PEP consistent aliases for names that don't currently conform

On Tue, 3 Mar 2009 at 06:01, Ivan Krsti?~G wrote: On Mar 2, 2009, at 7:08 PM, Steve Holden wrote: > > PS.: so is datetime.datetime a builtin then? :) > > Another historic accident. Like socket.socket. :-( > A pity this stuff wasn't addressed for 3.0. Way too late now, though. It may be t

Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections ready for pronouncement

On Mar 2, 2009, at 7:08 PM, Steve Holden wrote: PS.: so is datetime.datetime a builtin then? :) Another historic accident. Like socket.socket. :-( A pity this stuff wasn't addressed for 3.0. Way too late now, though. It may be too late to rename the existing accidents, but why not add co

Re: [Python-Dev] ABCs and MRO

Terry Reedy wrote: > Nick Coghlan wrote: >> Terry Reedy wrote: > As for the actual feature, I don't think it should hold up releases. Fair enough. >>> Given that the purpose of 2.7 is >>> a) maintenance of existing code (which can include minor new features >>> for existing facilities), an