Re: [Python-Dev] PEP 435 - ref impl disc 2

[Glenn Linderman]

On 5/4/2013 11:46 PM, Glenn Linderman wrote:
Somehow, the overloading is not finding the __add__ operator in the 
NamedInt class, when the NamedInt's are wrapped in enumerations.


And I guess I figured it out... NamedInt needs to test

issubclass( type( self ), NamedInt )

rather than

isinstance( self, NamedInt )

and likewise for other.  Sorry for the noise, and I finally figured out 
what issubclass is for  :)
___
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] PEP 435 - ref impl disc 2

[Glenn Linderman]

On 5/5/2013 12:10 AM, Glenn Linderman wrote:

On 5/4/2013 11:46 PM, Glenn Linderman wrote:
Somehow, the overloading is not finding the __add__ operator in the 
NamedInt class, when the NamedInt's are wrapped in enumerations.


And I guess I figured it out... NamedInt needs to test

issubclass( type( self ), NamedInt )

rather than

isinstance( self, NamedInt )

and likewise for other.  Sorry for the noise, and I finally figured 
out what issubclass is for  :)
Sorry, it is getting late here... issubclass was not the cure I thought 
it might be.
___
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] PEP 435 - ref impl disc 2

[Ethan Furman]

On 05/04/2013 11:31 PM, Glenn Linderman wrote:


x = NamedInt('the-x', 1 )
y = NamedInt('the-y', 2 )
# demonstrate that NamedInt propagates the names into an expression syntax
print( repr( x ), repr( y ), repr( x+y ))

from ref435 import Enum

# requires redundant names, but loses names in the expression
class NEI( NamedInt, Enum ):
 x = NamedInt('the-x', 1 )
 y = NamedInt('the-y', 2 )

print( repr( NEI( 1 )), repr( NEI( 2 )), repr( NEI(1) + NEI(2)))


Well, my first question would be why are you using named anything in an 
enumeration, where it's going to get another name?

But setting that aside, if you

--> print(NEI.x.__name__)
'x'

not 'the-x'.

Now let's look for the clues:

class Enum...
...
@StealthProperty
def name(self):
return self._name

class NamedInt...
...
def __name__(self):
return self._name  # look familiar?


When NamedInt goes looking for _name, it finds the one on `x`, not the one on 
`x.value`.

--
~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] PEP 435 - ref impl disc 2

[Glenn Linderman]

On 5/5/2013 12:21 AM, Ethan Furman wrote:

On 05/04/2013 11:31 PM, Glenn Linderman wrote:


x = NamedInt('the-x', 1 )
y = NamedInt('the-y', 2 )
# demonstrate that NamedInt propagates the names into an expression 
syntax

print( repr( x ), repr( y ), repr( x+y ))

from ref435 import Enum

# requires redundant names, but loses names in the expression
class NEI( NamedInt, Enum ):
 x = NamedInt('the-x', 1 )
 y = NamedInt('the-y', 2 )

print( repr( NEI( 1 )), repr( NEI( 2 )), repr( NEI(1) + NEI(2)))


Well, my first question would be why are you using named anything in 
an enumeration, where it's going to get another name?


:)  It is a stepping stone, but consider it a stupid test case for now.


But setting that aside, if you

--> print(NEI.x.__name__)
'x'

not 'the-x'.

Now let's look for the clues:

class Enum...
...
@StealthProperty
def name(self):
return self._name

class NamedInt...
...
def __name__(self):
return self._name  # look familiar?


When NamedInt goes looking for _name, it finds the one on `x`, not the 
one on `x.value`.


Indeed.

But that isn't the problem of biggest concern.  I changed NamedInt to 
use _intname instead of _name, and it didn't cure the bigger problem.


The bigger problem is that the arithmetic on enumeration items, which 
seems like it should be inherited from NamedInt (and seems to be, 
because the third value from each print is a NamedInt), doesn't pick up 
"x" or "y", nor does it pick up "the-x" or "the-y", but rather, it 
somehow picks up the str of the value.


The third item from each print should be the same in all print 
statements, but the first, that deals with the NamedInt directly, works, 
and the others, that are wrapped in Enum, do not.



___
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] PEP 435 - ref impl disc 2

[Nick Coghlan]

On Sun, May 5, 2013 at 5:21 PM, Ethan Furman  wrote:
> When NamedInt goes looking for _name, it finds the one on `x`, not the one
> on `x.value`.

There's also the code in enum_type.__call__ that ensures Enum.__repr__
and Enum.__str__ are used in preference to those from the value type.
(Specifically, the code at
https://bitbucket.org/stoneleaf/ref435/src/758d43b9f7327cd61dc2e45050539b6b5db1c4e3/ref435.py?at=default#cl-152
that ignores __repr__ and __str__ from non-Enum types)

I think this needs to be documented more clearly - if you want to keep
a custom __repr__ or __str__ when mixing Enum (or an Enum subclass)
with another type, then you need to explicitly set them in your
subclass. (e.g. in Glenn's case, setting "__repr__ =
NamedValue.__repr__")

I'm OK with magic to get the kind of enum behaviour we want, but I'm
not OK with *black* magic that we don't explain. There should be an
advanced section in the enum docs which explains these edge cases in
the way the enum metaclass interacts with the normal class machinery.

That said, I'm also fairly sure the current code is incorrect: I
believe it does the wrong thing when an Enum subclass further
customises __repr__, __str__ or __new__.

The more reasonable logic to me seems to be to figure out the "first
enum base" and the "first non-enum base" based on:

   enum_bases = [base for base in enum_class.mro() if issubclass(base, Enum)]
   non_enum_bases = [base for base in enum_class.mro() if not
issubclass(base, Enum)]

Then, if the current __new__, __str__ or __repr__ implementation is
the same as that for the first non-enum base, we replace it with the
impl from the first enum base.

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] PEP 435 - requesting pronouncement

[Antoine Pitrou]

On Sat, 4 May 2013 15:04:49 -0700
Eli Bendersky  wrote:
> Hello pydev,
> 
> PEP 435 is ready for final review. A lot of the feedback from the last few
> weeks of discussions has been incorporated.

I still would like to see Nick's class-based API preferred over the
functional API:

   class Season(Enum, members='spring summer autumn'):
  pass

The PEP doesn't even mention it, even though you got significant
pushback on the proposed _getframe() hack for pickling (including
mentions that IronPython and Cython may not support it), and nobody
seemed to be unhappy with the class-based proposal.

Regards

Antoine.


___
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] PEP 435 - requesting pronouncement

[Stefan Behnel]

Antoine Pitrou, 05.05.2013 12:05:
> On Sat, 4 May 2013 15:04:49 -0700
> Eli Bendersky wrote:
>> PEP 435 is ready for final review. A lot of the feedback from the last few
>> weeks of discussions has been incorporated.
> 
> I still would like to see Nick's class-based API preferred over the
> functional API:
> 
>class Season(Enum, members='spring summer autumn'):
>   pass
> 
> The PEP doesn't even mention it, even though you got significant
> pushback on the proposed _getframe() hack for pickling (including
> mentions that IronPython and Cython may not support it), and nobody
> seemed to be unhappy with the class-based proposal.

+1

Stefan


___
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] PEP 435 - requesting pronouncement

[Steven D'Aprano]

On 05/05/13 20:05, Antoine Pitrou wrote:


I still would like to see Nick's class-based API preferred over the
functional API:

class Season(Enum, members='spring summer autumn'):
   pass


-1

As already mentioned, this is no substitute for the functional API as it is a 
statement, not an expression.

As for pickling, the usual restrictions on pickling apply. It's not like the 
functional API creates new and unexpected restrictions.



--
Steven
___
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] PEP 435 - requesting pronouncement

[Antoine Pitrou]

On Sun, 05 May 2013 20:59:03 +1000
Steven D'Aprano  wrote:
> On 05/05/13 20:05, Antoine Pitrou wrote:
> 
> > I still would like to see Nick's class-based API preferred over the
> > functional API:
> >
> > class Season(Enum, members='spring summer autumn'):
> >pass
> 
> -1
> 
> As already mentioned, this is no substitute for the functional API as it is a 
> statement, not an expression.

So, can you explain why it would make a difference?

> As for pickling, the usual restrictions on pickling apply.

No. I'm sure pickling classes normally works on Cython and IronPython,
and with PEP 3154 pickling nested classes will also be supported.

Regards

Antoine.


___
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] PEP 435 - reference implementation discussion

[Tim Delaney]

On 5 May 2013 16:17, Ethan Furman  wrote:

