Fwd: defaultproperty
Sorry, Nick. GMail, for some reason, doesn't follow the reply-to properly for python-dev. Forwarding to list now... On 10/9/05, Nick Coghlan <ncoghlan@gmail.com> wrote:
Jim Fulton wrote:
Based on the discussion, I think I'd go with defaultproperty.
Questions:
- Should this be in builtins, alongside property, or in a library module? (Oleg suggested propertytools.)
- Do we need a short PEP?
The much-discussed never-created decorators module, perhaps?
Cheers, Nick.
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?
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. -Barry
On 10/10/05, Barry Warsaw <barry@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). -Brett
Brett Cannon wrote:
On 10/10/05, Barry Warsaw <barry@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: @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 | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://boredomandlaziness.blogspot.com
Nick Coghlan wrote:
As a location for this, I would actually suggest a module called something like "metatools",
-1, too vague and meaningless a name. If "decorator" is the official term for this kind of function, then calling the module "decorators" is precise and helpful. Other kinds of meta-level tools should go in their own suitably-named modules. -- Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg.ewing@canterbury.ac.nz +--------------------------------------+
participants (6)
-
Barry Warsaw -
Brett Cannon -
Calvin Spealman -
Fredrik Lundh -
Greg Ewing -
Nick Coghlan