Okay; off-topic or not, this looks like a fun thread, and I couldn't help but put my 0.02 in =) On Sun, 12 Mar 2000, Alexander Staubo wrote:
FOO, BAR, BAZ = range(3)
No, although that's a clever trick. Hey, do it again! :-)
What you cite above may mirror the effect of an enumerated type, but it doesn't contain any meta-information about the type itself: That is, FOO, BAR, BAZ are integers. They will fit into any integer expression and can be passed to any function taking integer arguments. The function won't balk if you pass a value from another "enumeration". Another problem with the above is that there is no way to ask Python to enumerate the values or names in the sequence, because its values are part of the top-level namespace -- I don't like that kind of namespace pollution.
Define "top-level namespace"? This is one of my favorite things about Python. You get the behavior you want below *for free*, because modules are done the Right Way (tm). '-- spam.py --- | FOO, BAR, BAZ = range(3) | | class Spam: | def __init__(self,foovar): | self.var=foovar `-- '-- eggs.py -- | import spam | can=spam.Spam(spam.FOO) `-- Alternatively, if eggs.py uses spam.py heavily, and is closely integrated with it: '-- eggs2.py -- | from spam import * | can=Spam(FOO) `-- I use both styles -- and you can choose! Clean namespaces, or terse syntax -- voluntary namespace pollution. You can even be selective (and this can really be fun) with expressions like: '-- eggs3.py | import spam | FOO=spam.FOO | Spam=spam.Spam `-- if you're heavily using FOO, but not BAR or BAZ in eggs ...
Well, tuples can be used as dictionary keys, lists cannot.
And that makes sense to you? I don't know the historical significance of tuples in Python -- I know the mathematical meaning, but Python tuples aren't quite it -- but it smells a lot like an interface that has been fit to the size of the implementation. A lot like, coincidentally, a procrustean bed. (Coincidentally because the term has popped up a lot lately; see the Byte thread.)
For some strange reason, although they have come under lots of fire, tuples make perfect sense to me. They don't seem to confuse new programmers much, either, since I've been introducing lots of people to python... For example; lists used as dictionary keys, if mutable, would have all sorts of confusing effects. Class instances, being explicitly references, don't have this problem; but if you pass a list in as a dictionary key, change the list... what should happen? class A: pass x=[] q=[] # you may want to think of that as # q=copy(x) # instead y={} z=() a=A() b=A() y[a]='a' y[b]='b' y[z]='z' # broken, but to prove the point y[x]='x' print y[q] The same thing goes for strings... I dunno. Type-defined mutability makes a lot of sense to me.
The alternative is returning dictionaries or tuples, is it not? Maybe I'm not thinking in a Pythonic vein. Maybe
A, B, C = GetABC()
Doesn't that just *look* nice? This is certainly how I'd write this happening in pseudocode, and I was overjoyed to find that python did it automatically.
is more immediately grokkable than
GetABC(A, B, C) # assuming these are "out" parameters
This style is BAD BAD BAD. I don't like having my variables manipulated by functions, if they're mutable... but it would be even WORSE to have the symbols actually changed! Nonsense like this contributes to some of the least readable code I've ever seen in C and C++ ... ugh. I *wish* you could return tuples in C++ =) (The worst part about this is that SOMEtimes, calling a function would create new variables for you, or reassign them, and sometimes it wouldn't... ugh. I don't like it.)
Well. Sure it is. Damn, I think you're right. ;-)
Glad you see it that way =) (Tuple unpacking is also brilliant, by the way, for constructs like for key,val in dict.items() ) -- ______ __ __ _____ _ _ | ____ | \_/ |_____] |_____| |_____| |_____ | | | | @ t w i s t e d m a t r i x . c o m http://www.twistedmatrix.com/~glyph/