On Jun 15, 2013, at 5:43 PM, Ethan Furman wrote:

On 06/15/2013 01:53 PM, Antoine Pitrou wrote:

...

On Sat, 15 Jun 2013 12:46:32 -0700 Ethan Furman wrote:

...

So I have the stdlb 3.4 Enum backported for both earlier 3.x and back to 2.4 in the 2.x series.

I would like to put this on PyPI, but the `enum` name is already taken.

Would it be inappropriate to call it `stdlib.enum`?

`backport.enum`?

Some other well-meaning soul has already claimed that name, but that one only covers 2.6 and 2.7.

-- ~Ethan~ _______________________________________________ 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/donald%40stufft.io

I claimed backport.enum, but you're welcome to the name. I was going to try and backport this PEP under that name anyways. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

Ethan Furman writes:

Thank you for the offer, but I think I'll go with GPS's idea of calling it enum34.

That name will be confusing once Python 3.5 exists (even as a development version). I'd argue that it is confusing even now, since this is a backport for Python version *earlier* than Python 3.4. The name ‘stdlib.enum’ avoids these problems, do you think that is suitable? -- \ “If trees could scream, would we be so cavalier about cutting | `\ them down? We might, if they screamed all the time, for no good | _o__) reason.” —Jack Handey | Ben Finney

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/15/2013 05:14 PM, Barry Warsaw wrote:

On Jun 15, 2013, at 12:46 PM, Ethan Furman wrote:

...

So I have the stdlb 3.4 Enum backported for both earlier 3.x and back to 2.4 in the 2.x series.

I would like to put this on PyPI, but the `enum` name is already taken.

Would it be inappropriate to call it `stdlib.enum`?

The last upload was on 2009-08-25. Maybe Ben Finney's abandoned it and wouldn't mind giving up the enum PyPI name?

That would screw anybody already using the existing distributions pretty badly. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlG84O0ACgkQ+gerLs4ltQ71qwCgo4uubYXVw/qvARESfzPLzFYZ Fb8AnjB5ZcwupMoQ6SP6r7Xl26Hg3wpQ =u3L7 -----END PGP SIGNATURE-----

On Jun 15, 2013, at 10:45 PM, Ben Finney wrote:

Ethan Furman writes:

...

So I have the stdlb 3.4 Enum backported for both earlier 3.x and back to 2.4 in the 2.x series.

I would like to put this on PyPI, but the `enum` name is already taken.

I have for a long time approved of ‘flufl.enum’ becoming the One Obvious Way to do enumerations, and am glad to see PEP 435 bring it into the standard library.

URL:http://mail.python.org/pipermail/python-ideas/2011-July/010811.html

There are some people still contacting me about their use of the ‘enum’ package on PyPI, so I think that to just replace it with a different code base under the same name would not be helpful.

...

Would it be inappropriate to call it `stdlib.enum`?

That sounds good to me.

Is there anything I can do to keep the ‘enum’ package online for continuity but make it clear, to automated tools, that this is end-of-life and obsoleted by another package?

Right now the best you can do is make a note of it. Pep 426 let's you do what you want.

-- \ “Free thought is a necessary, but not a sufficient, condition | `\ for democracy.” —Carl Sagan | _o__) | Ben Finney

_______________________________________________ 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/donald%40stufft.io

On Jun 16, 2013, at 1:52 AM, Ben Finney wrote:

Donald Stufft writes:

...

On Jun 15, 2013, at 10:45 PM, Ben Finney wrote:

...

Is there anything I can do to keep the ‘enum’ package online for continuity but make it clear, to automated tools, that this is end-of-life and obsoleted by another package?

Right now the best you can do is make a note of it. Pep 426 let's you do what you want.

Thanks. What specifically in PEP 426 do you mean; how would I make a note of “this package is end-of-life as is, please migrate to ‘flufl.enum’ instead” using PEP 426 metadata?

http://www.python.org/dev/peps/pep-0426/#obsoleted-by Note PEP426 isn't completed and isn't implemented :)

-- \ “There are no significant bugs in our released software that | `\ any significant number of users want fixed.” —Bill Gates, | _o__) 1995-10-23 | Ben Finney

_______________________________________________ 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/donald%40stufft.io

----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

On 06/15/2013 10:52 PM, Ben Finney wrote:

Donald Stufft writes:

...

On Jun 15, 2013, at 10:45 PM, Ben Finney wrote:

...

Is there anything I can do to keep the ‘enum’ package online for continuity but make it clear, to automated tools, that this is end-of-life and obsoleted by another package?

Right now the best you can do is make a note of it. Pep 426 let's you do what you want.

Thanks. What specifically in PEP 426 do you mean; how would I make a note of “this package is end-of-life as is, please migrate to ‘flufl.enum’ instead” using PEP 426 metadata?

Note that while flufl.enum was the inspiration, it is not the version that went into 3.4. Differences include: Enum does not allow subclassing when members have been defined int(Enum.member) is an error Similarities include: different Enum enumerations do not compare to each other members in an Enum enumeration are not ordered There may be (and probably are) other differences from flufl.enum, but it's late and I'm not remembering them. So to cut a long story short, your note should say: "migrate to enum34 instead." Oh, and I'm still learning the intricacies of distutils -- you should be able to ignore any errors if you try to install using `easy_install enum34`; I'll hopefully get those kinks worked out in the next few days. -- ~Ethan~

On Sun, Jun 16, 2013 at 8:19 AM, Barry Warsaw wrote:

On Jun 15, 2013, at 11:53 PM, Ethan Furman wrote:

...

Note that while flufl.enum was the inspiration, it is not the version that went into 3.4.

