[Python-Dev] dict.sortedkeys() (original) (raw)

Alex Martelli aleaxit at yahoo.com
Mon Apr 19 05:20:25 EDT 2004

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

More information about the Python-Dev mailing list