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

On Wed, Mar 4, 2009 at 1:31 PM, Guido van Rossum wrote: > On Wed, Mar 4, 2009 at 1:27 PM, Chris McDonough wrote: >> Daniel Stutzbach wrote: >>> On Wed, Mar 4, 2009 at 12:54 PM, Guido van Rossum wrote: >>> The same as always. We don't change APIs in bugfix releases. >>> >>> This questio

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

Hi Nick! Am 04.03.2009 22:34, Nick Coghlan schrieb: > Dennis Benzinger wrote: >> I'd prefer encoding the order in the class name, therefore I suggest >> (Ins|Insertion)(Order|Ordered)Dict, e.g. InsOrderDict. Abbreviating the >> first group to simply I probably is too confusing because of the use o

Re: [Python-Dev] Forgotten Py3.0 change to remove Queue.empty() and Queue.full()

Hi Jesse, I'm not sure what the most appropriate thing to do is. I could: (a) leave any multiprocessing changes to you, (b) alter the functioning of the method queue_empty inside test_multiprocessing to test for emptiness in a different manner I'm happy to go ahead and try my hand at making t

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

Daniel Stutzbach wrote: > On Wed, Mar 4, 2009 at 3:14 PM, Ivan Krstić > > wrote: > > I spent about a half hour sometime in the last month talking this > through with Itamar, though not in great detail. I'd be interested > in sitting down with b

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

Terry Reedy wrote: Lie Ryan wrote: Isn't ordered dictionary essentially also an "always sorted" container? It is always sorted depending on the order of insertion? I can't see any technical reason why the data structure can't accommodate them both. Can you point me to a discussion on this?

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

Steven D'Aprano wrote: I also can't think of an alternative explanation, so thus far, it's resistant to false positive semantics. "The keys don't expire with time." "It's stable against accidental deletions." "It's stable against accidentally over-writing values." Add to that: "The StableDict

Re: [Python-Dev] What to do about failing tests

2009/3/4 Tennessee Leeuwenburg : > On my local checkout I notice a number of failing tests (test_fileio > test_grp test_io test_urllib2_localnet). Is there anything that I should > attempt to do regarding these? Try "svn up". Those should be fixed now. -- Regards, Benjamin

[Python-Dev] forgive my patch submission

I am trying to learn the systems... I'm not trying to force a particular approach to the solution but I want to learn how to correctly follow the process. Please feel free to reject this -- I'm not trying to jump the gun given there isn't even an agreed requirement at this stage. Regards, -Tenness

[Python-Dev] What to do about failing tests

On my local checkout I notice a number of failing tests (test_fileio test_grp test_io test_urllib2_localnet). Is there anything that I should attempt to do regarding these? -Tennessee ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.o

Re: [Python-Dev] Forgotten Py3.0 change to remove Queue.empty() and Queue.full()

Yup, I'd need to remove support in multiprocessing too. ahead and tried adding a warning to my local checkout. Thanks for quickly checking this out. Will be nice to get the API cleaned-up. Leaving out part of the clean-up was a mistake. Raymond _

Re: [Python-Dev] Forgotten Py3.0 change to remove Queue.empty() and Queue.full()

Yup, I'd need to remove support in multiprocessing too. On Mar 4, 2009 8:39pm, Tennessee Leeuwenburg wrote: Hi all, just FYI... sorry for any list pollution I went ahead and tried adding a warning to my local checkout. The test suite raised a DeprecationWarning -- it appears those methods a

Re: [Python-Dev] Forgotten Py3.0 change to remove Queue.empty() and Queue.full()

Hi all, just FYI... sorry for any list pollution I went ahead and tried adding a warning to my local checkout. The test suite raised a DeprecationWarning -- it appears those methods are currently in use by other Lib code: test_multibytecodec_support test_multiprocessing /home/tjl/python3/lib/pyt

Re: [Python-Dev] Forgotten Py3.0 change to remove Queue.empty() and Queue.full()

Just noticed that the empty() and full() methods were still there. IIRC, we agreed to take them out (but leaving qsize() exposed). The docs entries and test cases were taken out, but the actual methods were accidentally left in. If so, the only thing to do is deprecate it in 3.1 for removal in 3

Re: [Python-Dev] Forgotten Py3.0 change to remove Queue.empty() and Queue.full()

That code doesn't look t scary... is trying to add a DeprecationWarning something that I could try to learn how to do and try my hand at? Maybe if someone else would like to address that more quickly, they'd be able to keep me in the loop so I can start learning how Things are Done? It looks a

