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

Edward Loper edloper at gradient.cis.upenn.edu
Fri Apr 2 21:19:17 EST 2004


> deprecated(comment_string) -- mostly for documentation, but would set
> the deprecated attribute.  The comment_string argument is a string
> explaining why it is deprecated.  Maybe this should also have
> arguments specifying the first Python release in which it was
> considered deprecated and the last Python release (if known) where it
> will be available.

Should this be a python-specific decorator?  Or should it also be used 
to mark deprecated objects in external libraries?  (The answer will 
affect the arguments specifing when it became depreciated and when it 
will go  away.)

If we add this, we might want to also define a standard way of marking 
classes and modules as depreciated.  (Perhaps by setting the 
__deprecated__ variable/property in all 3 cases.)

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

Alternatively, it could be checked by an external inspection tool like 
pychecker.  (Since metaclasses are so difficult to mix, it's probably 
better not to use them when we don't need to.)

-Edward




More information about the Python-Dev mailing list