Python's simplicity philosophy

[Terry Reedy]

"Alex Martelli" <aleax at aleax.it> wrote in message
news:WQ1tb.19726$9_.707480 at news1.tin.it...
> Terry Reedy wrote:
> > If the builtins are reduced in 3.0, as I generally would like, I
would
> > be fine with moving apply, map, filter, and a repaired version of
> > reduce to a 'fun'ctional or hof module.  But the argument of some
> > seems to be that this batteries-included language should
specifically
> > exclude even that.
>
> A functional module would be neat.

Good.  I wrongly thought you might be in the abolish camp.

>  A great way to enhance the chance that there will be one
>  would be starting one today (e.g. on sourceforge),
> ideally with both pure-Python and C-helped (or pyrex, etc)
> implementations,
> and get it reasonably-widely used, debugged, optimized.

Interesting idea.  Maybe I will do something with it.

> Also, I advocate that 3.0 should have a module or package (call it
> "legacy" for example) such that, if you started your program with
> some statement such as:
>
> from legacy import *
>
> compatibility with Python 2.4 or thereabouts would be repaired as
> much as feasible, to ease running legacy code, and to the expense
> of performance, 'neatness' and all such other great things if needed
> (e.g., no "repaired" versions or anything -- just compatibility).

Running old code in new interpreters seems not to be much of a problem
yet because of the current policy of not deleting features or (with
pretty minor or obscure exceptions) changing semantics.  But if any
deprecations take effect before 3.0, legacy could also be added
before.

I think there should also be an official 'retroxy' module to help run
(a feasible subset of) pythonx.y code in older interpreters.  A
retro23 module would define True, False, sum, enumerate and perhaps
other stuff.  Accompanying instructions could discuss which older
versions a new module like sets will work with.  I am sure this has
been invented privately several times.

> One reasonably popular counterproposal to that was to have it as
>
> from __past__ import *
>
> by analogy with today's "from __future__".

which Guido has strongly rejected since it would mean keeping old
stuff in the interpreter forever -- unless it were a synonym for
'import legacy' -- in which case your spelling is better.

>   I'd also like to make it
> easy to get this functionality with a commandline switch, like is
> the case today with -Q specifically for _division_ legacy issues.

 -L to mean 'import legacy' on startup should be possible.

> But mostly, each time I mention that on python-dev, I'm rebuffed
with
> remarks about such issues being way premature today.  Somebody's
> proposed starting a new list specifically about 3.0, to make sure
> remarks and suggestions for it made today are not lost about more
> day-to-day python-dev traffic, but I don't think anything's been
> done about that yet.

Perhaps Guido is trying to avoid pressure to start before he and the
PSF are ready.

I personally wish 3.0 were out now or the next release.  That is what
I more or less expected 2+ years ago when I suggested that the
division switch be delayed until 3.0 -- or rather, suggested that the
first release after 2 years make the switch *and* be called 3.0.  I
was not asking to have to import the new division rules for years and
years;-).

Terry