Re: [Python-Dev] Forgotten Py3.0 change to remove Queue.empty() and Queue.full()

2009/3/4 Raymond Hettinger : > Just notices that the empty() and full() methods were still there. > IIRC, we agreed to take them out (but leaving qsize() exposed). > The docs entries and test cases were taken out, but the actual > methods were accidentally left in. If so, the only thing to do is d

[Python-Dev] Forgotten Py3.0 change to remove Queue.empty() and Queue.full()

Just notices that the empty() and full() methods were still there. IIRC, we agreed to take them out (but leaving qsize() exposed). The docs entries and test cases were taken out, but the actual methods were accidentally left in. Raymond ___ Python-Dev m

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

2009/3/4 Guido van Rossum : > On Wed, Mar 4, 2009 at 3:23 AM, Nick Coghlan wrote: >> Benjamin Peterson wrote: >>> Yes, I'm already looking forward to Py4k now. :) >> >> Shh, Guido will need at least 5 years before he's ready to contemplate >> going through something like this again. >> >> Or maybe

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

On Wed, Mar 4, 2009 at 1:44 PM, Greg Ewing wrote: > rdmur...@bitdance.com wrote: > >> I actually like StableDict best.  When I hear that I think, "ah, the >> key order is stable in the face of insertions, unlike a regular dict". > > But it still doesn't convey what the ordering actually *is*. Ple

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

rdmur...@bitdance.com wrote: I actually like StableDict best. When I hear that I think, "ah, the key order is stable in the face of insertions, unlike a regular dict". But it still doesn't convey what the ordering actually *is*. -- Greg ___ Python-

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

On Wed, Mar 4, 2009 at 3:14 PM, Ivan Krstić < krs...@solarsail.hcs.harvard.edu> wrote: > I spent about a half hour sometime in the last month talking this through > with Itamar, though not in great detail. I'd be interested in sitting down > with both of you and trying to establish more precisely

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

Dennis Benzinger wrote: > I'd prefer encoding the order in the class name, therefore I suggest > (Ins|Insertion)(Order|Ordered)Dict, e.g. InsOrderDict. Abbreviating the > first group to simply I probably is too confusing because of the use of > I as a prefix for interfaces. Except I just don't see

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

On Wed, Mar 4, 2009 at 1:27 PM, Chris McDonough wrote: > Daniel Stutzbach wrote: >> On Wed, Mar 4, 2009 at 12:54 PM, Guido van Rossum wrote: >> >>> The same as always. We don't change APIs in bugfix releases. >>> >> >> This question is actually for the Zope folks and others who have had >> proble

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

Daniel Stutzbach wrote: > On Wed, Mar 4, 2009 at 12:54 PM, Guido van Rossum wrote: > >> The same as always. We don't change APIs in bugfix releases. >> > > This question is actually for the Zope folks and others who have had > problems with the 2.6 asyncore/asynchat: > > Are any of the problems

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

Lie Ryan wrote: > Isn't ordered dictionary essentially also an "always sorted" container? > It is always sorted depending on the order of insertion? I can't see any > technical reason why the data structure can't accommodate them both. Can > you point me to a discussion on this? My phrasing was a

Re: [Python-Dev] Integrate BeautifulSoup into stdlib?

On Mar 4, 2009, at 12:32 PM, James Y Knight wrote: I think html5lib would be a better candidate for an imrpoved HTML parser in the stdlib than BeautifulSoup. While we're talking about alternatives, Ian Bicking appears to swear by lxml:

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

Glyph, On Mar 4, 2009, at 12:31 AM, gl...@divmod.com wrote: If someone who has PEP-writing skills and some free time is updating asyncore to be more modern, I'd be very happy to walk that person through Twisted's API design and explain how either portions of our implementation could be lift

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

On Wed, Mar 4, 2009 at 12:54 PM, Guido van Rossum wrote: > The same as always. We don't change APIs in bugfix releases. > This question is actually for the Zope folks and others who have had problems with the 2.6 asyncore/asynchat: Are any of the problems due to a change in the documented API..

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

