On Feb 24, 2013, at 07:32 PM, Ethan Furman wrote:
>I would still like the int subclass, though, as it would be an aid to me on
>the Python side.
I think you'll know what I'm going to say. :)
1) Usually, you won't need it (see the responses from people who don't care
about the value).
2) When yo
On Feb 26, 2013, at 01:22 AM, Nick Coghlan wrote:
>I don't think we need true constants - labelled values should suffice
>for easier to debug magic numbers.
+1
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/list
On Feb 25, 2013, at 07:12 AM, Ethan Furman wrote:
>And if, in those places, the enums were based on ints (or strings), would it
>hurt you? Because in the places where I, as well as many others, use enums
>we *need* the int portion; and having to wrap the enum in an int() call is
>seven extra keys
On Feb 25, 2013, at 05:40 PM, brett.cannon wrote:
>http://hg.python.org/peps/rev/7aa92fb33436
>changeset: 4776:7aa92fb33436
>user:Brett Cannon
>date:Mon Feb 25 11:39:56 2013 -0500
>summary:
> Add PEP 445: The Argument Clinic DSL
I beat you with PEP 436. :)
-Barry
On Feb 25, 2013, at 05:19 PM, MRAB wrote:
>Would we be doing either of those? Surely we would be using a dict
>instead, and what does a dict use, identity or equality?
It's just a contrived example for email brevity. In my real world examples,
the code inside the conditions can be much more comp
On Feb 25, 2013, at 09:35 AM, Ethan Furman wrote:
>> >>> Colors = make('Colors', 'red green blue'.split())
>> >>> Animals = make('Animals', 'ant bee cat'.split())
>> >>> Colors.green == Animals.bee
>
>But this I don't, and in both mine, Ted's, and Alex's versions enums from
>differe
On Feb 25, 2013, at 10:25 AM, Ethan Furman wrote:
>Hey, I think I just had a light-bulb moment: have the enum implement
>__index__ -- that will solve my use-case of using them for list indices.
They don't currently, but I think it's reasonable, given that they already
support __int__.
https://bu
On Feb 26, 2013, at 10:04 AM, Tim Delaney wrote:
>You're starting to tread in an area that I investigated, did an
>implementation of, and then started moving away from due to a different
>approach (delegating to the methods in the owning Enum class when accessing
>EnumValue attribtues).
At first
On Feb 27, 2013, at 11:33 AM, fwierzbi...@gmail.com wrote:
>I am suggesting that we push forward on the "shared library" approach to the
>files in the Lib/* directory, so that would certainly include IronPython and
>PyPy as well I hope.
+1
>The easy part for Jython is pushing some of our "if is_
On Feb 27, 2013, at 04:51 PM, Michael Foord wrote:
>If you have other items you'd like to discuss please let me know and I can
>add them to the agenda.
I'd like to have some discussions around promotion of Python 3, how we can
accelerate its adoption, availability of supporting packages, what cri
On Feb 28, 2013, at 08:44 AM, fwierzbi...@gmail.com wrote:
>Sorry I meant "is_jython" as a sort of shorthand for a case by case
>check. It would be cool if we had a nice set of checks somewhere like
>"is_refcounted", etc. Would the sys.implementation area be a good
>place for such things?
Yep. U
On Mar 04, 2013, at 07:26 PM, Robert Collins wrote:
>It is of course possible for subunit and related tools to run their
>own implementation, but it seems ideal to me to have a common API
>which regular unittest, nose, py.test and others can all agree on and
>use : better reuse for pretty printers
On Mar 04, 2013, at 11:34 AM, Brett Cannon wrote:
>> And One True Way of invoking and/or discovering how to invoke, a package's
>> test suite.
>
>How does unittest's test discovery not solve that?
I should have added "from the command line". E.g. is it:
$ python -m unittest discover
$ python se
On Mar 04, 2013, at 07:41 PM, Antoine Pitrou wrote:
>> $ python -m unittest discover
>> $ python setup.py test
>> $ python setup.py nosetests
>> $ python -m nose test
>> $ nosetests-X.Y
>>
>> Besides having a multitude of choices, there's almost no way to
>> automatically discover (e.g. by metada
On Mar 04, 2013, at 03:02 PM, Daniel Holth wrote:
>setup.py's setup(test_suite="x")... not sure if this is a distutils or
>setuptools feature. PEP 426 has an extension mechanism that could do
>the job.
Shouldn't "testing" be a first order feature?
-Barry
signature.asc
Description: PGP signatur
On Mar 04, 2013, at 03:40 PM, Daniel Holth wrote:
>On Mon, Mar 4, 2013 at 3:14 PM, Barry Warsaw wrote:
>> On Mar 04, 2013, at 03:02 PM, Daniel Holth wrote:
>>
>>>setup.py's setup(test_suite="x")... not sure if this is a distutils or
>>>setuptools
On Mar 05, 2013, at 11:01 AM, Robert Collins wrote:
>The big thing is automated tools, not developers.
Exactly.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python
On Mar 04, 2013, at 05:04 PM, Brett Cannon wrote:
>Sure, but that has nothing to do with programmatic package discovery.
>That's something you will have to do as a person in making a qualitative
>decision along the same lines as API design. Flipping a bit in a config
>file saying "I have tests" do
On Mar 05, 2013, at 01:09 PM, Robert Collins wrote:
>It isn't about length. It is about knowing that *that* is what to type
>(and btw that exact command cannot run twisted's tests, among many
>other projects tests).
>Perhaps we are talking about different things. A top level script to
>run tests
On Mar 05, 2013, at 02:11 AM, Donald Stufft wrote:
>Doesn't setuptools/distribute already have a setup.py test command? That
>seems like the easiest way forward?
Yes, and in theory it can make `python setup.py test` work well. But there
are lots of little details (such as API differences for en
On Mar 17, 2013, at 05:37 PM, Christian Heimes wrote:
>Any attempt to fix the XML issues *will* change the behavior of the
>library and result into an incompatibility with older releases. Benjamin
>doesn't want to change the behavior of our XML libraries. IIRC Georg and
>Barry are +0. I think that
On Mar 17, 2013, at 09:16 PM, Glenn Linderman wrote:
>try:
>newSimpleXMLAPI()
>newapi = True
>except Exception:
>newapi = False
try:
True
except NameError:
True = 1
False = 0
-Barry
signature.asc
Description: PGP signature
___
On Mar 18, 2013, at 09:45 PM, Larry Hastings wrote:
>4. Store a string that looks like the Python declaration of the signature,
>and parse it (Nick's suggestion). For foo above, this would be
>"(arg,b=3,*,kwonly='a')". Length: 23 bytes.
Very nice.
-Barry
___
On Mar 20, 2013, at 11:22 AM, Eli Bendersky wrote:
>IDLE would be a great first foray into this "separate project" world,
>because it is many ways a separate project.
I really think that's true. A separate project, occasionally sync'd back into
the stdlib by a core dev seems like the right way t
On Mar 20, 2013, at 12:31 PM, Guido van Rossum wrote:
>Agreed that the "sync into stdlib" think should not happen, or should at
>best be a temporary measure until we can remove idle from the source
>tarball (maybe at the 3.4 release, otherwise at 3.5).
Right. Ultimately, I think IDLE should be a
On Mar 20, 2013, at 12:40 PM, Guido van Rossum wrote:
>I didn't hear any at the sprint here.
JFDI! :)
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
On Mar 20, 2013, at 01:18 PM, Matthias Klose wrote:
>The patch in the issue now makes a distinction between EXT_SUFFIX and
>SHLIB_SUFFIX, and restores the value of SO to SHLIB_SUFFIX. Now this could
>break users of sysconfig.get_config_var('SO'), however I don't see a better
>way than to restore
On Mar 20, 2013, at 11:11 PM, Antoine Pitrou wrote:
>On Wed, 20 Mar 2013 15:05:40 -0700
>Nick Coghlan wrote:
>>
>> Yes, the status quo of Idle is not something we should allow to
>> continue indefinitely, but decisions about its future development
>> should be made by active maintainers that are
On Mar 21, 2013, at 05:25 AM, Eli Bendersky wrote:
>1. Whether IDLE should be developed separately from the core Python
>repository (while still being shipped).
>
>I really want to constructively focus on (1).
In fact, solving (1) should help move along the discussions about separating
the stdlib
On Apr 01, 2013, at 08:20 PM, Kristján Valur Jónsson wrote:
>The relative import syntax
>
> (from foo import bar) is a getattr type of lookup (i.e. import foo, then get
> attr from it).
>
>This is in contrast with absolute import
>
> import foo.bar (get the module foo.bar from sys.modules or imp
On Apr 03, 2013, at 09:17 PM, Nick Coghlan wrote:
>Perhaps we should start emitting a DeprecationWarning for int subclasses
>returned from __int__ and __index__ in 3.4?
I definitely agree with doing this for __int__(), since it's intimately tied
to int(), which is clearly a type conversion operat
On Apr 04, 2013, at 01:14 AM, Nick Coghlan wrote:
>Implementing __index__ just means "This type can be converted to a Python
>integer without losing information". Aside from that extra "without
>information loss" qualification, it's the same as __int__.
Hmm.
object.__index__(self)
Called to
On Apr 04, 2013, at 03:04 AM, Steven D'Aprano wrote:
>On 04/04/13 01:16, Barry Warsaw wrote:
>> the other built-in types-as-functions, so int() calls __int__() which must
>> return a concrete integer.
>Why must it? I think that's the claim which must be justified
On Apr 03, 2013, at 01:46 PM, Barry Warsaw wrote:
>It's a consistency-of-implementation issue. Where built-in types are
>callable, they return concrete instances of themselves. This is true for
>e.g. list, tuple, dict, bytes, str, and should also be true of int.
Well, I guess i
On Apr 06, 2013, at 05:02 PM, Benjamin Peterson wrote:
>This means we need to talk about how many more 2.7 releases there are
>going to be.
I'm all for putting stakes in the ground and clearly describing the future
life of Python 2.7, rather than the current indefinite status quo. We talked
abou
On Apr 06, 2013, at 06:54 PM, Raymond Hettinger wrote:
>At this year's Pycon keynote, I surveyed the crowd (approx 2500 people)
>and all almost everyone indicated that they had tried out Python 3.x
>and almost no one was using it in production or writing code for it.
>That indicates that Python 2.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Apr 08, 2013, at 05:08 PM, Tres Seaver wrote:
>FWIW, the effort of porting the "modern" bits of the Zope ecosystem (the
>ones I still use in Pyramid apps today, meaning the component
>architecture, the ZODB, and a few others) soaked up basically
On Apr 12, 2013, at 03:53 PM, Lele Gaifax wrote:
>Eli Bendersky writes:
>
>> These enumeration values are not equal, nor do they and hence may exist
>> in the same set, or as distinct keys in the same dictionary::
>
>I'm not a native speaker and I found the above difficult to parse: is
>there any
On Apr 12, 2013, at 09:03 AM, Michael Urman wrote:
>> You also may not duplicate values in derived enumerations::
>>
>> >>> class BadColors(Colors):
>> ... yellow = 4
>> ... chartreuse = 2 # Oops!
>> Traceback (most recent call last):
>> ...
>> ValueError: Conflicti
On Apr 12, 2013, at 09:58 AM, R. David Murray wrote:
>> The ``Enum`` class supports iteration. Iteration is defined as the
>> sorted order of the item values::
>>
>> >>> class FiveColors(Enum):
>> ... pink = 4
>> ... cyan = 5
>> ... green = 2
>> ... blue = 3
>
On Apr 12, 2013, at 10:23 AM, R. David Murray wrote:
>I think either the iteration order should be undefined (like a set
>or dict), or the comparison operations should work. I'd prefer
>the latter, because of the use case I outlined.
Order (both iteration and comparison) is officially undefined
On Apr 12, 2013, at 03:31 PM, Dirkjan Ochtman wrote:
>On Fri, Apr 12, 2013 at 2:55 PM, Eli Bendersky wrote:
>> Ordered comparisons between enumeration values are *not* supported. Enums
>> are
>> not integers (but see `IntEnum`_ below)::
>>
>> >>> Colors.red < Colors.blue
>> Traceback (mo
On Apr 12, 2013, at 11:23 AM, R. David Murray wrote:
>To take advantage of their incommensurability with other Enums. It's
>not a big deal, though; I'm more concerned that the API be internally
>consistent. I presume that one could always define an Enum subclass
>and provide comparison methods i
On Apr 12, 2013, at 11:29 AM, R. David Murray wrote:
>You get that automatically if you return NotImplemented from the
>comparison methods. I don't think you should be explicitly raising
>NotImplemented.
Oh, that's much better. Thanks, I'll update the implementation, docs, and
PEP.
-Barry
___
On Apr 12, 2013, at 11:29 AM, R. David Murray wrote:
>You get that automatically if you return NotImplemented from the
>comparison methods. I don't think you should be explicitly raising
>NotImplemented.
Oh darn, this doesn't work for Python 2.7. You don't care for PEP 435, but
flufl.enum will
On Apr 12, 2013, at 08:36 AM, Ethan Furman wrote:
>Huh??
Refresh the page :).
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/ar
On Apr 12, 2013, at 04:57 PM, Phil Elson wrote:
>1) Is there limitation that EnumValues themselves must be immutable?
I'm not sure it makes sense to have mutable EnumValues, but yes, they are
immutable in the sense that you cannot change their underlying value (well,
without hackery).
>2) I'm mo
On Apr 12, 2013, at 09:43 AM, Guido van Rossum wrote:
>I do wonder about this passage in the PEP:
>
>> Let's say you wanted to encode an enumeration value in a database. You
>> might want to get the enumeration class object from an enumeration value::
>>
>> >>> cls = Colors.red.enum
>> >>
On Apr 12, 2013, at 11:21 AM, Russell E. Owen wrote:
>I, too, would strongly prefer to see ordering within an enum. I use
>home-made enums heavily in my code and find ordering comparisons useful
>there.
This was all hashed out in gory detail on python-ideas. I feel strongly that
base EnumValue
On Apr 12, 2013, at 12:56 PM, Guido van Rossum wrote:
>Agreed. I can't easily find that in the PEP though. It doesn't mention
>__getitem__ and I can't find any examples of using [].
Indeed, this looks like an omission in the PEP. flufl.enum's usage
documentation definitely talks about this:
htt
On Apr 12, 2013, at 04:52 PM, R. David Murray wrote:
>You are right, the problem of comparison of disparate types makes ordering
>a non-starter. But by the same token that means you are going to have to
>be consistent and give up on having a sorted iteration and a stable repr:
Why do you make me
On Apr 12, 2013, at 05:17 PM, R. David Murray wrote:
>Now, you could *further* require that the type of enum values be
>sortablebut that point you really have no excuse for not allowing
>enum values to be compared :)
I'd be more willing to give up on sorting for the base enum type's iteration
On Apr 12, 2013, at 02:34 PM, Guido van Rossum wrote:
>So, pragmatically, if e and f are values of the same enum class,
>couldn't e f (where is any comparison operator) defer to
>e.value f.value ? Or is the problem with being == and e
>and f being different enum values with the same underlying
On Apr 18, 2013, at 07:34 PM, Antoine Pitrou wrote:
>Normally you should break a buildbot as a celebration :)
Or do a release and go on vacation.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-de
On Apr 13, 2013, at 08:37 AM, Tim Delaney wrote:
>Just using definition order as the stable iteration order would do the
>trick - no need for any comparisons at all. Subclasses (e.g. IntEnum) can
>then override it.
I think this isn't possible if we want to keep backward compatibility with
earlier
On Apr 13, 2013, at 11:31 AM, Serhiy Storchaka wrote:
>On 12.04.13 15:55, Eli Bendersky wrote:
>> The enumeration value names are available through the class members::
>>
>> >>> for member in Colors.__members__:
>> ... print(member)
>> red
>> green
>> blue
>
>This is u
On Apr 13, 2013, at 08:33 AM, Guido van Rossum wrote:
>(And yes, I am now +1 on documenting this mechanism.)
Here's what I've added to the flufl.enum documentation:
Customization protocol
==
You can define your own enumeration value types by using the
``__value_factory__`` p
On Apr 13, 2013, at 12:51 PM, Steven D'Aprano wrote:
>I think that's too strong a restriction. I would expect to be able to do this:
>
>class Insect(Enum):
> wsap = 1 # Oops, needed for backward compatibility, do not remove.
> wasp = 1 # Preferred. Use this in new code.
> bee = 2
>
On Apr 20, 2013, at 07:10 PM, R. David Murray wrote:
>It seems strange to limit a new Python3 feature to the Python2 feature
>set. Just saying :)
For a critical feature sure, but I don't put __repr__ or enum item iteration
order in that category. There's no need for gratuitous incompatibility
e
On Apr 21, 2013, at 03:25 PM, Nick Coghlan wrote:
>Agreed. I think the stdlib enum library should use __prepare__ and
>iterate in definition order (since 2.x compatibility isn't of any
>concern), while flufl.enum can use "sorted by name" as the iteration
>order.
>
>An "order_by_name" keyword argum
On Apr 22, 2013, at 12:06 AM, Steven D'Aprano wrote:
>On 21/04/13 15:33, Nick Coghlan wrote:
>
>> The PEP is fine, as it already allows duplicate names without encouraging
>> them:
>>
>> class Insect(Enum):
>> wasp = 1 # Preferred. Use this in new code.
>> bee = 2
>>
On Apr 22, 2013, at 09:02 AM, Nick Coghlan wrote:
>Iteration order matters a lot if you don't want people complaining about
>enums being broken:
>
> class Days(enum.Enum):
>Monday = 1
>Tuesday = 2
>Wednesday = 3
>Thursday = 4
>Friday = 5
>Saturday = 6
>Sunday = 7
Sorr
On Apr 22, 2013, at 09:31 AM, Tim Delaney wrote:
>I'm fine with iteration order being by sorted name by default, so long as
>it's easily overrideable by enum subclasses or metaclasses e.g. an IntEnum
>should probably iterate in value order.
It does. :)
>For definition order, a 3.x-only metaclass
On Apr 22, 2013, at 10:30 PM, Donald Stufft wrote:
>I may be dull, but it wasn't until I started using Python 3 that it really
>clicked in my head what encode/decode did exactly. In Python2 I just sort of
>sprinkled one or the other when there was errors until the pain stopped. I
>mostly attribute
On Apr 22, 2013, at 06:22 PM, Guido van Rossum wrote:
>> You can ask the same question about all the other codecs. (And that
>> question has indeed been asked in the past.)
>
>Except for rot13. :-)
The fact that you can do this instead *is* a bit odd. ;)
from codecs import getencoder
encoder =
On Apr 25, 2013, at 03:34 PM, Lennart Regebro wrote:
>In the case of JSON objects, they are intended for data exchange, and
>hence in the end need to be byte strings.
Except that they're not.
http://bugs.python.org/issue10976
-Barry
___
Python-Dev mai
On Apr 23, 2013, at 03:44 PM, Antoine Pitrou wrote:
>I'm having a problem with the proposed implementation. I haven't found
>any mention of it, so apologies if this has already been discussed:
>
from flufl.enum import *
class C(Enum):
>... a = 1
>... b = 2
>...
C.a.__class__
>
>>
On Apr 23, 2013, at 01:20 PM, Philip Jenvey wrote:
>Furthermore, you could define methods/fields on enum values, like Java's
>enums.
There's no reason why you couldn't do this now, even with the class
separation. I've documented the customization protocol, so just add these
methods to the class
On Apr 23, 2013, at 10:24 AM, R. David Murray wrote:
>> >>> isinstance(C.a, C)
>> False
>> >>> isinstance(C(1), C)
>> False
>>
>> It would really be better if instances were actual instances of the
>> class, IMO.
>
>The first False looks correct to me, I would not expect an enum value to be
>an i
On Apr 23, 2013, at 04:33 PM, Antoine Pitrou wrote:
>That said, I don't see why it wouldn't make sense for an enum value to be an
>instance of that class. It can be useful to write `isinstance(value,
>MyEnumClass)`. Also, any debug facility which has a preference for writing
>out class names would
On Apr 23, 2013, at 10:53 AM, R. David Murray wrote:
>Ah. I'd be looking for a bug every time I saw isinstance(value,
>myEnumClass). A better class name for values and an API for getting that
>class from the EnumClass would be nice, though. (So that you could write
>"isinstance(value, MyEnumCla
On Apr 25, 2013, at 11:42 AM, Antoine Pitrou wrote:
>The PEP should mention how to get an enum from its raw value:
>
>>>> Colors[1]
>
>
>or:
>
>>>> Colors(1)
>
No, this is a failed experiment. It's deprecated in flufl.enum and shouldn't
make it into stdlib enum. getitem syntax i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Apr 25, 2013, at 03:02 PM, Tres Seaver wrote:
>On 04/25/2013 12:39 PM, Ethan Furman wrote:
>> Animals is a class. Giving Animals a parameter (such as 1 or 'ant')
>> should return the instance that matches.
>
>Animals is *not* a class -- it just
On Apr 25, 2013, at 01:18 PM, Ethan Furman wrote:
>> Ignore the single argument call syntax for Enums please. As Eli pointed
>> out, you have getitem syntax for this and the single argument call syntax
>> is deprecated. It will be removed in a future version of flufl.enum and
>> need not appear
On Apr 25, 2013, at 02:25 PM, Eli Bendersky wrote:
>I think it's important to stress what this syntax is actually going to be
>used for. No one (I hope) is actually going to write Animals(1) or
>Animals[1]. They will write Animals.ant - this is what enums are for in the
>first place! The way I see
On Apr 25, 2013, at 02:54 PM, Guido van Rossum wrote:
>I don't know what's going on,
Mostly that this is my first opportunity to chime in on the subject.
>but it feels like we had this same discussion a week ago, and I still
>disagree. Disregarding, the C[i] notation, I feel quite strongly that
On Apr 25, 2013, at 02:30 PM, Ethan Furman wrote:
>--> class Animal(Enum):
>... ant = 1
>... bee = 2
>... fly = 3
>
>--> Animal(2) # should return Animal.bee
>
>--> Animal('ant') # should return Animal.ant
>
>It seems to me that storing the instances on the class as attributes is
>mo
On Apr 21, 2013, at 09:12 PM, R. David Murray wrote:
>Regardless of the specific values involved, it is pretty much guaranteed
>that if anything other than definition order is used we *will* get bug
>reports/enhancement requests to fix it, on a regular basis. We can choose
>to live with that, but
On Apr 22, 2013, at 10:55 AM, Tim Delaney wrote:
>Would it be worthwhile storing a sorted version of the enum keys here? Or
>do you think the current space vs speed tradeoff is better?
It's an implementation detail that doesn't bother me too much either way.
-Barry
signature.asc
Description: P
On Apr 22, 2013, at 10:42 AM, Nick Coghlan wrote:
>On Mon, Apr 22, 2013 at 10:28 AM, Barry Warsaw wrote:
>> On Apr 22, 2013, at 09:02 AM, Nick Coghlan wrote:
>>
>>>Iteration order matters a lot if you don't want people complaining about
>>>enums being
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 to make it truly the same class.
It didn't sound simple to me, but I haven't seen any actual code ye
On Apr 25, 2013, at 04:09 PM, Ethan Furman wrote:
>We just fixed NoneType() to return None instead of raising an exception.
>
>Another use-case for calling NoneType is working with ORMs:
>
>result = []
>for field in row:
> type = get_type(field) # returns int, bool, str, NoneType, ...
>
On Apr 29, 2013, at 04:16 PM, Ethan Furman wrote:
>I suppose the other option is to have `.value` be whatever was assigned (1,
>'really big country', and (8273.199, 517) ), and the fact that
>`int(Stuff.china) ` blows up and doesn't store easily in a database is the
>programmers issue...
Correct.
On Apr 29, 2013, at 03:25 PM, Eli Bendersky wrote:
>I'm -1, and this is yet another bad sign of conflating enums with classes.
>If planets want to have attributes and behaviors, let them be normal
>classes. If they want a PlanetId *enum member*, that's OK, but there's no
>need to intermix the two.
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 and the justifications in the Stack Ove
On Apr 30, 2013, at 09:19 PM, Ethan Furman wrote:
>Subclassing an implemented Enum class now raises an error (is there a better
>word than 'implemented'?)
>
>--> class MoreColor(Color):
>... cyan = 4
>... magenta = 5
>... yellow = 6
>
>Traceback (most recent call last):
> File "", li
On Apr 30, 2013, at 06:00 AM, Steven D'Aprano wrote:
>flufl.enum has been in use for Mailman for many years, and I would like to
>hear Barry's opinion on this.
I'm not sure it matters now (I'm about a billion messages behind with little
hope of catching up), but FWIW, I have use cases for extendi
On Apr 29, 2013, at 11:10 AM, Stephen J. Turnbull wrote:
>Ethan thinks that "Seasons(3)" is a typecast, not an access into a
>mapping (which would be better expressed by "Seasons[3]"). Ie, the
>inverse of "int(AUTUMN)".
>
>This is consistent with the "AUTUMN is-a Seasons" position that Ethan
>and
On Apr 28, 2013, at 07:46 PM, Ethan Furman wrote:
>and similarly, Enum behavior /should be/ (in my opinion ;)
>
>Season.AUTUMN is Season('AUTUMN') is Season(3)
I think you'll have a problem with this. flufl.enum did this, but it has an
inherent conflict, which is why we removed the getattr-like
On Apr 29, 2013, at 03:36 PM, Steven D'Aprano wrote:
>That's not how I understand it. I expected that the correct way to use
>enums is with identity checks:
>
>if arg is Season.SUMMER:
> handle_summer()
It's certainly the way I've recommended to use them. I think `is` reads
better in conte
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 be True, I'd love it if someone show
On Apr 30, 2013, at 10:50 PM, Ethan Furman wrote:
>The way I had subclassing working originally was for the subclass to create
>it's own versions of the superclass' enum items -- they weren't the same
>object, but they were equal:
>
>--> class Color(Enum):
>... red = 1
>... green = 2
>...
On May 01, 2013, at 12:19 AM, Glenn Linderman wrote:
>Can Things('foo') lookup by name and Things['foo'] lookup by value? Or does
>that confuse things too?
I think it confuses things too much. Why isn't getattr() for lookup by name
good enough? It is for regular classes.
-Barry
___
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:
>>>>
>>&g
On May 02, 2013, at 11:44 AM, Greg Ewing wrote:
>Barry Warsaw wrote:
>> Why isn't getattr() for lookup by name
>> good enough?
>
>Because it will find things that are not enum items,
>e.g. '__str__'.
Why does that matter?
-Barry
___
On May 01, 2013, at 11:04 AM, Eli Bendersky wrote:
>Actually, in flufl.enum, IntEnum had to define a magic __value_factory__
>attribute, but in the current ref435 implementation this isn't needed, so
>IntEnum is just:
>
>class IntEnum(int, Enum):
>'''
>Class where every instance is a subcl
On May 01, 2013, at 08:47 PM, Georg Brandl wrote:
>Wait a moment... it might not be immediately useful for IntEnums (however,
>that's because base Enum currently defines __int__ which I find questionable),
And broken. And unnecessary. :)
>>> class Foo(Enum):
... a = 'a'
... b = 'b'
...
>>>
On May 01, 2013, at 03:11 PM, Ethan Furman wrote:
>The reason __int__ is there is because pure Enums should be using plain ints
>as their value 95% or more of the time, and being able to easily convert to a
>real int for either database storage, wire transmission, or C functions is a
>Good Thing.
On May 02, 2013, at 08:42 AM, Larry Hastings wrote:
>So, for the second time: How can Color.red and MoreColor.red be the same
>object when they are of different types?
It's a moot point now given Guido's pronouncement.
-Barry
___
Python-Dev mailing lis
On May 02, 2013, at 10:18 PM, Georg Brandl wrote:
>5) accept that convenience-created enums have restrictions such as no
>picklability and point them out in the docs?
That would work fine for me, but ultimately I'm with Guido. I just don't want
to have to pass the module name in.
-Barry
___
501 - 600 of 2704 matches
Mail list logo
