Python becoming less Lisp-like

[Carl Banks]

Torsten Bronger wrote:
> Steven Bethard <steven.bethard at gmail.com> writes:
> > Interesting.  I've never thought that.  What parts strike you as
> > "patchwork"?
>
> Well, with a little bit of experience in the field of programming
> languages, you can see which elements had been added later (ie years
> after Python's creation).  Properties surely would have looked
> *very* different 15 years ago.
>
> There would be keywords for static and class methods,

I don't think there would be.  For one thing, I doubt the Python
leadership thinks static and class methods are important enough to
warrant keywords.  For another thing, it violates Python's idea of how
much special belongs in class definitions (i.e., none at all).

In Python, classes aren't some magical land where the usual rules don't
hold (as they are in many other languages).  That's why "self." is used
on class variables, for instance.  A class is nothing more than a scope
that uses a smittering of magic to turn it into a type.

> no distinction
> between Unicode and non-Unicode,

True.

> and probably no multiple
> inheritance

I highly doubt it.  A couple years ago, when Python made the transition
to new-style classes, there was an opportunity to toss out multiple
inheritance.  Not only did the Python developers not toss it or
deprecate it, they put in a lot of work and effort to improve it.  We
now have a spiffy stable MRO algorithm to handle resolution of
attributes.

Besides, in the tradition of dynamic languages, MI is pretty par for
the course, unlike for static languages where it is seen as kind of
exotic.

>(which seem to have caused a lot of trouble recently),

Not sure what you're talking about here.  Was the problem with
XMLRPCServer related to MI?

> and no __new__.

Perhaps.  More likely, there would have been __new__ but no __init__.
At the C level, new and init do seem to serve distinct purposes, but I
don't know how important it would be in a new design.

> At first, I was very pleased by Python's syntax (and still I am).
> Then, after two weeks, I learned about descriptors and metaclasses
> and such and understood nothing (for the first time in syntax I felt
> totally lost).

Metaclasses weren't something that Python just threw in because it was
cool.  Rather, they were mostly a side effect of how Python constructs
classes.  When Python transistioned to new-style classes, the gods
decided to expose the metaclass functionality, because it could prove
useful in a lot of cases.

I believe, however, that there was an intentional lack of effort to
make them less obscure than they already are.  They didn't want average
people to be hacking metaclasses left and right.

> The reason why I stay with Python is (apart from the indenting
> syntax, huge community, and equally huge library) my feeling that
> the Python developers what to unify the language, even by dropping
> features.

Yes, fortunately that happens.  It's good, too.

> The current snapshot is a transitional Python and thus
> with some double features.  The numerical types and two kinds of
> classes are examples.  I'm very surprised about this, because Python
> is a production language, but I'm happy, too.

Yeah, well that's the price you gotta pay when remedying old mistakes
or restrictions.


-- 
CARL BANKS