FEEDBACK WANTED: Type/class unification

Marcin 'Qrczak' Kowalczyk qrczak at knm.org.pl
Sat Jul 28 17:46:46 EDT 2001


Sat, 28 Jul 2001 15:35:44 GMT, Guido van Rossum <guido at python.org> pisze:

> If there's anyone who believes the type/class unification should not
> become a feature in Python 2.2, please speak up now or forever hold
> your peace...  (But I'd rather you speak up!)

Type/class unification is definitely worth doing.

But since you want some critic, here is one: the picture is
complicated. Not that I know how to do it better, perhaps it's
unavoidable. Nevertheless it's so complicated that details escape me.

Relations between instances and classes, instance methods and class
methods and static methods, related magic attributes (__base__,
__bases__, __class__, __dict__, __mro__, mro, __init__, __new__,
__call__, __defined__), all these slots and wrappers and descriptors
and methods and functions, and e.g. what is really called when I
write o().

I didn't expect this basing on previous experience with Python where
most of important things were obvious at the first glance. Here
are examples of things in Python which were very easy for me: the =
operator, translation of syntactic sugar into methods, mutability
and immutability, == and is, indexing conventions in slices, apply
and *args and **kwargs, del and __del__, and almost all the syntax. I
like them. Things mentioned in the paragraph above are not among them.

Another hairy place is raise and except, i.e. what is really raised
when I write 'raise a' or 'raise a,b' - what a and b can be.

Other than that and some unimportant points, it's a nice and clean
language.

-- 
 __("<  Marcin Kowalczyk * qrczak at knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^                      SYGNATURA ZASTĘPCZA
QRCZAK



More information about the Python-list mailing list