Am I the only one who would love these extentions? - Python 3.0 proposals (long)

[Alexander Schmolck]

Alex Martelli <aleax at aleax.it> writes:

> Alexander Schmolck wrote:
>    ...
> > IMHO, this is a not such a good way to define enums. Why not do
> > 
> > AND, ASSERT, BREAK, CLASS, etc == "AND, ASSERT, BREAK, CLASS,
> > etc".split(", ")
> 
> Unfortunately, this breaks the "once, and only once" principle: you
> have to ensure the sequence of words is the same on both sides -- any
> error in that respect during maintenance will cause small or big
> headaches.

True, but I'd still prefer this one (+ editor macro) in most cases to
(ab)using numbers as symbols (this was my main point; I'm sure I could also
think of various hacks to avoid the duplication and do the the stuffing in the
global namespace implicitly/separately -- if it must go there at all costs).
The main advantage the above has over custom enum types is that it's
immediately obvious. Maybe the standard library should grow a canonical enum
module that adresses most needs.

 
> Keeping enum values in their own namespace (a class or instance) is
> also generally preferable to injecting them in global namespace,
> IMHO.  

Yep, this would also be my preference. I'd presumably use something like

  DAYS = enum('MON TUE WED [...]'.split())

maybe even without the split.


> If you want each constant's value to be a string, that's easy:

Doesn't have to be, strings are just the simplest choice for something with a
sensible 'repr' (since you might want some total order of your enums a class
might be better -- if one goes through the trouble of creating one's own enum
mechanism).

> 
> class myenum(Enum):
>     AND = ASSERT = BREAK = CLASS = 1
> 
> with:
> 
> class Enum: __metaclass__ = metaEnum
> 
> and:
> 
> class metaEnum(type):
>     def __new__(mcl, clasname, clasbases, clasdict):
>         for k in clasdict:
>             clasdict[k] = k
>         return type.__new__(mcl, clasname, clasbases, clasdict)

Yuck! A nice metaclass demo but far too "clever" and misleading for such a
simple task, IMO.

> 
> The problem with this is that the attributes' _order_ in the
> classbody is lost by the time the metaclass's __new__ runs, as
> the class attributes are presented as a dictionary.  But if the
> values you want are strings equal to the attributes' names, the
> order is not important, so this works fine.
> 
> But many applications of enums DO care about order, sigh.

If that prevents people from using the above, I'd consider it a good thing ;)

> 
> 
> > in combination with iterators).I'd also like to have the apply-* work in
> > assignments, e.g. ``first, second, *rest = someList``. This would also
> > make python's list destructuring facilities much more powerful.
> 
> Yes, I agree on this one.  Further, if the "*rest" was allowed to
> receive _any remaining iterable_ (not just necessarily a list, but
> rather often an iterator) you'd be able to use itertools.count()
> and other unbounded-iterators on the RHS.

Indeed, as I noted in my previous post, iterators and such extensions would go
very well together.

'as