> On 05/04/2013 10:59 PM, Ethan Furman wrote:
>
>> On 05/04/2013 08:50 PM, Tim Delaney wrote:
>>
>>> 2. Instead of directly setting the _name and _value of the enum_item, it
>>> lets the Enum class do it via Enum.__init__().
>>>
>> Subclasses can override this. This gives Enums a 2-phase construction
>>> just like other classes.
>>>
>>
>> Not sure I care for this.  Enums are, at least in theory, immutable
>> objects, and immutable objects don't call __init__.
>>
>
> Okay, still thinking about `value`, but as far as `name` goes, it should
> not be passed -- it must be the same as it was in the class definition
>

Agreed - name should not be passed.

I would have preferred to use __new__, but Enum.__new__ doesn't get called
at all from enum_type (and the implementation wouldn't be at all
appropriate anyway).

Tim Delaney
___
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] PEP 435 - ref impl disc 2

[Ethan Furman]

class NEI( NamedInt, Enum ):
x = NamedInt('the-x', 1 )
y = NamedInt('the-y', 2 )
@property
def __name__(self):
return self.value.__name__

___
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] PEP 435 - requesting pronouncement

[Ethan Furman]

On 05/05/2013 03:05 AM, Antoine Pitrou wrote:

On Sat, 4 May 2013 15:04:49 -0700
Eli Bendersky  wrote:

Hello pydev,

PEP 435 is ready for final review. A lot of the feedback from the last few
weeks of discussions has been incorporated.


I still would like to see Nick's class-based API preferred over the
functional API:

class Season(Enum, members='spring summer autumn'):
   pass

The PEP doesn't even mention it, even though you got significant
pushback on the proposed _getframe() hack for pickling (including
mentions that IronPython and Cython may not support it), and nobody
seemed to be unhappy with the class-based proposal.


Agreed that the PEP should mention it.

-1 on using it.

We don't need two different ways to use class syntax.

The functional interface is there for two reasons:

  - to easily create enums dynamically (fairly rare, I'm sure)

  - to easily create enums when prototyping or at the interactive prompt (I'll 
use it all the time -- it's convenient! ;)

--
~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] PEP 435 - requesting pronouncement

[Victor Stinner]

I'm unhappy with this API. I never used it. It is also more verbose than
the functional API.

Victor

Le dimanche 5 mai 2013, Antoine Pitrou a écrit :

> On Sat, 4 May 2013 15:04:49 -0700
> Eli Bendersky > wrote:
> > Hello pydev,
> >
> > PEP 435 is ready for final review. A lot of the feedback from the last
> few
> > weeks of discussions has been incorporated.
>
> I still would like to see Nick's class-based API preferred over the
> functional API:
>
>class Season(Enum, members='spring summer autumn'):
>   pass
>
> The PEP doesn't even mention it, even though you got significant
> pushback on the proposed _getframe() hack for pickling (including
> mentions that IronPython and Cython may not support it), and nobody
> seemed to be unhappy with the class-based proposal.
>
> Regards
>
> Antoine.
>
>
> ___
> 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/victor.stinner%40gmail.com
>
___
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] PEP 435 - requesting pronouncement

[Eli Bendersky]

On Sun, May 5, 2013 at 3:05 AM, Antoine Pitrou  wrote:

> On Sat, 4 May 2013 15:04:49 -0700
> Eli Bendersky  wrote:
> > Hello pydev,
> >
> > PEP 435 is ready for final review. A lot of the feedback from the last
> few
> > weeks of discussions has been incorporated.
>
> I still would like to see Nick's class-based API preferred over the
> functional API:
>
>class Season(Enum, members='spring summer autumn'):
>   pass
>
> The PEP doesn't even mention it, even though you got significant
> pushback on the proposed _getframe() hack for pickling (including
> mentions that IronPython and Cython may not support it),


Plenty of points were raised against having this members= API. People
argued ardently both ways .Guido publicly asked to decide in favor of the
functional API, and we added an explicit warning about pickling (which was
lifted from the docs of pickle itself). If you feel this has to be
discussed further, please open a new thread. I don't want another 100
bikeshedding emails to go into this one.

We'll mention this as a considered alternative in the PEP, though.


> and nobody
> seemed to be unhappy with the class-based proposal.
>
>
Not true, as you see.

Eli




> Regards
>
> Antoine.
>
>
> ___
> 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/eliben%40gmail.com
>
___
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] PEP 435 - ref impl disc 2

[Ethan Furman]

On 05/05/2013 01:08 AM, Nick Coghlan wrote:

On Sun, May 5, 2013 at 5:21 PM, Ethan Furman  wrote:

There's also the code in enum_type.__call__ that ensures Enum.__repr__
and Enum.__str__ are used in preference to those from the value type.
(Specifically, the code at
https://bitbucket.org/stoneleaf/ref435/src/758d43b9f7327cd61dc2e45050539b6b5db1c4e3/ref435.py?at=default#cl-152
that ignores __repr__ and __str__ from non-Enum types)

I think this needs to be documented more clearly - if you want to keep
a custom __repr__ or __str__ when mixing Enum (or an Enum subclass)
with another type, then you need to explicitly set them in your
subclass. (e.g. in Glenn's case, setting "__repr__ =
NamedValue.__repr__")


Certainly the docs need to be clear about this.  I don't think the PEP needs to be.  (Apologies if you were not 
referring to the PEP.)




The more reasonable logic to me seems to be to figure out the "first
enum base" and the "first non-enum base" based on:

enum_bases = [base for base in enum_class.mro() if issubclass(base, Enum)]
non_enum_bases = [base for base in enum_class.mro() if not
issubclass(base, Enum)]

Then, if the current __new__, __str__ or __repr__ implementation is
the same as that for the first non-enum base, we replace it with the
impl from the first enum base.


Fair point -- working on it.

--
~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] PEP 435 - requesting pronouncement

[Philip Jenvey]

On May 5, 2013, at 6:44 AM, Ethan Furman wrote:

> On 05/05/2013 03:05 AM, Antoine Pitrou wrote:
>> I still would like to see Nick's class-based API preferred over the
>> functional API:
>> 
>>class Season(Enum, members='spring summer autumn'):
>>   pass
>> 
>> The PEP doesn't even mention it, even though you got significant
>> pushback on the proposed _getframe() hack for pickling (including
>> mentions that IronPython and Cython may not support it), and nobody
>> seemed to be unhappy with the class-based proposal.

+1

> 
> Agreed that the PEP should mention it.
> 
> -1 on using it.
> 
> We don't need two different ways to use class syntax.
> 
> The functional interface is there for two reasons:
> 
>  - to easily create enums dynamically (fairly rare, I'm sure)
> 
>  - to easily create enums when prototyping or at the interactive prompt (I'll 
> use it all the time -- it's convenient! ;)

I don't understand, the class based API is perfectly fine for prototyping in 
the repl.

For dynamic creation, the class API always provides a functional API for free:

import types
types.new_class('Season', (Enum,), dict(values='spring summer autumn'))

It's not convenient, but that doesn't matter because this usage is rare anyway. 
Certainly much rarer than declarations of auto-numbered enums.

--
Philip Jenvey
___
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] PEP 435 - requesting pronouncement

[Charles-François Natali]

I'm chiming in late, but am I the only one who's really bothered by the syntax?

class Color(Enum):
red = 1
green = 2
blue = 3

I really don't see why one has to provide values, since an enum
constant *is* the value.
In many cases, there's no natural mapping between an enum constant and
a value, e.g. there's no reason why Color.red should be mapped to 1
and Color.blue to 3.

Furthermore, the PEP makes it to possible to do something like:

class Color(Enum):
red = 1
green = 2
blue = 3
red_alias = 1


which is IMO really confusing, since enum instances are supposed to be distinct.

All the languages I can think of that support explicit values (Java
being particular in the sense that it's really a full-fledge object
which can have attributes, methods, etc) make it optional by default.

Finally, I think 99% of users won't care about the assigned value
(which is just an implementation detail), so explicit value will be
just noise annoying users (well, me at least :-).

cf



2013/5/5 Eli Bendersky :
> Hello pydev,
>
> PEP 435 is ready for final review. A lot of the feedback from the last few
> weeks of discussions has been incorporated. Naturally, not everything could
> go in because some minor (mostly preference-based) issues did not reach a
> consensus. We do feel, however, that the end result is better than in the
> beginning and that Python can finally have a useful enumeration type in the
> standard library.
>
> I'm attaching the latest version of the PEP for convenience. If you've read
> previous versions, the easiest way to get acquainted with the recent changes
> is to go through the revision log at http://hg.python.org/peps
>
> A reference implementation for PEP 435 is available at
> https://bitbucket.org/stoneleaf/ref435
>
> Kind regards and happy weekend.
>
>
>
>
>
> ___
> 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/cf.natali%40gmail.com
>
___
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] PEP 379 Python launcher for Windows - behaviour for #!/usr/bin/env python line is wrong

