[Python-Dev] PEP 435 - ref impl disc 2

[Glenn Linderman]

On 5/11/2013 12:11 AM, Glenn Linderman wrote:
> * I'm playing with adding another keyword parameter to Enum, but it is 
> presently giving me an error about unknown keyword parameter passed to 
> __prepare__ even though I added **kwds to the list of its parameters. 
> I'll learn something by doing this.

OK, I figured out the error was because __prepare__ didn't have a **kwds 
parameters, but then got a similar one regarding __init__ — but EnumMeta 
doesn't even have an __init__ so I guess it was using type.__init__, but 
then I wondered if type.__init__ even does anything, because when I 
added __init__ to (my modified ref435a) EnumMeta, it didn't seem to 
matter if my __init__ did nothing, called super().__init__, or called 
type.__init__.  Anyway, defining one seems to get past the errors, and 
then the keyword can work.

So compare your ref435.py and my ref435a.py at 
<https://bitbucket.org/v_python/ref435a/src> to see the code required to 
support a keyword parameter that would expect a base type containing a 
name parameter to its __new__ and __init__, by providing the 
module-qualified name as that parameter.

Would this be a controversial enhancement to EnumMeta?  Together with my 
flags.py at the same link, it would enable definitions of enumeration 
values which have names, and which names could be reported in 
exceptions.... see demo3.py at the same link.

I suppose it might also be good to validate that no unexpected keyword 
parameters are passed in, rather than just ignoring them, as my code 
presently does? Not sure what the general thinking is regarding such 
parameters in such usages; it could be that some mixin class might want 
to define some keyword parameters too, so ignoring them seems a more 
flexible option.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20130511/d353c65b/attachment.html>