Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections ready for pronouncement
On Wed, Wed, 4 Mar 2009 13:52:59 -0800, Guido van Rossum wrote: On Wed, Mar 4, 2009 at 1:44 PM, Greg Ewing greg.ew...@canterbury.ac.nz 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*. Please, stick with OrderedDict. That's the name used historically by most people who independently reinvented this functionality. It's also what I typed into google and PYPI when I went looking for this functionality. +1 for odereddict or odict or OrderedDict. ___ 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 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 the hypothetical sorteddict would serve to reduce the likelihood of ordereddict being interpreted as sorteddict among the small percentage of people that actually read the two lines that might mention it in the documentation, but wouldn't significantly aid the intuition of people who first encounter it in someone else's code. And without an implementation, it would otherwise be documentation noise, not signal. FIFOdict ? Yeah, that blows the capitalization scheme, way, way out. Issues: * The popitem() method is LIFO. But traversal starts at the other end, if I understand correctly. popitem seems gratuitous (but handy and cheap) * In a non-popping context, there is no OUT. It just stores. * FIFO is more suggestive of queue behavior which does not apply here. It is suggestive of queue behavior, and the items are a queue if looked at from insertion, and traversal perspectives, if I understand correctly. But without OUT, FIFO is a bit too aggressively suggestively of queues... but not more so than ordereddict is a bit too suggestive of sorted behavior... And at least FIFO doesn't have the sorting connotation. * 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. Well, just because six other independent implementations use a name with connotations that they don't live up to is no reason to perpetuate such foolishness, nor introduce it into the Python stdlib. StableDict, eh? That's not so mysterious, perhaps, if you think of stable sorts^H^H^H^H^H (whoops, there's the wrong connotation rearing its ugly head again, sorry). 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 ;-) Sure. I didn't expect FIFOdict to be an extremely useful suggestion, but I wanted to make the point that if the name has an erroneous connotation, use a name that doesn't. And to get the discussion above flowing, to find out more about your thinking in the matter. InputOrderedDict might be more descriptive, yet not as long as that other atrocity I alluded to that you rightfully refused to quote :) From tree-walking, perhaps people would intuit the right connotations from InOrderDict which is no longer than ordereddict, but usually the tree is kept sorted too, so I'm afraid it might not be sufficient. Maybe SequenceDict ? SeqPreservingDict ? SeqDict ? All of these talk about sequences, which are generally not implied to be sorted. I like these well enough, and it is late enough, that I'm not going to think of more right now. 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 someone else's head... -- 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
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. For what it's worth, the first time I heard the term ordered dictionary, I assumed it would be a dict where the keys are kept in sorted order. But so what? Making things easy is an admirable goal, but we shouldn't lose sight of the fact that Python is a programming language, not a door handle. There's no requirement that every last feature is easy to intuit for a naive user. It's okay if people sometimes guess wrong, so long as they have opportunity to learn better. Speaking as an ignorant and lazy programmer, being user-friendly is one thing, but molly-coddling the ignorant and lazy is another. Especially when it takes just a few seconds to type import collections; help(collections.odict) and learn that the O stands for ordered, and that the order is specifically order of insertion rather than lexicographic order. Having good help text is user-friendly. Naming the class InsertionSequenceOrderPreservingDictionary is just dumbing down at the cost of usability. I trust this wasn't a serious suggestion, but just in case it was, I'll point out that we have dict instead of UnorderedKeyValueMapping. Does anyone think that people find Python harder to learn because of that choice? I think FIFOdict is a reasonable abbreviation for InsertionSequenceOrderPreservingDictionary :) I see your smiley, but in my opinion, the sort of programmer who can't work out what an OrderedDict (or odict) is, given the name, the doc string and the Internet, is going to have even more trouble working out what FIFOdict means. I have no strong feelings either way between odict and OrderedDict. PEP 8 seems to demand OrderedDict, but I actually prefer odict on the basis that an ordered dictionary feels like a fundamental data structure like str, list and dict rather than a specialist class like HTTPBasicAuthHandler. (I realise that fundamental data structure is not a well-defined category.) I look forward to the day OrderedDict becomes a built-in so it can be renamed odict :) -- Steven ___ 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 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 itself sorted in key order +1 -1 Introducing the hypothetical sorteddict would serve to reduce the likelihood of ordereddict being interpreted as sorteddict among the small percentage of people that actually read the two lines that might mention it in the documentation, but wouldn't significantly aid the intuition of people who first encounter it in someone else's code. And without an implementation, it would otherwise be documentation noise, not signal. 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. I think this would simplify things and putting these methods into the odict documentation makes it clearer how it actually behaves for people that just scan the method index to get an impression of what the object is about. Regards, Gisle ___ 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
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 little more typo-friendly. Just my 2c, please feel free to ignore. OrderDict would of course be the alternative-casing version. Secondly, regarding this list: I couldn't find a lot of documentation regarding list culture, so I'm quite nervous about the potential for stepping in where I'm not welcome before I have spent a lot of time 'spinning up' on this issues of this list. I am interested in learning more about how Python is written and, if I can, providing some assistance to that task. However it's going to be a long, slow process for me. At the same time, I do have firsthand knowledge of how hard it can be to get people to contribute to anything to any degree, and as such don't want to be a part of the problem by being too tentative in introducing myself. I would appreciate any pointers regarding what is appreciated on this list and what is not. Hopefully, over time I will be able to make some form of useful, concrete code contributions in the form of patches or documentation, but I do realise it will take a lot of hands-on learning first. Trying to grok the discussions on this list seems like a big part of that. Thanks, -Tennessee ___ 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
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()) # sort the items sorted(odict.items()) # sort the (key, value) pairs More complex variations are also possible. The idea of a SortedDict is that it should be sorted at all times, without needing an explicit sort method, e.g.: D = SortedDict(d=1, a=1, b=1) print D = SortedDict(a=1, b=1, d=1) D['c'] = 1 print D = SortedDict(a=1, b=1, c=1, d=1) If you need to call a sort method on the dict to generate the sorted version, you might as well just pass the values you want to sorted(). That's more flexible, as you can sort whatever you want by anything you like. I only know one use-case for a SortedDict: doctests. It's hard to use dicts in doctests, because when you print the dict, the items appear in arbitrary order. If you had a SortedDict, you could always predict what the dict would look like and use it in a doctest. Possibly there are other use-cases, but if so I don't know what they are. -- Steven ___ 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
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 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: [...] 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 ;-) This will be no surprise to those who have seen the many discussions on ordered dicts that c.l.py has spawned over the years. 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] 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 sorted(odict.values()) # sort the items sorted(odict.items()) # sort the (key, value) pairs All of these are useful, but not when you want to sort the odict in-place. Since ordered dict is all about order, a method for changing the underlying key order seems quite useful. An odict.sort() would be easy to implement both in the current code (where it would delegate to self._keys.sort()) and in an alternative implementation using a linked list of keys (variants of mergesort work very nicely with linked lists). The idea of a SortedDict is that it should be sorted at all times, A SortedDict would be nice to have, but we might rather want to use a balanced tree for the its C implementation, i.e. not inherit from dict at all. ___ 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
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 are only two parts of dict behaviour, whether ordered, sorted or otherwise. You can lookup, delete or modify items anywhere in the dict, not just at the ends. Doesn't sound very queue-like to me. [...] 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. Well, just because six other independent implementations use a name with connotations that they don't live up to is no reason to perpetuate such foolishness, nor introduce it into the Python stdlib. I don't believe the name is any more misleading than dict itself, or str. It is a standard well-known name. From Google: Results 1 - 10 of about 264 for StableDict Results 1 - 10 of about 6,880 for OrderedDict Results 1 - 10 of about 21,700 for ODict (I have made no effort to exclude false positives.) Yes, if you are a Martian or somebody learning to program for the first time, you have to learn what an ordered dict is. So what? You had to learn what a str was the first time you came across one too. StableDict, eh? That's not so mysterious, perhaps, if you think of stable sorts^H^H^H^H^H (whoops, there's the wrong connotation rearing its ugly head again, sorry). What does it mean to say a dict is stable? That is doesn't decay and rot away if you leave it alone? Do items evaporate out of ordinary dicts if you leave them alone for long enough? That once you add an item, you can't remove it or mutate it? It's not clear what the Stable in StableDict could mean. I didn't expect FIFOdict to be an extremely useful suggestion, but I wanted to make the point that if the name has an erroneous connotation, use a name that doesn't. FIFOdict is *far* more misleading, as it erroneously suggests that you can't (or at least shouldn't) access elements in the middle of the dict. From tree-walking, perhaps people would intuit the right connotations from InOrderDict which is no longer than ordereddict, but usually the tree is kept sorted too, so I'm afraid it might not be sufficient. No, I'm sorry, that's wrong. Inorder traversal of a binary tree is nothing like order-of-insertion traversal of a dict. node = 'a' node.right = 'c' node.left = 'b' Inorder traversal of node gives: b, a, c. Order-of-insertion traversal gives: a, c, b. C'mon folks, brainstorm, don't complain about ordereddict if you can't come up with some alternatives for discussion!!! There are two good alternatives: OrderedDict and odict, or as Raymond puts it, green with pink polka dots versus pink with green polka dots. I don't think there's much point in suggesting fluorescent orange with brown and grey stripes as well. -- Steven ___ 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
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 double-d, is slightly shorter, and I think a little more typo-friendly. Just my 2c, please feel free to ignore. OrderDict would of course be the alternative-casing version. The naming discussion is largely shooting the breeze at this point - the OrderedDict naming follows PEP 8 and has a decent history of use in this context, and I don't believe the objections and alternatives are compelling enough to get anyone to write the code necessary to change it. For such a recent patch the status quo wins by default argument isn't as strong as it can sometimes be, but it still carries some weight. Someone might surprise me and come forward with a patch to change the name, but I really doubt it at this point. Secondly, regarding this list: I would appreciate any pointers regarding what is appreciated on this list and what is not. Hopefully, over time I will be able to make some form of useful, concrete code contributions in the form of patches or documentation, but I do realise it will take a lot of hands-on learning first. Trying to grok the discussions on this list seems like a big part of that. I'd say you're off to a good start - wanting to learn and understand the existing culture rather than demanding that the current list members adapt to *your* style is a great first step :) As for the culture itself... 'respect' is the main word that comes to my mind: - respect for other people's time in trying to post messages that are concise and to the point - respect for other people's points of view in trying to resolve design disagreements - respect for other people's abilities in assuming that errors are inadvertent mistakes or due to a small misunderstanding rather than a result of sheer incompetence - respect for Python's users in ensuring a variety of perspectives are taken into account when considering changes Also, you may have looked at this already, but if not, the developer page has some useful pointers: http://www.python.org/dev/ http://www.python.org/dev/culture/ Hope that helps! 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] 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 double-d, is slightly shorter, and I think a little more typo-friendly. Just my 2c, please feel free to ignore. OrderDict would of course be the alternative-casing version. Secondly, regarding this list: I couldn't find a lot of documentation regarding list culture, so I'm quite nervous about the potential for stepping in where I'm not welcome before I have spent a lot of time 'spinning up' on this issues of this list. I am interested in learning more about how Python is written and, if I can, providing some assistance to that task. However it's going to be a long, slow process for me. At the same time, I do have firsthand knowledge of how hard it can be to get people to contribute to anything to any degree, and as such don't want to be a part of the problem by being too tentative in introducing myself. I would appreciate any pointers regarding what is appreciated on this list and what is not. Hopefully, over time I will be able to make some form of useful, concrete code contributions in the form of patches or documentation, but I do realise it will take a lot of hands-on learning first. Trying to grok the discussions on this list seems like a big part of that. Just dive in. We'll savage you when you get out of line :^). Seriously, as long as it's about development *of* rather than *with* Python, you should be OK. A couple of weeks lurking (or reading the list history) will tell you most things you need to know. regards Steve takes-all-sorts-to-make-a-world-ly y'rs - 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] 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
itself sorted in key order
+1
-1
Introducing the hypothetical sorteddict would serve to reduce the
likelihood of ordereddict being interpreted as sorteddict among the
small percentage of people that actually read the two lines that might
mention it in the documentation, but wouldn't significantly aid the
intuition of people who first encounter it in someone else's code.
And without an implementation, it would otherwise be documentation
noise, not signal.
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.
I think this would simplify things and putting these methods into the
odict documentation makes it clearer how it actually behaves for people
that just scan the method index to get an impression of what the object
is about.
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.
a = odict(bloh='foo', blah='faa')
a # odict([('bloh', 'foo'), ('blah', 'faa')])
b = odict(lambda a, b: (a[0] b[0]), bloh='foo', blah='faa')
b # sorted by key: odict([('blah', 'faa'), ('bloh', 'foo')])
c = odict(lambda a, b: (a[1] b[1]), bloh='foo', blah='faa')
c # sorted by value: odict([('blah', 'faa'), ('bloh', 'foo')])
b = odict(lambda a, b: (a[0] b[0]), bloh='foo', blah='faa')
b # sorted by key, descending: odict([('bloh', 'foo'), ('blah', 'faa')])
___
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: 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 ;-) historydict? 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] 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), a hash table (i.e. dict) probably isn't the right data structure to use as the basis for an always sorted container. In-memory databases, balanced trees, etc, etc. Further, unlike a more general sorted dictionary, an insertion ordered dict already has specific use cases in the standard library. ConfigParser will use it by default in 2.7/3.1 and namedtuple._asdict() is being changed in those versions to return an OrderedDict so that iterating over the result of _asdict() will process the fields in the same order as iterating over the tuple itself. It is also being added because an insertion ordered dictionary was the primary example for the new metaclass __prepare__ method introduced by PEP 3115. Adapting the example from that PEP: # The metaclass class OrderedClass(type): @classmethod def __prepare__(metacls, name, bases): # No keywords in this case return collections.OrderedDict() def __new__(cls, name, bases, classdict): # Note that we replace the classdict with a regular # dict before passing it to the superclass, so that we # don't continue to record the order after the class # has been created. result = type.__new__(cls, name, bases, dict(classdict)) result.member_names = list(classdict.keys()) return result # An instance of the metaclass class StructDef(metaclass=OrderedClass): # This dummy example uses types directly, but something # like struct module format codes may make more sense field1 = int field2 = float field3 = customType trailingField = str Unlike a normal class definition, the order of the field definitions in structure matters, and in the example above, this information is preserved by the metaclass. This can greatly simplify the process of defining types where the order of the fields matters (e.g. so the values can be serialised in the correct order for a binary translation of some kind). 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] 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: * 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 ;-) historydict? agedict? ___ 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 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 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 ;-) historydict? agedict? 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 problem with keeping OrderedDict as the name. (Ordered does not mean sorted, it means insertion order preserving may become a FQA (Frequent Question Answer :), but it is short and clear and takes no longer than explaining what a StableDict _is_.) Although, that might be another argument in favor of StableDict: since unless you think what I wrote above you aren't going to have a clue what it is, someone reading code and encountering it would be more likely to look it up, whereas with OrderedDict someone is more likely to assume they know what it is and get confused for a little while before looking it up. Do I feel strongly enough about this to write a patch? No :) --RDM ___ 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 Wed, Mar 4, 2009 at 3:01 AM, Glenn Linderman v+pyt...@g.nevcal.com 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 someone else's head... TemporalDict -- Since the order of insertion is important SerialDict -- From Websters: of, relating to, consisting of, or arranged in a series, rank, or row serial order -- Benji York ___ 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
rdmurray at 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 problem with keeping OrderedDict as the name. (Ordered does not mean sorted, it means insertion order preserving may become a FQA (Frequent Question Answer :), but it is short and clear and takes no longer than explaining what a StableDict _is_.) Thanks to Python (and Raymond :-)), I now know what polka dots are. Python-improves-my-English-skills'ly yours, Antoine. ___ 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
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 like in list, the first optional argument would be a function that returns the sorting key of the object. If the optional argument is not specified, the current ordereddict semantic (by insertion order) will be used. As the PEP mentions (and Hrvoje brought up again already in this thread), a hash table (i.e. dict) probably isn't the right data structure to use as the basis for an always sorted container. In-memory databases, balanced trees, etc, etc. 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? ___ 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 Wed, Mar 4, 2009 at 7:53 AM, 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. Nor can I at the moment think of an alternative explanation of what a StableDict might be. +1 -- Cheers, Leif ___ 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 Wed, Mar 4, 2009 at 7:53 AM, 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.
Nor can I at the moment think of an alternative explanation of what a
StableDict might be.
Hmm, perhaps a better explanation than a hasty +1:
stabledict makes me think of merge sort, being a stable sort. In
the same way that merge sort doesn't needlessly swap elements while
sorting, stabledict might be thought to not needlessly swap elements
while {inserting, deleting}. I also can't think of an alternative
explanation, so thus far, it's resistant to false positive semantics.
--
Cheers,
Leif
___
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
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 the end of a sequence is O(1), no search required. Inserting an item at a random 'sorted' point requires at best an O(logN) search. Insertion itself is O(1) to O(N) depending on the structure. ___ 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
Leif Walsh wrote:
On Wed, Mar 4, 2009 at 7:53 AM, 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.
Nor can I at the moment think of an alternative explanation of what a
StableDict might be.
Hmm, perhaps a better explanation than a hasty +1:
stabledict makes me think of merge sort, being a stable sort.
Why merge sort in particular? Why not bubble sort, heap sort, insertion
sort or any one of many other stable sorts?
Is this analogy really simpler than merely learning the fact that the
dict keys are kept in the order they are inserted? It's not a very
difficult concept. Why are we complicating it by inventing obscure,
complicated analogies with utterly unrelated functions?
In
the same way that merge sort doesn't needlessly swap elements while
sorting, stabledict might be thought to not needlessly swap elements
while {inserting, deleting}.
You're drawing an awfully long bow here. One might equally argue that in
the same way that bubble sort does lots and lots of swapping, stabledict
might be thought to be horribly inefficient and slow.
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.
--
Steven
___
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
Am 04.03.2009 14:25, Benji York schrieb: On Wed, Mar 4, 2009 at 3:01 AM, Glenn Linderman v+pyt...@g.nevcal.com 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 someone else's head... TemporalDict -- Since the order of insertion is important SerialDict -- From Websters: of, relating to, consisting of, or arranged in a series, rank, or row serial order Because the class is designed to only support insertion order and not any other sorting why choose a generic name that could also describe a class that supports a different order? 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. Dennis Benzinger ___ 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
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 little ambiguous - always sorted for an arbitrary key function is better handled with something other than a hash map + additional bookkeeping due to the effect on the speed of insertion and deletion. With a specifically insertion-ordered dict, only deletion is really slowed down by the additional bookkeeping: it drops to O(n) due to the need to find and remove the key being deleted from the sequence of keys as well as from the hash map). As Terry noted, supporting arbitrary sort orders would slow down insertion as well. 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] 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 this proliferation of dict types with different sort orders ever happening. The distinction between OrderedDict and dict is that the order of keys()/values()/items() isn't arbitrary the way it is in a regular dict - there's a defined order that will always be used. That's all the name tells you - if someone assumes they know what that ordering is without actually looking at the documentation (and gets it wrong as a result), then I don't see how that is any different from the fact that someone might mistakenly assume that list.sort() puts the items in descending order instead of ascending order. For other sort orders, it seems far more likely to me that a collections.SortedMap type would be added at some point in the future that accepts a key function like the one accepted by sorted() and list.sort(). Such a data type would make different trade-offs between insertion, deletion and lookup speeds than those made in the hash map based OrderedDict. 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] 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-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 Wed, Mar 4, 2009 at 1:44 PM, Greg Ewing greg.ew...@canterbury.ac.nz 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*. Please, stick with OrderedDict. That's the name used historically by most people who independently reinvented this functionality. -- --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
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 is stable because it has no bugs, unlike the buggy dict ___ 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:
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 the end of a sequence is O(1), no search required.
Inserting an item at a random 'sorted' point requires at best an
O(logN) search. Insertion itself is O(1) to O(N) depending on the
structure.
Yeah, but with a proper algorithm[1] it is possible to get a O(1) append
(which is the characteristic we want for insertion order dictionary,
while falling back to O(log n) if we explicitly give comparer function
(or comparison key extractor).
[1] The insertion algorithm will test for where to insert from the end
of the list. This way, insertion-order dict will still be O(1) (with an
increased constant), else if custom order is specified insertion it will
be O(n)
#UNTESTED BECAUSE I DON'T HAVE PYTHON CURRENTLY
# Note that it derives from OrderDict
class MyOrderDict(OrderDict):
def __init__(*args, **kwds):
if len(args) 2:
raise TypeError('expected at most 2 arguments')
if len(args) == 2:
self._cmp, args = args[0], args[1:]
else:
self._cmp = lambda a, b: True
if not hasattr(self, '_keys'):
self._keys = []
self.update(*args, **kwds)
def __setitem__(self, key, value):
if key not in self:
self._key.append(None)
for i, k in enumerate(reversed(self._key)):
i = -i - 1
if self._cmp((k, self[k]), (key, value)):
self._key[i], self._key[i - 1] = k, key
else:
self._key[i] = k
dict.__setitem__(self, key, value)
___
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
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 of I as a prefix for interfaces. Except I just don't see this proliferation of dict types with different sort orders ever happening. Maybe there's a misunderstanding because I don't see it either. I was trying to suggest four alternative names for the OrderedDict class. I don't prefer encoding every possible sort order into the class name. I just wanted to improve the name of OrderedDict. The distinction between OrderedDict and dict is that the order of keys()/values()/items() isn't arbitrary the way it is in a regular dict - there's a defined order that will always be used. Yes, the insertion order. That's all the name tells you - if someone assumes they know what that ordering is without actually looking at the documentation (and gets it wrong as a result), then I don't see how that is any different from the fact that someone might mistakenly assume that list.sort() puts the items in descending order instead of ascending order. And because that's all the name tells you I suggested to make the name more clear by prepending Ins or Insertion. For other sort orders, it seems far more likely to me that a collections.SortedMap type would be added at some point in the future that accepts a key function like the one accepted by sorted() and list.sort(). Such a data type would make different trade-offs between insertion, deletion and lookup speeds than those made in the hash map based OrderedDict. [...] Yes. Dennis Benzinger ___ 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] 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] 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] 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] 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] 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
Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections ready for pronouncement
2009/3/1 Armin Ronacher armin.ronac...@active-4.com: Hi everybody, PEP 372 was modified so that it provides a simpler API (only the dict API to be exact) and it was decided to start with a Python-only implementation and replace it with a C version later if necessary. Annotated changes from earlier versions of the PEP: - the extra API for ordered dict was dropped to keep the interface simple and clean. Future versions can still be expanded but it's impossible to drop features later on. - To keep the implementation simple 3.1 / 2.7 will ship with a Python-only version of the class. It can still be rewritten in C if it turns out to be too slow or thread safety is required. The corresponding issue in the tracker: http://bugs.python.org/issue5397 Link to the PEP: http://www.python.org/dev/peps/pep-0372/ Anything else that should be done? Have you considered naming? I would think that odict or ordereddict would be more consistent with other collections names especially defaultdict. -- 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
Benjamin Peterson schrieb: 2009/3/1 Armin Ronacher armin.ronac...@active-4.com: Hi everybody, PEP 372 was modified so that it provides a simpler API (only the dict API to be exact) and it was decided to start with a Python-only implementation and replace it with a C version later if necessary. Annotated changes from earlier versions of the PEP: - the extra API for ordered dict was dropped to keep the interface simple and clean. Future versions can still be expanded but it's impossible to drop features later on. - To keep the implementation simple 3.1 / 2.7 will ship with a Python-only version of the class. It can still be rewritten in C if it turns out to be too slow or thread safety is required. The corresponding issue in the tracker: http://bugs.python.org/issue5397 Link to the PEP: http://www.python.org/dev/peps/pep-0372/ Anything else that should be done? Have you considered naming? I would think that odict or ordereddict would be more consistent with other collections names especially defaultdict. We're already quite inconsistent with type name casing in the collections module, so it wouldn't matter so much. (Though I'd find symmetry with defaultdict pleasing as well.) Georg ___ 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 Mon, Mar 2, 2009 at 1:28 PM, Georg Brandl g.bra...@gmx.net wrote: Benjamin Peterson schrieb: 2009/3/1 Armin Ronacher armin.ronac...@active-4.com: Hi everybody, PEP 372 was modified so that it provides a simpler API (only the dict API to be exact) and it was decided to start with a Python-only implementation and replace it with a C version later if necessary. Annotated changes from earlier versions of the PEP: - the extra API for ordered dict was dropped to keep the interface simple and clean. Future versions can still be expanded but it's impossible to drop features later on. - To keep the implementation simple 3.1 / 2.7 will ship with a Python-only version of the class. It can still be rewritten in C if it turns out to be too slow or thread safety is required. The corresponding issue in the tracker: http://bugs.python.org/issue5397 Link to the PEP: http://www.python.org/dev/peps/pep-0372/ Anything else that should be done? Have you considered naming? I would think that odict or ordereddict would be more consistent with other collections names especially defaultdict. We're already quite inconsistent with type name casing in the collections module, so it wouldn't matter so much. (Though I'd find symmetry with defaultdict pleasing as well.) +1 for odict. Somehow I thought that was the name proposed by the PEP. :-( -- --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
Hi, Georg Brandl g.brandl at gmx.net writes: We're already quite inconsistent with type name casing in the collections module, so it wouldn't matter so much. (Though I'd find symmetry with defaultdict pleasing as well.) We either have the way to be consistent with defaultdict and dict or with Counter, MutableMapping etc. I think it's a bit too chaotic already to make a fair decision here. If we seriously consider a C implementation it would probably be a good idea to call it `odict`. C-Classes are usually lower cased as far as I can see. Regards, Armin ___ 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
Benjamin Peterson wrote: 2009/3/1 Armin Ronacher armin.ronac...@active-4.com: [...] The corresponding issue in the tracker: http://bugs.python.org/issue5397 Link to the PEP: http://www.python.org/dev/peps/pep-0372/ Anything else that should be done? Have you considered naming? I would think that odict or ordereddict would be more consistent with other collections names especially defaultdict. Surely that's just a thinko in the subject line? The PEP specifies ordered dictionary and nobody has been talking about directories. 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] PEP 372 -- Adding an ordered directory to collections ready for pronouncement
2009/3/2 Armin Ronacher armin.ronac...@active-4.com: Hi, Georg Brandl g.brandl at gmx.net writes: We're already quite inconsistent with type name casing in the collections module, so it wouldn't matter so much. (Though I'd find symmetry with defaultdict pleasing as well.) We either have the way to be consistent with defaultdict and dict or with Counter, MutableMapping etc. I think normal class names are fine for ABCs, but I brought it up because the other dictionary class in collections had a all lowername. I think it's a bit too chaotic already to make a fair decision here. If we seriously consider a C implementation it would probably be a good idea to call it `odict`. C-Classes are usually lower cased as far as I can see. I don't implementation language should determine naming. -- 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
Guido van Rossum guido at python.org writes: +1 for odict. Somehow I thought that was the name proposed by the PEP. It originally was, Raymond wanted to change it. I would still vote for odict if that's still possible :) Regards, Armin ___ 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
Steve Holden steve at holdenweb.com writes: Surely that's just a thinko in the subject line? The PEP specifies ordered dictionary and nobody has been talking about directories. Actually, the initial version of the PEP had that typo in the topic. Guess I copy pasted wrong again: http://www.google.com/search?q=%22adding+an+ordered+directory%22 Regards, Armin ___ 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
/bikeshedding Yes. Also we need to paint it green with pink polka dots :-) ___ 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: +1 for odict. Somehow I thought that was the name proposed by the PEP. :-( The examples in the PEP used 'odict' (until recently), but the patch was for OrderedDict. I don't personally mind either way. 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] PEP 372 -- Adding an ordered directory to collections ready for pronouncement
Raymond Hettinger wrote: /bikeshedding Yes. Also we need to paint it green with pink polka dots :-) Or should that be pink with green polka dots? ;) 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] PEP 372 -- Adding an ordered directory to collections ready for pronouncement
[Nick Coghlan] The examples in the PEP used 'odict' (until recently), but the patch was for OrderedDict. As an experiment, try walking down the hall asking a few programmers who aren't in this conversion what they think collections.odict() is? Is it a class or function? What does it do? Can the English as second language folks guess what the o stands for? Is it a builtin or pure python? My guess is that the experiment will be informative. When we use the class, we typically only spell-out the constructor once while actually using the returned object many times. So, have we really saved any typing? In the context of other applications, which is clearer? json.loads(jtext, object_pairs_hook=odict) config = ConfigParser(dict_type=odict) or json.loads(jtext, object_pairs_hook=OrderedDict) config = ConfigParser(dict_type=OrderedDict) I find the former to be non-communicative. 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
Is it a class or function? What does it do? Can the English as second language folks guess what the o stands for? Is it a builtin or pure python? My guess is that the experiment will be informative. I'll do that tomorrow (if I manage to remember). My guess is that ordered dictionary is as descriptive to them as odict or blonzo (well, perhaps they do recognize the dictionary part of it, and manage not to confuse it with directory). As for the ordered part, my guess is that most people will suggest that it means sorted (native speakers or not). Regards, Martin ___ 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
2009/3/2 Armin Ronacher armin.ronac...@active-4.com: Hi, Raymond Hettinger python at rcn.com writes: When we use the class, we typically only spell-out the constructor once while actually using the returned object many times. So, have we really saved any typing? I'm fine with the typed out name as well, but I still would prefer lowercase to stay consistent with defaultdict/dict. +1 -- 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
Unfortunately PEP 8 never really took off naming-wise, so we're mostly following the reuse the naming scheme from existing code in the same module rule, and I think there lowercase wins, thanks to defaultdict. Traditionally, the all lowercase name referred to a C type. The other classes in collections are named Counter, UserDict, UserList, UserString, MutableMapping, etc. Besides, the lowercase/uppercase distinction helps us distinguish functions from classes. This is the way I've see every Python book do it since the dawn of time. 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 Mon, Mar 2, 2009 at 3:13 PM, Raymond Hettinger pyt...@rcn.com wrote: Unfortunately PEP 8 never really took off naming-wise, so we're mostly following the reuse the naming scheme from existing code in the same module rule, and I think there lowercase wins, thanks to defaultdict. Traditionally, the all lowercase name referred to a C type. The other classes in collections are named Counter, UserDict, UserList, UserString, MutableMapping, etc. Besides, the lowercase/uppercase distinction helps us distinguish functions from classes. This is the way I've see every Python book do it since the dawn of time. Then they're all wrong. In 3.0 we're moving away from this, e.g. cPickle is gone, so is cStringIO. The implementation language should not shine through. *Maybe* the built-in status should guide the capitalization, so only built-in types are lowercase (str, int, dict etc.). Anyway, it seems the collections module in particular is already internally inconsistent -- NamedTuple vs. defaultdict. In a sense defaultdict is the odd one out here, since these are things you import from some module, they're not built-in. Maybe it should be renamed to NamedDict? -- --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
[GvR] *Maybe* the built-in status should guide the capitalization, so only built-in types are lowercase (str, int, dict etc.). That makes sense. Anyway, it seems the collections module in particular is already internally inconsistent -- NamedTuple vs. defaultdict. FWIW, namedtuple() is a factory function that creates a class, it isn't a class itself. There are no instances of namedtuple(). Most functions are all lowercase. Don't know if that applies to factory functions too. 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
Hi, Guido van Rossum guido at python.org writes: Anyway, it seems the collections module in particular is already internally inconsistent -- NamedTuple vs. defaultdict. In a sense defaultdict is the odd one out here, since these are things you import from some module, they're not built-in. Maybe it should be renamed to NamedDict? I suppose you mean DefaultDict. That would actually be the best solution. Then the module would be consistent and the new ordered dict version would go by the name OrderedDict. Regards, Armin PS.: so is datetime.datetime a builtin then? :) ___ 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 Mon, Mar 2, 2009 at 3:43 PM, Raymond Hettinger pyt...@rcn.com wrote: [GvR] *Maybe* the built-in status should guide the capitalization, so only built-in types are lowercase (str, int, dict etc.). That makes sense. Anyway, it seems the collections module in particular is already internally inconsistent -- NamedTuple vs. defaultdict. FWIW, namedtuple() is a factory function that creates a class, it isn't a class itself. There are no instances of namedtuple(). Most functions are all lowercase. Don't know if that applies to factory functions too. This is unfortunately ambiguous; e.g. threading.Lock() is a factory function too. Anyways, I was mistaken about this example; I should have pointed to Counter and the UserXxx classes in collections.py. On Mon, Mar 2, 2009 at 3:44 PM, Armin Ronacher armin.ronac...@active- I suppose you mean DefaultDict. Yes, I've been distracted. :-( That would actually be the best solution. Then the module would be consistent and the new ordered dict version would go by the name OrderedDict. OK. PS.: so is datetime.datetime a builtin then? :) Another historic accident. Like socket.socket. :-( -- --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
Quick question? Is PEP 8 still current for what is being done in Py3.x? I just took a quick look and it says: Class Names Almost without exception, class names use the CapWords convention. Classes for internal use have a leading underscore in addition. - Original Message - From: Guido van Rossum gu...@python.org To: Raymond Hettinger pyt...@rcn.com Cc: python-dev@python.org; Armin Ronacher armin.ronac...@active-4.com Sent: Monday, March 02, 2009 3:38 PM Subject: Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections ready for pronouncement On Mon, Mar 2, 2009 at 3:13 PM, Raymond Hettinger pyt...@rcn.com wrote: Unfortunately PEP 8 never really took off naming-wise, so we're mostly following the reuse the naming scheme from existing code in the same module rule, and I think there lowercase wins, thanks to defaultdict. Traditionally, the all lowercase name referred to a C type. The other classes in collections are named Counter, UserDict, UserList, UserString, MutableMapping, etc. Besides, the lowercase/uppercase distinction helps us distinguish functions from classes. This is the way I've see every Python book do it since the dawn of time. Then they're all wrong. In 3.0 we're moving away from this, e.g. cPickle is gone, so is cStringIO. The implementation language should not shine through. *Maybe* the built-in status should guide the capitalization, so only built-in types are lowercase (str, int, dict etc.). Anyway, it seems the collections module in particular is already internally inconsistent -- NamedTuple vs. defaultdict. In a sense defaultdict is the odd one out here, since these are things you import from some module, they're not built-in. Maybe it should be renamed to NamedDict? -- --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
On Mon, Mar 2, 2009 at 3:52 PM, Raymond Hettinger pyt...@rcn.com wrote: Quick question? Is PEP 8 still current for what is being done in Py3.x? I just took a quick look and it says: Class Names Almost without exception, class names use the CapWords convention. Classes for internal use have a leading underscore in addition. Yes, this is still the rule for new classes. I am *not* (have never been) in favor of a hasty overhaul of established APIs. Some of these were fixed for 3.0 (e.g. cPickle). The rest will just be deviant forever. Not a big deal as long as the number is fixed and limit. -- --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
Guido van Rossum wrote: On Mon, Mar 2, 2009 at 3:43 PM, Raymond Hettinger pyt...@rcn.com wrote: [GvR] *Maybe* the built-in status should guide the capitalization, so only built-in types are lowercase (str, int, dict etc.). That makes sense. Anyway, it seems the collections module in particular is already internally inconsistent -- NamedTuple vs. defaultdict. FWIW, namedtuple() is a factory function that creates a class, it isn't a class itself. There are no instances of namedtuple(). Most functions are all lowercase. Don't know if that applies to factory functions too. This is unfortunately ambiguous; e.g. threading.Lock() is a factory function too. Anyways, I was mistaken about this example; I should have pointed to Counter and the UserXxx classes in collections.py. On Mon, Mar 2, 2009 at 3:44 PM, Armin Ronacher armin.ronac...@active- I suppose you mean DefaultDict. Yes, I've been distracted. :-( That would actually be the best solution. Then the module would be consistent and the new ordered dict version would go by the name OrderedDict. OK. 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. 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] PEP 372 -- Adding an ordered directory to collections ready for pronouncement
On Mon, 02 Mar 2009 14:36:32 -0800, Raymond Hettinger wrote: [Nick Coghlan] The examples in the PEP used 'odict' (until recently), but the patch was for OrderedDict. As an experiment, try walking down the hall asking a few programmers who aren't in this conversion what they think collections.odict() is? Is it a class or function? What does it do? Can the English as second language folks guess what the o stands for? Is it a builtin or pure python? My guess is that the experiment will be informative. 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 beleive he was partly misguided by his knowledge of C++. C++ has always had std::map which returns sorted data upon iteration (it's a binary tree); they're now adding std::unordered_map (and std::unordered_set), to be implemented with a hash table. So, if you come from C++, it's easy to mistake the meaning of an ordered dict. This said, I don't have a specific suggestion, but I would stay with lowercase-only for simmetry with defaultdict. -- Giovanni Bajo Develer S.r.l. http://www.develer.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
