Typing system vs. Java
aleaxit at yahoo.com
Wed Aug 1 16:58:50 CEST 2001
"Christopher Barber" <cbarber at curl.com> wrote in message
news:pso66c9rpo8.fsf at jekyll.curl.com...
> > What is a real world problem that would not have existed if Python had
> > strict compile-time checking, and how common is such a problem?
> Here is a real-world problem: a developer wants to use a language with
> compile-time type checking and rejects Python because it doesn't have it.
Why is this "a problem"? Counterexample: a developer wants
to use a language with an 'e' in the language's name and rejects
Python because it has no 'e' in its name. Should we therefore
rename Python to 'Pethon' to "solve this problem"?
Each developer or development organization can freely choose
whatever constraint he/she/it/they prefer regarding their
programming tools. If this it a problem, it's *HIS* (her,
its, their) problem, not Python's. It would be silly and
self-defeating if Python tried to match such constraints just
because they are posed as constraints.
If it's worth for Python to have an 'e' in its name, it must
be because using that letter has intrinsic value within the
logic of Python, so, you should be arguing about that
intrinsic value, not about "marketing" advantages that
may stem from having it, if you want to speak "real world".
Marketing, by definition, isn't about the real world - it's
about successfully projecting a fantasy in the minds of
people with deep-enough pockets to make you rich:-).
> Well, I actually used Python on a number of projects a couple of years ago
> did spend more time than I would have liked writing tests to detect type
Probably no more time than I spend cursing [expletive deleted]'s who
write type-tests. They THINK they care if a isA b... I'd SO like to
rub their faces hard against all the collected works of General
Semanticists and make them foreswear the cursed "is of identity"!
"BEHAVES-LIKE-A" (i.e. IS_ADAPTABLE_TO_PROTOCOL) is what, at most,
one SHOULD be testing (if anything). Alas, the protocol adaptation
PEP is languishing. In 90 case of 100, though, "just try and catch
the exceptions if any" will do basically just as well.
> I found myself writing comments next to variables indicating
> their intended type. I would much have preferred turning those comments
> actual type declarations.
I fully agree that executable, formalized code is VASTLY superior
in all ways to comments. But the point is that one shouldn't be
asserting IS-A, even in comments, and that's what types ARE (as
opposed to protocols, aka interfaces: the confusion between the
two is, of course, rampant).
> I don't think that lack of static type declarations makes Python at all
> It is still an interesting and useful language. I just think that it
> better with the ability to use static typing when you want to.
I suspect that the loss of dynamic-ity needed to *ensure* the
'typing' was STATIC would totally kill Python, disfiguring it
beyond all recognition. If a USEFUL compiler-recognizable
way to assert protocol-conformance existed, then theoretically
it could in SOME (but NOT all!) cases be hoisted up to compile
time (just like, e.g., in print 2+2, the addition COULD be
done at compile time -- although Python doesn't bother doing
so, there's no *theoretical* impediment to doing it). Just
like you could do now with
assert isinstance(foo, bar)
[except that you *SHOULDN'T*!] -- it's theoretically possible
(although NOT in all cases -- and in practice not done by
the Python compiler) to sometimes hoist such assertions up
It's quite a different issue to dream about a way to assert
'anything that can ever be possibly bound to this variable
X must respect the following constraint' (it makes no
difference whether the constraint is isinstance, or if
it's something actually USEFUL). Conceptually, that would
require the assert equivalent to be inserted at each point
where X *might* be rebound (which might then be hoisted up
to compile-time in some cases). Seems awfully hard to me
in the general case.
More information about the Python-list