You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

148 lines
5.9 KiB

From: wtanksle at (William Tanksley)
Date: Thu, 29 Apr 1999 23:06:15 GMT
Subject: Python IS slow ! [was] Re: Python too slow for real world
References: <> <> <> <> <> <>
Message-ID: <>
Content-Length: 5450
X-UID: 259
On 29 Apr 1999 10:35:50 +0200, Markus Kohler wrote:
>>>>>> "William" == William Tanksley <wtanksle at> writes:
> William> On Wed, 28 Apr 1999 20:04:00 GMT, Paul Prescod wrote:
> >> William Tanksley wrote:
> >>> And Oberon (SlimBinaries), and Eiffel (typing and general
> >>> compile-time error catching), and ...
> >> Actually, isn't Eiffel's type system famous for being full of
> >> holes?
> William> I'm familiar with the covariance/contravariance argument,
> William> but I've never before heard anyone say anything about
> William> Eiffel being full of holes. What problems have you heard
> William> of?
>As far as I remember Eiffel requires a global system analysis to be type
>safe at compile time.
According to Meyer, that would be the most permissive thing to do. He
also suggested an option, the rule about "no polymorphic CATcalls", which
would not require such intensive processing and would allow most of the
same things.
All in all, though, after having read over Meyer's materials very
carefully, I have to say that I don't like his justifications. I just
looked at the Sather site (Sather is an Eiffel-inspired language which
uses contravariance), and they explain how to solve the problem he was
demonstrating (in a MUCH more logical and reuable way!).
Since Sather is itself an subclass of Eiffel, I don't think I'm violating
any typing rules by claiming that imitating Sather is similar to taking
things from Eiffel ;-).
Sather itself offers some interesting options for inheritance. For
example (let me translate to Python):
class Gizmo(Object):
inherits the interface of Object, but _none_ of its implementation. If
you want the same member functions as Object had, you have to do this:
class Gizmo(Object):
import Object
from Object import new, del, etc
This means that classes can behave like modules (because they bring
functions into their namespace the same way)... And logically, vice
Of course, "inheriting an interface" is only meaningful with static
typing. Notice that this also addresses the issue of interfaces -- every
class is an interface.
The disturbing thing, of course, is that this is totally incompatible with
the current way of doing things. That's easy to overcome, though:
class Gizmo(Object, <Doodad>):
from Doodad import *
> >> Regardless, wouldn't a better source of inspiration on typing
> >> be a language with *optional* compile-time error checking?
> William> Good question. I don't know the answer, but I can point
> William> out the dangers of not planning our path.
[the dangers of C++ and other loose languages -- mixed measures considered
> William> The other dangerous side, of course, is being one of the
> William> languages which are so safe you can't use them without a
> William> huge manual and pages of UML. Python can NOT wind up
> William> like this, regardless of the dangers obvious in the other
> William> side.
>Agreed. The main problem with todays statically typed languages is that
>they are too restrictive and to complicated.
I'm not sure that they're _too_ restrictive; they work in their domains.
The problem is that we don't want to loose Python's greatest strength:
it's friendly.
> William> Let me expand a little on the dangers of C++.
> William> - virtual functions. It shouldn't be my job to tell the
> William> compiler when virtual lookups are the only thing to do;
> William> the compiler ought to be able to tell. For performance
> William> gurus, a way to hint to the compiler that virtual lookups
> William> were _not_ needed might be useful -- but what if the
> William> programmer was wrong?
>True, SmallEiffel inlines most of the virtual function calls automatically.
>This is the way to go.
Inlines virtual functions? I think you got your wires crossed ;-).
Virtual functions, by definition, can't be inlined. Inlining is where you
place the routine's source code directly into the code of the calling
> William> - GC -- hard to add after the fact. No worry with
> William> Python, but what if there are other issues like it?
>I'm not sure if I understand this sentence. Do you mean GC is hard to add
>to python without breaking existing code ?
>I would agree with that. And why do you say "no worry"
>Do you mean GC is not worth the effort ?
Guido seems to think so. Anyone who disagrees is free to contribute and
work on porting GC code (I would like to see it).
I think that worrying about the other issues is FAR more rewarding -- RC
is not only hard to replace with GC, but the rewards for doing so are
relatively small (in comparison to the other things we can think about).
I don't want to stop anyone from trying, though. The nice thing about
free software is that even if everyone disagrees with you or thinks it's
not worth it you can still get it done.
So what other issues are worth thinking about? I don't know.
> You may have a look at Strongtalk a Smalltalk with static (optional)
> type checking.
Found it using (a GOOD search engine for technical matters).
I'll be spending some time reading it. My initial impression: _very_
good. This would fit well, I think.
> Markus
-William "Billy" Tanksley
"But you shall not escape my iambics."
-- Gaius Valerius Catullus