On Fri, Apr 12, 2013 at 3:23 PM, Barry Warsaw wrote:
> On Apr 12, 2013, at 12:56 PM, Guido van Rossum wrote:
>
> >Agreed. I can't easily find that in the PEP though. It doesn't mention
> >__getitem__ and I can't find any examples of using [].
>
> Indeed, this looks like an omission in the PEP. f
On 13/04/13 10:13, Glenn Linderman wrote:
can't define two names in the same enum to have the same value, per the PEP.
I think that's too strong a restriction. I would expect to be able to do this:
class Insect(Enum):
wsap = 1 # Oops, needed for backward compatibility, do not remove.
On Fri, Apr 12, 2013 at 7:07 PM, Steven D'Aprano wrote:
> On 13/04/13 05:33, Barry Warsaw wrote:
>>
>> On Apr 12, 2013, at 11:21 AM, Russell E. Owen wrote:
>>
>>> I, too, would strongly prefer to see ordering within an enum. I use
>>> home-made enums heavily in my code and find ordering comparison
On 13/04/13 05:33, Barry Warsaw wrote:
On Apr 12, 2013, at 11:21 AM, Russell E. Owen wrote:
I, too, would strongly prefer to see ordering within an enum. I use
home-made enums heavily in my code and find ordering comparisons useful
there.
This was all hashed out in gory detail on python-ideas
Well, even better. :-)
On Fri, Apr 12, 2013 at 5:13 PM, Glenn Linderman wrote:
> On 4/12/2013 3:59 PM, Guido van Rossum wrote:
>
> class Insect(Enum):
> wasp = 1
> bee = 1
> ant = 2
>
> We'd have Insect.wasp == Insect.bee < Insect.ant but Insect.wasp is
> not Insect.bee.
>
>
> can't d
On 04/12/2013 03:58 PM, Christian Tismer wrote:
I wanted to point a bling guy to the Python wiki:
http://wiki.python.org/moin/BeginnersGuide/Programmers/SimpleExamples#preview
and when reading a little bit, I found the entry on multiline strings.
This entry?
Defining multiline strings
strin
On 4/12/2013 3:59 PM, Guido van Rossum wrote:
class Insect(Enum):
wasp = 1
bee = 1
ant = 2
We'd have Insect.wasp == Insect.bee < Insect.ant but Insect.wasp is
not Insect.bee.
can't define two names in the same enum to have the same value, per the PEP.
___
On 13/04/13 08:58, Christian Tismer wrote:
I wanted to point a bling guy to the Python wiki:
http://wiki.python.org/moin/BeginnersGuide/Programmers/SimpleExamples#preview
[...]
Where would I add such a complaint, usually?
Or should I simply fix it?
It's a wiki. You can fix it yourself, next
On Fri, 12 Apr 2013 18:35:58 -0400, Barry Warsaw wrote:
> On Apr 12, 2013, at 05:17 PM, R. David Murray wrote:
>
> >Now, you could *further* require that the type of enum values be
> >sortablebut that point you really have no excuse for not allowing
> >enum values to be compared :)
>
> I'd b
On Fri, Apr 12, 2013 at 3:44 PM, Barry Warsaw wrote:
> On Apr 12, 2013, at 02:34 PM, Guido van Rossum wrote:
>
>>So, pragmatically, if e and f are values of the same enum class,
>>couldn't e f (where is any comparison operator) defer to
>>e.value f.value ? Or is the problem with being == and e
I wanted to point a bling guy to the Python wiki:
http://wiki.python.org/moin/BeginnersGuide/Programmers/SimpleExamples#preview
and when reading a little bit, I found the entry on multiline strings.
I found that example pretty contorted, because this is not a multiline
string.
Instead, there
On Apr 12, 2013, at 02:34 PM, Guido van Rossum wrote:
>So, pragmatically, if e and f are values of the same enum class,
>couldn't e f (where is any comparison operator) defer to
>e.value f.value ? Or is the problem with being == and e
>and f being different enum values with the same underlying
On 13 April 2013 08:32, Barry Warsaw wrote:
> On Apr 12, 2013, at 04:52 PM, R. David Murray wrote:
>
> >You are right, the problem of comparison of disparate types makes ordering
> >a non-starter. But by the same token that means you are going to have to
> >be consistent and give up on having a
On Apr 12, 2013, at 05:17 PM, R. David Murray wrote:
>Now, you could *further* require that the type of enum values be
>sortablebut that point you really have no excuse for not allowing
>enum values to be compared :)
I'd be more willing to give up on sorting for the base enum type's iteration
On Apr 12, 2013, at 04:52 PM, R. David Murray wrote:
>You are right, the problem of comparison of disparate types makes ordering
>a non-starter. But by the same token that means you are going to have to
>be consistent and give up on having a sorted iteration and a stable repr:
Why do you make me
On Apr 12, 2013, at 12:56 PM, Guido van Rossum wrote:
>Agreed. I can't easily find that in the PEP though. It doesn't mention
>__getitem__ and I can't find any examples of using [].
Indeed, this looks like an omission in the PEP. flufl.enum's usage
documentation definitely talks about this:
htt
On Fri, Apr 12, 2013 at 2:17 PM, R. David Murray wrote:
> On Fri, 12 Apr 2013 14:06:55 -0700, Eli Bendersky
> wrote:
> > I actually think that having values with different types within a single
> > Enum is conceptually wrong and should be disallowed at creation time.
> With
> > enums, you either
So, pragmatically, if e and f are values of the same enum class,
couldn't e f (where is any comparison operator) defer to
e.value f.value ? Or is the problem with being == and e
and f being different enum values with the same underlying value? But
that's already iffy, isn't it? (Barry's favorit
On 04/12/2013 02:06 PM, Eli Bendersky wrote:
On Fri, Apr 12, 2013 at 1:52 PM, R. David Murray wrote:
>>> import enum
>>> class Foo(enum.Enum):
...aa = 1
...bb = 2
...cc = 'hi'
>>> Foo
Traceback (most recent call last):
File "", line 1, in
Fil
On Fri, 12 Apr 2013 14:06:55 -0700, Eli Bendersky wrote:
> I actually think that having values with different types within a single
> Enum is conceptually wrong and should be disallowed at creation time. With
> enums, you either care or don't care about their actual value. If you don't
> care (the
On 04/12/2013 10:05 AM, Guido van Rossum wrote:
On Fri, Apr 12, 2013 at 1:39 AM, Antoine Pitrou wrote:
I think we want glob("*.py") to find
"SETUP.PY" under Windows. Anything else will probably be surprising to
users of that platform.
Yeah, I suppose so. But there are more crazy details. E.g.
On Fri, Apr 12, 2013 at 1:52 PM, R. David Murray wrote:
> On Fri, 12 Apr 2013 15:33:02 -0400, Barry Warsaw wrote:
> > On Apr 12, 2013, at 11:21 AM, Russell E. Owen wrote:
> >
> > >I, too, would strongly prefer to see ordering within an enum. I use
> > >home-made enums heavily in my code and find
On Fri, 12 Apr 2013 15:33:02 -0400, Barry Warsaw wrote:
> On Apr 12, 2013, at 11:21 AM, Russell E. Owen wrote:
>
> >I, too, would strongly prefer to see ordering within an enum. I use
> >home-made enums heavily in my code and find ordering comparisons useful
> >there.
>
> This was all hashed o
On 04/12/2013 12:37 PM, � wrote:
On Fri, Apr 12, 2013 at 7:21 PM, Russell E. Owen wrote:
Using intEnum is certainly doable, but that opens up the door to
comparing values from different Enums, which is not something I'd want
to allow.
I agree. Comparing values from different Enums could cause
On Fri, Apr 12, 2013 at 12:26 PM, Barry Warsaw wrote:
> On Apr 12, 2013, at 09:43 AM, Guido van Rossum wrote:
>
>>I do wonder about this passage in the PEP:
>>
>>> Let's say you wanted to encode an enumeration value in a database. You
>>> might want to get the enumeration class object from an enu
On Apr 12, 2013, at 11:21 AM, Russell E. Owen wrote:
>I, too, would strongly prefer to see ordering within an enum. I use
>home-made enums heavily in my code and find ordering comparisons useful
>there.
This was all hashed out in gory detail on python-ideas. I feel strongly that
base EnumValue
On Apr 12, 2013, at 09:43 AM, Guido van Rossum wrote:
>I do wonder about this passage in the PEP:
>
>> Let's say you wanted to encode an enumeration value in a database. You
>> might want to get the enumeration class object from an enumeration value::
>>
>> >>> cls = Colors.red.enum
>> >>
On Fri, Apr 12, 2013 at 7:21 PM, Russell E. Owen wrote:
> Using intEnum is certainly doable, but that opens up the door to
> comparing values from different Enums, which is not something I'd want
> to allow.
I agree. Comparing values from different Enums could cause a lot of
hard to find bugs.
O
On Fri, Apr 12, 2013 at 9:30 AM, Barry Warsaw wrote:
> On Apr 12, 2013, at 09:03 AM, Michael Urman wrote:
> >(For the latter behavior, would adding DupEnum.name2 = DupEnum.name1 after
> >the class declaration work today?)
>
> Yes, but the repr/str of the alias will show the original value.
>
Tha
On 07.04.2013 21:50, "Martin v. Löwis" wrote:
So I believe that extension building is becoming more and more
painful on Windows for Python 2.7 as time passes (and it is already
way more painful than it is on Linux), and I see no way to do much
about that. The "stable ABI" would have been a solut
On Apr 12, 2013, at 04:57 PM, Phil Elson wrote:
>1) Is there limitation that EnumValues themselves must be immutable?
I'm not sure it makes sense to have mutable EnumValues, but yes, they are
immutable in the sense that you cannot change their underlying value (well,
without hackery).
>2) I'm mo
In article
,
Guido van Rossum wrote:
> On Fri, Apr 12, 2013 at 9:34 AM, Guido van Rossum wrote:
> > To me, NotImplementedError means that a subclass didn't implement
> > something it should have implemented. But that's not the case here, is
> > it? It's not a bug in the class, it's a bug in th
We are researchers from different parts of the world and conducted a study on
the world’s biggest bogus computer science conference WORLDCOMP
( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia
from University of Georgia, USA.
We submitted a fake paper to WORLDCOMP 20
On Fri, 12 Apr 2013 19:42:25 +0200
Ralf Schmitt wrote:
> Guido van Rossum writes:
>
> > Actually, I've heard of code that dynamically falls back on short
> > names when paths using long names exceed the system limit for path
> > length (either 256 or 1024 IIRC). But short names pretty much requi
Guido van Rossum writes:
> Actually, I've heard of code that dynamically falls back on short
> names when paths using long names exceed the system limit for path
> length (either 256 or 1024 IIRC). But short names pretty much require
> consulting the filesystem, so we can probably ignore them.
T
On Fri, Apr 12, 2013 at 1:39 AM, Antoine Pitrou wrote:
> Ok, I've taken a look at the code. Right now lower() is used for two
> purposes:
>
> 1. comparisons (__eq__ and __ne__)
> 2. globbing and matching
>
> While (1) could be dropped, for (2) I think we want glob("*.py") to find
> "SETUP.PY" unde
On Fri, Apr 12, 2013 at 9:34 AM, Guido van Rossum wrote:
> To me, NotImplementedError means that a subclass didn't implement
> something it should have implemented. But that's not the case here, is
> it? It's not a bug in the class, it's a bug in the call site. So I
> agree it ought to be TypeErro
On 04/12/2013 08:37 AM, Barry Warsaw wrote:
On Apr 12, 2013, at 11:29 AM, R. David Murray wrote:
You get that automatically if you return NotImplemented from the
comparison methods. I don't think you should be explicitly raising
NotImplemented.
Oh darn, this doesn't work for Python 2.7. You
On Fri, Apr 12, 2013 at 8:02 AM, Barry Warsaw wrote:
> Interesting. I'm having a hard time articulating why, but NotImplementedError
> just feels more right to me in this case.
To me, NotImplementedError means that a subclass didn't implement
something it should have implemented. But that's not
ACTIVITY SUMMARY (2013-04-05 - 2013-04-12)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open3908 ( +3)
closed 25569 (+61)
total 29477 (+64)
Open issues wit
1) Is there limitation that EnumValues themselves must be immutable?
2) I'm most excited by the prospect of using these Enums as function
defaults. I've not worked it through fully, but I'm guessing the following
will work?
>>> class Colors(Enum):
...red = (256, 0, 0)
>>> def fill(color=
On Apr 12, 2013, at 08:36 AM, Ethan Furman wrote:
>Huh??
Refresh the page :).
-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/ar
On Apr 12, 2013, at 11:29 AM, R. David Murray wrote:
>You get that automatically if you return NotImplemented from the
>comparison methods. I don't think you should be explicitly raising
>NotImplemented.
Oh darn, this doesn't work for Python 2.7. You don't care for PEP 435, but
flufl.enum will
On Apr 12, 2013, at 11:29 AM, R. David Murray wrote:
>You get that automatically if you return NotImplemented from the
>comparison methods. I don't think you should be explicitly raising
>NotImplemented.
Oh, that's much better. Thanks, I'll update the implementation, docs, and
PEP.
-Barry
___
On 04/12/2013 08:02 AM, Barry Warsaw wrote:
On Apr 12, 2013, at 03:31 PM, Dirkjan Ochtman wrote:
On Fri, Apr 12, 2013 at 2:55 PM, Eli Bendersky wrote:
Ordered comparisons between enumeration values are *not* supported. Enums
are
not integers (but see `IntEnum`_ below)::
>>> Colors.red
On 04/12/2013 07:51 AM, Barry Warsaw wrote:
On Apr 12, 2013, at 10:23 AM, R. David Murray wrote:
I think either the iteration order should be undefined (like a set
or dict), or the comparison operations should work. I'd prefer
the latter, because of the use case I outlined.
Order (both itera
On Apr 12, 2013, at 11:23 AM, R. David Murray wrote:
>To take advantage of their incommensurability with other Enums. It's
>not a big deal, though; I'm more concerned that the API be internally
>consistent. I presume that one could always define an Enum subclass
>and provide comparison methods i
On 12 Apr, 2013, at 16:59, Antoine Pitrou wrote:
> Le Fri, 12 Apr 2013 14:43:42 +0200,
> Ronald Oussoren a écrit :
>>
>> On 12 Apr, 2013, at 10:39, Antoine Pitrou wrote:
Perhaps it would be best if the code never called lower() or
upper() (not even indirectly via os.path
On Fri, 12 Apr 2013 11:02:54 -0400, Barry Warsaw wrote:
> On Apr 12, 2013, at 03:31 PM, Dirkjan Ochtman wrote:
> >On Fri, Apr 12, 2013 at 2:55 PM, Eli Bendersky wrote:
> >> >>> Colors.blue >= Colors.green
> >> Traceback (most recent call last):
> >> ...
> >> NotImplementedError
>
On Fri, 12 Apr 2013 10:50:44 -0400, Barry Warsaw wrote:
> Nick brought this up in private email, and my response was basically that
> iteration order for Enums should not be guaranteed, even if that happens to
> work in the current implementation. The reason why it works in the current
> implemen
On Apr 12, 2013, at 03:31 PM, Dirkjan Ochtman wrote:
>On Fri, Apr 12, 2013 at 2:55 PM, Eli Bendersky wrote:
>> Ordered comparisons between enumeration values are *not* supported. Enums
>> are
>> not integers (but see `IntEnum`_ below)::
>>
>> >>> Colors.red < Colors.blue
>> Traceback (mo
On Apr 12, 2013, at 10:23 AM, R. David Murray wrote:
>I think either the iteration order should be undefined (like a set
>or dict), or the comparison operations should work. I'd prefer
>the latter, because of the use case I outlined.
Order (both iteration and comparison) is officially undefined
On Apr 12, 2013, at 09:58 AM, R. David Murray wrote:
>> The ``Enum`` class supports iteration. Iteration is defined as the
>> sorted order of the item values::
>>
>> >>> class FiveColors(Enum):
>> ... pink = 4
>> ... cyan = 5
>> ... green = 2
>> ... blue = 3
>
Le Fri, 12 Apr 2013 14:43:42 +0200,
Ronald Oussoren a écrit :
>
> On 12 Apr, 2013, at 10:39, Antoine Pitrou wrote:
> >>
> >>
> >> Perhaps it would be best if the code never called lower() or
> >> upper() (not even indirectly via os.path.normcase()). Then any
> >> case-folding and path-normaliz
On Apr 12, 2013, at 09:03 AM, Michael Urman wrote:
>> You also may not duplicate values in derived enumerations::
>>
>> >>> class BadColors(Colors):
>> ... yellow = 4
>> ... chartreuse = 2 # Oops!
>> Traceback (most recent call last):
>> ...
>> ValueError: Conflicti
On 4/12/2013 9:53 AM, Lele Gaifax wrote:
Eli Bendersky writes:
These enumeration values are not equal, nor do they and hence may exist
in the same set, or as distinct keys in the same dictionary::
I'm not a native speaker and I found the above difficult to parse: is
there anything missing be
On Apr 12, 2013, at 03:53 PM, Lele Gaifax wrote:
>Eli Bendersky writes:
>
>> These enumeration values are not equal, nor do they and hence may exist
>> in the same set, or as distinct keys in the same dictionary::
>
>I'm not a native speaker and I found the above difficult to parse: is
>there any
i agree with that, and good point, i guess i misunderstood.
enums could be a nice edition, i cant wait to see how this goes.
--Sinistersnare
On Fri, Apr 12, 2013 at 10:23 AM, R. David Murray wrote:
> On Fri, 12 Apr 2013 10:19:29 -0400, Davis Silverman <
> sinistersn...@gmail.com> wrote:
> >
On Fri, 12 Apr 2013 10:19:29 -0400, Davis Silverman
wrote:
> I think the reason they are not supporting __lt__, __gt__,etc. is because
> ints are optional values for enums, therefore it wouldnt be a good idea to
> compare enums of different types in that way.
>
> example:
>
> >>>class MyEnum(En
I think the reason they are not supporting __lt__, __gt__,etc. is because
ints are optional values for enums, therefore it wouldnt be a good idea to
compare enums of different types in that way.
example:
>>>class MyEnum(Enum):
>>> fir = 1
>>> sec = 2
>>> thir = "THIRD!"
and doing
>>> MyEn
Eli Bendersky writes:
> These enumeration values are not equal, nor do they and hence may exist
> in the same set, or as distinct keys in the same dictionary::
I'm not a native speaker and I found the above difficult to parse: is
there anything missing between "nor do they" and "and hence may ex
> You may not define two enumeration values with the same integer value::
>
> >>> class Bad(Enum):
> ... cartman = 1
> ... stan = 2
> ... kyle = 3
> ... kenny = 3 # Oops!
> ... butters = 4
> Traceback (most recent call last):
> ...
> ValueErro
On Fri, 12 Apr 2013 05:55:00 -0700, Eli Bendersky wrote:
> Link to the PEP: http://www.python.org/dev/peps/pep-0435/ [it's also pasted
> fully below for convenience].
This looks great. There's just one bit I don't understand. I'm sure
it was discussed in the python-ideas thread, but the discuss
On Fri, Apr 12, 2013 at 2:55 PM, Eli Bendersky wrote:
> Ordered comparisons between enumeration values are *not* supported. Enums
> are
> not integers (but see `IntEnum`_ below)::
>
> >>> Colors.red < Colors.blue
> Traceback (most recent call last):
> ...
> NotImplementedError
>
On 12 Apr, 2013, at 15:00, Christian Heimes wrote:
> Am 12.04.2013 14:43, schrieb Ronald Oussoren:
>> At least for OSX the kernel will normalize names for you, at least for HFS+,
>> and therefore two names that don't compare equal with '==' can refer to the
>> same file (for example the NFKD and
Am 12.04.2013 14:43, schrieb Ronald Oussoren:
> At least for OSX the kernel will normalize names for you, at least for HFS+,
> and therefore two names that don't compare equal with '==' can refer to the
> same file (for example the NFKD and NFKC forms of Löwe).
>
> Isn't unicode fun :-)
Seriousl
Hello python-dev,
We're happy to present the revised PEP 435, collecting valuable feedback
from python-ideas discussions as well as in-person discussions and
decisions made during the latest PyCon language summit. We believe the
proposal is now better than the original one, providing both a wider
On 12 Apr, 2013, at 10:39, Antoine Pitrou wrote:
>>
>>
>> Perhaps it would be best if the code never called lower() or upper()
>> (not even indirectly via os.path.normcase()). Then any case-folding
>> and path-normalization bugs are the responsibility of the application,
>> and we won't have to
Le Fri, 12 Apr 2013 08:06:37 -0400,
Devin Jeanpierre a écrit :
> On Fri, Apr 12, 2013 at 4:39 AM, Antoine Pitrou
> wrote:
> > Ok, I've taken a look at the code. Right now lower() is used for two
> > purposes:
> >
> > 1. comparisons (__eq__ and __ne__)
> > 2. globbing and matching
> >
> > While (1
On Fri, Apr 12, 2013 at 4:39 AM, Antoine Pitrou wrote:
> Ok, I've taken a look at the code. Right now lower() is used for two
> purposes:
>
> 1. comparisons (__eq__ and __ne__)
> 2. globbing and matching
>
> While (1) could be dropped, for (2) I think we want glob("*.py") to find
> "SETUP.PY" unde
On 12 April 2013 09:39, Antoine Pitrou wrote:
> Ok, I've taken a look at the code. Right now lower() is used for two
> purposes:
>
> 1. comparisons (__eq__ and __ne__)
> 2. globbing and matching
>
> While (1) could be dropped, for (2) I think we want glob("*.py") to find
> "SETUP.PY" under Window
Le Thu, 11 Apr 2013 15:42:00 -0700,
Guido van Rossum a écrit :
> On Thu, Apr 11, 2013 at 2:27 PM, Antoine Pitrou
> wrote:
> > On Thu, 11 Apr 2013 14:11:21 -0700
> > Guido van Rossum wrote:
> >> Hey Antoine,
> >>
> >> Some of my Dropbox colleagues just drew my attention to the
> >> occurrence of
72 matches
Mail list logo
