some random reflections of a "Python newbie": (2) language issues

[skaller]

Preston Landers wrote:
 
> Unfortunately for you, Python dicts are a built-in type (for speed
> reasons) and thus you cannot subclass it, then then implement your
> locking mechanism.  This is one of the few obvious inconsistencies in
> Python's implementation.  If you could subclass builtins, then what you
> want to do would be completely trivial.

	I don't agree: python is NOT inconsistent here. See how Viper does it,
it retains the Python typing model as is, generalising the notion
of type object instead of insisting that they all be classes,
and that classes are always types. [This is the case in almost all
OO programming languages, including C++, Eiffel, and Java: the core
types are NOT classes. All provide 'class emulations' of the core types,
as python does]

	Secondly, a dictionary with locking is not a 
subtype of a dictionary. [But this is a common mistake]
If it were, an algorithm accepting a dictionary 
would also accept a dictionary with locking -- and 
that is not the case, because the latter might be locked, 
and break the algorithm. It is in fact  more likely to be
completely the other way around: an algorithm which works with
a dictionary that supports locking, and tests to see if the
dictionary is locked, will work with one that
does not permit it to be locked.
(assuming that exceptions are counted as errors, and would be
raised if one was attempting to add a key to a locked dictionary)

	The general rule for subtyping is: a subtype must
be MORE CONSTRAINED than the super type. You can NOT add
flexibility, only remove it. Example: a symmetric matrix
is a subtype of a matrix _considered as a readonly value_.

	It turns out subtyping in OO is almost useless
when the objects are mutable. This is because 
the mutators must be simultaneously covariant and
contravariant -- which means they must be invariant,
and the object is then isomorphic to the original,
that is, it isn't a proper subtype at all, but the same type.
[That is, it has the same behaviour]

	There's only one exception: when all the methods
have invariant arguments (such as integers). In that case,
variance on the object works. For example, device drivers
(the invariant types are 'characters' the driver reads or writes).
The types that cannot be OO'ified include numbers,
and anything else that has to relate to some other
OO'ified object. Which is almost everything else
in the real world.

	Please note I'm not saying classes are useless,
I'm saying subclassing is more or less useless.
So the fact that Python objects can't be subclassed
is no great loss: few python types could be sensibly
subclassed anyhow. [The main exception, I think,
is the file type, which could be usefully subclassed ..
because it has invariant methods]

	Again, note that class __xxxx__ methods
for sequences are useful -- but this is not subclassing,
but signature based genericity. Unlike OO,
that is supported by robust mathematical theory.

-- 
John Skaller, mailto:skaller at maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia
homepage: http://www.maxtal.com.au/~skaller
voice: 61-2-9660-0850