PEP 309 - Built-in closure type (with tentative syntax proposal)

[Alex Martelli]

Peter Harris wrote:

> Alex Martelli <aleaxit at yahoo.com> wrote in message
> news:<b2tqpq026u1 at enews2.newsguy.com>...
>> Consider that sets, for example, HAVE had to start their
>> life as a standard library module, NOT as a built-in type.
>> Is currying a more fundamental and precious concept than
>> SETS...?!  Not really.  So...
>> 
>> 
>> Alex
> 
> Well, when you put it that way I can see your point.
> 
> But then I was in favour of sets being built-in and having the
> compiler accept syntax like {1,2,3} to construct them. I'm
> probably just too keen on that sort of thing.

It depends on your goals, really.  Python is a solid, stable
language, suitable for production use and widely used in large
production-stage software systems.  It is therefore perfectly
right and proper that change in Python proceed slowly and
meticulously, with lots of care about backwards compatibility.

However, the same resistance to change may be a minus for you
if your goal is very different -- playing with language ideas
and concepts, leaving your mark by contributing some kind of
major language-level enhancement (_implementation_-level
enhancements that will break no program but will speed some
up are quite welcome even in Python of course;-), and the like.

For such goals, I would recommend targeting different languages.

Ruby might be quite suitable, for example: it's close to Python
in many ways, but more plastic both technically (your Ruby
program can change the behavior of built-in objects) and, it
seems to me, socially (a community more attuned to change).  I
think that plasticity is a _downside_ if you're thinking of a
language to use for actual production use, but an _upside_ if
you want to do research, innovation, experimentation.

Or, you could look into a language with a good macro system,
such as Common Lisp, or Dylan -- with suitably clever macros,
the language's syntax becomes putty in your hands.  Again, I'm
far happier NOT having such plasticity in a language to be
used for production code, but if experimenting with novel ideas
was my goal, I would seriously consider that option.

"Horses for courses".  Python is excellent for _many_ uses, but
I consider it *cannot* ever be excellent for *every* use without
paying excessive prices in terms of complication, stability,
excessive plasticity leading to multiple "dialects", and so on.
Fortunately there ARE several other good languages around that
do fill the niches Python is best off avoiding, such as, maybe,
those that best meet your needs and desires.


Alex