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), and
b) easing
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.
On Mon, Mar 2, 2009 at 1:14 PM, Paul Moore p.f.mo...@gmail.com wrote:
2009/3/2 Jeffrey Yasskin jyass...@gmail.com:
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
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
On Tue, Mar 3, 2009 at 11:20 AM, Forest list8a.for...@tibit.com 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?
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
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 patches
[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
On Tue, March 3, 2009 11:54 am, Guido van Rossum wrote:
On Tue, Mar 3, 2009 at 11:20 AM, Forest list8a.for...@tibit.com 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
On Tue, Mar 3, 2009 at 12:02 PM, Raymond Hettinger pyt...@rcn.com 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
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tres Seaver wrote:
Guido van Rossum wrote:
On Wed, Oct 8, 2008 at 6:39 PM, Bill Janssen jans...@parc.com wrote:
Josiah Carlson josiah.carl...@gmail.com wrote:
But yes, zope needs to be changed to reflect the updated
asyncore/asynchat semantics.
2009/3/3 Daniel (ajax) Diniz aja...@gmail.com:
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
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
[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
On Tue, Mar 3, 2009 at 12:23 PM, Tres Seaver tsea...@palladion.com 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,
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...
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
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.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Guido van Rossum wrote:
On Tue, Mar 3, 2009 at 12:23 PM, Tres Seaver tsea...@palladion.com 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
On Tue, Mar 3, 2009 at 1:17 PM, gl...@divmod.com 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
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
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.
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
On Tue, Mar 3, 2009 at 3:05 PM, Scott David Daniels
scott.dani...@acm.org 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
On Tue, Mar 3, 2009 at 05:13, rdmur...@bitdance.com 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
On Tue, Mar 3, 2009 at 5:15 PM, Brett Cannon br...@python.org wrote:
On Tue, Mar 3, 2009 at 05:13, rdmur...@bitdance.com 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
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
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
On Tue, Mar 3, 2009 at 17:30, Eric Smith e...@trueblade.com 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
Brett Cannon wrote:
On Tue, Mar 3, 2009 at 17:30, Eric Smith e...@trueblade.com
mailto:e...@trueblade.com 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
2009/3/3 Brett Cannon br...@python.org:
On Tue, Mar 3, 2009 at 17:30, Eric Smith e...@trueblade.com 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
On 3 Mar, 10:20 pm, gu...@python.org wrote:
On Tue, Mar 3, 2009 at 1:17 PM, gl...@divmod.com 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
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
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
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
36 matches
Mail list logo
