Real Problems with Python

[Tim Peters]

[neelk at cswcasa.com, with an excellent & thoughtful piece, herewith
 telegraphically condensed -- see the original for more context]

> 1. Reference counting memory management

Change that to "trash cycles aren't reclaimed", and it will eventually get
fixed (possibly sooner than later, given Neil S's latest work).  CPython
users don't want to give up the relative predictability of
reference-counting anyway.  *Many* view rc as "a feature"!

> ...
>    In the long run, the solution is to use a conservative garbage
>    collection algorithm (such as the Boehm collector),

"No chance" in CPython -- the BDW collector is a large package of difficult
code, and can be extremely tricky to port to new platforms.  Can also be
tricky to get it to play nice with extension modules.  CPython has nothing
like that now, and never will (or so I predict).  And BDW is an excellent
implementation of this approach, so it's exceedingly unlikely someone is
going to come out with an easier-to-live-with conservative package.  Bottom
line:  this is as futile as hoping to add curly braces.

>    o Use JPython. It hijacks Java's garbage collection, so there are
>      no problems with cyclic data structures. It doesn't ever call
>      __del__ methods, though I don't think this is a problem in
>      practice.

It sure is for people who rely on __del__ methods.

> 2. Lack of lexical scoping
>
>    Tim Peters disagrees, but I miss it a lot, even after using Python
>    for years.

Actually, Tim wholly agrees that you miss it a lot.  He only disagrees when
people insist that *he* misses it a lot <0.1 wink -- they do, you know! and,
no, I don't>.  I don't *object* to adding lexical scoping, though, and
Guido's primary objection has been reduced to the cyclic trash problem, so
this is back to #1 now.

> ...
>    There's another, more subtle problem -- much of the work that's
>    been done on optimizing and analyzing highly dynamic languages has
>    been from on the Scheme/ML/Lisp world, and almost of that work
>    assumes lexically-scoped environments. So using well-understood
>    optimization techniques is made harder by the difference.

Na -- this is like thinking most supercomputer optimization work has focused
on speeding floating-point code, so integer code must be harder <0.9 wink>.
Python's scoping largely reduces to Scheme but where all functions are
defined at top-level (inventing unique names as needed to prevent name
clashes).  More formally, you can certainly *model* Python's scoping in
Scheme, so any technique sufficient to optimize Scheme code so modeling
suffices to optimize Python too.  How's that for a slick argument <wink>?
Your wallet will be returned at the door.

>    Workarounds:
>
>    o Greg Ewing has a closure patch, that makes functions and
>      lambdas work without creating too much cyclic garbage.

Guido dislikes that implementation.

> ...
> 3. Multiple inheritance is unsound
>
>    By 'unsound' I mean that a method call to a method inherited by a
>    subclass of two other classes can fail, even if that method call
>    would work on an instance of the base class.

Unsure what this is about; am pretty sure nobody has complained about it
before.  Certainly "depth first, left to right" is an unprincipled approach,
but in practice it's more than predictable enough to use.

> ...
>    Prognosis:
>
>    I don't think there's any hope of this ever being fixed. It's just
>    too much a part of Python, and there isn't much pressure to fix
>    it. Just avoid using MI in most circumstances.

People use MI in Python all the time!  It works great.  AFAIK, the claim
above is the sole "pressure to fix it".

> 4. Lack of support for highly declarative styles of programming

This is the hardest for me, because I love highly declarative styles but too
often find they grate against Python's greater love of "obviousness".  I
certainly favor adding list comprehensions, because they're one happy case
where greater power and greater clarity coincide.

> ...
>    o Christian Tismer's Stackless Python patch enables the use of
>      first-class continuations in regular Python code. This lets
>      people easily and in pure Python create and experiment with all
>      sorts of funky control structures, like coroutines, generators,
>      and nondeterministic evaluation.
>
>    Prognosis:
>
>    Pretty good, if Stackless Python makes it in, along with list
>    comprehensions. (Personally, I suspect that this is the single most
>    important improvement possible to Python, since it opens up a
>    whole new category of expressiveness to the language.)

Don't tell him I said this, but that's exactly why Guido fears it (any stuff
he may say about destabilizing the core interpreter loop is a smoke screen
<0.5 wink>):  one programmer's "expressiveness" is often another's
"gibberish".  Christian needs to find a "killer app" for Stackless.  Perhaps
the Palm Pilot port is it.  Perhaps some form of migrating computations
among machines is it.  Hard to say -- who would have guessed that Zope would
prove popular <wink>.  But stressing "adds unbounded new power to express
control flow in novel, unique new ways" is exactly the way to scare 99% of
this community in the other direction.  Let's try lying about Stackless
instead ("it's really a floor wax, despite that it was originally sold as a
dessert topping").

> 5. The type/class dichotomy, and the lack of a metaobject system.

Certain to be fixed in P3K, almost certain not to be fixed in CPython 1.x.

> ...
> 6. The iteration protocol
>
>    The iteration protocol is kind of hacky. This is partly a function
>    of the interface, and partly due to the way the type-class
>    dichotomy prevents arranging the collection classes into a nice
>    hierarchy.

It was designed to support straightforward sequence types, and works fine
for that.  It indeed doesn't generalize beyond that without major strain.

> ...
>    o Wait for Guido to invent a better way: Tim Peters has said on the
>      newsgroup that GvR is working on a better design,

I've been pushing Icon's generators (Sather's iterators, if that's more
familiar -- "semi-coroutines" for the abstractoids) since '91.  A very clean
& general iteration protocol can be built on that (e.g., iteration over
recursive structures is as natural as breathing).  It's easy to implement
given Stackless.  It's even easier to implement directly.  Guido warmed to
it at one point last year, but hasn't mentioned it again (but neither have
I).

Thanks again for the useful post, Neel!  It was gourment food for thought.

back-to-cheeze-whiz-and-dairy-whip-ly y'rs  - tim