Python -- (just) a successful experiment?

[Paul Rubin]

"Terry Reedy" <tjreedy at udel.edu> writes:
> Hypothesis 1: someone learned Python and Tkinter, felt dissatisfied with 
> Tkinter, went searching the universe for an alternative, found GTK, and 
> wrote PyGTK, perhaps learning C in the process.
> 
> Hypothesis 2: a C-programmer who is a satisfied user of GTK (on *nix, 
> presumably) learns Python.  "Neat, but I also want to keep using GTK." 
> Which he can because it is relatively easy.
> 
> Repeat H1 and H2 for every wrapping.  You believe in H1.  I suspect H2 is 
> more often true, but admit I have no data.

I dunno about PyGTK but one of the more common complaints about
wxPython is that it's not Pythonic enough.  And wxPython is probably
the most popular Python GUI toolkit after Tkinter.  So people don't
want C wrappers.  I think what they mostly want is a wide choice of
good looking widgets.  They don't like Tkinter because its widget set
is limited and what widgets it does have, look like crap.

> I have an alternate interpretation.  There is a Python wrapping for
> as many C libraries as there are because Python is neat and wrapping
> is fairly easy and the rewards great.

I think Python outgrew this "glue" orientation years ago and its main
failings today are where it holds onto that orientation instead of trying
to stand as a language in its own right.  The Python docs should specify
what Python code actually does, not simply that Python wraps the C library.

> When I learned Python several years ago, being able to interactively drive 
> and easily script foreign libraries was touted as one of its killer 
> applications.  Numerical Python, wrapping BLAS, LINPACK, and FTPPACK was a 
> prime example.  So in a sense, you are criticizing Python for being 
> successful at what I believe was one of its design goals.

Having a good FFI is certainly an important feature but Python
programs should first and foremost be Python programs.  Compare the
situation with Java or Common Lisp for example.  Both of those
languages have better FFI's than Python in every serious
implementation (consider why SWIG is popular--because Python's C API
is so clumsy), and yet the specs for those languages are far more
thorough than the Python docs.