[Paul Moore]

On 4 May 2013 16:42, Vinay Sajip  wrote:

> I've taken a quick look at it, but I probably won't be able to make any
> changes until the near the end of the coming week. Feel free to have a go;
>

OK, I have a patch against the standalone pylauncher repo at
https://bitbucket.org/pmoore/pylauncher. I'm not sure what the best
approach is - I didn't want to patch the python core version directly (a)
because I wouldn't be able to test it easily, and (b) because I'd want a
standalone version anyway until 3.4 comes out.

BTW, the tests for pylauncher fail for me on the unpatched version, so all
I can say is that the patched version fails the same way and my manual
tests worked as expected...

I can rework it against cpython if needed.

Paul.
___
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] PEP 435 - requesting pronouncement

[Paul Moore]

OK, I thought I'd take a look. I have never particularly needed enums in
real life, so I'm reading the PEP from the POV of a naive user who is just
thinking "hey, neat, Python got enums, let's see how they work". I have
been skimming the discussions and my head has been exploding with the
complexity, so I admit I was very, very scared that the PEP might be
equally daunting.

First, the good news - from the POV described above, the PEP is both
readable and intuitive. Nice job, guys!

Now the problems I had:

1. Having to enter the values is annoying. Sorry, I read the rationale and
all that, and I *still* want to write a C-Like enum { A, B, C }. I fully
expect to edit and reorder enums (if I ever use them) and get irritated
with having to update the value assignments.
2. Enums are not orderable by default. Yuk. I doubt I'll care about this
often (iteration is more important) but when I do, I'll be annoyed.
3. This is just a thought, but I suspect that IntEnums iterating in
definition order but ordering by value could trip people up and cause hard
to diagnose bugs.
4. I'll either use the functional form all the time (because I don't have
to specify values) or never (because it's ugly as sin). I can't work out
which aspect will win yet.

And one omission that struck me. There's no mention of the common case of
bitmap enums.

class Example(Enum):
   a = 1
   b = 2
   c = 4

Do I need to use an IntEnum (given the various warnings in the PEP about
how "most people won't need it") if I want to be able to do things like
flags = "Example.a | Example.c"? I think there should at least be an
extended example in the PEP covering a bitmap enum case. (And certainly the
final documentation should include a cookbook-style example of bitmap
enums).

Summary - good job, I like the PEP a lot. But Python's enums are very
unlike those of other languages, and I suspect that's going to be more of
an issue than you'd hope...

Paul.



On 4 May 2013 23:04, Eli Bendersky  wrote:

> Hello pydev,
>
> PEP 435 is ready for final review. A lot of the feedback from the last few
> weeks of discussions has been incorporated. Naturally, not everything could
> go in because some minor (mostly preference-based) issues did not reach a
> consensus. We do feel, however, that the end result is better than in the
> beginning and that Python can finally have a useful enumeration type in the
> standard library.
>
> I'm attaching the latest version of the PEP for convenience. If you've
> read previous versions, the easiest way to get acquainted with the recent
> changes is to go through the revision log at http://hg.python.org/peps
>
> A reference implementation for PEP 435 is available at
> https://bitbucket.org/stoneleaf/ref435
>
> Kind regards and happy weekend.
>
>
>
>
>
> ___
> 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/p.f.moore%40gmail.com
>
>
___
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] PEP 435 - requesting pronouncement

[Antoine Pitrou]

On Sun, 5 May 2013 07:09:14 -0700
Eli Bendersky  wrote:
> On Sun, May 5, 2013 at 3:05 AM, Antoine Pitrou  wrote:
> 
> > On Sat, 4 May 2013 15:04:49 -0700
> > Eli Bendersky  wrote:
> > > Hello pydev,
> > >
> > > PEP 435 is ready for final review. A lot of the feedback from the last
> > few
> > > weeks of discussions has been incorporated.
> >
> > I still would like to see Nick's class-based API preferred over the
> > functional API:
> >
> >class Season(Enum, members='spring summer autumn'):
> >   pass
> >
> > The PEP doesn't even mention it, even though you got significant
> > pushback on the proposed _getframe() hack for pickling (including
> > mentions that IronPython and Cython may not support it),
> 
> Plenty of points were raised against having this members= API.

The main point seems to be "I don't like it". If you consider this a
strong argument against the concrete issues with the functional API,
then good for you.

> Guido publicly asked to decide in favor of the
> functional API, and we added an explicit warning about pickling (which was
> lifted from the docs of pickle itself).

This is not true. The pickling restrictions which have been raised are
specifically caused by the functional syntax, something which your
warning omits.

> If you feel this has to be
> discussed further, please open a new thread. I don't want another 100
> bikeshedding emails to go into this one.

This is not bikeshedding since it addresses concrete functional issues.
(but apparently you would very much like to sweep those issues under
the carpet in the name of "bikeshedding")

Regards

Antoine.
___
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] PEP 435 - requesting pronouncement

[Guido van Rossum]

I am fine with adding more information about this issue to the PEP. I
am not fine with reopening the issue. I really, really, really have
looked at it from all sides and the current design of the functional
API has my full blessing.

On Sun, May 5, 2013 at 10:46 AM, Antoine Pitrou  wrote:
> On Sun, 5 May 2013 07:09:14 -0700
> Eli Bendersky  wrote:
>> On Sun, May 5, 2013 at 3:05 AM, Antoine Pitrou  wrote:
>>
>> > On Sat, 4 May 2013 15:04:49 -0700
>> > Eli Bendersky  wrote:
>> > > Hello pydev,
>> > >
>> > > PEP 435 is ready for final review. A lot of the feedback from the last
>> > few
>> > > weeks of discussions has been incorporated.
>> >
>> > I still would like to see Nick's class-based API preferred over the
>> > functional API:
>> >
>> >class Season(Enum, members='spring summer autumn'):
>> >   pass
>> >
>> > The PEP doesn't even mention it, even though you got significant
>> > pushback on the proposed _getframe() hack for pickling (including
>> > mentions that IronPython and Cython may not support it),
>>
>> Plenty of points were raised against having this members= API.
>
> The main point seems to be "I don't like it". If you consider this a
> strong argument against the concrete issues with the functional API,
> then good for you.
>
>> Guido publicly asked to decide in favor of the
>> functional API, and we added an explicit warning about pickling (which was
>> lifted from the docs of pickle itself).
>
> This is not true. The pickling restrictions which have been raised are
> specifically caused by the functional syntax, something which your
> warning omits.
>
>> If you feel this has to be
>> discussed further, please open a new thread. I don't want another 100
>> bikeshedding emails to go into this one.
>
> This is not bikeshedding since it addresses concrete functional issues.
> (but apparently you would very much like to sweep those issues under
> the carpet in the name of "bikeshedding")
>
> Regards
>
> Antoine.
> ___
> 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/guido%40python.org



-- 
--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] PEP 435 - requesting pronouncement

[Guido van Rossum]

This has all long been hashed out, and I've pronounced on this
already. I'm sorry you weren't there for the bikeshedding, but nothing
you say here is new and it was all considered carefully.

On Sun, May 5, 2013 at 10:07 AM, Charles-François Natali
 wrote:
> I'm chiming in late, but am I the only one who's really bothered by the 
> syntax?
>
> class Color(Enum):
> red = 1
> green = 2
> blue = 3
>
> I really don't see why one has to provide values, since an enum
> constant *is* the value.
> In many cases, there's no natural mapping between an enum constant and
> a value, e.g. there's no reason why Color.red should be mapped to 1
> and Color.blue to 3.
>
> Furthermore, the PEP makes it to possible to do something like:
>
> class Color(Enum):
> red = 1
> green = 2
> blue = 3
> red_alias = 1
>
>
> which is IMO really confusing, since enum instances are supposed to be 
> distinct.
>
> All the languages I can think of that support explicit values (Java
> being particular in the sense that it's really a full-fledge object
> which can have attributes, methods, etc) make it optional by default.
>
> Finally, I think 99% of users won't care about the assigned value
> (which is just an implementation detail), so explicit value will be
> just noise annoying users (well, me at least :-).
>
> cf
>
>
>
> 2013/5/5 Eli Bendersky :
>> Hello pydev,
>>
>> PEP 435 is ready for final review. A lot of the feedback from the last few
>> weeks of discussions has been incorporated. Naturally, not everything could
>> go in because some minor (mostly preference-based) issues did not reach a
>> consensus. We do feel, however, that the end result is better than in the
>> beginning and that Python can finally have a useful enumeration type in the
>> standard library.
>>
>> I'm attaching the latest version of the PEP for convenience. If you've read
>> previous versions, the easiest way to get acquainted with the recent changes
>> is to go through the revision log at http://hg.python.org/peps
>>
>> A reference implementation for PEP 435 is available at
>> https://bitbucket.org/stoneleaf/ref435
>>
>> Kind regards and happy weekend.
>>
>>
>>
>>
>>
>> ___
>> 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/cf.natali%40gmail.com
>>
> ___
> 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/guido%40python.org