Guido van Rossum wrote: > On Wed, Mar 4, 2009 at 10:51 AM, Jean-Paul Calderone > wrote: > > On Wed, 4 Mar 2009 10:46:28 -0800, Guido van Rossum > > wrote: > >> > >> On Wed, Mar 4, 2009 at 10:27 AM, Jean-Paul Calderone > >> wrote: > >> [snip] > >>> > >>> So, as a disinterested party in this sp

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 4, 2009, at 2:44 PM, gl...@divmod.com wrote: Maintaining compatibility with the 2.6.x version of asyncore presupposes that *someone* has written some software against that version of asyncore and it might break if they installed an upgrade

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

On 06:51 pm, exar...@divmod.com wrote: On Wed, 4 Mar 2009 10:46:28 -0800, Guido van Rossum wrote: On Wed, Mar 4, 2009 at 10:27 AM, Jean-Paul Calderone wrote: So, as a disinterested party in this specific case, I'd say revert to the pre-2.6 behavior. Sorry, but I really do think that we

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

Guido van Rossum wrote: > On Wed, Mar 4, 2009 at 10:51 AM, Jean-Paul Calderone > wrote: >> On Wed, 4 Mar 2009 10:46:28 -0800, Guido van Rossum >> wrote: >>> On Wed, Mar 4, 2009 at 10:27 AM, Jean-Paul Calderone >>> wrote: >>> [snip] So, as a disinterested party in this specific case, I'd sa

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

On Wed, 4 Mar 2009 10:54:19 -0800, Guido van Rossum wrote: On Wed, Mar 4, 2009 at 10:51 AM, Jean-Paul Calderone wrote: On Wed, 4 Mar 2009 10:46:28 -0800, Guido van Rossum wrote: On Wed, Mar 4, 2009 at 10:27 AM, Jean-Paul Calderone wrote: [snip] So, as a disinterested party in this specif

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

On Wed, Mar 4, 2009 at 10:51 AM, Jean-Paul Calderone wrote: > On Wed, 4 Mar 2009 10:46:28 -0800, Guido van Rossum > wrote: >> >> On Wed, Mar 4, 2009 at 10:27 AM, Jean-Paul Calderone >> wrote: >> [snip] >>> >>> So, as a disinterested party in this specific case, I'd say revert to >>> the pre-2.6

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

On Wed, 4 Mar 2009 10:46:28 -0800, Guido van Rossum wrote: On Wed, Mar 4, 2009 at 10:27 AM, Jean-Paul Calderone wrote: [snip] So, as a disinterested party in this specific case, I'd say revert to the pre-2.6 behavior.  It does less harm than leaving the current behavior. Sorry, but I really

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

On Wed, Mar 4, 2009 at 10:27 AM, Jean-Paul Calderone wrote: > - Show quoted text - > On Wed, 4 Mar 2009 10:21:26 -0800, Guido van Rossum > wrote: >> >> On Wed, Mar 4, 2009 at 10:14 AM, Sidnei da Silva >> wrote: >>> >>> On Wed, Mar 4, 2009 at 3:04 PM, Guido van Rossum >>> wrote: Sounds

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

On Wed, 4 Mar 2009 10:21:26 -0800, Guido van Rossum wrote: On Wed, Mar 4, 2009 at 10:14 AM, Sidnei da Silva wrote: On Wed, Mar 4, 2009 at 3:04 PM, Guido van Rossum wrote: Sounds like it's not so much the code that's future proof but the process used for evolving it. That seems to be missing

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

On Wed, Mar 4, 2009 at 10:14 AM, Sidnei da Silva wrote: > On Wed, Mar 4, 2009 at 3:04 PM, Guido van Rossum wrote: >> Sounds like it's not so much the code that's future proof but the >> process used for evolving it. That seems to be missing for asyncore. >> :-( > > Turning the issue around a bit,

Re: [Python-Dev] Integrate BeautifulSoup into stdlib?

James Y Knight schrieb: > On Mar 4, 2009, at 9:56 AM, Chris Withers wrote: > >> Vaibhav Mallya wrote: >>> We do have HTMLParser, but that doesn't handle malformed pages >>> well, and just isn't as nice as BeautifulSoup. >> >> Interesting, given that BeautifulSoup is built on HTMLParser ;-) > >

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

On Wed, Mar 4, 2009 at 3:04 PM, Guido van Rossum wrote: > Sounds like it's not so much the code that's future proof but the > process used for evolving it. That seems to be missing for asyncore. > :-( Turning the issue around a bit, has anyone considered polishing up the current fix to restore it

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

On Wed, Mar 4, 2009 at 3:23 AM, Nick Coghlan wrote: > Benjamin Peterson wrote: >> Yes, I'm already looking forward to Py4k now. :) > > Shh, Guido will need at least 5 years before he's ready to contemplate > going through something like this again. > > Or maybe a decade to be on the safe side ;)

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

