On 29 June 2013 06:30, Ethan Furman et...@stoneleaf.us 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
(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 =
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
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 =
On Fri, Jun 28, 2013 at 1:30 PM, Ethan Furman et...@stoneleaf.us 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
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
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
On 16 June 2013 05:46, Ethan Furman et...@stoneleaf.us 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)
On Jun 16, 2013, at 1:52 AM, Ben Finney ben+pyt...@benfinney.id.au wrote:
Donald Stufft don...@stufft.io writes:
On Jun 15, 2013, at 10:45 PM, Ben Finney ben+pyt...@benfinney.id.au wrote:
Is there anything I can do to keep the ‘enum’ package online for
continuity but make it clear, to
On 16 June 2013 15:58, Donald Stufft don...@stufft.io wrote:
On Jun 16, 2013, at 1:52 AM, Ben Finney ben+pyt...@benfinney.id.au wrote:
Donald Stufft don...@stufft.io writes:
On Jun 15, 2013, at 10:45 PM, Ben Finney ben+pyt...@benfinney.id.au wrote:
Is there anything I can do to keep the
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~
On 06/15/2013 10:52 PM, Ben Finney wrote:
Donald Stufft don...@stufft.io 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
Ethan Furman et...@stoneleaf.us 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
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
On Sun, Jun 16, 2013 at 8:19 AM, Barry Warsaw ba...@python.org 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.
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
On Sat, 15 Jun 2013 12:46:32 -0700
Ethan Furman et...@stoneleaf.us 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
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
-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
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
On 06/15/2013 01:53 PM, Antoine Pitrou wrote:
On Sat, 15 Jun 2013 12:46:32 -0700
Ethan Furman et...@stoneleaf.us 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.
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
On Jun 15, 2013, at 5:43 PM, Ethan Furman et...@stoneleaf.us wrote:
On 06/15/2013 01:53 PM, Antoine Pitrou wrote:
On Sat, 15 Jun 2013 12:46:32 -0700
Ethan Furman et...@stoneleaf.us 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
Ethan Furman et...@stoneleaf.us 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
On Jun 15, 2013, at 10:45 PM, Ben Finney ben+pyt...@benfinney.id.au wrote:
Ethan Furman et...@stoneleaf.us 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.
Donald Stufft don...@stufft.io writes:
On Jun 15, 2013, at 10:45 PM, Ben Finney ben+pyt...@benfinney.id.au 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?
26 matches
Mail list logo
