Brett Cannon wrote:
> On 10/10/05, Barry Warsaw <[EMAIL PROTECTED]> wrote:
>
>>On Mon, 2005-10-10 at 01:47, Calvin Spealman wrote:
>>
>>
>>>Never created for a reason? lumping things together for having the
>>>similar usage semantics, but unrelated purposes, might be something to
>>>avoid and maybe that's why it hasn't happened yet for decorators. If
>>>ever there was a makethreadsafe decorator, it should go in the thread
>>>module, etc. I mean, come on, its like making a module just to store a
>>>bunch of unrelated types just to lump them together because they're
>>>types. Who wants that?
>>
>>Like itertools?
>>
>>+1 for a decorators module.
>
>
> +1 from me as well. And placing defaultproperty in there makes sense
> if it is meant to be used as a decorator and not viewed as some spiffy
> descriptor.
>
> Should probably work in Michael's update_meta() function as well
> (albeit maybe with a different name since I think I remember Guido
> saying he didn't like the name).
I thought mimic was a nice name:
@mimic(func)
def wrapper(*args, **kwds):
return func(*args, **kwds)
As a location for this, I would actually suggest a module called something
like "metatools", rather than "decorators". The things these have in common is
that they're about manipulating the way functions and the like interact with
the Python language infrastructure - they're tools to make metaprogramming a
bit easier.
If "contextmanager" isn't made a builtin, this module would also be the place
for it.
Ditto for any standard context managers (such as closing()) which aren't made
builtins.
At the moment, the only location for such things is the builtin namespace
(e.g. classmethod, staticmethod).
Regardless, a short PEP is needed to:
a. pick a name for the module
b. decide precisely what will be in it for Python 2.5
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.blogspot.com
_______________________________________________
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