On Tue, Mar 3, 2009 at 9:31 PM, wrote: > > 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.interne

Re: [Python-Dev] Integrate BeautifulSoup into stdlib?

At 2:56 PM + 3/4/09, Chris Withers wrote: >Vaibhav Mallya wrote: >> We do have HTMLParser, but that doesn't handle malformed pages well, and >> just isn't as nice as BeautifulSoup. > >Interesting, given that BeautifulSoup is built on HTMLParser ;-) In BeautifulSoup >= 3.1, yes. Before that (<

Re: [Python-Dev] Integrate BeautifulSoup into stdlib?

On Mar 4, 2009, at 9:56 AM, Chris Withers wrote: Vaibhav Mallya wrote: We do have HTMLParser, but that doesn't handle malformed pages well, and just isn't as nice as BeautifulSoup. Interesting, given that BeautifulSoup is built on HTMLParser ;-) I think html5lib would be a better candidat

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

Am 04.03.2009 14:25, Benji York schrieb: > On Wed, Mar 4, 2009 at 3:01 AM, Glenn Linderman wrote: > >> C'mon folks, brainstorm, don't complain about ordereddict if you can't come >> up with some alternatives for discussion!!! (and some reasons why the >> suggestions might be good or bad) Even y

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

Leif Walsh wrote: On Wed, Mar 4, 2009 at 7:53 AM, wrote: I actually like StableDict best. When I hear that I think, "ah, the key order is stable in the face of insertions, unlike a regular dict". Nor can I at the moment think of an alternative explanation of what a "StableDict" might be. Hm

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

Lie Ryan wrote: Isn't ordered dictionary essentially also an "always sorted" container? It is always sorted depending on the order of insertion? I can't see any technical reason why the data structure can't accommodate them both. Can you point me to a discussion on this? Appending an item at

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

On Wed, Mar 4, 2009 at 7:53 AM, wrote: > I actually like StableDict best.  When I hear that I think, "ah, the > key order is stable in the face of insertions, unlike a regular dict". > Nor can I at the moment think of an alternative explanation of what a > "StableDict" might be. Hmm, perhaps a b

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

On Wed, Mar 4, 2009 at 7:53 AM, wrote: > I actually like StableDict best.  When I hear that I think, "ah, the > key order is stable in the face of insertions, unlike a regular dict". > Nor can I at the moment think of an alternative explanation of what a > "StableDict" might be. +1 -- Cheers,

Re: [Python-Dev] svn (403 Forbidden)

On Wed, Mar 4, 2009 at 8:18 AM, Luis Saavedra wrote: > how to fix this problem?, on another machine I don't have this problem..., Which machines does it work/fail on? I probably can't help you, but maybe that will help someone else figure it out. -- Cheers, Leif ___

Re: [Python-Dev] Integrate BeautifulSoup into stdlib?

Vaibhav Mallya wrote: We do have HTMLParser, but that doesn't handle malformed pages well, and just isn't as nice as BeautifulSoup. Interesting, given that BeautifulSoup is built on HTMLParser ;-) Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simpl

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

Nick Coghlan wrote: Lie Ryan wrote: How about making odict ordered by insertion order, then provide an optional argument for defining sorter? This optional argument must be a function/lambda/callable object and must be the first argument. or better yet, in the spirit of dumping cmp comparison

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

bitdance.com> writes: > > I actually like StableDict best. When I hear that I think, "ah, the > key order is stable in the face of insertions, unlike a regular dict". > Nor can I at the moment think of an alternative explanation of what a > "StableDict" might be. > > That said, I have no proble

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

On Wed, Mar 4, 2009 at 3:01 AM, Glenn Linderman wrote: > C'mon folks, brainstorm, don't complain about ordereddict if you can't come > up with some alternatives for discussion!!!  (and some reasons why the > suggestions might be good or bad)  Even your bad ideas might trigger a good > name in som

[Python-Dev] svn (403 Forbidden)

Hi, when I run: $ mkdir NewDir $ cd NewDir $ svn checkout http://svn.python.org/projects/python/trunk python svn: Server sent unexpected return value (403 Forbidden) in response to REPORT request for '/projects/!svn/vcc/default' how to fix this problem?, on another machine I don't have this p

Re: [Python-Dev] ABCs and MRO

