Mailman 3 August 2001 - Python-Dev

Inline caveat
by Skip Montanaro Aug. 23, 2001

Aug. 23, 2001

There is, of course, a definite downside to Inline. Your code will get harder to read and maintain because you and whoever else has to maintain your code has to be familiar with all the languages you are inlining. Skip

5 7

PEP 265 - Sorting Dictionaries by Value
by Grant Griffin Aug. 23, 2001

Aug. 23, 2001

PEP: 265 Title: Sorting Dictionaries by Value Version: $Revision: 0.1 $ Author: g2(a)iowegian.com (Grant Griffin) Status: Draft Type: Standards Track Created: 8-Aug-2001 Python-Version: 2.2 Post-History: Abstract This PEP suggests a "sort by value" operation for dictionaries. The primary benefit would be in terms of "batteries included" support for a common Python idiom which, in its current form, is both difficult for beginners to understand and cumbersome for all to implement. Motivation … [View More]A common use of dictionaries is to count occurrences by setting the value of d[key] to "1" on its first occurrence, then increment the value on each subsequent occurrence. This can be done several different ways, but the "get" method is the most succinct: d[key] = d.get(key, 0) + 1 Once all occurrences have been counted, a common use of the resulting dictionary is to print the occurrences in occurrence-sorted order, often with the largest value first. This leads to a need to sort a dictionary's items by value. The canonical method of doing so in Python is to first use d.items() to get a list of the dictionary's items, then invert the ordering of each item's tuple from (key, value) into (value, key), then sort the list; since Python sorts the list based on the first item of the tuple, the list of (inverted) items is therefore sorted by value. If desired, the list can then be reversed, and the (value, key) tuples can be re- inverted back to (key, value). (However, in my experience, the inverted tuple ordering is fine for most purposes, e.g. printing out the list.) For example, given an occurrence count of: >>> d = {'a':2, 'b':23, 'c':5, 'd':17, 'e':1} we might do: >>> items = d.items() >>> items = [(v, k) for (k, v) in items] >>> items.sort() >>> items.reverse() # so largest is first >>> items = [(k, v) for (v, k) in items] resulting in: >>> items [('b', 23), ('d', 17), ('c', 5), ('a', 2), ('e', 1)] which shows the list in by-value order, largest first. (In this case, 'b' was found to have the most occurrences.) This works fine, but is "hard to use" in two aspects. First, although this idiom is known to veteran Pythoneers, it is not at all obvious to newbies--either in terms of its algorithm (inverting the ordering of item tuples) or its implementation (using list comprehensions--which are difficult for beginners.) Second, it requires having to repeatedly type a lot of "gunge", resulting in both tedium and mistakes. We therefore would rather Python provide a method of sorting dictionaries by value which would be both easy for newbies to understand (or, better yet, not to _have to_ understand) and easier for all to use. Rationale As Tim Peters has pointed out, this sort of thing brings on the problem of trying to be all things to all people. Therefore, we will limit its scope to try to hit "the sweet spot". Unusual cases (e.g. sorting via a custom comparison function) can, of course, be handled "manually" using present methods. Here are some simple possibilities: The "items" method of dictionaries can be augmented with new parameters having default values that provide for full backwards-compatibility: 1) items(sort_by_values=0, reversed=0) or maybe just: 2) items(sort_by_values=0) since reversing a list is easy enough. Alternatively, items() could simply let us control the (key, value) order: 3) items(values_first=0) Again, this is fully backwards-compatible. It does less "work" than the others, but it at least eases the most complicated/tricky part of the sort-by-value problem: inverting the order of item tuples. Using this is very simple: items = d.items(1) items.sort() items.reverse() # (if desired) The primary drawback of the preceding three approaches is the additional overhead for the parameter-less "items()" case, due to having to process default parameters. (However, if one assumes that items() gets used primarily for creating sort-by-value lists, this is not really a drawback in practice.) Alternatively, we might add a new dictionary method which somehow embodies "sorting". This approach offers two advantages. First, it avoids adding overhead to the items() method. Second, it is perhaps more accessible to newbies: when they go looking for a method for sorting dictionaries, they hopefully run into this one, and they will not have to understand the finer points of tuple inversion and list sorting to achieve sort-by-value. To allow the four basic possibilities of sorting by key/value and in forward/reverse order, we could add this method: 4) sorted_items(by_value=0, reversed=0) I believe the most common case would actually be "by_value=1, reversed=1", but the defaults values given here might lead to fewer surprises by users: sorted_items() would be the same as items() followed by sort(). Finally (as a last resort), we could use: 5) items_sorted_by_value(reversed=0) Implementation The proposed dictionary methods would necessarily be implemented in C. Presumably, the implementation would be fairly simple since it involves just adding a few calls to Python's existing machinery. Concerns Aside from the run-time overhead already addressed in possibilities 1- 3, concerns with this proposal probably will fall into the categories of "feature bloat" and/or "code bloat". However, I believe that several of the suggestions made here will result in quite minimal bloat, resulting in a good tradeoff between bloat and "value added". Tim Peters has noted that implementing this in C might not be significantly faster than implementing it in Python today. However, the major benefits intended here are "accessibility" and "ease of use", not "speed". Therefore, as long as it is not noticeably slower (in the case of plain "items()", speed need not be a consideration. References A related thread called "counting occurrences" appeared on comp.lang.python in August, 2001. This included examples of approaches to systematizing the sort-by-value problem by implementing it as reusable Python functions and classes. Copyright This document has been placed in the public domain. -------------------------------------------------------------------- Also...this just in from Tim Peters: <Tim> Here's one to add to the PEP as an alternative: dict.sort(sort_specifier) where sort_specifier is one of these strings: 'kv->kv' 'kv->vk' 'kv->k' 'kv->v' 'vk->kv' 'vk->vk' 'vk->k' 'vk->v' The first 4 sort by keys first, the second 4 by values first. The string to the right of '->' says whether you want a list of (key, value) pairs, (value, key) pairs, just keys, or just values. So to sort by values and return only the keys (corresponding to increasing order of values), dict.sort('vk->k') There are two other sort_specifier possibilities: 'k' 'v' dict.sort('k') is the same as ksort(dict): def ksort(dict): x=dict.keys() x.sort() return x and similarly for dict.sort('v') returning dict.values() sorted. Reversals are the user's problem. </Tim> Your comments and suggestions are welcome and appreciated. I think the two big questions for the community here are: 1) Is this useful enough to justify the feature/code bloat? (Tim has suggested that this might be a hard sell to Guido, so if you like it in whatever form, let's hear from you!) 2) Of all the many possibilities, which do you find the most useful and Pythonic? thanks-much-ly y'rs, =g2 -- _____________________________________________________________________ Grant R. Griffin g2(a)dspguru.com Publisher of dspGuru http://www.dspguru.com Iowegian International Corporation http://www.iowegian.com [View Less]

7 12

Re: copy, len and the like as 'object' methods?
by Moore, Paul Aug. 23, 2001

Aug. 23, 2001

> I can appreciate that your tastes are different from > mine...in fact I said something similar to David when he > first suggested it to me but on reflection it seemed such > a subtle thing when compared against the weirdness of the > definition of len: > > def len(obj): > return obj.__length__() > > It does a little bit more but not much! A strange thought, but with the advent of type/class unification and the 'object' base class, is it possible to … [View More]

2 1

copy, len and the like as 'object' methods?
by James_Althoff＠i2.com Aug. 23, 2001

Aug. 23, 2001

David Ascher wrote: >Again, I wasn't considering getting rid of old builtins. We're going to >be adding new methods to all of the types anyway (since they'll derive >from object), so I was just suggesting that len or length be an alias >for __len__. (While admittedly being an OO zealot ;-) I too would be pleased to see a len/length method. And I really enjoy using the new string methods. Thanks for adding them! :-) Jim

9 14

Re: copy, len and the like as 'object' methods?
by Greg Wilson Aug. 23, 2001

Aug. 23, 2001

FWIW, David's 'len()' methods would definitely make Python easier to teach --- just about every beginner types 'x.len()' instead of 'len(x)' over and over during their first two or three exercises. Greg ----------------------------------------------------------------------------------------------------------------- The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error or there are any problems please … [View More]

3 2

PEP 268 - Extended HTTP functionality and WebDAV
by Greg Stein Aug. 23, 2001

Aug. 23, 2001

I've completed my first draft of PEP 268 and am seeking feedback. http://python.sourceforge.net/peps/pep-0268.html My next step is to begin implementing the 'httpx' module and rejiggering the 'davlib' module. This work will occur in the /nondist/sandbox/ area (probably under a Lib subdir there). This work is intended to go into Python 2.2. Possibly appearing in time for 2.2a3, but 2.2b1 at the latest. Cheers, -g -- Greg Stein, http://www.lyra.org/

2 1

Near Final PEP 237 - Unifying Long Integers and Integers
by Guido van Rossum Aug. 23, 2001

Aug. 23, 2001

Please comment on a new version of PEP 237: http://python.sourceforge.net/peps/pep-0237.html I've updated a few parts of the PEP for more accuracy and to reflect more implementation details. I've had very few negative responses to this PEP, and quite a few positive, so I'm assuming this is not controversial and we can follow the transition plan described in the PEP. Only phase A of the transition plan will be implemented in Python 2.2. I've implemented phase A completely, and tentatively … [View More]

2 1

copy, len and the like as 'object' methods?
by James_Althoff＠i2.com Aug. 22, 2001

Aug. 22, 2001

Guido wrote: >AFAICT, the len() method proposal is just an attempt to be more OO, >and to avoid being made fun of by a bunch of Perlers. I don't care >about #1, and it's naive to think that solving one issue will avoid >#2. I agree that it isn't so important to be swayed by #1 and #2 above. But there is a #3. I've introduced over fifty programmers (coming from Java) to Jython and a high percentage trip over this initially (momentarily, at least ;-). It doesn't take much to get … [View More]

1 0

RELEASED: Python 2.2a2 is out!
by barry＠zope.com Aug. 22, 2001

Aug. 22, 2001

We've released Python 2.2a2, the second alpha for Python 2.2, for your enjoyment, education, and edification. Download it from: http://www.python.org/2.2/ Give it a good try, and report what breaks to the bug tracker: http://sourceforge.net/bugs/?group_id=5470 New features in this release include: - Tim Peters developed a brand new Windows installer using Wise 8.1, generously donated to us by Wise Solutions. - The floor division operator // has been added as outlined in PEP 238. … [View More]

1 0

PEP 252, PEP 253 and jython issues
by Samuele Pedroni Aug. 22, 2001

Aug. 22, 2001

FYI I'm up to finish with the whole picture tour of PEP 252/PEP 253 wrt to pontential jython issues. My head has not exploded but I'm a bit worried: - on one hand for the amount of work that seems necessary on Jython side (but that's our problem) - on the other hand by some design tangle: how to mostly preserve the codebase, how to make the life for advanced users easy and natural, how to follow the spec. I hope both that I'm just not clever enough and I have overlooked things wrongly ... … [View More]

1 0