Kay Schluehr writes:
> I wonder what is the current state of type/class unification i.e.
> "new style classes"?
>
> The Python 2.5 library reference ( chapter 2.3 ) still states that
> this issue is being "far from complete".
The current state is this: Python has already introduced "new style classes"
which do provide type/class unification. Now it IS possible to subclass
built-in types like int, string, list, and dict. However, for backward
compatibility reasons, the "old style classes" were not removed. There
are very minor and obscure differences in behavior between new style
classes and old style classes which shouldn't affect most users, but
we believe strongly in supporting backward compatibility where possible.
In Python 3000 (AKA Py3K, AKA Python 3.0) we are intentionally breaking
backward compatibility to remove cruft. Old style classes will go away
and all classes will be new style.
> ( BTW this signals the user that the object system is quite immature
> and early alpha. Maybe one should
> rethink commenting the current state of development all over the
> public docs? )
You are completely correct. The manual is misleading and makes the state
of things sound far worse than it is. We probably ought to update the
manual. Thanks for pointing it out.
> Since we discuss new features here I would like to listen what
> people think about opening builtin types?
> So far Python has a protective policy to not let users add a method
> to e.g. an int or str. Is there a deeper
> design issue or is it for pure implementation/optimization reasons?
Yes, please do discuss the idea here... it would be very much on-topic
for this list (more so than some of the other conversations going on
<wink>).
For the most part, Python does not strongly encourage users to modify
existing classes (like Ruby does). Instead, we encourage subclassing
to add new features -- and that already works fine for built-in classes.
However, this is more of a practice than a prohibition... it IS
possible to modify existing classes in Python. Here's an example:
>>> myInstance = MyClass()
>>> myInstance.func1(42)
func1(42)
>>> def func2(self, x):
print 'func2(%s)' % x
>>> MyClass.func2 = func2
>>> myInstance.func2(42)
func2(42)
Unfortunately, for implementation reasons you can't modify most
built-in (and some user-defined) classes in this fashion:
>>> int.func2 = func2
Traceback (most recent call last):
File "<pyshell#35>", line 1, in -toplevel-
int.func2 = func2
TypeError: can't set attributes of built-in/extension type 'int'
Most Python programmers would probably agree that this is a
perfectly fine restriction. Built-in classes like int and dict
are widely used... allowing the code from any one module to
modify them has dangerously non-local effects. (Yes, I know...
it works OK for Ruby... but I, for one, am still wary.) If
your code really needs to modify the behavior of int (or dict
or whatever) then use a subclass of int (or dict or whatever)
in your own code which you can modify freely.
But if you've got a convincing argument (preferably with use
cases that are only poorly addressed by today's Python) for why
this behavior ought to be added to Py3K... please let us know!
-- Michael Chermside
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
