Re: [Python-Dev] backported Enum

[Nick Coghlan]

On 29 June 2013 06:30, Ethan Furman  wrote:
>> 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.

I'd actually do something a bit more complex, but also cleaner from a
type system perspective:

class EnumError(Exception): pass
class EnumValueError(EnumError, ValueError): pass
class EnumAttributeError(EnumError, AttributeError): pass
class EnumKeyError(EnumError, KeyError): pass

However, it's probably not necessary. The value lookup API should just
document clearly which exception it throws.

Cheers,
Nick.

--
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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

Re: [Python-Dev] backported Enum

[Barry Warsaw]

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
___
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

Re: [Python-Dev] backported Enum

[Guido van Rossum]

On Fri, Jun 28, 2013 at 1:30 PM, Ethan Furman  wrote:
> On 06/28/2013 01:07 PM, Jim J. Jewett wrote:
>> (On June 19, 2013) Barry Warsaw wrote about porting mailman from
>>> 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.

I also have a strong preference for the new way of doing this. In
Python, type(arg) is usually a constructor or conversion/cast, and
that maps reasonably well on what we're doing here with enums --
taking a value and turning it into the corresponding enum (which still
shares some properties with that value, and more if it's an IntEnum).
Also, this is a no-op (technically, the identity function) if the arg
is already a member of that enum.

On the other hand, Color['red'] feels more like a lookup -- this is
not so much rhyming with the behavior of other classes (classes are
rarely mappings) but still the mnemonic tip "foo[bar] is a lookup"
should help in remembering the meaning.

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.

-- 
--Guido van Rossum (python.org/~guido)
___
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

Re: [Python-Dev] backported Enum

[Ethan Furman]

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~
___
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

Re: [Python-Dev] backported Enum

[Barry Warsaw]

On Jun 28, 2013, at 01:07 PM, Jim J. Jewett wrote:

>> 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?

The individual decisions made (begrudging) sense at the time, although I don't
think it was noticed that the combined effect was to switch the meanings.

Call syntax makes sense for converting a value to an enum because that mirrors
calling built-in types, e.g. int('7').  Getitem syntax makes sense for
lookup-by-name.

>> 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?

No.  I'm not using IntEnums and regular enums don't have an __int__, which
makes sense because their values can be anything.  .value is the way to get at
the value.  (Note that even though I don't use IntEnums, my values are all
integers.  It's just not worth it to change all my imports.)

-Barry
___
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

[Python-Dev] backported Enum

[Jim J. Jewett]

 
(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

___
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

Re: [Python-Dev] backported Enum

[Nick Coghlan]

On 16 June 2013 05:46, 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.

We should resolve http://bugs.python.org/issue17961 (switching the
functional creation API to use strings instead of 1-based integers)
before we get too gung ho about encouraging people to use the
backport.

Cheers,
Nick.

--
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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

Re: [Python-Dev] backported Enum

[Barry Warsaw]

On Jun 16, 2013, at 01:13 PM, Eli Bendersky wrote:

>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.

Let's write it down here!  It was mostly mechanical, and some probably would
have been done to fix deprecations in flufl.enum.  Here's the list.

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.

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)

Changing the imports (obviously), e.g.

-from flufl.enum import Enum
+from enum import Enum

Adapting to the different repr as seen in a doctest, e.g.

-
+

Fixing some type tests.  I have one case that was testing for an enum member
to do value type conversion.  Since enum members are now instances of their
enum class, and because members no longer have a .enum attribute (because you
can just ask for its __class__), the type test actually became simpler:

-elif hasattr(obj, 'enum') and issubclass(obj.enum, Enum):
+elif isinstance(obj, Enum):

An unexpected difference is that failing name lookups raise a KeyError instead
of a ValueError.  There are many cases where I catch failing lookups in my
REST API.  Fixing this was mostly easy...

-except ValueError:
+except KeyError:

...except in one case where I was previously allowing the ValueError to
percolate up to signal to a higher level that some exception handling had to
be done.  Here, I had to convert the exception:

-# This will raise a ValueError if the enum value is unknown.  Let
-# that percolate up.
-return self._enum_class[enum_value]
+# This will raise a KeyError if the enum value is unknown.  The
+# Validator API requires turning this into a ValueError.
+try:
+return self._enum_class[enum_value]
+except KeyError as exception:
+# Retain the error message.
+raise ValueError(exception.message)

Interestingly, I found an existing hidden bug in an upgrade script where I was
not converting a value from an integer to an enum.  Nice to catch that one.

For now, I'll hold out on merging this branch to trunk until I can get enum34
packaged up for Debian.  Other than that, it looks pretty good!

Merge proposal: http://tinyurl.com/l2fq38l
Branch: https://code.launchpad.net/~barry/mailman/pep435

-Barry


signature.asc
Description: PGP signature
___
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

Re: [Python-Dev] backported Enum

[Eli Bendersky]

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 .
>
> 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
___
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

Re: [Python-Dev] backported Enum

[Barry Warsaw]

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 .

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.

-Barry
___
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

Re: [Python-Dev] backported Enum

[Ben Finney]

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

___
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

Re: [Python-Dev] backported Enum

[Ethan Furman]

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~
___
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

Re: [Python-Dev] backported Enum

[Ethan Furman]

On 06/15/2013 06:50 PM, Donald Stufft wrote:


I claimed backport.enum, but you're welcome to the name. I was going to try and 
backport this PEP under that name anyways.


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

--
~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/archive%40mail-archive.com

Re: [Python-Dev] backported Enum

[Nick Coghlan]

On 16 June 2013 15:58, Donald Stufft  wrote:
>
> 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 :)

