new enum idiom

[Alex Martelli]

"Robert Amesz" <rcameszREMOVETHIS at dds.removethistoo.nl> wrote in message
news:90273B4rcamesz at 127.0.0.1...
    [snip]
> >    xx = enum('foo=%s'%base1, 'foo2', 'foo3', 'bar=%d'%base2, 'etc')
> >
> >here, base1 is accepted whatever type it is (as long as it's able
> >to produce a string-form:-), but base2 is requested to be able to
> >produce an integer specifically.
>
> Hmm I see a problem here: doesn't the %-operator take a tuple on the
> right hand side, or has that changed in 2.0? In 1.52 it should be:
>
>     xx = enum('foo=%s'%(base1,), 'foo2', 'foo3', 'bar=%d'%(base2,),
>               'etc')
>
> That doesn't make it any prettier.

Python 1.5.2 (#1, Sep 17 1999, 20:15:36)  [GCC egcs-2.91.66 19990314/Linux
(egcs
- on linux-i386
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> print "foo%dbar" % 23
foo23bar
>>>


> As both forms seem equally capable to get the job done, and I can't see
> the one method being significantly more efficient that the other, in
> the end it would an argument over aesthetics.
>
> Aesthetic argument 1: I don't like data making an unneccesary roundtrip
> into a different domain. When using 's=n' numeric data (n) has to be
> expressed as a string.
>
> Aesthetic argument 2: The form 's=n' is in fact a tuple coded as a
> string, so why not get rid of the coding and make it explicit?  After
> all, one of Pythons design paradigms would to be: "explicit is better
> than implicit".

Two good points (which really boil down to one).  Counterpoints
would include "it's nicer to have all strings than some strings
and some tuples", and "other languages allowing such explicit
specs [C/C++ only, AFAIK] use the name=value syntax, so that will
be easier to read for people coming from those languages".  But
I'm just arguing for argument's sake -- it's an obscure corner
of an obscure idiom, and both usages look pretty much OK to me
for something likely to see frequencies as low as this.


> Oddly enough, the thing which attracted me to Python was the C-meets-
> Lisp quality of its syntax. Both C and Lisp are - in my opnion - among
> the purest and most minimalist types of languages. Python seems to be
> able to combine the two extreme paradigms into an effective, yet clean
> language.

Nolo contendere -- and I'd add that C and Lisp seem to me to have
(opposite) serious syntax flaws, making their underlying semantic
simplicity harder to grasp/appreciate for some, while Python's
syntax is SO clean and neat.


Alex