-- 
--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] PEP 435 - requesting pronouncement

[Guido van Rossum]

On Sun, May 5, 2013 at 10:41 AM, Paul Moore  wrote:
> OK, I thought I'd take a look. I have never particularly needed enums in
> real life, so I'm reading the PEP from the POV of a naive user who is just
> thinking "hey, neat, Python got enums, let's see how they work". I have been
> skimming the discussions and my head has been exploding with the complexity,
> so I admit I was very, very scared that the PEP might be equally daunting.
>
> First, the good news - from the POV described above, the PEP is both
> readable and intuitive. Nice job, guys!
>
> Now the problems I had:
>
> 1. Having to enter the values is annoying. Sorry, I read the rationale and
> all that, and I *still* want to write a C-Like enum { A, B, C }. I fully
> expect to edit and reorder enums (if I ever use them) and get irritated with
> having to update the value assignments.

I guess there are cultural differences around this. Anyway, you can
use the functional/convenience API for this purpose.

> 2. Enums are not orderable by default. Yuk. I doubt I'll care about this
> often (iteration is more important) but when I do, I'll be annoyed.

I personally agree with you, but not strongly enough to override Barry
and Eli who seem to be strongly for unordered enums.

> 3. This is just a thought, but I suspect that IntEnums iterating in
> definition order but ordering by value could trip people up and cause hard
> to diagnose bugs.

This is somewhat in conflict with your #1. :-)

> 4. I'll either use the functional form all the time (because I don't have to
> specify values) or never (because it's ugly as sin). I can't work out which
> aspect will win yet.

But not everybody will make the same choice.

> And one omission that struck me. There's no mention of the common case of
> bitmap enums.
>
> class Example(Enum):
>a = 1
>b = 2
>c = 4
>
> Do I need to use an IntEnum (given the various warnings in the PEP about how
> "most people won't need it") if I want to be able to do things like flags =
> "Example.a | Example.c"? I think there should at least be an extended
> example in the PEP covering a bitmap enum case. (And certainly the final
> documentation should include a cookbook-style example of bitmap enums).

You'd have to use IntEnum. Plus, these are hardly enums -- they are a
particularly obscure old school hack for representing sets of flags.
(I liked Pascal's solution for this better -- it had a bit set data
structure that supported sets of enums.)

> Summary - good job, I like the PEP a lot. But Python's enums are very unlike
> those of other languages, and I suspect that's going to be more of an issue
> than you'd hope...

We're pretty confident that we're doing about the best job possible
given the constraints (one of which is getting this accepted into
Python 3.4 without any of the participants incurring permanent brain
damage).

-- 
--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] PEP 435 - requesting pronouncement

[Guido van Rossum]

On Sun, May 5, 2013 at 3:05 AM, Antoine Pitrou  wrote:
> I still would like to see Nick's class-based API preferred over the
> functional API:
>
>class Season(Enum, members='spring summer autumn'):
>   pass
>
> The PEP doesn't even mention it, even though you got significant
> pushback on the proposed _getframe() hack for pickling (including
> mentions that IronPython and Cython may not support it), and nobody
> seemed to be unhappy with the class-based proposal.

This particular bikeshed has sailed.

I heard all the feedback, took into account my own thoughts, and have
decided that we should go ahead with this syntax and the _getframe()
hack. If the _getframe() hack doesn't work on a given platform, the
__module__ attribute is not set correctly, so pickling will fail, but
everything else will work. We can work on a PEP to replace the
_getframe() hack separately; I think it's functionality that is useful
beyond Enum() and namedtuple(), and can be implemented on all
platforms with something a lot less general than _getframe().

Authors can also avoid the _getframe() hack in two ways: (a) use the
full class definition; (b) specify the full dotted class name in the
call. (We should modify namedtuple() to support this too BTW.)

-- 
--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] PEP 435 - requesting pronouncement

[Steven D'Aprano]

On 06/05/13 03:07, Charles-François Natali wrote:

I'm chiming in late, but am I the only one who's really bothered by the syntax?

class Color(Enum):
 red = 1
 green = 2
 blue = 3

I really don't see why one has to provide values, since an enum
constant *is* the value.
In many cases, there's no natural mapping between an enum constant and
a value, e.g. there's no reason why Color.red should be mapped to 1
and Color.blue to 3.



The functional API provides a way to conveniently create enums without caring 
what value they get. Other than that, the PEP explains that there was an early 
proposal to declare names without values:

# rejected syntax
class Color(Enum):
red
green
blue


but this was rejected for being too magical, and too confusing to those who 
aren't expecting it.



Furthermore, the PEP makes it to possible to do something like:

class Color(Enum):
 red = 1
 green = 2
 blue = 3
 red_alias = 1


which is IMO really confusing, since enum instances are supposed to be distinct.


Enums often have duplicate values, sometimes to provide aliases, sometimes to 
correct spelling errors, or to manage deprecated names, etc.

class Color(Enum):
red = 1
green = 2  # this is the preferred spelling
blue = 3
gren = green  # oops, do not remove, needed for backwards compatibility


E.g. I googled on "C enum" and the very first hit includes a duplicate value:

http://msdn.microsoft.com/en-AU/library/whbyts4t%28v=vs.80%29.aspx

And two examples from asm-generic/errno.h:

#define EWOULDBLOCK EAGAIN  /* Operation would block */
#define EDEADLOCK   EDEADLK




All the languages I can think of that support explicit values (Java
being particular in the sense that it's really a full-fledge object
which can have attributes, methods, etc) make it optional by default.

Finally, I think 99% of users won't care about the assigned value
(which is just an implementation detail), so explicit value will be
just noise annoying users (well, me at least :-).



Compatibility with (e.g.) C enums is an important use-case for these, and in 
that case you likely will care about the actual value.


--
Steven
___
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] PEP 435 - requesting pronouncement

[Paul Moore]

On 5 May 2013 18:49, Guido van Rossum  wrote:

> > Summary - good job, I like the PEP a lot. But Python's enums are very
> unlike
>
> those of other languages, and I suspect that's going to be more of an
> issue
> > than you'd hope...
>
> We're pretty confident that we're doing about the best job possible
> given the constraints (one of which is getting this accepted into
> Python 3.4 without any of the participants incurring permanent brain
> damage).


Agreed. My points were definitely minor ones (and addressed by your reply,
thanks).

Paul
___
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] PEP 435: initial values must be specified? Yes

[Ethan Furman]

On 05/05/2013 10:07 AM, � wrote:> I'm chiming in late, but am I the only one 
who's really bothered by the syntax?


class Color(Enum):
 red = 1
 green = 2
 blue = 3


No, you are not only one that's bothered by it.  I tried it without assignments until I discovered that bugs are way too 
easy to introduce.  The problem is a successful name lookup looks just like a name failure, but of course no error is 
raised and no new enum item is created:


--> class Color(Enum):
... red, green, blue
...

--> class MoreColor(Color):
... red, orange, yellow
...

--> type(MoreColor.red) is MoreColor
False

--> MoreColor.orange
   # value should be 5

About the closest you going to be able to get is something like:

def e(_next=[1]):
e, _next[0] = _next[0], _next[0] + 1
return e

class Color(Enum):
red = e()
green = e()
blue = e()

and you can keep using `e()` for all your enumerations, since you don't care what actual value each enumeration member 
happens to get.


--
~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] PEP 435: initial values must be specified? Yes

[Tim Delaney]

On 6 May 2013 06:09, Ethan Furman  wrote:

> On 05/05/2013 10:07 AM, � wrote:> I'm chiming in late, but am I the only
> one who's really bothered by the syntax?
>
>>
>> class Color(Enum):
>>  red = 1
>>  green = 2
>>  blue = 3
>>
>
> No, you are not only one that's bothered by it.  I tried it without
> assignments until I discovered that bugs are way too easy to introduce.
>  The problem is a successful name lookup looks just like a name failure,
> but of course no error is raised and no new enum item is created:
>
> --> class Color(Enum):
> ... red, green, blue
> ...
>
> --> class MoreColor(Color):
> ... red, orange, yellow
> ...
>
> --> type(MoreColor.red) is MoreColor
> False
>
> --> MoreColor.orange
># value should be 5
>

