new enum idiom

[Robert Amesz]

Alex Martelli wrote:

>"Robert Amesz" <rcameszREMOVETHIS at dds.removethistoo.nl> wrote in
>message news:90268BCE3rcamesz at 127.0.0.1...
>    [snip]
>> Oh, allright. let's just call it a *little* easier, then. I mainly
>> like the lispy flavour.
>
>Which is probably what will turn many other people OFF:-).

Ah, Lisp, so beautiful, so pristine, so ... verbose. Well, it's great 
for lists, but anything numeric is a chore. Let's see:
   (EQ (PLUS 1 1) 2)
   t
Phew, so least that's still true... ;-)

Still, Lisp must have influenced Python, there's the 'lambda' and 'map' 
to prove it.


>> Also, as a small extra bonus, you can use
>> expressions with the tuple-notation. That allows you to do things
>> like: 
>>
>>    #global constants
>>    base1 = 100
>>    base2 = 200
>>
>>    #Someplace else
>>    xx = enum(('foo',base1), 'foo2', 'foo3', ('bar',base2), 'etc')
>>
>> Of course, you can always eval() the right hand part of
>> 'foo=base1', but the other form catches any syntax errors in those
>> expressions before the program actually runs.
>
>But the string-syntax goes one better by allowing, not just syntax
>checking (at compile time), but also type-checking (at runtime) if
>you wish to specify it:
>
>    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.

Anyhow it's not hard to coerce something into an int, so the entire 
'bar=%d' vs. 'bar=%s' argument doesn't really matter. I *do* agree that 
any arguments must be typechecked explicitly, that's just sound 
programming practice.


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".


>Very un-Lispish, no doubt, but, IS this comp.lang.lisp...?-)

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.

So there you have it, it's out in the open now:

I'm Robert Amesz
 -- and I'm a Python-user... ;-)