[issue26988] Add AutoNumberedEnum to stdlib

Roundup Robot added the comment: New changeset 2e243f78720e by Ethan Furman in branch 'default': Issue26988: remove AutoEnum https://hg.python.org/cpython/rev/2e243f78720e -- ___ Python tracker

[issue26988] Add AutoNumberedEnum to stdlib

Changes by Ethan Furman : -- stage: -> resolved status: open -> closed ___ Python tracker ___

[issue26988] Add AutoNumberedEnum to stdlib

Vedran Čačić added the comment: # Just wait until I put the keys to the time machine in their usual place... :-) Ok, while we're talking about whether declarative style is a good idea, Python has already got the initial seed of that style. With Guido's blessing! PEP 526 enables us to mix

[issue26988] Add AutoNumberedEnum to stdlib

David Hagen added the comment: One solution similar to one proposed by Vedran works with the current Enum: class Color(Enum): red = object() green = object() blue= object() I tested this in PyCharm and it is perfectly happy with the autocomplete and everything. The

[issue26988] Add AutoNumberedEnum to stdlib

Kenneth Reitz added the comment: There's a difference between boiler-plate and "code". > On Aug 19, 2016, at 10:53 AM, Ethan Furman wrote: > > > Ethan Furman added the comment: > > No magic, but a whole heap of extra boiler-plate. :( > > -- > >

[issue26988] Add AutoNumberedEnum to stdlib

Ethan Furman added the comment: No magic, but a whole heap of extra boiler-plate. :( -- ___ Python tracker ___

[issue26988] Add AutoNumberedEnum to stdlib

Barry A. Warsaw added the comment: Hey, I just realized that you can get pretty darn close with just a little bit of extra typing, and existing stdlib: from enum import Enum from itertools import count auto = count() class Color(Enum): red = next(auto) green =

[issue26988] Add AutoNumberedEnum to stdlib

Ethan Furman added the comment: Vedran, you have some very interesting points. However, if you really want to champion this you'll need to take it to Python Ideas. -- ___ Python tracker

[issue26988] Add AutoNumberedEnum to stdlib

Vedran Čačić added the comment: > For me, it's legit to use a singleton in an enum. But you cannot explain _why_, right? Like Raymond says, it's not working like anything else in Python works. To me, this looks almost the same as the gripes of those lazy people who want "myfile.close"

[issue26988] Add AutoNumberedEnum to stdlib

STINNER Victor added the comment: 2016-08-19 14:19 GMT+02:00 Vedran Čačić : > In fact, what _is_ explicit, is this: > > class Color(metaclass=Enum): > green = object() > yellow = object() > > I could live with it. :-) For me, it's legit to use a

[issue26988] Add AutoNumberedEnum to stdlib

Vedran Čačić added the comment: Absolutely. How the hell is `green = None` explicit?! On the other hand, `class Color(Enum, style='declarative'):` is explicit. People must learn something. Why then don't they learn the right thing instead of "hey, assigning None inside enums magically does

[issue26988] Add AutoNumberedEnum to stdlib

Kenneth Reitz added the comment: Explicit is better than implicit :) -- ___ Python tracker ___ ___

[issue26988] Add AutoNumberedEnum to stdlib

Vedran Čačić added the comment: I must say I never understood how exactly is assigning a constant better in this regard. To me, after a = SOMETHING b = SOMETHING a and b should be the same, right? _Especially_ when SOMETHING is None or (), but also when it's some bare identifier like

[issue26988] Add AutoNumberedEnum to stdlib

STINNER Victor added the comment: Would it be possible to use a auto or AUTO_ENUM constant from the enum in the Enum class? (And drop AutoEnum class.) -- ___ Python tracker

[issue26988] Add AutoNumberedEnum to stdlib

Kenneth Reitz added the comment: This addition to Python, specifically the bare assignment-free `red` syntax would be a huge mistake for the language. It looks like a syntax error to me, and completely destroys my mental model for how Python code either does work or should work. A simple

[issue26988] Add AutoNumberedEnum to stdlib

Vedran Čačić added the comment: I don't think the problem is with (Auto)Enum at all. Problem is in a different place, and this is just a symptom. Problem is that people make too many assumptions about `class` suite. Yes, type is default metaclass. But not every class should be constructed by

[issue26988] Add AutoNumberedEnum to stdlib

John Hagen added the comment: Ethan, thank you so much for all of your work. Looking forward to any future collaboration. -- ___ Python tracker ___

[issue26988] Add AutoNumberedEnum to stdlib