Actually, my implementation at  https://bitbucket.org/magao/enum (the one
mentioned in the PEP) does detect MoreColor.red as a duplicate. It's
possible to do it, but it's definitely black magic and also involves use of
sys._getframe() for more than just getting module name.

>>> from enum import Enum
>>> class Color(Enum):
... red, green, blue
...
>>> class MoreColor(Color):
... red, orange, yellow
...
Traceback (most recent call last):
  File "", line 1, in 
  File ".\enum.py", line 388, in __new__
raise AttributeError("Duplicate enum key '%s.%s' (overriding '%s')" %
(result.__name__, v.key, k
eys[v.key]))
AttributeError: Duplicate enum key 'MoreColor.red' (overriding 'Color.red')
>>>

So long as I can get one of the requirements documented to implement an
auto-number syntax I'll be happy enough with stdlib enums I think.

class Color(AutoIntEnum):
red = ...
green = ...
blue = ...

Not as pretty, but ends up being less magical.

Tim Delaney
___
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] PEP 435: initial values must be specified? Yes

[Guido van Rossum]

On Sun, May 5, 2013 at 2:55 PM, Tim Delaney  wrote:
> So long as I can get one of the requirements documented to implement an
> auto-number syntax I'll be happy enough with stdlib enums I think.

Specifically what do you want the PEP to promise?

-- 
--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] Difference in RE between 3.2 and 3.3 (or Aaron Swartz memorial)

[Matej Cepl]

- Original Message -
> From: "Armin Rigo" 
> To: "Matej Cepl" 
> Cc: python-dev@python.org
> Sent: Saturday, May 4, 2013 11:59:42 AM
> Subject: Re: [Python-Dev] Difference in RE between 3.2 and 3.3 (or Aaron 
> Swartz memorial)
> 
> Hi Matej,
> 
> On Thu, Mar 7, 2013 at 11:08 AM, Matej Cepl  wrote:
> >  if c is not ' ' and c is not '  ':
> > if c != ' ' and c != ' ':
> 
> Sorry for the delay in answering, but I just noticed what is wrong in
> this "fix": it compares c with the same single-character ' ' twice,
> whereas the original compared it with ' ' and with the two-character '

Comments on 
https://github.com/mcepl/html2text/commit/f511f3c78e60d7734d677f8945580f52ef7ef742#L0R765
 (perhaps in https://github.com/aaronsw/html2text/pull/77) are more than 
welcome. When using

SPACE_RE = re.compile(r'\s\+') 

for checking, whole onlywhite function is not needed anymore (and it still made 
me wonder what Aaron meant when he wrote it). Why line.isspace() doesn't work 
is weird though.

Best,

Matěj
___
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] Difference in RE between 3.2 and 3.3 (or Aaron Swartz memorial)

[MRAB]

On 05/05/2013 23:01, Matej Cepl wrote:

- Original Message -

From: "Armin Rigo" 
To: "Matej Cepl" 
Cc: python-dev@python.org
Sent: Saturday, May 4, 2013 11:59:42 AM
Subject: Re: [Python-Dev] Difference in RE between 3.2 and 3.3 (or Aaron Swartz 
memorial)

Hi Matej,

On Thu, Mar 7, 2013 at 11:08 AM, Matej Cepl  wrote:
>  if c is not ' ' and c is not '  ':
> if c != ' ' and c != ' ':

Sorry for the delay in answering, but I just noticed what is wrong in
this "fix": it compares c with the same single-character ' ' twice,
whereas the original compared it with ' ' and with the two-character '


Comments on 
https://github.com/mcepl/html2text/commit/f511f3c78e60d7734d677f8945580f52ef7ef742#L0R765
 (perhaps in https://github.com/aaronsw/html2text/pull/77) are more than 
welcome. When using

SPACE_RE = re.compile(r'\s\+')


That will match a whitespace character followed by a '+'.


for checking, whole onlywhite function is not needed anymore (and it still made 
me wonder what Aaron meant when he wrote it). Why line.isspace() doesn't work 
is weird though.


What do you mean by "doesn't work"?

___
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] PEP 435 - requesting pronouncement

[Eli Bendersky]

On Sun, May 5, 2013 at 10:46 AM, Antoine Pitrou  wrote:

> On Sun, 5 May 2013 07:09:14 -0700
> Eli Bendersky  wrote:
> > On Sun, May 5, 2013 at 3:05 AM, Antoine Pitrou 
> wrote:
> >
> > > On Sat, 4 May 2013 15:04:49 -0700
> > > Eli Bendersky  wrote:
> > > > Hello pydev,
> > > >
> > > > PEP 435 is ready for final review. A lot of the feedback from the
> last
> > > few
> > > > weeks of discussions has been incorporated.
> > >
> > > I still would like to see Nick's class-based API preferred over the
> > > functional API:
> > >
> > >class Season(Enum, members='spring summer autumn'):
> > >   pass
> > >
> > > The PEP doesn't even mention it, even though you got significant
> > > pushback on the proposed _getframe() hack for pickling (including
> > > mentions that IronPython and Cython may not support it),
> >
> > Plenty of points were raised against having this members= API.
>
> The main point seems to be "I don't like it". If you consider this a
> strong argument against the concrete issues with the functional API,
> then good for you.
>
> > Guido publicly asked to decide in favor of the
> > functional API, and we added an explicit warning about pickling (which
> was
> > lifted from the docs of pickle itself).
>
> This is not true. The pickling restrictions which have been raised are
> specifically caused by the functional syntax, something which your
> warning omits.
>
> > If you feel this has to be
> > discussed further, please open a new thread. I don't want another 100
> > bikeshedding emails to go into this one.
>
> This is not bikeshedding since it addresses concrete functional issues.
> (but apparently you would very much like to sweep those issues under
> the carpet in the name of "bikeshedding")
>

I'm sorry that you're taking this issue so personally, Antoine.

As for pickling enums created with the functional API, I don't think we now
provide less than the pickle module dictates in the general sense. The
pickle docs say:

The following types can be pickled:
  [...]

   - classes that are defined at the top level of a module
   - instances of such classes whose __dict__ or the result of calling
   __getstate__() is picklable (see section *Pickling Class
Instances*for
details).

I'll open a separate thread about how this can be implemented and
documented in the best way possible, but I really don't see it as an
unsolvable issue.

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] PEP 435: initial values must be specified? Yes

[Tim Delaney]

On 6 May 2013 08:00, Guido van Rossum  wrote:

> On Sun, May 5, 2013 at 2:55 PM, Tim Delaney 
> wrote:
> > So long as I can get one of the requirements documented to implement an
> > auto-number syntax I'll be happy enough with stdlib enums I think.
>
> Specifically what do you want the PEP to promise?
>

It was mentioned in the other threads, but the requirement is either:

1. That the dictionary returned from .__prepare__ provide a
way to obtain the enum instance names once it's been populated (e.g. once
it's been passed as the classdict to __new__). The reference implementation
provides a _enum_names list attribute. The enum names need to be available
to a metaclass subclass before calling the base metaclass __new__.

OR

2. A way for subclasses of Enum to modify the value before it's assigned to
the actual enum - see the PEP 435 reference implementation - discussion
thread where I modified the reference implementation to give enum instances
2-phase construction, passing the value to Enum.__init__. This way is more
limited, as you need to use an appropriate mix-in type which puts certain
constraints on the behaviour of the enum instances (e.g. they *have* to be
int instances for auto-numbering). The implementation is also more complex,
and as noted in that thread, __init__ might not be appropriate for an Enum.

Tim Delaney
___
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] PEP 435: initial values must be specified? Yes

[Guido van Rossum]

On Sun, May 5, 2013 at 3:34 PM, Tim Delaney  wrote:
> On 6 May 2013 08:00, Guido van Rossum  wrote:
>>
>> On Sun, May 5, 2013 at 2:55 PM, Tim Delaney 
>> wrote:
>> > So long as I can get one of the requirements documented to implement an
>> > auto-number syntax I'll be happy enough with stdlib enums I think.
>>
>> Specifically what do you want the PEP to promise?

