[Python-Dev] decorator module patch
ianb at colorstudy.com
Sun Mar 12 20:16:04 CET 2006
Georg Brandl wrote:
>> Also, I thought we were trying to move away from modules that shared a name
>> with one of their public functions or classes. As it is, I'm not even sure
>> that a name like "decorator" gives the right emphasis.
> I thought about "decorators" too, that would make "decorators.decorator". Hm.
I personally like pluralized modules for exactly the reason that they
don't clash as much with members or likely local variables.
datetime.datetime frequently leads me to make mistakes.
>> In general, decorators belong in the appropriate domain-specific module
>> (similar to context managers). In this case, though, the domain is the
>> manipulation of Python functions - maybe the module should be called
>> "metafunctions" or "functools" to reflect its application domain, rather than
>> the coincidental fact that its first member happens to be a decorator.
> Depends on what else will end up there. If it's "memoize" or "deprecated" then
> the name "functools" doesn't sound too good either.
memoize seems to fit into functools fairly well, though deprecated not
so much. functools is similarly named to itertools, another module that
is kind of vague in scope (though functools is much more vague).
partial would make just as much sense in functools as in functional.
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org
More information about the Python-Dev