On Thu, 2 May 2013 13:15:00 -0700 Eli Bendersky <eliben at gmail.com> wrote: > > Two things that were suggested in private: > > > > 1) ask users to pass the module name to the convenience function > > explicitly (i.e. pass "seasonmodule.Season" instead of "Season" as the > > class "name"). Guido doesn't like it :-) > > > > 2) dicth the "convenience function" and replace it with a regular > > class-based syntax. Ethan doesn't like it :-) > > > > Re (2), we already have the hack in stdlib in namedtuple, so not allowing > it for an enum is a step backwards. That's a fallacy. There is no step backwards if you adopt a class-based syntax, which is just as convenient as the proposed "convenience function". I have a hard time understanding that calling a function to declare a class is suddenly considered "convenient". > If > sys._getframe(1).f_globals['__name__'] feels hackish, maybe it can be > shortened to a convenience function the stdlib provides? It's not the notation which is hackish, it's the fact that you are inspecting the frame stack in the hope of getting the right information. What if someone wants to write another convenience function that wraps your convenience function? What if your code is executing from some kind of step-by-step debugger which inserts an additional frame in the call stack? What if someone wants the enum to be nested inside another class (rather than reside at the module top-level)? Regards Antoine.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4