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), and b) easing conversion of code to 3.1 I am puzzled at the idea of adding a new facility to 2.7 that would not be in 3.1+. It would lock code into 2.7+ and counter purpose b). It's possible we will end up in a situation where 3.0 and 3.1 are both aligned with 2.6, while 2.7 aligns with 3.2. That's particularly so with only 6 months or so between 3.0 and 3.1, while I currently expect the gap between 2.6 and 2.7 to be closer to the traditional 18 months. 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. I suspect the discrepancy here relates to different views on the purpose of future 2.x releases. I would demote your two points above to be goals b) and c) and give its primary purpose as: a) Provide an updated 2.x compatible release with new features for the benefit of those not yet able to make the transition to the 3.x series. Some of those new features will be additional 3.x series backports, some of them will be new features that were added to both 2.x and 3.x at the same time. The only thing that I believe *shouldn't* happen is for 2.7 to be released with new features that aren't yet available in a 3.x release. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 is intended that Py3 have features that never appear in Py2. My suggestion is aimed at avoiding the possibility that a new feature such as simplegeneric appear in 2.7 and *not* in 3.x. [snip] The only thing that I believe *shouldn't* happen is for 2.7 to be released with new features that aren't yet available in a 3.x release. Which is the point of my suggestion -- correctly read and understood ;-). Terry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ABCs and MRO
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 simplegeneric, but not of fixing the issue with ABCs. I'm not sure the ABC issue is fixable - after all, it's by design that ABCs can implement __issubclass__ and magically become superclasses of arbitrary classes as a result. I'm not happy about fixing simplegeneric, though, as the whole point was just to expose an existing implementation, because it might be generally useful. If we start expanding and enhancing it, there are better implementations already available on PyPI (better in the sense of having seen real-world use). And if they don't handle ABCs, then that might indicate that needing to handle ABCs isn't as vital as this discussion would seem to imply (but I have no real-world data myself to make such a claim). One way to deal with __subclasscheck__ definitions other than ABCMeta.__subclasscheck__ would be to make the someone registered a subclass interface public in addition to the tell me when someone registers a subclass interface. Then other __subclasscheck__ definitions could call the someone registered a subclass method when the class is defined if they want to be usable with generic functions. I'm not sure I follow this. Can you clarify? My intuition is that *no* notification hook can deal with ABCs that code arbitrary checks in their __subclasscheck__ method (so there's no registration involved, particular classes just magically become subclasses). Hm, oops, you're right. So you'd have to scan the relevant abcs and cache the list that turns up true ... probably with cooperation from the ABCs so you'd know when to invalidate the cache. Ick. 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. You can get something similar to the mro by checking whether ABCs are subclasses of each other. The key point about the MRO is that you get it just from the initial class, via __mro__. You're not checking if another class is *in* the MRO, but rather you're *generating* the list of classes in the MRO. I was trying to reply to PJE's statement that The hairier issue for these types of systems is method precedence. I agree that getting the set of abcs for an instance is more difficult that I'd thought. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 value. 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 end from which to pop? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections ready for pronouncement
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? Yes. It pops-off the most recently inserted new key and its corresponding value. 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. What's your use case? If you really need this you can do it easily by taking the first key returned by the iterator: def popfirstitem(o): key = next(iter(o)) # raises StopIteration if o is empty value = o[key] del o[key] return key, value Shouldn't popitem() allow the caller to choose which end from which to pop? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 reviews as needed and ask-pretty-please-for-inclusion' :) Would early post-3.1a1 versus pre-3.1a1 make a difference in likelihood of proposed changes going in? I can try to come up with a detailed list before March 5, but I'd rather present it next week, after taking a look at all remaining open issues. FWIW, further tracker cleanup should happen sometime next week, let me know if you need any tracker janitorvelopment done :) Regards, Daniel [1] Current list: http://bugs.python.org/issue1097797 http://bugs.python.org/issue3244 http://bugs.python.org/issue736428 http://bugs.python.org/issue1175686 http://bugs.python.org/issue4733 [2] Examples: http://bugs.python.org/issue4953 http://bugs.python.org/issue1074333 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 patches to validate it and check it in. It's not a lot of code changes. Mitchell, thanks for the reports and patches you've been contributing. FWIW, I plan to follow up on these specific issues (and 5276) before 3.1a2, mostly to add tests and a +1 for integration. Regards, Daniel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 end from which to pop? Forest, I've taken another look at what's involved and am inclined to recommend the idea. It can be done without mucking-up the regular dict API and without precluding any of the other possible underlying algorithms. I like that it supports an entire new categoy of use cases with only a trivial, easily-understood API extension. Patch is attached at http://bugs.python.org/issue5397 Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 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 (od7.diff), I didn't notice one. Perhaps I simply missed something. What's your use case? An LRU cache which occasionally needs to scan the oldest keys in the underlying odict to see if they should be purged. If you really need this you can do it easily by taking the first key returned by the iterator: Yep. I simply missed something. That's what I get for reading patches while hungry. :) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 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 simply missed something. Shouldn't popitem() allow the caller to choose which end from which to pop? Forest, I've taken another look at what's involved and am inclined to recommend the idea. It can be done without mucking-up the regular dict API and without precluding any of the other possible underlying algorithms. I like that it supports an entire new categoy of use cases with only a trivial, easily-understood API extension. Patch is attached at http://bugs.python.org/issue5397 -1. This seems creeping featurism -- it's easy enough to do this without adding a custom method. (And Forest admitted as much.) However, reviewing your patch made me realize that the list of keys is accessible as o._keys. I recommend that you either make this a __private variable (signalling strongly that people shouldn't ever reference it), or alternatively make it a public API. Otherwise, if you just leave it _undocumented, people *are* going to figure out clever things they can do with it (e.g. o._keys.sort() will turn the odict into a sorted dict). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 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. Trust me; it's faster, cleaner, and easier to use now. Just for completeness, I built a fresh 2.6, installed Medusa (from http://www.amk.ca/python/code/medusa.html), and it runs just fine (well, as well as it does on 2.5, anyway). I think this is a Zope issue. Way back in the day, Zope monkeypatched whole parts of asyncore, replacing them with some of its own code. If that's still the case, this breakage should be no surprise. Zope has been hooking the 'asyncore.loop' function (wrapping it in order to add a clean shutdown' flog) since 2001 at least (the 2.5 branch is the earliest checkout I have, and it was branched in early January 2002). Zope also began patched asyncore's logging functions in 2.7, and later updated that patch to make the logger use the stdlib 'logging' module. I think the change we need to make (in ZServer/medusa/http_server.py) is to emulate the new 'writeable' implementation in asynchat, at least when running under 2.6. Zope's 'ZServer.medusa.http_server.http_request.writable()' implementation is:: def writable (self): # this is just the normal async_chat 'writable', # here for comparison return self.ac_out_buffer or len(self.producer_fifo) The Python 2.5 asynchat.asynchat.writable does:: def writable (self): predicate for inclusion in the writable for select() # return len(self.ac_out_buffer) or len(self.producer_fifo) or # (not self.connected) # this is about twice as fast, though not as clear. return not ( (self.ac_out_buffer == '') and self.producer_fifo.is_empty() and self.connected ) The Python 2.6 asynchat.asynchat.writable now does:: def writable (self): predicate for inclusion in the writable for select() return self.producer_fifo or (not self.connected) medusa 0.5.4's medusa.http_server.http_request doesn't override 'writable', but it does have a broken 'writeable_for_proxy': def writable_for_proxy (self): # this version of writable supports the idea of a 'stalled' # producer # [i.e., it's not ready to produce any output yet] This is # needed by # the proxy, which will be waiting for the magic combination of # 1) hostname resolved # 2) connection made # 3) data available. if self.ac_out_buffer: return 1 elif len(self.producer_fifo): p = self.producer_fifo.first() if hasattr (p, 'stalled'): return not p.stalled() else: return 1 *crickets*. The 2.6 version of asyncore *also* breaks supervisord, which does *not* use Zope's medusa: it uses medusa 0.5.4. 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. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJrZG0+gerLs4ltQ4RAnsmAJ9v/vPkHgE3AdP5ngVuYaKlxDGhJACgsCi2 3awbUffi2BU41qQgd6eJV18= =WBt6 -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] draft 3.1 release schedule
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 post-3.1a1 versus pre-3.1a1 make a difference in likelihood of proposed changes going in? I can try to come up with a detailed list before March 5, but I'd rather present it next week, after taking a look at all remaining open issues. Assuming you find reviews/committers for those patches, it's all good until the first beta. -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 popitem() allow the caller to choose which end from which to pop? Thinking it through a bit more, and LRU cache would actually need to access the oldest item before knowing whether to remove it. Besides, popitem() should probably retain the signature of dict.popitem(). I therefore retract my suggestion about popitem(). Still, I think an LRU cache would be a very common use case for an ordered dict. The current implementation already uses a list to keep track of order, which makes accessing the oldest key a simple matter of exposing it. Perhaps a new method like getfirst() would be worth while here? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 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, AFAICT. 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. Maybe packages requiring asyncore functionality should just copy the version of asyncore they like into their own three and stick with that. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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... or possibly twisted, as that new name? ;-) (Sorry, I was trying to avoid this thread, but that was an opening I could drive a truck through). In all seriousness, I seem to recall that Thomas Wouters was interested in doing integrating some portion of Twisted core into the standard library as of last PyCon. I mention him specifically by name in the hopes that it will jog his memory. 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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 talking about here -- basically a sequence type that holds things in arbitrary order, but with the additional ability to look things up quickly by a key. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 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, AFAICT. 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. Maybe packages requiring asyncore functionality should just copy the version of asyncore they like into their own three and stick with that. That was the very solution Chris came up with earlier today: stick a fork in it, its done! Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJraty+gerLs4ltQ4RAjBSAJ4niecZJusKY4XiioJ18mdhdMixxQCfWvcQ Dwkh1ZBuxtGRbhUI4qy96Sc= =ms0I -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] asyncore fixes in Python 2.6 broke Zope's version of medusa
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 proper design under a new name. Might I suggest reactor... or possibly twisted, as that new name? ;-) (Sorry, I was trying to avoid this thread, but that was an opening I could drive a truck through). In all seriousness, I seem to recall that Thomas Wouters was interested in doing integrating some portion of Twisted core into the standard library as of last PyCon. I mention him specifically by name in the hopes that it will jog his memory. 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 asyncore that a future-proof and maximally flexible design of such an API is not easy. This is one of those cases where I believe thinking hard up front will really pay off. In this case I would recommend going through a full-blown PEP process before committing to an API, to avoid making the same mistake twice. (I don't mean this as a dig at Twisted, just as an observation about this particular design problem. If Twisted solves all the problems already, writing the PEP should be easy.) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 name for what we're talking about here -- basically a sequence type that holds things in arbitrary order, but with the additional ability to look things up quickly by a key. I almost agree, except that the API uses the dict, not list, API. For instance, items are appended by adding a key, not with .append. With sort not available and .popitem removing the last added item, 'indexed stack' would be a bit closer. Indeed, I plan to try out odicts with graph algorithms that need keyed access to stacked items. tjr ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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. Shouldn't popitem() allow the caller to choose which end from which to pop? Thinking it through a bit more, and LRU cache would actually need to access the oldest item before knowing whether to remove it. Besides, popitem() should probably retain the signature of dict.popitem(). I therefore retract my suggestion about popitem(). Still, I think an LRU cache would be a very common use case for an ordered dict. The current implementation already uses a list to keep track of order, which makes accessing the oldest key a simple matter of exposing it. Perhaps a new method like getfirst() would be worth while here? But you must decide if what you want really does LRU -- does accessing the oldest entry make it the most recent entry? --Scott David Daniels scott.dani...@acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 keeps itself sorted in key order -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 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 current patch (od7.diff), I didn't notice one. Perhaps I simply missed something. Shouldn't popitem() allow the caller to choose which end from which to pop? Thinking it through a bit more, and LRU cache would actually need to access the oldest item before knowing whether to remove it. Besides, popitem() should probably retain the signature of dict.popitem(). I therefore retract my suggestion about popitem(). Still, I think an LRU cache would be a very common use case for an ordered dict. The current implementation already uses a list to keep track of order, which makes accessing the oldest key a simple matter of exposing it. Perhaps a new method like getfirst() would be worth while here? But you must decide if what you want really does LRU -- does accessing the oldest entry make it the most recent entry? Beware, deleting an item from an OrderedDict (in the current implementation) is O(N). To implement an LRU cache you are probably better off ignoring OrderedDict so that you can manipulate the list of keys directly. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding PEP consistent aliases for names that don't currently conform
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 addressed for 3.0. Way too late now, though. 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 can be switched in the distant future? As a user I'd be +1 on that. In fact, I might even start using 'as' in my own code for that purpose right now. I've always felt vaguely confused and disturbed whenever I imported 'datetime', but until this discussion I didn't realize why :) Thinking about it, I know I've written 'from datetime import DateTime' a number of times and then had to go back and fix my code when I tried to run it. And I'm sure that sometimes when that happens I've had to (re)read the docs (or do a 'dir') to find out why my import wasn't working. Having said all that out loud, I think I might be stronger than a +1 on this idea. I'd be willing to help with doc and even code patches once I finish learning how to contribute properly. +1 from me to fix these little mishaps in naming in both modules. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 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 historic accident. Like socket.socket. :-( A pity this stuff wasn't addressed for 3.0. Way too late now, though. A pity indeed. 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 can be switched in the distant future? +1, if it's not done in a rush and only for high-visibility modules -- let's start with socket and datetime. 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. As a user I'd be +1 on that. In fact, I might even start using 'as' in my own code for that purpose right now. I've always felt vaguely confused and disturbed whenever I imported 'datetime', but until this discussion I didn't realize why :) Thinking about it, I know I've written 'from datetime import DateTime' a number of times and then had to go back and fix my code when I tried to run it. And I'm sure that sometimes when that happens I've had to (re)read the docs (or do a 'dir') to find out why my import wasn't working. Having said all that out loud, I think I might be stronger than a +1 on this idea. I'd be willing to help with doc and even code patches once I finish learning how to contribute properly. +1 from me to fix these little mishaps in naming in both modules. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 can be switched in the distant future? Should the names in the __repr__ be changed now or later? datetime(2008, 7, 31, 12, 0, 0) datetime.datetime(2008, 7, 31, 12, 0) Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 tried to restructure the library in 2.6? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding PEP consistent aliases for names that don't currently conform
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 way, due to loading old pickles. Remember the problems we had when we tried to restructure the library in 2.6? Forever is a long time. =) If we keep the PendingDeprecationWarning for a long time and really get the word out of the renames then people can migrate their pickles over time. The real problem with the 2.6 reorg was that people didn't want to have zero lead time to update their pickles and they way the transition was being handled. In this case the old names and simply subclass the new names and have no issues with old code. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 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 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 tried to restructure the library in 2.6? Forever is a long time. =) If we keep the PendingDeprecationWarning for a long time and really get the word out of the renames then people can migrate their pickles over time. The real problem with the 2.6 reorg was that people didn't want to have zero lead time to update their pickles and they way the transition was being handled. In this case the old names and simply subclass the new names and have no issues with old code. There's also no reason why someone couldn't write a pickle updater for when such problems do rear their ugly heads. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding PEP consistent aliases for names that don't currently conform
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 names basically have to live forever in some way, due to loading old pickles. Remember the problems we had when we tried to restructure the library in 2.6? Forever is a long time. =) If we keep the PendingDeprecationWarning for a long time and really get the word out of the renames then people can migrate their pickles over time. The real problem with the 2.6 reorg was that people didn't want to have zero lead time to update their pickles and they way the transition was being handled. In this case the old names and simply subclass the new names and have no issues with old code. Yes, I'm already looking forward to Py4k now. :) -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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, 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 learned from asyncore that a future-proof and maximally flexible design of such an API is not easy. This is one of those cases where I believe thinking hard up front will really pay off. In this case I would recommend going through a full-blown PEP process before committing to an API, to avoid making the same mistake twice. (I don't mean this as a dig at Twisted, just as an observation about this particular design problem. If Twisted solves all the problems already, writing the PEP should be easy.) I didn't see it as a dig at Twisted; you're right, this is a hard problem. Twisted doesn't solve all the problems perfectly, either; much has been made of some rather unfortunate nuances of the IProducer and IConsumer interfaces. I also regret that no Twisted people (myself included) seem to have the time to go through the PEP process and get something accepted. Even if Twisted's interfaces aren't perfect, there's a lot of working application code which demonstrates that they are sufficient. Perhaps more importantly, they are future-proof. Every proposal we've come up with for addressing the more subtle shortcomings of these APIs has been completely backwards-compatible; there are no APIs with vague or broken semantics, just sub-optimal spellings. The fact that there are already multiple reactor implementations which share very little code helps. 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 lifted for the stdlib, or how a high level layer could be written into asyncore so that the author of a particular chunk of low-level networking code could ignore whether they're using the stdlib mainloop or one of the Twisted ones. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 terminology should be ordereddict -- what we have here sorteddict -- hypothetical future type that keeps itself sorted in key order FIFOdict ? Yeah, that blows the capitalization scheme, way, way out. 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. I think FIFOdict is a reasonable abbreviation for InsertionSequenceOrderPreservingDictionary :) -- Glenn -- http://nevcal.com/ === A protocol is complete when there is nothing left to remove. -- Stuart Cheshire, Apple Computer, regarding Zero Configuration Networking ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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-popping context, there is no OUT. It just stores. * FIFO is more suggestive of queue behavior which does not apply here. * Stores to existing keys don't go at the end; they leave the order unchanged. 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 dots, but I'm starting to appreciate why others are insisting on pink with green polka dots ;-) Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
