[Zope] Zope needs this (and Dynamo has it)

[Glyph Lefkowitz]

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/