Ethan Furman added the comment: Thank you, Raymond, David, Barry, John, etc. for your feedback. While I really like AutoEnum I can see that that much magic doesn't need to exist in the stdlib. Unfortunately, the alternatives aren't very pretty, so I'll leave the AutoNumberEnum as a recipe in

[issue26988] Add AutoNumberedEnum to stdlib

Barry A. Warsaw added the comment: Ethan, the suggestion has come up several times about using a dummy value such as the empty tuple to do autonumbering, thus looking more Pythonic. I'm not a huge fan of the empty tuple, and I'm still not sure whether we need this, but I wonder if it would

[issue26988] Add AutoNumberedEnum to stdlib

Raymond Hettinger added the comment: Temporarily, marking this as open so that more people can see the new comments. For John, I'm not sure what I can say that will help you. The goal of the standard libraries modules is to provide tools the use language we have, not to invent a new language

[issue26988] Add AutoNumberedEnum to stdlib

David Hagen added the comment: > Secondarily, the doesn't seem to be any use case that can't be readily > covered by the existing classes. The use case that doesn't have a clean interface in 3.5 at the moment is the most common use case of enums: just a collection of named objects of given

[issue26988] Add AutoNumberedEnum to stdlib

Raymond Hettinger added the comment: > you ran your test script with the -m "run module as script" flag Right, that was a mistest, so it looks like triple quotes do work. I did notice that there's also an issue if one line reads, "red='hello'". But really, the big issue is using a

[issue26988] Add AutoNumberedEnum to stdlib

Ethan Furman added the comment: Raymond, I appreciate your review and your poll. I am open to removing AutoEnum, but would like to give it a couple more weeks of review. (I'll post on py-dev.) The only point you made that I will firmly refute is the "unexpected breakage": you ran your test

[issue26988] Add AutoNumberedEnum to stdlib

STINNER Victor added the comment: > Raymond, what are your thoughts about the version of AutoEnum that requires > that a bare tuple be used as the value. It has been in the Python docs since > 3.4 and was actually the original request of this issue: >

[issue26988] Add AutoNumberedEnum to stdlib

STINNER Victor added the comment: > It's not just C that has enums where you can define a unique group of names > and omit the values ... Yes, Python 3.4 too: Animal = Enum('Animal', 'ant bee cat dog') https://docs.python.org/dev/library/enum.html#functional-api --

[issue26988] Add AutoNumberedEnum to stdlib

Emanuel Barry added the comment: I tend to like all things magic, but the more I think about it, and the less I like it being a part of the standard library. I've had a use for this feature before, and when I did, I cooked my own 12-lines subclass of EnumMeta and _EnumDict. Raymond's points

[issue26988] Add AutoNumberedEnum to stdlib

John Hagen added the comment: @Raymond, you raise valid concerns to be sure. Hoping we can work something out. @Ethan, what are your thoughts? It's not just C that has enums where you can define a unique group of names and omit the values for clarity when they are not significant: C++:

[issue26988] Add AutoNumberedEnum to stdlib

Raymond Hettinger added the comment: The use of a bare identifier as a self-assigning statement is unprecedented in the world of Python. PyFlakes flags it as an error (because prior to now, a bare identifier in a class statement was almost always an error). I suspect this will cause issues

[issue26988] Add AutoNumberedEnum to stdlib

STINNER Victor added the comment: FYI Raymond Hettinger started a discussion on Twitter about this feature, and the feedback may not be as good as you expected: https://twitter.com/raymondh/status/765652816849285120 (I dislike this new magic thing, but I also never used the enum module, so I'm

[issue26988] Add AutoNumberedEnum to stdlib

Ethan Furman added the comment: added missing '#' -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue26988] Add AutoNumberedEnum to stdlib

John Hagen added the comment: I think there is a small typo in the Changelog / What's New. The Issue isn't hyper-linked: https://docs.python.org/3.6/whatsnew/changelog.html#id2 -- ___ Python tracker

[issue26988] Add AutoNumberedEnum to stdlib

Changes by Ethan Furman : -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker ___

[issue26988] Add AutoNumberedEnum to stdlib

Roundup Robot added the comment: New changeset 7ed7d7f58fcd by Ethan Furman in branch 'default': Add AutoEnum: automatically provides next value if missing. Issue 26988. https://hg.python.org/cpython/rev/7ed7d7f58fcd -- nosy: +python-dev ___ Python

[issue26988] Add AutoNumberedEnum to stdlib

