[Python-Dev] PEP 435 - ref impl disc 2 (original) (raw)

Glenn Linderman v+python at g.nevcal.com
Sun May 12 04:56:54 CEST 2013

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>

More information about the Python-Dev mailing list