> >> It was mentioned in the other threads, but the requirement is either: > >> > >> 1. That the dictionary returned from <enum metaclass>.__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