2009/3/3 Jeffrey Yasskin : > Unfortunately, I think overloading functions on Number or Iterable > would be really useful, and constraining it to only look at base > classes would be unfortunate. That could well be the case. So the question is, I guess, how would you write such a function now? Beca

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

On Wed, 4 Mar 2009 at 23:37, Lie Ryan wrote: Steve Holden wrote: Raymond Hettinger wrote: > > > Perhaps the terminology should be > > > > > >ordereddict -- what we have here > > > > > >sorteddict -- hypothetical future type that keeps > > > itself sorted in key orde

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

Steve Holden wrote: Raymond Hettinger wrote: 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:

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

Lie Ryan wrote: How about making odict ordered by insertion order, then provide an > optional argument for defining sorter? This optional argument must be a > function/lambda/callable object and must be the first argument. As the PEP mentions (and Hrvoje brought up again already in this thread),

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

Raymond Hettinger wrote: > >>> 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 o

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

Gisle Aas wrote: On Mar 4, 2009, at 9:01 , Glenn Linderman wrote: On approximately 3/3/2009 11:22 PM, came the following characters from the keyboard of Raymond Hettinger: Perhaps the terminology should be ordereddict -- what we have here sorteddict -- hypothetical future type that keeps

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

Tennessee Leeuwenburg wrote: > Hello all, > > First a comment on-thread: > I can't wait to get an ordered dictionary in the stdlib! The > discussion regarding suggestions for the name appears to be ongoing. > What about the name 'orderdict' instead of 'ordereddict'?. It doesn't > contain the dou

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

Tennessee Leeuwenburg wrote: > Hello all, > > First a comment on-thread: > I can't wait to get an ordered dictionary in the stdlib! The > discussion regarding suggestions for the name appears to be ongoing. > What about the name 'orderdict' instead of 'ordereddict'?. It doesn't > contain the dou

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

Glenn Linderman wrote: FIFOdict ? Yeah, that blows the capitalization scheme, way, way out. [...] It is suggestive of queue behavior, and the items are a queue if looked at from insertion, and traversal perspectives, if I understand correctly. Why is this relevant? Insertion and traversal

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

Steven D'Aprano wrote: Gisle Aas wrote: Instead of introducing a sorteddict I would instead suggest that the future should bring an odict with a sort method; possibly also keys_sorted and items_sorted methods. Instead of odict.sorted(), that can be spelled: sorted(odict) # sort the keys so

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

Raymond Hettinger wrote: [...] > FWIW, PEP 372 has links to seven other independent implementations and > they all have names that are some variant spelling OrderedDict except > for one which goes by the mysterious name of StableDict. > > Am still +1 on painting the class green with pink polka dot

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

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? Yes. The popitem() method is O(1). Raymond ___ Python-Dev mailing list Python-Dev@python.org

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

Benjamin Peterson wrote: > Yes, I'm already looking forward to Py4k now. :) Shh, Guido will need at least 5 years before he's ready to contemplate going through something like this again. Or maybe a decade to be on the safe side ;) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com |

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

Gisle Aas wrote: Instead of introducing a sorteddict I would instead suggest that the future should bring an odict with a sort method; possibly also keys_sorted and items_sorted methods. Instead of odict.sorted(), that can be spelled: sorted(odict) # sort the keys sorted(odict.values()) #

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

Hello all, First a comment on-thread: I can't wait to get an ordered dictionary in the stdlib! The discussion regarding suggestions for the name appears to be ongoing. What about the name 'orderdict' instead of 'ordereddict'?. It doesn't contain the double-d, is slightly shorter, and I think a l

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

On Mar 4, 2009, at 9:01 , Glenn Linderman wrote: On approximately 3/3/2009 11:22 PM, came the following characters from the keyboard of Raymond Hettinger: Perhaps the terminology should be ordereddict -- what we have here sorteddict -- hypothetical future type that keeps its

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

On Wed, 4 Mar 2009 05:23:33 pm Glenn Linderman wrote: > The problem with the ordereddict/OrderedDict/odict is that there > are way too many possible orderings, and without being more > specific (InsertionSequenceOrderPreservingDictionary) people are > doing to think "sort" when they hear "ordered".

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

On approximately 3/3/2009 11:22 PM, came the following characters from the keyboard of Raymond Hettinger: Perhaps the terminology should be ordereddict -- what we have here sorteddict -- hypothetical future type that keeps itself sorted in key order +1 -1 Introducing