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

[Alexander Staubo]

> From: zope-admin@zope.org [mailto:zope-admin@zope.org]On
> Behalf Of Glyph
> Lefkowitz
> Sent: Monday, March 13, 2000 8:50 AM
> To: Alexander Staubo
> Cc: 'Martijn Faassen'; Zope Mailing List (E-mail)
> Subject: RE: [Zope] Zope needs this (and Dynamo has it)
>
> Okay; off-topic or not, this looks like a fun thread, and I
> couldn't help
> but put my 0.02 in =)

Interestingly enough, the US dollar dropped exactly 0.02 cents today
from yesterday. ;-)

> > > 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*,

Not exactly. I suggest you read it again. What you and Martijn propose
gives _no_ type safety at run-time. That's just like using constants,
except they're wrapped in a module namespace.

And they do pollute the top-level -- that is, the module-global --
namespace. Let me know when you find out how to enumerate the values in
an enumerated type, and how to convert an enumerated value back to its
name -- and then I might think you're up to something.

Similarly to C++, Python classes behave like namespaces, so you can
avoid pollution by wrapping the values in a class:

	class Foo:
	  FOO, BAR, BAZ = range(3)

and so you can enumerate the values as attributes.

> because modules
> are done the Right Way (tm).

True. However, personally I prefer lexical scoping -- which I hear is
under consideration for Python 3000 -- to the weird three-level
namespace that Python provides. Having to import "global" variables
because the compiler optimizes assignments is way uncool.

[Re: Tuples, mutability]
> 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?

I'm not contesting that dictionary keys should be immutable, but rather
that lists and tuples are nearly the same things (*nearly*, but not
quite) with the crucial difference that lists are mutable. Why? There's
no real design here. The only scientific answer to that question is
"Because."

--
Alexander Staubo
http://alex.mop.no/