> It was mentioned in the other threads, but the requirement is either:
>
> 1. That the dictionary returned from .__prepare__ provide a
> way to obtain the enum instance names once it's been populated (e.g. once
> it's been passed as the classdict to __new__). The reference implementation
> provides a _enum_names list attribute. The enum names need to be available
> to a metaclass subclass before calling the base metaclass __new__.
>
> OR
>
> 2. A way for subclasses of Enum to modify the value before it's assigned to
> the actual enum - see the PEP 435 reference implementation - discussion
> thread where I modified the reference implementation to give enum instances
> 2-phase construction, passing the value to Enum.__init__. This way is more
> limited, as you need to use an appropriate mix-in type which puts certain
> constraints on the behaviour of the enum instances (e.g. they *have* to be
> int instances for auto-numbering). The implementation is also more complex,
> and as noted in that thread, __init__ might not be appropriate for an Enum.

I'll let Eli or Ethan respond to this. It sounds fine to me to support
you with some kind of hook in the spec, even though I personally would
rather assign my enum values explicitly (I'm old-fashioned that way
:-).

-- 
--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] PEP 435: initial values must be specified? Yes

[Eli Bendersky]

On Sun, May 5, 2013 at 3:34 PM, Tim Delaney wrote:

> On 6 May 2013 08:00, Guido van Rossum  wrote:
>
>> On Sun, May 5, 2013 at 2:55 PM, Tim Delaney 
>> wrote:
>> > So long as I can get one of the requirements documented to implement an
>> > auto-number syntax I'll be happy enough with stdlib enums I think.
>>
>> Specifically what do you want the PEP to promise?
>>
>
> It was mentioned in the other threads, but the requirement is either:
>
> 1. That the dictionary returned from .__prepare__ provide
> a way to obtain the enum instance names once it's been populated (e.g. once
> it's been passed as the classdict to __new__). The reference implementation
> provides a _enum_names list attribute. The enum names need to be available
> to a metaclass subclass before calling the base metaclass __new__.
>
> OR
>
> 2. A way for subclasses of Enum to modify the value before it's assigned
> to the actual enum - see the PEP 435 reference implementation - discussion
> thread where I modified the reference implementation to give enum instances
> 2-phase construction, passing the value to Enum.__init__. This way is more
> limited, as you need to use an appropriate mix-in type which puts certain
> constraints on the behaviour of the enum instances (e.g. they *have* to be
> int instances for auto-numbering). The implementation is also more complex,
> and as noted in that thread, __init__ might not be appropriate for an Enum.
>

So your preferred solution is (1), which requires exposing the metaclass
and an attribute publicly? I have to ask - to what end? What is the goal of
this? To have an AutoNumberedEnum which is guaranteed to be compatible with
stdlib's Enum?

IMHO this goal is not important enough, and I'm not aware of other stdlib
modules that go to such lengths exposing implementation details publicly
(but I'd be happy to be educated on this!)

Assuming ref435 goes as-is into stdlib in 3.4, can't you just assume its
implementation? And then change yours if it changes? Python's stdlib
doesn't change that often, but if we do want to change the implementation
at some point, this documented piece of internals is surely going to be in
the way. Why should the future malleability of a stdlib module be
sacrificed for the sake of this extension?

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] PEP 435 - ref impl disc 2

[Glenn Linderman]

On 5/5/2013 6:07 AM, Ethan Furman wrote:

class NEI( NamedInt, Enum ):
x = NamedInt('the-x', 1 )
y = NamedInt('the-y', 2 )
@property
def __name__(self):
return self.value.__name__


This cured it, thank you.  But I really still don't understand why the 
numbers showed up as names... seems to me that either the name of the 
enumeration member, or the name of the NamedInt should have showed up, 
without this property definition.


The PEP is the only documentation I had, other than the reference 
implementation, but I can't say I fully understand the reference 
implementation, not having dealt with metaclass much. Hopefully the 
documentation will explain all the incantations necessary to make things 
work in an expected manner. I guess I don't understand why Enum can't 
wrap the __str__ and __repr__ of the type of the mixed class, instead of 
replacing it, and then forcing overrides in subclasses.


But empirically, it didn't seem to be __str__ and __repr__ that caused 
the visible problem, it was __name__. So you asked why would I want to 
put a named object as the value of something else with a name... and 
that is a fair question... really I don't... but I see one of the 
beneficial uses of Enum being collecting flags values together, and 
constructing a flag that is useful for debugging (has a name or 
expression telling what the values are).  So while the PEP thinks 
IntEnum is an odd case, I think it is important. And since IntEnum loses 
its name when included in an expression, I was trying to marry it to 
NamedInt to fill the gap.


So you asked why would I want to put a named object as the value of 
something else with a name... maybe Enum should make provision for 
that... if the primary type ( Int for IntEnum, NamedInt for 
NamedIntEnum) happens to have a __name__ property, maybe the name of 
enumeration members should be passed to the constructor for the 
members... in other words,


class NIE( NamedInt, Enum ):
x = 1
y = 2

could construct enumeration members x and y whose values are 
NamedInt('x', 1) and

NamedInt('y', 2)...
___
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] PEP 435 - requesting pronouncement

[Nikolaus Rath]

Guido van Rossum  writes:
>> 1. Having to enter the values is annoying. Sorry, I read the rationale and
>> all that, and I *still* want to write a C-Like enum { A, B, C }. I fully
>> expect to edit and reorder enums (if I ever use them) and get irritated with
>> having to update the value assignments.
>
> I guess there are cultural differences around this. Anyway, you can
> use the functional/convenience API for this purpose.

Would it be wise to forbid ... as an enum value to preserve the option
to use it for automatic value assignment in some indefinite future?


Best,

   -Nikolaus

-- 
 »Time flies like an arrow, fruit flies like a Banana.«

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C
___
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] PEP 435: initial values must be specified? Yes

[Guido van Rossum]

On Sun, May 5, 2013 at 3:55 PM, Eli Bendersky  wrote:
>
>
>
> On Sun, May 5, 2013 at 3:34 PM, Tim Delaney 
> wrote:
>>
>> On 6 May 2013 08:00, Guido van Rossum  wrote:
>>>
>>> On Sun, May 5, 2013 at 2:55 PM, Tim Delaney 
>>> wrote:
>>> > So long as I can get one of the requirements documented to implement an
>>> > auto-number syntax I'll be happy enough with stdlib enums I think.
>>>
>>> Specifically what do you want the PEP to promise?
>>
>>
>> It was mentioned in the other threads, but the requirement is either:
>>
>> 1. That the dictionary returned from .__prepare__ provide
>> a way to obtain the enum instance names once it's been populated (e.g. once
>> it's been passed as the classdict to __new__). The reference implementation
>> provides a _enum_names list attribute. The enum names need to be available
>> to a metaclass subclass before calling the base metaclass __new__.
>>
>> OR
>>
>> 2. A way for subclasses of Enum to modify the value before it's assigned
>> to the actual enum - see the PEP 435 reference implementation - discussion
>> thread where I modified the reference implementation to give enum instances
>> 2-phase construction, passing the value to Enum.__init__. This way is more
>> limited, as you need to use an appropriate mix-in type which puts certain
>> constraints on the behaviour of the enum instances (e.g. they *have* to be
>> int instances for auto-numbering). The implementation is also more complex,
>> and as noted in that thread, __init__ might not be appropriate for an Enum.
>
>
> So your preferred solution is (1), which requires exposing the metaclass and
> an attribute publicly? I have to ask - to what end? What is the goal of
> this? To have an AutoNumberedEnum which is guaranteed to be compatible with
> stdlib's Enum?
>
> IMHO this goal is not important enough, and I'm not aware of other stdlib
> modules that go to such lengths exposing implementation details publicly
> (but I'd be happy to be educated on this!)
>
> Assuming ref435 goes as-is into stdlib in 3.4, can't you just assume its
> implementation? And then change yours if it changes? Python's stdlib doesn't
> change that often, but if we do want to change the implementation at some
> point, this documented piece of internals is surely going to be in the way.
> Why should the future malleability of a stdlib module be sacrificed for the
> sake of this extension?

Hm. Either you should argue much more strongly against Tim's solution,
or you should expose the implementation detail he needs. Recommending
that he should just use an internal detail of the implementation and
hope it never changes sounds like encouraging a bad habit. It also
seems you're contradicting yourself by saying that the code is
unlikely to change and at the same time wanting to reserve the right
to change it.

Also note that the future malleability of a stdlib module is affected
even by 3rd party use that goes beyond the documented API -- it all
depends on a pragmatic weighing of how important a proposed change is
against how likely it is to break existing use, and there are plenty
of examples in the past where we have resisted changing an
implementation detail because it would break too much code.

If you really don't want to guarantee this part of the implementation,
you should recommend that Tim just copy all of ref435. TBH I don't see
what deriving AutoNumberEnum from the stdlib Enum class buy him except
that he has to maintain less code. I don't expect there to be a lot of
opportunities anywhere for writing isinstance(x, Enum).

-- 
--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] PEP 435: initial values must be specified? Yes

