Could Python supplant Java?
James J. Besemer
jb at cascade-sys.com
Tue Aug 27 01:19:46 CEST 2002
> James J. Besemer wrote:
>> The conclusion then is that languages such as C++ and Delphi are "late
>> binding" languages and provide full Polymorphism THAT way.
> You started saying that you could implement polymorphism with early
> binding and gave the C++ as an example. Funny, isn't it ?
Don't confuse a sarcastic statement made when I'm exhausted by the
argument with what I really think.
Since I started a week ago by defining early vs. late binding I hardly
think it's meaningful for people to argue I'm wrong by changing the
>> Either way, there's nothing unique about Python's OOP facilities
>> which was my
>> main point.
> Who said so ?
This was a very lengthy thread with many side arguments. I don't say
you took this position but some said Python was superior in this regard
and I disagree.
> I don't see nothing truly new in Python, *except* for the fact that
> you get (IMHO) best of most languages, and a clear and simple syntax
> with it.
> Now if you're in for speed, leave out C++ and go for C and assembly.
> The C++ OOP stuff is not without overhead.
Well, yes and no.
I ran some benchmarks and depending on OS and CPU speed, C++'s overhead
for member functions is between 25 and 50% of that for a static function
call. Virtual functions are 50-60% more than a static function call.
For Python, a class function call costs between 33-45% more than a
regular global function. I suppose the cost is the cost of 2 hash table
lookups (one for the object reference and one for the object's member
More interestingly, Python's function calls range from 50X to 360X
slower than C++s. So if C++'s OOP overhead is too much for performance
oriented applications, than Python is right out. [Although that's the
inference to be made, I personally think even Python is suitable for
some "real time" applications.]
This also clearly illustrates the difference between early and late
binding. Yes, there is overhead for C++ virtual functions but it's an
extra instruction inline that runs at machine speeds. In late binding
languages such as Python, we're talking a chunk of runtime library C
code -- one or two orders of magnitude slower.
> Remember that this was about : can a language with late binding be
> used for a large project ?
Even THAT was a side argument IIRC. It started out Python vs. Java
which has nothing to do with any of the above.
I agree with you that it's ridiculous to say late binding languages
cannot be used for large projects. There are many examples from Lisp
and we're even beginning to see a few using Python. Where I demur is
that I think some early binding features become more valuable in larger
projects. Essential? No. More useful, better than not having them? Yes.
James J. Besemer 503-280-0838 voice
2727 NE Skidmore St. 503-280-0375 fax
Portland, Oregon 97211-6557 mailto:jb at cascade-sys.com
More information about the Python-list