On 04/25/2013 07:13 PM, Nick Coghlan wrote:
On Fri, Apr 26, 2013 at 8:29 AM, Barry Warsaw wrote:
On Apr 25, 2013, at 03:19 PM, Guido van Rossum wrote:
Clearly this is a trick question. :-)
A bit, yes. :)
I was told when this was brought up previously (a week ago?) that it
would be simple
On 04/25/2013 08:14 PM, Greg wrote:
On 26/04/2013 1:28 p.m., Ethan Furman wrote:
Interesting idea, but why does Day(3) have to be disallowed to make it
work?
Because it's ambiguous. Which day of the week is number 3? It
depends on where you start.
Ah.
I should perhaps point out tha
On 04/25/2013 10:01 PM, Steven D'Aprano wrote:
On 26/04/13 13:22, Greg wrote:
On 26/04/2013 3:12 p.m., Glenn Linderman wrote:
On 4/25/2013 7:49 PM, Nick Coghlan wrote:
You couldn't create an enum of callables, but that would be a
seriously weird thing to do anyway
But aren't all classe
On 04/25/2013 10:30 PM, Nick Coghlan wrote:
Alternatively, we can flip it around and require that each enum
definition nominate an expected value type (defaulting to int) and
only convert class attributes that are instances of that type to
instances of the enum class.
I think this option makes
On 04/26/2013 08:50 AM, Larry Hastings wrote:
FWIW I'm +0.5 on "the enum metaclass ignores callables and
descriptors". This seems reasonably Pythonic, much more so than "ignore
everything except ints and strings". And as long as we're
special-casing it I think we should opt for flexibility. Cer
On 04/26/2013 09:27 AM, Serhiy Storchaka wrote:
26.04.13 18:50, Larry Hastings написав(ла):
On 04/26/2013 12:34 AM, Greg Ewing wrote:
Or if, as Guido says, the only sensible things to use
as enum values are ints and strings, just leave anything
alone that isn't one of those.
The standard Java
On 04/26/2013 06:37 PM, Greg Ewing wrote:
Eli Bendersky wrote:
There's a conceptual difference between a value of an enumeration and a
collection of such values.
Not if you think of an enum as a type and a type as
defining a set of values. From that point of view, the
enum itself is already a
On 04/26/2013 11:17 AM, Eli Bendersky wrote:
I feel that this thread has lost track of it long ago. Some time back in the
Enum discussions (some 350 messages ago or
so), there was a proposal to have this:
class Color(Enum):
RED, BLUE, GREEN
By doing some crazy-cool shenanigans. Although th
On 04/26/2013 07:29 PM, Glenn Linderman wrote:
On 4/26/2013 6:22 PM, Greg Ewing wrote:
Guido van Rossum wrote:
If we had access to the syntax used for the definition, this would be
simple: assignments define items, def statements define methods. But
at run time we only see the final object resu
On 04/27/2013 09:01 AM, Guido van Rossum wrote:
Hm... A lightbulb just went off. Objects representing both undecorated
and decorated methods have a __get__() method, courtesy of the
descriptor protocol. Maybe checking for that will work? It feels
Pythonic to me: it uses a corner of the language
I filed bug http://bugs.python.org/issue17853 last night.
If somebody could point me in the right direction (mainly which files to look
in), I'd be happy to attempt a patch.
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pyth
On 04/27/2013 10:35 AM, Guido van Rossum wrote:
On Sat, Apr 27, 2013 at 10:04 AM, Ethan Furman wrote:
While this will certainly work, it means you can't have class variables that
happen to be the same type as the enum -- so no int in an IntEnum, for
example.
The solution I like best i
On 04/27/2013 12:47 PM, Ethan Furman wrote:
On 04/27/2013 11:45 AM, Steven D'Aprano wrote:
On 27/04/13 12:51, Ethan Furman wrote:
On 04/26/2013 07:29 PM, Glenn Linderman wrote:
[...]
class Color( Enum ):
Enum.__enumerationItems__(
red=1,
green=2,
On 04/27/2013 11:45 AM, Steven D'Aprano wrote:
On 27/04/13 12:51, Ethan Furman wrote:
On 04/26/2013 07:29 PM, Glenn Linderman wrote:
[...]
class Color( Enum ):
Enum.__enumerationItems__(
red=1,
green=2,
blue=3,
)
# other method
On 04/27/2013 02:57 PM, Guido van Rossum wrote:
On Sat, Apr 27, 2013 at 1:01 PM, Ethan Furman wrote:
It seems to me that the *most* common case will be a simple name mapping, in
which case one can do:
Planet = Enum._make('Planet', 'MERCURY VENUS EARTH')
and be done w
On 04/27/2013 04:07 PM, Philip Jenvey wrote:
Call me crazy, but might I suggest:
class Planet(Enum, values='MERCURY VENUS EARTH'):
"""Planets of the Solar System"""
Okay, you're crazy! ;)
I must be too, 'cause I really like that suggestion. Works easily, simple metaclass (or simple ad
On 04/27/2013 04:17 PM, Ethan Furman wrote:
On 04/27/2013 04:07 PM, Philip Jenvey wrote:
class Planet(Enum, values='MERCURY VENUS EARTH'):
"""Planets of the Solar System"""
I must be too, 'cause I really like that suggestion. Works eas
On 04/27/2013 07:01 PM, Greg Ewing wrote:
PJ Eby wrote:
On Sat, Apr 27, 2013 at 2:27 PM, Ethan Furman wrote:
I filed bug http://bugs.python.org/issue17853 last night.
About the only workaround I can see is to put "Season = Season" at the
top of a class that uses this inside
On 04/27/2013 07:12 PM, Greg Ewing wrote:
Guido van Rossum wrote:
And __init__/__new__ probably shouldn't be
overridden.
Why shouldn't __init__ be overridden? It's the obvious
way to support Java-style enum-items-with-attributes.
Overriding __init__ is a PITA because __init__ is also called
On 04/27/2013 09:20 PM, Guido van Rossum wrote:
On Saturday, April 27, 2013, Greg Ewing wrote:
This whole business can be avoided by doing things differently
in the first place. Instead of initialising the enum items by
calling the class, just assign a tuple of args to the name
a
On 04/27/2013 08:59 PM, Greg Ewing wrote:
Ethan Furman wrote:
Overriding __init__ is a PITA because __init__ is also called when you do
Planet(3) # get EARTH
and __init__ was expecting a gravitational constant and radius (or something
like that).
A couple ways around that:
1) have the
On 04/27/2013 08:59 PM, Greg Ewing wrote:
It's possible to make it work, I think. The __call__ method
of the metaclass is going to have to do something special
anyway, so that Planet(3) can look up and return an existing
instance instead of making a new one. And if it doesn't make
a new instance
On 04/27/2013 09:20 PM, Guido van Rossum wrote:
On Saturday, April 27, 2013, Greg Ewing wrote:
class Planet(Enum):
MERCURY = (3.303e+23, 2.4397e6)
VENUS = (4.869e+24, 6.0518e6)
EARTH = (5.976e+24, 6.37814e6)
MARS= (6.421e+23, 3.3972e6)
JUPITER = (1.9e+27, 7.1
Example enumeration:
class Seasons(Enum):
SPRING = 1
SUMMER = 2
AUTUMN = 3
WINTER = 4
days_in_year = 365
@property
def avg_temp(self):
return (75, 92, 66, 33)[int(self)+1] # enums are 1-based
Definite Issues:
- should enum items be of the type of the Enu
On 04/28/2013 01:02 PM, Guido van Rossum wrote:
My opinions added
Mine also now added.
Example enumeration:
class Seasons(Enum):
SPRING = 1
SUMMER = 2
AUTUMN = 3
WINTER = 4
days_in_year = 365
@property
def avg_temp(self):
return (75, 92, 66, 33
On 04/28/2013 02:29 PM, Antoine Pitrou wrote:
On Sun, 28 Apr 2013 13:02:11 -0700
Guido van Rossum wrote:
- for the above two, how should they be included/excluded?
IMO Everything should be enumerated except
(a) things with a __get__() method (i.e. descriptors)
(b) __dunder__ names
I th
On 04/28/2013 04:37 PM, Steven D'Aprano wrote:
On Sun, Apr 28, 2013 at 12:32 PM, Ethan Furman wrote:
- should an enum item be selectable via __call__ instead of __getitem__
(i.e. Seasons(3) is AUTUMN)
Does anyone know why this is even an issue? Is this pure bike-shedding over the
On 04/28/2013 07:10 PM, Stephen J. Turnbull wrote:
@Ethan: I have real trouble sympathizing with your point of view
because you consistently pluralize your Enum names. AUTUMN *is not* a
SeasonZZ, it is an element of the *collection* Seasons. OTOH, AUTUMN
*is* a Season (look Ma, no ZZ!)
I wou
On 04/28/2013 06:52 PM, Steven D'Aprano wrote:
On 29/04/13 10:29, Ethan Furman wrote:
On 04/28/2013 04:37 PM, Steven D'Aprano wrote:
On Sun, Apr 28, 2013 at 12:32 PM, Ethan Furman wrote:
- should an enum item be selectable via __call__ instead of __getitem__
(i.e. Season(3)
[re-directing back to python-dev]
On 04/28/2013 08:42 PM, Davis Silverman wrote:
as a not super experienced python developer, when i see Season('AUTUMN') it
looks like im creating an a Season object. I
understand your resoning, that it acts like a boolean singleton, however, i
feel it would co
On 04/28/2013 09:54 PM, Guido van Rossum wrote:
On Sunday, April 28, 2013, Ethan Furman wrote:
Enums are the same: they could return brand new instances every time, and
programs using `==` to compare will keep
on working. That they don't is an implementation detail.
Whoa. In this cas
[starting new thread to not pollute the summary thread]
On 04/28/2013 11:54 PM, Antoine Pitrou wrote:> On Sun, 28 Apr 2013 17:29:35
-0700
Ethan Furman wrote:
Not only is this inconsistent with the rest of Python*, but it's going to be a
PITA for data storage/retrieval:
d
[creating new thread]
On 04/29/2013 01:30 AM, Steven D'Aprano wrote:
On Sun, Apr 28, 2013 at 11:50:16PM -0700, Ethan Furman wrote:
In other words, currently:
class Color(Enum):
red = 1
green = 2
blue = 3
class MoreColor(Color):
cyan = 4
magent
On 04/29/2013 08:39 AM, Guido van Rossum wrote:
Indeed, the "type(Color.red) is Color" claim was meant for the
situation where red is defined directly in Color, and I used type()
instead of isinstance() because Barry was proposing to overload
isinstance() to make this true without equating the cl
On 04/29/2013 09:30 AM, Larry Hastings wrote:
On 04/29/2013 06:51 AM, Eli Bendersky wrote:
flufl.enum disallows this:
class Color(Enum):
red = 1
blue = 2
green = 1 # oops!
Has it been decided that this is now allowed? If this is indeed the case, then
Color(1) is a problem. The options
In the Planet example we saw the possibility of specifying arguments to enum
item __init__:
class Planet(Enum):
MERCURY = (3.303e+23, 2.4397e6)
VENUS = (4.869e+24, 6.0518e6)
EARTH = (5.976e+24, 6.37814e6)
MARS= (6.421e+23, 3.3972e6)
JUPITER = (1.9e+27, 7.1492e7)
On 04/29/2013 02:45 PM, Terry Jan Reedy wrote:
On 4/29/2013 8:24 AM, Eli Bendersky wrote:
Thanks for the summary. One issue I don't see addressed here is
int-compatibility. Am I correct to assume that nothing changes w.r.t.
that, and that an IntEnum subclass of Enum will be provided which is
is
On 04/29/2013 03:25 PM, Eli Bendersky wrote:
On Mon, Apr 29, 2013 at 2:59 PM, Ethan Furman wrote:
In the Planet example we saw the possibility of specifying arguments to enum
item __init__:
class Planet(Enum):
MERCURY = (3.303e+23, 2.4397e6)
VENUS = (4.869e+24, 6.0518e6
On 04/29/2013 03:13 PM, Guido van Rossum wrote:
Only if it is easy to implement. This example doesn't look like a good
fit for enums, but if the enum implementation can easily support this
(e.g. if there's nothing special about __init__) I don't want to
forcibly rule it out. I don't want to have
This just doesn't make sense to me:
--> class Stuff(Enum):
... blue = 1
... china = 'really big country'
... random = (8273.199, 517)
--> Stuff.blue.name == 'blue'
--> Stuff.blue.value == 1
--> Stuff.china.name == 'china'
--> Stuff.china.value == ???
--> Stuff.random.name == 'rando
On 04/29/2013 03:25 PM, Eli Bendersky wrote:
Besides, did we not agree that the only acceptable *members* for enums are going to
be descriptors? In the above, mass &
radius are not descriptors.
Actually, it's the other way -- descriptors are excluded from being enum items,
along with dunder
On 04/29/2013 03:50 PM, Ethan Furman wrote:
This just doesn't make sense to me:
--> class Stuff(Enum):
... blue = 1
... china = 'really big country'
... random = (8273.199, 517)
--> Stuff.blue.name == 'blue'
--> Stuff.blue.value ==
On 04/29/2013 06:23 PM, Marco Hemmelrath wrote:
First of all, hi, I'm new to this list.
Following the enum discussions on this list I am kind of confused about how
enums and their respective instances, i.e.
the values, should behave in "normal" context.
I apologize beforehand for the mass of "q
On 04/29/2013 05:38 PM, Greg Ewing wrote:
Ethan Furman wrote:
I suppose the other option is to have `.value` be whatever was assigned (1,
'really big country', and (8273.199, 517) ),
I thought that was the intention all along, and that we'd
given up on the idea of auto-as
Greetings,
Eli asked me to put the reference implementation here for review.
It is available at https://bitbucket.org/stoneleaf/aenum in ref435.py and
test_ref435.py
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/
On 04/30/2013 01:12 PM, Ethan Furman wrote:
It is available at https://bitbucket.org/stoneleaf/aenum in ref435.py and
test_ref435.py
Oh, as written in requires 3.3+. If you want to play around with it and are stuck on an earlier version, remove the
`from None` on line 68.
--
~Ethan
On 04/30/2013 03:24 PM, Glenn Linderman wrote:
On 4/30/2013 1:12 PM, Ethan Furman wrote:
Greetings,
Eli asked me to put the reference implementation here for review.
It is available at https://bitbucket.org/stoneleaf/aenum in ref435.py and
test_ref435.py
Thanks for the code reference
On 04/30/2013 03:34 PM, Ethan Furman wrote:
On 04/30/2013 03:24 PM, Glenn Linderman wrote:
On 4/30/2013 1:12 PM, Ethan Furman wrote:
Greetings,
Eli asked me to put the reference implementation here for review.
It is available at https://bitbucket.org/stoneleaf/aenum in ref435.py and
On 04/30/2013 07:05 PM, Nikolaus Rath wrote:
Larry Hastings writes:
On 04/29/2013 07:42 PM, Nikolaus Rath wrote:
State is a class, it just inherits from enum. Thus:
type(State) == type(enum) == type(EnumMetaclass)
issubclass(State, enum) == True
HTH,
-Nikolaus
If you'd tried it, you
Latest code available at https://bitbucket.org/stoneleaf/aenum.
--> class Color(Enum):
... red = 1
... green = 2
... blue = 3
Enum items are virtual attributes looked by EnumType's __getattr__. The win
here is that
--> Color.red.green.blue
no longer works. ;)
Subclassing an imp
On 04/30/2013 11:18 PM, Barry Warsaw wrote:
On Apr 28, 2013, at 11:50 PM, Ethan Furman wrote:
But as soon as:
type(Color.red) is Color # True
type(MoreColor.red) is MoreColor # True
then:
Color.red is MoreColor.red # must be False, no?
If that last statement can still
On 04/30/2013 09:47 PM, Barry Warsaw wrote:
On Apr 30, 2013, at 07:39 PM, Glenn Linderman wrote:
Because Guido said no subclassing.
Indeed, I heard him. But what I heard was that subclasses shouldn't be
allowed to define new enumeration values, and that was the point of all his
justification
On 04/30/2013 10:41 PM, Barry Warsaw wrote:
What does it break if you remove the `if base._enum` check? I mean, can we be
consenting adults here or not?
I removed the error and added a couple lines to EnumType.__getattr_, and now subclassing works as I think you are used
to it working.
Ver
On 05/01/2013 12:05 AM, Steven D'Aprano wrote:
On Tue, Apr 30, 2013 at 09:19:49PM -0700, Ethan Furman wrote:
Latest code available at https://bitbucket.org/stoneleaf/aenum.
Ethan, you seem to be writing a completely new PEP in opposition to
Barry's PEP 435. But your implementati
New repo to avoid confusion:
https://bitbucket.org/stoneleaf/ref435
which has the latest updates from the feedback.
Subclassing is again disabled. Let's get the rest of it done, then we can come
back to that issue if necessary.
--
~Ethan~
___
Pytho
On 05/01/2013 08:35 AM, Steven D'Aprano wrote:
On 02/05/13 01:09, Ethan Furman wrote:
New repo to avoid confusion:
https://bitbucket.org/stoneleaf/ref435
Apparently I have to log in before I can even see the repo.
Not going to happen.
Sorry, just made it public. Try again?
--
~
We may not want to /completely/ disallow subclassing. Consider:
--> class StrEnum(str, Enum):
...'''string enums for Business Basic variable names'''
...
--> class Vendors(StrEnum):
EnumError: subclassing not allowed
My point is that IntEnum, StrEnum, ListEnum, FloatEnum are all "subclasse
On 05/01/2013 02:48 PM, Eli Bendersky wrote:
> Am 01.05.2013 20:04, schrieb Eli Bendersky:
>
> > Actually, in flufl.enum, IntEnum had to define a magic
__value_factory__
> > attribute, but in the current ref435 implementation this isn't
needed, so
> > IntEnu
On 05/01/2013 02:36 PM, Tim Delaney wrote:
On 2 May 2013 02:18, Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/01/2013 12:14 PM, Guido van Rossum wrote:
> But we'd probably have to give up something else, e.g. adding methods
> to enums, or any hope th
On 05/01/2013 02:07 PM, Guido van Rossum wrote:
On Wed, May 1, 2013 at 2:04 PM, Eli Bendersky wrote:
class BehaviorMixin:
# bla bla
class MyBehavingIntEnum(int, BehaviorMixin, Enum):
foo = 1
bar = 2
It's a common pattern to do this with a base class rather than a
mixin, though, and
On 05/02/2013 07:57 AM, Barry Warsaw wrote:
On May 01, 2013, at 11:54 AM, Larry Hastings wrote:
On 04/30/2013 11:29 PM, Ethan Furman wrote:
On 04/30/2013 11:18 PM, Barry Warsaw wrote:
On Apr 28, 2013, at 11:50 PM, Ethan Furman wrote:
But as soon as:
type(Color.red) is Color
In order for the Enum convenience function to be pickleable, we have this line
of code in the metaclass:
enum_class.__module__ = sys._getframe(1).f_globals['__name__']
This works fine for Cpython, but what about the others?
--
~Ethan~
___
Python-
On 05/02/2013 01:52 PM, Eli Bendersky wrote:
Back to my question from before, though - do we have a real technical
limitation of having something like
inspect.what_module_am_i_now_in() that's supposed to work for all Python code?
By which you really mean inspect.what_module_was_I_called_from(
On 05/02/2013 04:45 PM, Greg Ewing wrote:
Eli Bendersky wrote:
TypeError: Cannot subclass enumerations
This message might be better phrased as "cannot extend
enumerations", since we're still allowing subclassing
prior to defining members.
I like it, thanks!
--
~Ethan~
_
On 05/02/2013 04:43 PM, Greg Ewing wrote:
Guido van Rossum wrote:
you should do some other check,
e.g. "if x in Color:".
So you don't think it's important to have an easy
way to take user input that's supposed to be a
Color name and either return a Color or raise
a ValueError?
I don't believ
On 05/04/2013 04:33 AM, Antoine Pitrou wrote:
On Sat, 4 May 2013 16:42:08 +1000
Nick Coghlan wrote:
On Sat, May 4, 2013 at 4:10 PM, Georg Brandl wrote:
Am 04.05.2013 01:22, schrieb Antoine Pitrou:
On Sat, 04 May 2013 11:15:17 +1200
Greg Ewing wrote:
Eli Bendersky wrote:
I'm just curious w
On 05/04/2013 08:11 PM, Tim Delaney wrote:
I've been able to achieve the auto-numbering without relying on the internal
implementation at all (with a
limitation), with a single change to enum_type.__new__. My previous patch was
slightly wrong - fix below as well. All
existing tests pass. BTW
On 05/04/2013 10:59 PM, Ethan Furman wrote:
On 05/04/2013 08:50 PM, Tim Delaney wrote:
Think I've come up with a system that works for my auto-numbering case without
knowing the internals of enum_type. Patch
passes all existing test cases. The patch does two things:
[snip]
2. Inste
On 05/04/2013 08:50 PM, Tim Delaney wrote:
Think I've come up with a system that works for my auto-numbering case without
knowing the internals of enum_type. Patch
passes all existing test cases. The patch does two things:
1. Finds the first non-Enum class on the MRO of the new class and uses
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 exp
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/p
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
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://bitbucke
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 t
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
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. Th
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
allowi
On 05/06/2013 10:48 AM, Georg Brandl wrote:
Am 05.05.2013 22:09, schrieb Ethan Furman:
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
On 05/05/2013 01:01 AM, Glenn Linderman wrote:
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"
On 05/05/2013 02: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.
class Color(AutoIntEnum):
red = ...
green = ...
blue = ...
Will this do?
class AutoNumber
On 05/06/2013 07:58 PM, Tim Delaney wrote:
Considering that doesn't actually work with the reference implementation
(AutoNumber.__new__ is never called) ... no.
Two points:
1) Did you grab the latest code? That exact implementation passes in the
tests.
2) You can write your __new__ ho
On 05/06/2013 08:35 PM, Glenn Linderman wrote:
N.B. In your latest ref435.py code, line 105, should be "An Enum class _is_ final..."
rather than "in".
Thanks, fixed.
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.o
On 05/06/2013 10:18 PM, Tim Delaney wrote:
On 7 May 2013 15:14, Tim Delaney mailto:timothy.c.dela...@gmail.com>> wrote:
Unfortunately, if you subclass AutoNumber from IntEnum it breaks.
-- Run Python3 --
Traceback (most recent call last):
File "D:\home\repos\m
On 05/07/2013 07:48 AM, Piotr Duda wrote:
What about adding simple syntax (I proposed this earlier, but no one
commented) that take care of assigning name and module, something
like:
def name = expression
which would be rough equivalent for:
name = expression
name.__name__ = 'name'
name.__mod
On 05/07/2013 08:01 AM, Piotr Duda wrote:
2013/5/7 Ethan Furman :
On 05/07/2013 07:48 AM, Piotr Duda wrote:
What about adding simple syntax (I proposed this earlier, but no one
commented) that take care of assigning name and module, something
like:
def name = expression
which would be
On 05/07/2013 08:03 AM, Nick Coghlan wrote:
On Tue, May 7, 2013 at 11:34 PM, Eli Bendersky wrote:
4) Using _getframe(N) here seems like an overkill to me.
It's not just overkill, it's fragile - it only works if you call the
constructor directly. If you use a convenience function in a utility
On 05/09/2013 11:46 PM, Nick Coghlan wrote:
As an added bonus, people trying to understand the details of
metaclasses will now have a non-trivial standard library example to
investigate
Hmmm... __prepare__ really isn't doing very much at the moment... I could have it do more... maybe create so
On 05/10/2013 10:15 PM, Glenn Linderman wrote:
But the last few lines of demo1 demonstrate that NIE doesn't like, somehow,
remember that its values, deep down under
the covers, are really int. And doesn't even like them when they are wrapped
into IntET objects. This may or may not
be a bug i
On 05/12/2013 04:49 PM, Raymond Hettinger wrote:
After the long design effort for the enum module,
I'm sure there will be a forthcoming effort to apply
them pervasively throughout the standard library.
I'd like to apply them where it makes sense. It would be a good way for me to learn all that
On 05/12/2013 08:15 PM, Stephen J. Turnbull wrote:
Ethan Furman writes:
> I will certainly ask for advice on which modules to spend my time
> on. I know enums are not a cure-all, but they are great for
> debugging and interactive work.
Especially in new code where they
On 05/13/2013 12:06 AM, Raymond Hettinger wrote:
Ethan's email suggests that against my advice he is in-fact going to go through
the standard library, applying enums
quite broadly.
I think you are falling victim to Wizard's First Rule: people will believe what
they want to be true, or are af
On 05/10/2013 10:15 PM, Glenn Linderman wrote:
So it is quite possible to marry the two, as Ethan helped me figure out using
an earlier NamedInt class:
class NIE( IntET, Enum ):
x = ('NIE.x', 1)
y = ('NIE.y', 2)
z = ('NIE.z', 4)
and then expressions involving members of NIE (an
On 05/13/2013 07:36 PM, Ethan Furman wrote:
Here's your code, revamped. I did make a slight change in the meta -- I moved
the name assignment above the __init__
call so it's available in __init__.
--8<
from ref435 imp
On 05/13/2013 10:01 PM, Glenn Linderman wrote:
Sorry if this sounds repetitious, but all the other times I've mentioned it, it
has been in a big discussion of other
stuff too.
It's a while 'til 3.4. A bitfield-type enum may show up in the docs, if no
where else. ;)
--
~Ethan~
On 05/13/2013 10:01 PM, Glenn Linderman wrote:
On 5/13/2013 7:36 PM, Ethan Furman wrote:
On 05/10/2013 10:15 PM, Glenn Linderman wrote:
So it is quite possible to marry the two, as Ethan helped me figure out using
an earlier NamedInt class:
class NIE( IntET, Enum ):
x = ('NIE.
On 05/13/2013 11:11 PM, Ethan Furman wrote:
On 05/13/2013 10:01 PM, Glenn Linderman wrote:
On 5/13/2013 7:36 PM, Ethan Furman wrote:
On 05/10/2013 10:15 PM, Glenn Linderman wrote:
So it is quite possible to marry the two, as Ethan helped me figure out using
an earlier NamedInt class:
class
On 05/14/2013 08:22 AM, Carlos Nepomuceno wrote:
Hi guys! This is my first post on this list.
Hi Carlos!
I'd like have your opinion on how to safely implement WSGI on a production
server.
Unfortunately this list is for the development /of/ Python, no development
/with/ Python.
Try aski
On 05/13/2013 11:32 AM, Guido van Rossum wrote:
But now you enter a different phase of your project, or one of your
collaborators does, or perhaps you've released your code on PyPI and one of
your users does. So someone tries to pickle some class instance that happens
to contain an unpicklab
On 05/14/2013 01:58 PM, Guido van Rossum wrote:
On Tue, May 14, 2013 at 1:09 PM, Ethan Furman wrote:
On 05/13/2013 11:32 AM, Guido van Rossum wrote:
But now you enter a different phase of your project, or one of your
collaborators does, or perhaps you've released your code on PyPI an
On 05/14/2013 03:16 PM, Nick Coghlan wrote:
On 15 May 2013 07:38, "Guido van Rossum" mailto:gu...@python.org>> wrote:
On Tue, May 14, 2013 at 2:13 PM, Ethan Furman mailto:et...@stoneleaf.us>> wrote:
> On 05/14/2013 01:58 PM, Guido van Rossum wrote:
>>
>> O
901 - 1000 of 1590 matches
Mail list logo
