[Python-Dev] PEP 318: Let's propose some useful built-in decorators

Guido van Rossum guido at python.org
Sat Apr 3 12:07:14 EST 2004


> > 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...

Hence my parenthetical remark.

But given that it is quite simple to do using decorators, surely
*someone* will implement it.  How useful it will be remains to be
seen.  Maybe someone should take this idea, run with it, and report
how it enhanced their project?

> > 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.

First, it's sometimes useful to know when subclassing which methods
you are overriding and which you are adding -- this may help the
reader understanding what's going on.  And then of course it would be
useful to have automatic verification of this information so that the
reader can actually believe it.

> - "a bit"
> 
> I'm not sure I like the idea of promoting something that uses
> sys._getframe.

Me neither.

> > 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.

It would be simple enough in C.

--Guido van Rossum (home page: http://www.python.org/~guido/)



More information about the Python-Dev mailing list