I haven't yet decided whether to continue with development of flufl.enum or not. I think there's a lot of value in promoting a standard enum library and having PEP 435 in both the 3.4 stdlib and in a good backport may outweigh the differences. I mostly agree with everything in PEP 435 <wink>.

One big test will be porting Mailman 3 to enum34. I expect that to mostly Just Work and I don't think the differences will affect it (I've already adjusted for the lack of inheritance - mostly I have to see what effect it will have on the database layer).

OTOH, if folks really depend on the differences in flufl.enum, I will probably at least continue to maintain it, but not add any new features.

If you write down the process of porting mailmain from flufl to stdlib.enum in some place, it can make the process much easier for others, and even encourage them to follow the same path. Eli

(On June 19, 2013) Barry Warsaw wrote about porting mailman from flufl.enum to the stdlib.enum:

Switching from call syntax to getitem syntax for looking up an enum member by name, e.g.

- delivery_mode = DeliveryMode(data['delivery_mode']) + delivery_mode = DeliveryMode[data['delivery_mode']]

Switching from getitem syntax to call syntax for looking up an enum member by value, e.g.

- return self._enum[value] + return self._enum(value)

Interesting that these two were exactly opposite from flufl.enum.

Is there a reason why these were reversed? I can sort of convince myself that it makes sense because dicts work better with strings than with ints, but ... it seems like such a minor win that I'm not sure it is worth backwards incompatibility. (Of course, I also don't know how much use stdlib.enum has already gotten with the current syntax.)

Switching from int() to .value to get the integer value of an enum member, e.g.

- return (member.list_id, member.address.email, int(member.role)) + return (member.list_id, member.address.email, member.role.value)

Is just this a style preference? Using a .value attribute certainly makes sense, but I don't see it mentioned in the PEP as even optional, let alone recommended. If you care that the value be specifically an int (as opposed to any object), then a int constructor may be better.

[Some additional changes that mean there will be *some* changes, which does reduce the pressure for backwards compatibility.] ...

An unexpected difference is that failing name lookups raise a KeyError instead of a ValueError.

I could understand either, as well as AttributeError, since the instance that would represent that value isn't a class attribute. Looking at Enum creation, I think ValueError would be better than TypeError for complaints about duplicate names. Was TypeError chosen because it should only happen during setup? I would also not be shocked if some people expect failed value lookups to raise an IndexError, though I expect they would adapt if they get something else that makes sense. Would it be wrong to create an EnumError that subclasses (ValueError, KeyError, AttributeError) and to raise that subclass from everything but _StealthProperty and _get_mixins? -jJ -- If there are still threading problems with my replies, please email me with details, so that I can try to resolve them. -jJ

On 06/28/2013 01:07 PM, Jim J. Jewett wrote:

(On June 19, 2013) Barry Warsaw wrote about porting mailman from flufl.enum to the stdlib.enum:

...

Switching from call syntax to getitem syntax for looking up an enum member by name, e.g.

...

- delivery_mode = DeliveryMode(data['delivery_mode']) + delivery_mode = DeliveryMode[data['delivery_mode']]

Switching from getitem syntax to call syntax for looking up an enum member by value, e.g.

- return self._enum[value] + return self._enum(value)

Interesting that these two were exactly opposite from flufl.enum.

Is there a reason why these were reversed?

Originally the call syntax was used for both value and name lookup. Various folks were unhappy with that arrangement, and since the use-case that I was thinking of at the time was getting enum members back from databases, etc., I went with EnumClass(value); I still wanted to be able to use name lookups, so lobbied for getitem syntax for that. Nobody noticed this was the opposite of flufl.enum. Oh, I say "I", and it is certainly my reasons, but I no longer remember if was me that initially proposed those specific ideas, and there were certainly many others that agreed.

...

Switching from int() to .value to get the integer value of an enum member, e.g.

- return (member.list_id, member.address.email, int(member.role)) + return (member.list_id, member.address.email, member.role.value)

Is just this a style preference?

Nope. If you want the exact value, accessing `.value` is the way to get it.

Using a .value attribute certainly makes sense, but I don't see it mentioned in the PEP as even optional, let alone recommended.

I'll look again at the PEP and the docs and make sure that point is clear.

If you care that the value be specifically an int (as opposed to any object), then a int constructor may be better.

Not entirely sure what you mean by this? Had it been me, I would have subclassed Enum (as, say, FluflEnum) and added `__int__` to it so that those lines would have remained the same.

...

[Some additional changes that mean there will be *some* changes, which does reduce the pressure for backwards compatibility.] ...

An unexpected difference is that failing name lookups raise a KeyError instead of a ValueError.

I could understand either, as well as AttributeError, since the instance that would represent that value isn't a class attribute.

Looking at Enum creation, I think ValueError would be better than TypeError for complaints about duplicate names. Was TypeError chosen because it should only happen during setup?

Yes. That particular error can only happen during setup.

I would also not be shocked if some people expect failed value lookups to raise an IndexError, though I expect they would adapt if they get something else that makes sense.

Would it be wrong to create an EnumError that subclasses (ValueError, KeyError, AttributeError) and to raise that subclass from everything but _StealthProperty and _get_mixins?

Wouldn't bother me; I'm not sure what the bar is for adding new exceptions, though. -- ~Ethan~

On Jun 28, 2013, at 02:11 PM, Guido van Rossum wrote:

I have no idea why it was the other way around in flufl.enum, but admittedly neither of these rules are absolute, and it's possible that flufl.enum just evolved that way without conscious decisions, or that it came from taking a different perspective.

The latter, but I think PEP 435 made the right choices, at least for the stdlib version. It doesn't bother me that I had to switch them when porting. -Barry