(original) (raw)

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 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.