Ethan Furman added the comment: Okay, I think I'm done making changes unless any more mistakes are found. Thanks everyone for the pushing, prodding, and feedback! -- Added file: http://bugs.python.org/file43986/issue26988.stoneleaf.05.patch ___

[issue26988] Add AutoNumberedEnum to stdlib

John Hagen added the comment: @Ethan I reviewed your latest patch. I think it's a good step forward in terms of simplicity. Most of my comments were not major. Even before this patch, I was mulling around how enum.Unique, enum.UniqueEnum, and enum.unique seemed to violate the "There should

[issue26988] Add AutoNumberedEnum to stdlib

Ethan Furman added the comment: The 80-column thing isn't fixed yet, but I redid the patch: - removed AutoNameEnum since there was some question of casing, etc - redid the methodology of auto-generating values: instead of adding it all to the prepared namespace or the metaclass, I now

[issue26988] Add AutoNumberedEnum to stdlib

Ethan Furman added the comment: Oh, and yes, I'll fix the whole 80-column thing. ;) -- ___ Python tracker ___

[issue26988] Add AutoNumberedEnum to stdlib

Ethan Furman added the comment: Okay, here's an updated patch with the doc changes. Once the main patch is committed I'm going to reorganize the docs a bit, but that's later. -- assignee: -> ethan.furman Added file: http://bugs.python.org/file43743/issue26988.stoneleaf.02.patch

[issue26988] Add AutoNumberedEnum to stdlib

John Hagen added the comment: I like the addition of UniqueEnum. It's the default use case often. -- ___ Python tracker ___

[issue26988] Add AutoNumberedEnum to stdlib

Ethan Furman added the comment: Here's the code. I'll do the doc changes next. -- keywords: +patch Added file: http://bugs.python.org/file43694/issue26988.stoneleaf.01.patch ___ Python tracker

[issue26988] Add AutoNumberedEnum to stdlib

John Hagen added the comment: >class BaseZeroEnum(Enum, start=0): > "initial integer is 0" > ... I also think this looks better. -- ___ Python tracker

[issue26988] Add AutoNumberedEnum to stdlib

Barry A. Warsaw added the comment: On Jul 11, 2016, at 07:05 PM, Ethan Furman wrote: >class BaseZeroEnum(Enum, start=0): > "initial integer is 0" > ... > >? Oh, and yes if you specify a starting number you also activate the >AutoNumber feature. I like the way this one looks. --

[issue26988] Add AutoNumberedEnum to stdlib

Ethan Furman added the comment: If you are constructing your own base Enum type, which would you rather do? class BaseZeroEnum(Enum): "initial integer is 0" _start_ = 0 ... or class BaseZeroEnum(Enum, start=0): "initial integer is 0" ... ? Oh, and yes if you specify a

[issue26988] Add AutoNumberedEnum to stdlib

Ethan Furman added the comment: That brings up a really good point -- this feature requires the __prepare__ method of the metaclass, so it won't work in Python 2 any way. So, yeah, bug-fix-mostly mode for enum34. :) -- ___ Python tracker

[issue26988] Add AutoNumberedEnum to stdlib

