Guido van Rossum wrote:
> On 12/11/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> Josiah Carlson wrote:
>>> [EMAIL PROTECTED] 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 | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
