Real Problems with Python

[Neel Krishnaswami]

Tim Peters <tim_one at email.msn.com> wrote:
> [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).

Done -- this is what I meant anyway. :)

> > 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.

Here's some code:

class Foo:
   x = 99
   def frob(self):
       print "%d bottles of beer" % self.x

class Bar:
   x = "bar"
   def wibble(self):
       print "Belly up to the " + self.x

Note that all the operations on Foo and Bar work safely for direct
instances of Foo and Bar.  But if you define a subclass like so:
 
class Baz(Bar, Foo):
   pass

you can get type errors even though both of the superclasses have
type-safe operations:

>>> q = Baz()
>>> q.frob()
Traceback (innermost last):
  [...]
TypeError: illegal argument type for built-in operation

This is only an annoyance in day-to-day work, but it becomes a big
problem if you are serious about building automatic code analysis
tools for Python (eg for CP4E). This is because the soundness theorems
needed to write things like soft typing tools no longer hold. :(

> > 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.

Agreed that slinging higher-order functions around like there's no
tomorrow is often very cryptic, but that's not quite what I meant.  I
mean "declarative" more in the sense of SQL, and I firmly believe that
this is frequently far and away the most natural and obvious style of
describing a very large class of problems. Deeply nested for loops
aren't "obvious" either, unless you've been programming for
years. 

Plus it's not just databases that can benefit -- empirically the
constraint based approach to GUIs is much simpler to work with. And
having two important and very different domains call out for this
stuff is a big sign it's significant IMO.

> > 6. The iteration protocol
> >
> 
> 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).

I have only a nodding acquaintance with Icon or Sather, but I've
programmed in CLU, and really enjoyed it. I suspect that in large part
this was because of the cleanness with which iteration could be
expressed in it. Iteration is an awful big chunk of what programs
*do*, and being able to say it cleanly made writing them easier.


Neel