On 05/12/2013 08:15 PM, Stephen J. Turnbull wrote:
Ethan Furman writes:
> I will certainly ask for advice on which modules to spend my time
> on. I know enums are not a cure-all, but they are great for
> debugging and interactive work.
Especially in new code where they are used throughout. Not so in the
existing stdlib, I expect.
Perhaps not to somebody who is already well versed in it. It would be very
helpful to me. ;)
The concrete limitation on that theory that I envision with
retrofitting the stdlib is that cooperative modules (those that call
into and are called from the module being converted to use enums) are
going to be expecting values, not enums. So you need to convert
return values and arguments, and not only do you *not* get the benefit
of enum reprs in the cooperating modules, but you introduce additional
complexity in the converted module. Nor can you say "OK, it's more
than I expected but I'll do the whole stdlib," because you don't know
who is calling into or supplying callbacks to the stdlib modules.
Well, somebody else might, but I know how much (little?) time I have. It'll be great to have new modules use Enums;
retrofitted modules should use Psuedonums (okay, I made that word up -- it's supposed to be an Enum but with some other
type mixed in so it's no longer a pure Enum, more like a psuedo enum). As I was saying, if tkinter was up for
conversion it would just be to StrEnum, and that would mostly consist of adding the enumeration at the top, exporting it
to global, then browsing for locations where the string value was used and removing the quotes. Of course, having said
that I'm sure somebody will chime in with "yes, but..."
In many cases you could convert code to use IntEnum instead of Enum,
preserving the old semantics, and probably not needing to convert
return values, but again I expect the benefits of Enum-ness would
attenuate quickly as cooperating code converts them to int internally.
Hmmm... yeah, that would suck.
Well, I'm sure I can help in others ways if this doesn't pan out. Maybe some
other new module that Raymond objects to. ;)
--
~Ethan~
_______________________________________________
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
