[Python-Dev] PEP 318: Let's propose some useful built-in
mwh at python.net
Sat Apr 3 05:58:57 EST 2004
Guido van Rossum <guido at python.org> writes:
> While I ponder the decorator syntax, let's propose some built-in
> We could also add a standard implementation of synchronized. Or
> perhaps that should be imported from threading. (But is that really
> a good thing to copy from Java?)
I don't want to sound FUDdy, but I was under the impression that
people didn't think this is something we actually want...
> Other possibilities (all these are pretty much thinking aloud and very
> much up for votes; and not original, I've seen these proposed
> overrides -- indicates that this overrides a base class method. Maybe
> the default metaclass could check that if this is used there actually
> is a corresponding base class method, and we might have a "strict"
> metaclass that checks this is set for all overriding methods.
I don't get the point of this.
> I'm still torn whether to promote defining properties this way:
> def x(self):
> "Doc string for x"
> return self.__x
> def x(self, newx):
> self.__x = newx
> def x(self):
> del self.__x
> but if people like this (whatever the decorator syntax :) we might as
> well make this the recommended way to define properties.
- "a bit"
I'm not sure I like the idea of promoting something that uses
> Should there be a a separate module from which all those decorators
> are imported, or should we make them built-ins, following the trend
> set by classmethod etc.?
I'm not sure any of the above are important enough to be builtins.
funcattrs, maybe, but there's sod all reason to implement that in C,
and getting Python implementations into the builtins seems likely to
be pain. Could do it in site.py, I guess.
Also, remember to put the galaxy back when you've finished, or an
angry mob of astronomers will come round and kneecap you with a
small telescope for littering.
-- Simon Tatham, ucam.chat, from Owen Dunn's review of the year
More information about the Python-Dev