[docs] Code, test, and doc review for PEP-0435 Enum (issue 17947)

ethan at stoneleaf.us ethan at stoneleaf.us
Tue May 14 20:18:48 CEST 2013


http://bugs.python.org/review/17947/diff/8131/Lib/enum.py
File Lib/enum.py (right):

http://bugs.python.org/review/17947/diff/8131/Lib/enum.py#newcode103
Lib/enum.py:103: enum_class = type.__new__(metacls, cls, bases,
classdict)
On 2013/05/14 20:12:43, isoschiz wrote:
> 
> Sorry - I did typo: I meant MyEnumMeta, as you indicated.
> 
> The Decimal implementation may indeed exhibit the problem. However, I
think it
> can easily be solved by just replacing type with super() in that line.
It will
> work identically in all of the simple cases, but should also work
should anyone
> want to do anything "weird".
> 
> Also note that this can also apply if the __new__ methods are doing
some extra
> work (either before or after the actual allocation), exactly like this
function.
> So even if ext.Parent wasn't an extension class, it might want it's
__new__
> called so it could, say, add a new property into the classdict or
similar.

One of us is confused -- and I don't know which of us it is! ;)

I'll try it both ways with cDecimal as soon as I get a chance, but as
far as cooperitive _new__'s how would that work?  If A calls B's
__new__, which creates an object, and B calls C's __new__ which creates
an object, which one am I getting back? If we reverse that, and B and C
call the next __new__ before creating an object, won't we eventually hit
type, and definitely not have the correct object?

http://bugs.python.org/review/17947/


More information about the docs mailing list