On Oct 24, 2009, at 10:50 AM, exar...@twistedmatrix.com wrote:
I think that we should consider requests to make specific classes new-
style (and grant them when doing so won't cause compatibility
problems),
make all new classes new-style, but otherwise leave this alone until
3.x
is widely adopted.
While your argument makes sense to me, there's a fundamental problem
with the way Python introduced new-style classes that creates an
ongoing maintenance tension. I think we should start addressing the
problem incrementally now (especially since it sounded like Kelly was
volunteering for some work!) rather than put it off for one big chunk
when we do a 3k migration.
Let's say you're writing a new Twisted application today. You want to
be prepared for the day when everything is new-style, but you also
want to use existing Twisted functionality. You're using some long-
standing library class, that looks like this:
# in Twisted
class Library: pass
What do you do? Well, the obvious upgrade path here is to make a
class which (A) inherits from "Library" to get Twisted functionality
and (B) inherits from "object" to get new-style-ness. So you go ahead
and write:
# in your application
class Application(object, Library): pass
... and that's great. It works, your class is new-style, and it gets
all the library functionality that you want. Except now, you've made
the old-style-ness of 'Library' a very important part of its
interface. If, one day, we flip any kind of new-style switch, instead
of neatly defining a new-style twisted-using class, your code will do
this instead:
Traceback (most recent call last):
File "your-application.py", line 1, in <module>
class Application(object, Library): pass
TypeError: Error when calling the metaclass bases
Cannot create a consistent method resolution
order (MRO) for bases object, Library
I would really like a more abstract declaration that applications can
use in the meanwhile, to get new-style semantics but still allow
inheritable classes to evolve.
I suspect that we could do this with some kind of metaclass, but that
seems ugly. More reasonable, I imagine, would be something like:
class Application(newStyle(Library)): pass
and we could implement 'newStyle' to do something sane in the face of
either an old-style or a new-style "Library" class.
Of course, there are still issues with behavior differences on
decorators and so on, and so the same compatibility issues might still
come up, but in my experience those issues are significantly less
serious and easier to fix than "my entire program blows up and will
not start unless I make all my classes old-style".
_______________________________________________
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