[Tim Delaney]

On 6 May 2013 08:55, Eli Bendersky  wrote:

> 1. That the dictionary returned from .__prepare__ provide
> a way to obtain the enum instance names once it's been populated (e.g. once
> it's been passed as the classdict to __new__). The reference implementation
> provides a _enum_names list attribute. The enum names need to be available
> to a metaclass subclass before calling the base metaclass __new__.
>
>> So your preferred solution is (1), which requires exposing the metaclass
>> and an attribute publicly? I have to ask - to what end? What is the goal of
>> this? To have an AutoNumberedEnum which is guaranteed to be compatible with
>> stdlib's Enum?
>>
>
My preferred solution is 1 (for the reason mentioned above) but it does not
require exposing the metaclass publically (that's obtainable via
type(Enum)). It does require a way to get the enum names before calling the
base metaclass __new__, but that does not necessarily imply that I'm
advocating exposing _enum_names (or at least, not directly).

My preferred way would probably be a note that the dictionary returned from
the enum metaclass __prepare__ implements an enum_names() or maybe
__enum_names__() method which returns an iterator over the enum instance
names in definition order. The way this is implemented by the dictionary
would be an implementation detail.

The enum metaclass __new__ needs access to the enum instance names in
definition order, so I think making it easily available to enum metaclass
subclasses as well just makes sense.

Tim Delaney
___
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] PEP 435 - requesting pronouncement

[Ethan Furman]

On 05/05/2013 03:16 PM, Nikolaus Rath wrote:

Guido van Rossum  writes:

1. Having to enter the values is annoying. Sorry, I read the rationale and
all that, and I *still* want to write a C-Like enum { A, B, C }. I fully
expect to edit and reorder enums (if I ever use them) and get irritated with
having to update the value assignments.


I guess there are cultural differences around this. Anyway, you can
use the functional/convenience API for this purpose.


Would it be wise to forbid ... as an enum value to preserve the option
to use it for automatic value assignment in some indefinite future?


No.  If somebody has a use for ... is a value we're not going to say no on the very remote chance that Guido someday 
changes his mind on that point.  ;)


--
~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] PEP 435: initial values must be specified? Yes

[Barry Warsaw]

On May 05, 2013, at 03:43 PM, Guido van Rossum wrote:

>I'll let Eli or Ethan respond to this. It sounds fine to me to support
>you with some kind of hook in the spec, even though I personally would
>rather assign my enum values explicitly (I'm old-fashioned that way
>:-).

Assuming the picklability of functional API created Enums is fixed (sorry,
another threadsplosion still awaits me), if you *really* have to have
autonumbering, use the functional API.  IMHO, the class API doesn't need them.

-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] PEP 435 - reference implementation discussion

[Tim Delaney]

On 5 May 2013 21:58, Tim Delaney  wrote:

> On 5 May 2013 16:17, Ethan Furman  wrote:
>
>> On 05/04/2013 10:59 PM, Ethan Furman wrote:
>>
>>> On 05/04/2013 08:50 PM, Tim Delaney wrote:
>>>
 2. Instead of directly setting the _name and _value of the enum_item,
 it lets the Enum class do it via Enum.__init__().

>>> Subclasses can override this. This gives Enums a 2-phase construction
 just like other classes.

>>>
>>> Not sure I care for this.  Enums are, at least in theory, immutable
>>> objects, and immutable objects don't call __init__.
>>>
>>
>> Okay, still thinking about `value`, but as far as `name` goes, it should
>> not be passed -- it must be the same as it was in the class definition
>>
>
> Agreed - name should not be passed.
>
> I would have preferred to use __new__, but Enum.__new__ doesn't get called
> at all from enum_type (and the implementation wouldn't be at all
> appropriate anyway).
>

*If* I can manage to convince Guido and Eli over in that other (initial
values) thread, I think it's still probably worthwhile calling __init__ on
the enum instance, but with no parameters. That would allow more
behaviour-based enums to set up any other initial state they require.

Tim Delaney
___
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] PEP 435: initial values must be specified? Yes

[Eli Bendersky]

> >> It was mentioned in the other threads, but the requirement is either:
> >>
> >> 1. That the dictionary returned from .__prepare__
> provide
> >> a way to obtain the enum instance names once it's been populated (e.g.
> once
> >> it's been passed as the classdict to __new__). The reference
> implementation
> >> provides a _enum_names list attribute. The enum names need to be
> available
> >> to a metaclass subclass before calling the base metaclass __new__.
> >>
> >> OR
> >>
> >> 2. A way for subclasses of Enum to modify the value before it's assigned
> >> to the actual enum - see the PEP 435 reference implementation -
> discussion
> >> thread where I modified the reference implementation to give enum
> instances
> >> 2-phase construction, passing the value to Enum.__init__. This way is
> more
> >> limited, as you need to use an appropriate mix-in type which puts
> certain
> >> constraints on the behaviour of the enum instances (e.g. they *have* to
> be
> >> int instances for auto-numbering). The implementation is also more
> complex,
> >> and as noted in that thread, __init__ might not be appropriate for an
> Enum.
> >
> >
> > So your preferred solution is (1), which requires exposing the metaclass
> and
> > an attribute publicly? I have to ask - to what end? What is the goal of
> > this? To have an AutoNumberedEnum which is guaranteed to be compatible
> with
> > stdlib's Enum?
> >
> > IMHO this goal is not important enough, and I'm not aware of other stdlib
> > modules that go to such lengths exposing implementation details publicly
> > (but I'd be happy to be educated on this!)
> >
> > Assuming ref435 goes as-is into stdlib in 3.4, can't you just assume its
> > implementation? And then change yours if it changes? Python's stdlib
> doesn't
> > change that often, but if we do want to change the implementation at some
> > point, this documented piece of internals is surely going to be in the
> way.
> > Why should the future malleability of a stdlib module be sacrificed for
> the
> > sake of this extension?
>
> Hm. Either you should argue much more strongly against Tim's solution,
> or you should expose the implementation detail he needs. Recommending
> that he should just use an internal detail of the implementation and
> hope it never changes sounds like encouraging a bad habit. It also
> seems you're contradicting yourself by saying that the code is
> unlikely to change and at the same time wanting to reserve the right
> to change it.
>

OK, then I'll say without contradictions that I don't expect the
implementation of Enum to be stable at this point. We don't even *have* an
implementation yet. All we have is some (pretty good!) code Ethan wrote and
I only partially reviewed. The final implementation may be completely
different, and then again we may want to change it in light of new input. I
wouldn't want to constrain ourselves at this point. Perhaps when 3.4 is
branched will be a point in time in which this can be re-visited. Makes
sense?


> Also note that the future malleability of a stdlib module is affected
> even by 3rd party use that goes beyond the documented API -- it all
> depends on a pragmatic weighing of how important a proposed change is
> against how likely it is to break existing use, and there are plenty
> of examples in the past where we have resisted changing an
> implementation detail because it would break too much code.
>

Agreed, but if we document these details, we're forever bound, pragmatic
weighing notwithstanding. Also, in this particular case if auto-numbered
enums in the class API are deemed super-useful we may end up incorporating
a syntax for them anyway, which will render the external module obsolete.


> If you really don't want to guarantee this part of the implementation,
> you should recommend that Tim just copy all of ref435. TBH I don't see
> what deriving AutoNumberEnum from the stdlib Enum class buy him except
> that he has to maintain less code. I don't expect there to be a lot of
> opportunities anywhere for writing isinstance(x, Enum).
>

That's what I was trying to say, I guess. Even if the chance of changing
the implementation of Enum is pretty low (after 3.4 I mean, before that
it's pretty damn high), I don't think that restricting ourselves here is
justified by Tim's maintaining less code in his external module. With all
due respect, of course ;-)

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] PEP 435 - requesting pronouncement

[Guido van Rossum]

On Sun, May 5, 2013 at 4:15 PM, Ethan Furman  wrote:
> On 05/05/2013 03:16 PM, Nikolaus Rath wrote:
>>
>> Guido van Rossum  writes:

 1. Having to enter the values is annoying. Sorry, I read the rationale
 and
 all that, and I *still* want to write a C-Like enum { A, B, C }. I fully
 expect to edit and reorder enums (if I ever use them) and get irritated
 with
 having to update the value assignments.