Barry A. Warsaw added the comment: On Jul 11, 2016, at 12:27 AM, Ethan Furman wrote: >Not sure. At this point I have the stdlib enum, enum34 enum, and aenum enum. > >In terms of capability, aenum is the most advanced, followed by the stdlib >enum, and finally enum34 (really the only difference

[issue26988] Add AutoNumberedEnum to stdlib

Ethan Furman added the comment: Yeah, I think the public interface will just be the AutoEnum and AutoNameEnum style. --- > Will these features go into enum34? Not sure. At this point I have the stdlib enum, enum34 enum, and aenum enum. In terms of capability, aenum is the most advanced,

[issue26988] Add AutoNumberedEnum to stdlib

John Hagen added the comment: To me, class Color(AutoEnum) and class Color(AutoEnum, IntEnum) is a little more straightforward. It makes usage of AutoEnum similar to IntEnum, and I would expect it to be at least as popular as it. A enum-related side question, since the plan is for this to go

[issue26988] Add AutoNumberedEnum to stdlib

Barry A. Warsaw added the comment: On Jul 10, 2016, at 05:42 PM, Ethan Furman wrote: >class Color(Enum, settings=AutoNumber): [...] >class Color(Enum, settings=AutoName): I guess `settings` would take an AutoType enum. But that can't also be autonumbered or it would be autos all the way down.

[issue26988] Add AutoNumberedEnum to stdlib

Ethan Furman added the comment: I like AutoEnum. Another auto-related thought: one of the more common Enum questions on StackOverflow is how to automatically have the value be the stringified version of the name: class Huh(Enum): this that those Huh.this.name == Huh.this.value # True

[issue26988] Add AutoNumberedEnum to stdlib

John Hagen added the comment: Some ideas for the new stdlib class: BasicEnum - This helps emphasize that it is a simpler version of Enum that doesn't support all of the Enum features (like assigning values). It also helps communicate that if you don't need values this is a better fit.

[issue26988] Add AutoNumberedEnum to stdlib

Ethan Furman added the comment: I need names. `aenum` already has an `AutoNumberEnum` (the one from the docs, no magic) so I hate to use the same name for the stdlib version with different behavior. So I either need a different name for the stdlib version, or a different name for the aenum

[issue26988] Add AutoNumberedEnum to stdlib

Ethan Furman added the comment: The problem with testing the type of object a name refers to outside the class is it then becomes more difficult to make that an Enum member: class AddressType(Enum): pobox mailbox # third-party po box property Having to assign a value to

[issue26988] Add AutoNumberedEnum to stdlib

John Hagen added the comment: > What happens with `property`? > > - `property` is looked up in the class namespace Perhaps you've already considered this, I'm not intimately familiar with how classes are parsed and constructed but is it possible to determine if the object is a decorator? It

[issue26988] Add AutoNumberedEnum to stdlib

Ethan Furman added the comment: A standard feature of Enum is that either space separated strings or a list of strings is accepted any where either is. _sunder_ names are the ones reserved for Enum use (such as _value_, _name_, and soon _order_ (for py2/py3 compatible code). --

[issue26988] Add AutoNumberedEnum to stdlib

Barry A. Warsaw added the comment: On Jul 09, 2016, at 03:20 PM, Ethan Furman wrote: >As far as I can tell there is only one "good" way around this: > >- store any names you don't want auto-numbered into an `_ignore_` > attribute (this only needs to be global and built-in names that > are

[issue26988] Add AutoNumberedEnum to stdlib

Ethan Furman added the comment: There is one wrinkle with auto-numbering. Consider the following code: class Color(AutoNumberEnum): red green blue @property def cap_name(self): return self.name.upper() What happens with `property`? - `property` is looked up in the class

[issue26988] Add AutoNumberedEnum to stdlib

John Hagen added the comment: Is this something we want to get in before the next alpha in two days? Just wanted to bring up the deadline since this may be a feature people want to play around with during the alpha phase. Ethan, I'm happy to help with documentation or anything else.

[issue26988] Add AutoNumberedEnum to stdlib

John Hagen added the comment: @Ethan/Barry what needs to be done now to accept or reject this for Python 3.6? Should I propose it onto python-dev? If accepted, would be nice to get it in before alpha 3 (~2 weeks). What's nice about this proposal is Ethan has already written the code, so

[issue26988] Add AutoNumberedEnum to stdlib

John Hagen added the comment: @Ethan, I hadn't tried to use the aenum AutoNumberEnum that way, but I agree with Barry that I like it. To me that is the ideal case we should shoot for as I think it's the best* long term and deviate only if practical concerns prevent it. So I am +1 for empty

[issue26988] Add AutoNumberedEnum to stdlib

Ethan Furman added the comment: It's in _EnumDict.__getitem__; there's some duplication in __setitem__ for supporting Python 2 (although with 2 you have to use either the empty tuple, or some other handy thing that may go in the __doc__ attribute, for example). --

[issue26988] Add AutoNumberedEnum to stdlib

Barry A. Warsaw added the comment: Wow Ethan, that's quite interesting. I'm not sure if I like it or not. :) It's better than having to assign a dummy value to the enum items, and if we did require that, I'd suggest just throwing away the values for autonumbering. But not having to specify

[issue26988] Add AutoNumberedEnum to stdlib

Ethan Furman added the comment: On the other hand, if you use aenum you can do: class Color(AutoNumber): red green blue And isn't that better*? ;) * For those in danger of swallowing their tongue over the magic involved: The magic is turned off as soon as any descriptor is

[issue26988] Add AutoNumberedEnum to stdlib

Changes by Ethan Furman : -- nosy: +barry, eli.bendersky ___ Python tracker ___ ___

[issue26988] Add AutoNumberedEnum to stdlib

New submission from John Hagen: I suggest that the AutoNumberedEnum be added to the standard library for the following reasons: 1) Provides a fundamental tool for defining a unique, abstract set of coupled members 2) Avoids boilerplate @enum.unique for a very common use case of enumerations