[Python-Dev] dict.sortedkeys()

[Alex Martelli]

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