PyOpinion: Does Python Programming Marginalize You?

[Ken Seehof]

Rainer Deyke wrote:

> Ken Seehof <kens at sightreader.com> wrote in message
> news:393DDDF8.DE0401BB at sightreader.com...
> > Rainer Deyke wrote:
> > > Write an optimizing compiler that increase performance by a factor of at
> > > least 100 and decreases memory usage by a factor of at least 100.
> Python in
> > > its current incarnation is too inefficient to be useful as primary
> language
> > > for shrink-wrapped software.
> >
> > Because of it's dynamic nature, Python simply can't be optimized all that
> much
> > (read about all that type inference stuff and you'll see what I mean).
>
> A truly good optimizer might do wonders by analysing the entire system.  For
> example, it sees that a certain name can only reference objects of certain
> type, so it bypasses the generic access mechanism.  It sees that instances
> of class X only get attributes from a certain set, so the dictionary is
> replaced by a more efficient data structrure.  In general, if a human can
> read a python program and produce an equivalent efficient assembly program,
> a computer should be able to get close.

The type analysis is the tough part.  It is extremely difficult, and usually
impossible, to do meaningful and robust type analysis in a dynamic language such
as python.  Yes, it is true that perhaps 99% of python code doesn't actually
involve fancy abstract type hacking.  However, almost no python code can be
/verified not to involve fancy abstract type hacking/.  Almost every line of
code can invoke a function call.  A function call can have arbitrary side
effects on the local and global dictionaries.  In order for an optimizer to be
robust, it must never change the behaviour of a program, even if the program is
written badly.

I very much want somebody to prove me wrong.

These issues are so problematic that they have driven even Guido to come up with
some very strange ideas like having two kinds of python: the usual dynamic
python mode for most modules, and a non-pythonic python mode (invoked by a
special token at the beginning of the module) for modules that are to be
optimized.

> > Fortunately that just doesn't matter!
> >
> > 98% of code does not need to run fast.  You write the other 2% in C.
> > 98% of all objects (on a per-object basis) do not need to be packed tight.
> You
> > implement the other 2% in C.
> >
> > Conclusion: The primary language does not need to be efficient.
>
> But this involves complicated maneuvering between Python and C.  In many
> instances it is easier to just write the program in straight C.

> --
> Rainer Deyke (root at rainerdeyke.com)
> "In ihren Reihen zu stehen heisst unter Feinden zu kaempfen" - Abigor

That's certainly true.  This kind of thing will get much easier as new
development tools are created.  For example, I've developed a code generator (a
Visual C++ wizard named PyExtWizard) some time ago to create python extension
modules and add new type and function boilerplates.  So for me, it's very easy
to get from python to C.  When some new (python based) build utilities come out
and get integrated into some well designed python IDEs, extension writing will
become easier still.

Getting from C to python is not as important as getting from python to C in this
context (C to python more important for adding scripting capabilities to
existing C/C++ applications).  I generally have a C layer at the bottom that
doesn't have any awareness of the higher python layer(s).  All high level coding
(including all of the user interface) is done in Python.

I'm picturing a world where python extension development will be as easy in a
Python IDE as pure C/C++ development in an IDE such as Visual C++.  This is
doable.

BTW, in this scenario, Python can be an excellent lab environment for testing
C/C++ code.

--
Ken Seehof
kens at sightreader.com
starship.python.net/crew/seehof
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


-------------- next part --------------
A non-text attachment was scrubbed...
Name: kens.vcf
Type: text/x-vcard
Size: 343 bytes
Desc: Card for Ken Seehof
URL: <http://mail.python.org/pipermail/python-list/attachments/20000607/8d2c6eb1/attachment.vcf>