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 | [EMAIL PROTECTED] | http://blog.ianbicking.org _______________________________________________ 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