That specific bit is stable, though :)

Cheers,
Nick.

--
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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

Re: [Python-Dev] backported Enum

[Donald Stufft]

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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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

Re: [Python-Dev] backported Enum

[Ben Finney]

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?

-- 
 \“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/archive%40mail-archive.com

Re: [Python-Dev] backported Enum

[Donald Stufft]

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.
> 
> 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
___
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

Re: [Python-Dev] backported Enum

[Ben Finney]

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.

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?

-- 
 \   “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/archive%40mail-archive.com

Re: [Python-Dev] backported Enum

[Donald Stufft]

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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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

Re: [Python-Dev] backported Enum

[Gregory P. Smith]

I tend to just pick a name and stick with it.  subprocess32 is subprocess
backported from 3.2 (with the 3.3 timeout feature also in it).  unittest2
is unittest from 2.7.

It tends to work.  and it also emphasizes that i'm unlikely to backport
future non-bugfix updates beyond the release mentioned and merely focus on
keeping it stable and available for use on older pythons.

A "backport" namespace is a neat idea but unless someone's going to create
a system for backports to register which versions they are backports from
and automagically have sub-module imports from backport pick the backported
code or the standard library version when the Python VM is recent enough to
not need a backport I wouldn't bother claiming that name.  (and even that
feels like overengineering)

-gps



On Sat, 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`?
>
> --
> ~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/**
> greg%40krypto.org
>
___
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

Re: [Python-Dev] backported Enum

[Ethan Furman]

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/archive%40mail-archive.com

Re: [Python-Dev] backported Enum

[Lefavor, Matthew (GSFC-582.0)[MICROTEL LLC]]

What if there's some obscure PyPi module that requires that `enum` package, or 
some other project (not hosted on PyPI) that requires Ben Finney's original 
`enum` package? Is there anyway to get usage data to make sure nobody's been 
using it recently?

ML

On Jun 15, 2013, at 5: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?

-Barry
___
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/matthew.lefavor%40nasa.gov

___
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

Re: [Python-Dev] backported Enum

[Tres Seaver]

-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  tsea...@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-

___
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

Re: [Python-Dev] backported Enum

[Barry Warsaw]

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?

-Barry
___
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

Re: [Python-Dev] backported Enum

[Antoine Pitrou]

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`?


___
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

[Python-Dev] backported Enum

[Ethan Furman]

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`?

--
~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/archive%40mail-archive.com