>>>
>>>
>>> I guess there are cultural differences around this. Anyway, you can
>>> use the functional/convenience API for this purpose.
>>
>>
>> Would it be wise to forbid ... as an enum value to preserve the option
>> to use it for automatic value assignment in some indefinite future?
>
>
> No.  If somebody has a use for ... is a value we're not going to say no on
> the very remote chance that Guido someday changes his mind on that point.
> ;)

Correct. *If* we were to have a change of heart on this issue, we'd
just introduce a class AutoNumberEnum. But I find the "..." syntax
sufficiently ugly that I really don't expect I'll ever change my mind.

-- 
--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] PEP 435: initial values must be specified? Yes

[Greg Ewing]

Ethan Furman wrote:

--> class Color(Enum):
... red, green, blue
...

--> class MoreColor(Color):
... red, orange, yellow
...

--> type(MoreColor.red) is MoreColor
False


This argument no longer applies, since we're not
allowing enums to be extended.


class Color(Enum):
red = e()
green = e()
blue = e()

and you can keep using `e()` for all your enumerations, since you don't 
care what actual value each enumeration member happens to get.


I don't think it's true that people wanting auto-numbering
don't care what values they get. Rather, they probably want
ordinal values assigned separately and consecutively for
each type, as in every other language I'm aware of that
provides auto-numbered enums.

If you *really* don't care what the values are, there's no
need for the items to have values at all.

--
Greg

___
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] PEP 435: initial values must be specified? Yes

[Ethan Furman]

On 05/05/2013 04:14 PM, Tim Delaney wrote:


1. That the dictionary returned from .__prepare__ provide a way 
to obtain the enum instance names
once it's been populated (e.g. once it's been passed as the classdict to 
__new__). The reference implementation
provides a _enum_names list attribute. The enum names need to be available to a 
metaclass subclass before calling
the base metaclass __new__.


[...]


My preferred solution is 1 (for the reason mentioned above) but it does not 
require exposing the metaclass publically
(that's obtainable via type(Enum)). It does require a way to get the enum names 
before calling the base metaclass
__new__, but that does not necessarily imply that I'm advocating exposing 
_enum_names (or at least, not directly).

My preferred way would probably be a note that the dictionary returned from the 
enum metaclass __prepare__ implements an
enum_names() or maybe __enum_names__() method which returns an iterator over 
the enum instance names in definition
order. The way this is implemented by the dictionary would be an implementation 
detail.


I like having an __enum_names__() that returns a list or tuple of (name, value) 
pairs in definition order.

--
~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] PEP 435: initial values must be specified? Yes

[Ethan Furman]

On 05/05/2013 04:57 PM, Greg Ewing wrote:

Ethan Furman wrote:

--> class Color(Enum):
... red, green, blue
...

--> class MoreColor(Color):
... red, orange, yellow
...

--> type(MoreColor.red) is MoreColor
False


This argument no longer applies, since we're not
allowing enums to be extended.


Actually, it does:

--> class Color(Enum):
...black, red, green, blue, cyan, magenta, yellow, black # oops!

--
~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] PEP 435 - ref impl disc 2

[Nick Coghlan]

On Mon, May 6, 2013 at 8:57 AM, Glenn Linderman  wrote:
> So you asked why would I want to put a named object as the value of
> something else with a name... maybe Enum should make provision for that...
> if the primary type ( Int for IntEnum, NamedInt for NamedIntEnum) happens to
> have a __name__ property, maybe the name of enumeration members should be
> passed to the constructor for the members... in other words,
>
> class NIE( NamedInt, Enum ):
> x = 1
> y = 2
>
> could construct enumeration members x and y whose values are NamedInt('x',
> 1) and
> NamedInt('y', 2)...

I think there comes a point where "subclass the metaclass" is the
right answer to "how do I do X with this type?". I believe making two
different kinds of value labelling mechanisms play nice is such a case
:)

Abstract Base Classes were the first real example of metaclass magic
in the standard library, and they avoided many of the confusing
aspects of metaclass magic by banning instantiation - once you get to
a concrete subclass, instances behave pretty much like any other
instance, even though type(type(obj)) is abc.ABCMeta rather than type:

>>> import collections
>>> class Example(collections.Hashable):
... def __hash__(self): return 0
...
>>> type(Example)

>>> type(Example())

>>> type(type(Example()))


Enumerations will only be the second standard library instance of
using metaclasses to create classes and objects that behave
substantially differently from conventional ones that use type as the
metaclass. The difference in this case relative to ABCs is that more
of the behavioural changes are visible on the instances.

This is *not* a bad thing (this is exactly what the metaclass
machinery is designed to enable), but it does mean we're going to have
to up our game in terms of documenting some of the consequences (as
Ethan noted, this doesn't need to go into the PEP, since that's aimed
at convincing people like Guido that already understand this stuff -
it's the enum module documentation, and potentially the language
reference, that is going to need enhancement). "Here's the section on
metaclasses in the language reference, figure out the consequences for
yourselves" is a defensible situation when we're providing metaclasses
primarily as a toolkit for third party frameworks, but a standard
library module that exploits them the way the enum module does places
additional obligations on us. The upside is that the very presence of
the enum module provides a concrete non-trivial example for us to lean
on in those explanations, rather than having to come up with toy
examples :)

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] PEP 435 - ref impl disc 2

[Glenn Linderman]

On 5/5/2013 7:14 PM, Nick Coghlan wrote:

I think there comes a point where "subclass the metaclass" is the
right answer to "how do I do X with this type?". I believe making two
different kinds of value labelling mechanisms play nice is such a case
:)


Could be.

Could be that sufficient operators added to an IntEnum subclass might 
work too. Although it might be unexpected that adding two enumeration 
members would produce a NamedInt :)  But of course, if the enumeration 
were defined by NamedIntEnum, it might be less surprising.


On the other hand, if Enum is in stdlib, and lots of flags parameters 
get defined with Enum, then it would be a pain in the neck to redefine 
them with NamedIntEnum, so that debugging of flag combinations is 
easier. There are enough flag parameters in the stdlib APIs to make me 
think this would be a deficiency.


Sadly, once the Enums are defined, there is to be no way to subclass 
them to add functionality, like producing a NamedInt result from 
operations on them.
___
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] PEP 435 - ref impl disc 2

[Nick Coghlan]

On Mon, May 6, 2013 at 12:46 PM, Glenn Linderman  wrote:
> Sadly, once the Enums are defined, there is to be no way to subclass them to
> add functionality, like producing a NamedInt result from operations on them.

That rule is enforced by the metaclass, so... ;)

Custom metaclasses are amazingly powerful, the trick is to deploy
their power judiciously, such that people can use the custom classes
associated with them without getting confused. SQL Alchemy, Django and
other frameworks do this quite well, but it *does* create subsections
of the type hierarchy which don't play well with others (for example,
having the same class be both an SQL Alchemy Table definition and a
Django Model definition probably isn't going to work).

Enums are the same - they carve out a subtree in the type hierarchy
that *doesn't* behave the same as the standard tree anchored directly
on type. This *is* going to cause conflicts with meta-tools that only
handle ordinary types - the trick is that the cause of the problem (a
custom metaclass) is also the solution (a custom metaclass derived
from enum.enum_type).

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] PEP 435 - ref impl disc 2

[Glenn Linderman]

On 5/5/2013 9:51 PM, Nick Coghlan wrote:

On Mon, May 6, 2013 at 12:46 PM, Glenn Linderman  wrote:

Sadly, once the Enums are defined, there is to be no way to subclass them to
add functionality, like producing a NamedInt result from operations on them.

That rule is enforced by the metaclass, so... ;)


Sure.  But:

stdlib contains:
  Enum (with subclass prohibiting metaclass)
  APIs with flags
  (assumed, in time) Enums defining the flag values (complete with 
enforcement by the metaclass)


user code:
  have to recreate all the Enums defining flag values using custom 
enum_type metaclass.


Seems like FlagEnum might be a a good thing to invent before 
(re-)defining Enums for all the flag values (that's what I'm after in 
combining NamedInt and Enum, really).


I suppose that a mere mortal could simply define a subclass of int that 
keeps track of expressions during arithmetic... using __name__ 
attributes of its operands if they exist, and as long as the mere mortal 
remembered to use it, it would achieve the same goal.  But having that 
built in with the flag value definitions would assure that it was 
available for everyone, all the time.
___
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] PEP 435 - requesting pronouncement

[Antoine Pitrou]

On Sun, 5 May 2013 15:27:36 -0700
Eli Bendersky  wrote:
> 
> As for pickling enums created with the functional API, I don't think we now
> provide less than the pickle module dictates in the general sense. The
> pickle docs say:

Next time, please try reading the message(s) you are replying to before
posting.

Thanks

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