[Python-Dev] PEP 8 updates/clarifications

[Nick Coghlan]

Guido van Rossum wrote:
> On 12/11/05, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> Josiah Carlson wrote:
>>> skip at pobox.com wrote:
>>>>     Ian> Do not use accessor methods, like ``obj.getFoo()`` and
>>>>     Ian> ``obj.setFoo(v)``, instead just expose a public attribute
>>>>     Ian> (``obj.foo``).  If necessary you can use ``property`` to implement
>>>>     Ian> the same functionality that accessor methods would give you.
>>>>
>>>> Don't properties only work with new-style clsses?  If so, this should
>>>> probably be noted.
>>> In the future, aren't all classes going to become new-style?  Was it
>>> going to wait until Py3k, or sometime sooner?
>> Going the Java route (no implicit base class) would be an interim step along
>> that road (i.e., a release or two where there is no default __metaclass__
>> fallback).
>>
>> Any old code could be fixed by putting "from types import ClassType as
>> __metaclass__" at the top of the affected modules.
> 
> I'm not sure what you are proposing and I'm not sure what problem you
> are trying to solve.

I'm accustomed to handling major semantic changes in an API by deprecating the 
API first, then later bringing it back with the new semantics. A sharp cutover 
to new semantics (even in a version advertised as backwards incompatible) 
makes me nervous :)

> The plan for new-style vs. classic classes is simple and doesn't need
> to change (IMO): until Py3k, the status quo will remain; in Py3k,
> there is only new-style (except if you use a custom metaclass).

The problem I have with the currently planned sharp cutover is that the errors 
caused by the change are not necessarily easy to predict, causing difficulties 
with managing that transition. Tracking down whether or not the change to 
new-style classes is the cause of a given Py3k migration problem could be 
difficult.

Code can be future-proofed by instituting one of three rules:
   1. Always inherit from something (enforcable via "__metaclass__ = None")
   2. Always use new-style classes by default (via "__metaclass__ = type")
   3. Always use old-style classes by default
       (via "from types import ClassType as __metaclass__")

One way to make this migration easier to manage would be to have the class 
creation code check __builtins__ for a definition of __metaclass__. This would 
make it possible for application developers to determine whether or not their 
application or any of its support libraries are dependent on certain classes 
being old-style (by running the program and changing the default metaclass via 
"__builtins__.__metaclass_ = None" or "__builtins__.__metaclass_ = type").

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org