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 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 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
> and have the metaclass make the constructor call.
>
> cl
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 metaclass store the args somewhere special
2013/4/27 Nick Coghlan :
> On Sun, Apr 28, 2013 at 11:38 AM, Benjamin Peterson
> wrote:
>> 2013/4/27 Nick Coghlan :
>>>
>>> On 28 Apr 2013 04:30, "Ethan Furman" wrote:
I filed bug http://bugs.python.org/issue17853 last night.
If somebody could point me in the right direction
On Sun, Apr 28, 2013 at 11:38 AM, Benjamin Peterson wrote:
> 2013/4/27 Nick Coghlan :
>>
>> On 28 Apr 2013 04:30, "Ethan Furman" wrote:
>>>
>>> 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),
This actually should have been for issue #17330, but I had the wrong
bug open when I copy-and-pasted the number.
On Sat, Apr 27, 2013 at 11:21 PM, brett.cannon
wrote:
> http://hg.python.org/cpython/rev/75e32a0bfd74
> changeset: 83525:75e32a0bfd74
> branch: 3.3
> parent: 83517:4b4ed1e1
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 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 a function defi
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.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http
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 a function definition,
This whole business can be avoide
2013/4/27 Nick Coghlan :
>
> On 28 Apr 2013 04:30, "Ethan Furman" wrote:
>>
>> 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.
>
> Hmm, interesting challenge. A ke
On 28 Apr 2013 04:30, "Ethan Furman" wrote:
>
> 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.
Hmm, interesting challenge. A key part of the problem is that the 3.x
c
Guido van Rossum writes:
> 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 is the helper class
On Sat, Apr 27, 2013 at 5:10 PM, Ethan Furman wrote:
> class Planet(
> Enum,
> names='''
>MERCURY
>VENUS
>EARTH
>MARS
>SATURN
>JUPITER
>
On Sat, Apr 27, 2013 at 2:27 PM, Ethan Furman wrote:
> 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.
Wow. I had no idea Python actually did this (override class-l
Steven D'Aprano writes:
> I'm sorry, but all these suggestions are getting the API completely
> backwards by making the common case harder than the rare case.
>
> We're creating an Enum, right? So the *common case* is to populate it
> with enum values. 99% of the time, enumerated values will be al
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 easily, simple
metaclass (or simple addition to curren
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 Apr 27, 2013, at 2: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 wit
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 with it.
That looks horri
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 with it.
That looks horrible.
--
--Guido van Rossum (python.org/~g
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 methods and ass
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,
blue=
Hi Guido,
Yes indeed, wrong list - I've forwarded this to the intended destination,
biopython-dev, and we'll continue the discussion there:
http://lists.open-bio.org/pipermail/biopython-dev/2013-April/010560.html
(It is nice to see Python getting used in all sorts of Google Summer
of Code project
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 is the hel
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 methods and assignments
Or, if we go with the metaclass magic
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 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 is the helper class (called, originally enough,
> en
Sounds like this was accidentally CC'ed to python-dev.
On Sat, Apr 27, 2013 at 10:23 AM, 阮铮 wrote:
> Hi Eric and Peter,
>
> I'm preparing the proposal for the codon alignment project. Two things I may
> want to hear your advice.
>
> 1) In the biopython wiki page, you mentioned "model selection" i
On Sat, Apr 27, 2013 at 9:41 AM, Nick Coghlan wrote:
> On Sun, Apr 28, 2013 at 2:11 AM, Larry Hastings wrote:
>> On 04/26/2013 02:41 PM, Guido van Rossum wrote:
>>
>> I am still optimistic that we can come up with a rule that
>> works well enough in practice (and the Zen rule to which I was
>> re
Hi Eric and Peter,
I'm preparing the proposal for the codon alignment project. Two things I may
want to hear your advice.
1) In the biopython wiki page, you mentioned "model selection" in the Approach
& Goals. I'm not sure if there are any advantages to use codon alignment for
model selection
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
On Sun, Apr 28, 2013 at 2:11 AM, Larry Hastings wrote:
> On 04/26/2013 02:41 PM, Guido van Rossum wrote:
>
> I am still optimistic that we can come up with a rule that
> works well enough in practice (and the Zen rule to which I was
> referring was, of course, "practicality beats purity").
>
>
> T
On 04/26/2013 02:41 PM, Guido van Rossum wrote:
I am still optimistic that we can come up with a rule that
works well enough in practice (and the Zen rule to which I was
referring was, of course, "practicality beats purity").
The rule I liked best is "ignore callables, descriptors, and anything
I've always found the nested class solution confusing when I had to
use it in Django. It is a technical solution to a technical problem,
but the resulting code is not very readable unless you have seen it a
lot; it is a new, exceptional pattern.
And as for using 'in' instead of 'isinstance' to che
Guido van Rossum wrote:
> we'd like to be able to define methods for the enum values, and the simplest
> way (for the user) to define methods for the enum values would be to allow
> def statements, possibly decorated, in the class. But now the implementation
> has to draw a somewhat murky line
On Sat, Apr 27, 2013 at 7:41 AM, Guido van Rossum wrote:
> On Fri, Apr 26, 2013 at 11:17 AM, Eli Bendersky wrote:
>> In contrast, personally I feel the current proposal in PEP 435 has an appeal
>> from the POV of simplicity. It really is a very nice separation of concerns
>> between enum values a
Why not defining new methods/changing the behaviour using a different
metaclass?
Victor
Le 27 avr. 2013 05:12, "Nikolaus Rath" a écrit :
> Steven D'Aprano writes:
> > 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 wro
39 matches
Mail list logo
