[Python-Dev] Fwd: defaultproperty

Nick Coghlan ncoghlan at gmail.com
Tue Oct 11 11:05:36 CEST 2005

Brett Cannon wrote:
> On 10/10/05, Barry Warsaw <barry at python.org> 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:

   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 

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


Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-Dev mailing list