> Eli, it would be nice if you stopped with this claim.

>
> I'm not advocating "not having a convenience syntax", I'm advocating
> having a convenience syntax which is *class-based* rather than
> function-based.
>
> Debuggers are beside the point: there are two kinds of "convenience
> syntax" on the table; one allows pickling by construction, one
> requires an ugly hack which may not solve all cases (and which may
> apparently make Jython / IronPython mildly unhappy). Why you insist
> on ignoring the former and imposing the latter is beyond me.
>

I'm not trying to belittle our class-based suggestion. I just think there
are two separate issues here, and I was focusing on just one of them for
now. The one I've been focusing on is how to make the function-based
convenience syntax work with pickling in the vast majority of interesting
cases. This appears to be possible by using the same pattern used by
namedtuple, and even better by encapsulating this pattern formally in
stdlib so it stops being a hack (and may actually be useful for other code
too).

The other issue is your proposal to have a class-based convenience syntax
akin to (correct me if I got this wrong):

class Animal(Enum):
  __values__ = 'cat dog'

This is obviously a matter of preference (and hence bikeshedding), but this
still looks better to me:

Animal = Enum('Animal', 'cat dog')

It has two advantages:

1. Shorter
2. Parallels namedtuple, which is by now a well known and widely used
construct

On the other hand, your proposal has the advantage that it allows pickles
without hacks in the implementation.

Did I sum up the issues fairly?

I don't know what to decide here. There's no clear technical merit to
decide on one against the other (IMHO!), it's a matter of preference.
Hopefully Guido will step in and save us from our misery ;-)

Eli
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to