Ben Finney <[EMAIL PROTECTED]> wrote:
> > a = enum ('foo', 'bar', 'baz')
> > b = enum ('foo', 'bar', 'baz')
>
> Two separate enumerations are created
OK, most of the rest follows from that.
> > str (a)
>
> Not defined in the current specification. Suggestions?
Well, by analogy with
>>> a = set ((1, 2, 3))
>>> print '%s' % a
set([1, 2, 3])
I would think:
enum('foo', 'bar', 'baz')
would make sense.
> > repr (a)
>
> Not defined in the current specification. Suggestions?
Hmm. Maybe what I suggested for str() would work for repr() too. I'm a
little worried, however, about things that aren't == but print the same.
It might make more sense for repr() to include the id (in the style of
'<__main__.x instance at 0x8208f6c>'). Same with the repr() of an enum
member.
> > hash (a)
>
> -1210774164 # or some other hash value
I saw some debate about mutable or immutable. Doesn't making something
hashable kinda-sorta mean it has to be immutable?
> > You imply that it works from "An enumerated type is created from a
> > sequence of arguments to the type's constructor", but I suspect
> > that's not what you intended.
>
> That's what I intended; a sequence of arguments. Is there a better way
> to refer to the positional arguments collectively?
I'm not really a language lawyer, so I can't say. I was mostly trying to
explore the corners of the envelope.
> > There's been a number of threads recently where people called
> > regex methods with flags (i.e. re.I) when integers were expected, with
> > bizarre results. Making the flags into an enum would solve the problem
> > while retaining backwards compatibility.
>
> Yes, this is a prime use case for enums. I tried to cover this in the
> "Motivation"::
>
> Other examples include error status values and states
> within a defined process.
>
> Can anyone think of a better way to express this, without necessarily
> referring to any specific set of flags or states or codes or whatever?
Cite the regex thread :-)
--
http://mail.python.org/mailman/listinfo/python-list
