RE: [Python-Dev] dict.sortedkeys()
[Jeff Epler]
Factor sorted into a function that returns a sorted copy: def sorted(seq): seq = list(seq) seq.sort() return seq
or one that sorts in place: def sorted(seq): seq.sort() return seq
Now you can write your one-liner: for i in sorted({}.keys()): ...
Yes, of course. But I'm working on a large business app framework. That means either: 1. Writing sorted into every module where it's needed. 2. Putting sorted into a package somewhere, which makes it longer and uglier with absolute referencing. 3. Customizing consumers' Python install. ...none of which are good options. [Bob Ippolito]
I'm pretty sure that in Python 2.4 you will be able to say sorted(seq).
Excellent! That'll do nicely. :) -another bob
[Bob Ippolito]
I'm pretty sure that in Python 2.4 you will be able to say sorted(seq).
Excellent! That'll do nicely. :)
Even better, you'll be able to say sorted(iterable), and a dict is an iterable (yielding its keys), so you can say sorted(dict). $ ./python Python 2.4a0 (#93, Mar 31 2004, 10:08:22) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-113)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
import sys sorted(sys.modules) ['UserDict', '__builtin__', '__main__', '_codecs', '_sre', 'codecs', 'copy_reg', 'distutils', 'distutils.dep_util', 'distutils.distutils', 'distutils.errors', 'distutils.log', 'distutils.os', 'distutils.re', 'distutils.spawn', 'distutils.string', 'distutils.sys', 'distutils.util', 'encodings', 'encodings.aliases', 'encodings.codecs', 'encodings.exceptions', 'encodings.iso8859_15', 'encodings.types', 'exceptions', 'linecache', 'os', 'os.path', 'posix', 'posixpath', 're', 'readline', 'rlcompleter', 'signal', 'site', 'sre', 'sre_compile', 'sre_constants', 'sre_parse', 'stat', 'string', 'sys', 'types', 'warnings', 'zipimport']
--Guido van Rossum (home page: http://www.python.org/~guido/)
On Saturday 17 April 2004 10:21 pm, Robert Brewer wrote: ...
Yes, of course. But I'm working on a large business app framework. That means either:
1. Writing sorted into every module where it's needed. 2. Putting sorted into a package somewhere, which makes it longer and uglier with absolute referencing. 3. Customizing consumers' Python install.
...none of which are good options.
Is sorted the ONLY "utility" function your LARGE business app framework needs in addition to what comes with Python 2.3? That would really be utterly astounding to me. In my experience, when coding a large framework I always end up needing somewhere between 0.5 and 2 "utility functions" per tens of thousands of SLOCs (standardized lines of code -- logical lines, ignoring comments, blank lines, docstrings, &c). So, in a moderately large framework of 100,000 lines, I would expect to need somewhere between 5 and 20 utility functions (in addition to Python builtins, of course). I never expect Python's built-ins to swell to accomodate _every_ such minute need, of course. The only truly unacceptable alternative, in my opinion, is to repeat the coding for the utility functions more than once: as long as they're coded _once, and only once_, I'm a pretty happy camper. When I was relatively new as a Pythonista, I used to deal with "the utiliities issue" by injecting names in __builtin__ during the start-up of my framework: import __builtin__ import utils for u in utils.__all__: setattr(__builtin__, u, getattr(utils, u)) or the like. I have since decided that this is not at all a good idea -- as the number of utilities grows, there may be clashes with builtins, names being shadowed, etc, etc -- and the opacity of seeing a barename used and having to guess where it comes from is particularly unacceptable. These days, I far prefer to code, more simply: import __builtin__ # get error msg in case of conflict assert not hasattr(__builtin__, 'ut') import utils as ut __builtin__.ut = ut and access the utilities from everywhere as ut.sorted, ut.scrambled, etc, etc. ONE relatively mysterious barename is OK, it's always 'ut' or 'util' after all, and with nested packages etc it may be worth it to avoid the hassle of importing it repeatedly from different places in the hierarchy. Alternatively, from mywondrousframework_toplevel import utils as ut may be quite acceptable (even though this line _is_ needed in every module of the framework, I don't think it counts as "repetition" -- and it does simplify things if two frameworks are in use at the same time...).
[Bob Ippolito]
I'm pretty sure that in Python 2.4 you will be able to say
sorted(seq).
Excellent! That'll do nicely. :)
Yes, for this one specific need, but surely there will be other tiny utilities you desire to have available. Moreover, I don't think you can expect to release production applications relying on Python 2.4 anytime before this coming fall (optimistically, september -- but I wouldn't base my business on the assumption that this date can't possibly shift to, say, october...) -- and that's only if your customers are uniformly "early adopters" (for many corporations with a large installed base of Python code, it's _always_ a hassle to get them to upgrade their reference Python version, even though backwards compatibility IS targeted and a lot of effort is put into it...). So, I think you should still consider what "utility-functions access strategy" is most appropriate for your needs. The "trickle" of neat utility functions into Python's built-ins, by itself, will not entirely solve the problem for you, IMHO. Alex
participants (3)
-
Alex Martelli
-
Guido van Rossum
-
Robert Brewer