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
>> (ValueE
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 p
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
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'
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
(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 = Delivery
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 g
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, an
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 thin
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
h
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 Pyth
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
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 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, t
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
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 m
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
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,
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 thi
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 a
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 inappropria
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 Warsa
-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 `e
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 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`?
`backpo
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 mail
26 matches
Mail list logo
