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

[Guido van Rossum]

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

I guess there could be a C-level equivalent way of getting the same
attributes set, so that introspecting tools might be able to
understand those, too.  The aguments would probably not be machine
interpretable, so considerably liberty should be allowed as long as
some conventions are established.  I'm not sufficiently interested in
pursueing this to see it through as a spec though.

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

If you or someone else is interested in doing this, please consider
writing a separate PEP.

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

Of course.

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