My own 12 points list

[Michael Hudson]

pruebauno at latinmail.com (nnes) writes:

> I have really no mayor gripes, and the few things I would change would
> break backward compatibility, but here is the list anyway:
> 
> 1.) Eliminate the whole long stuff. E.g. built-in long () function,
> "L", etc. It is a Python language implementation detail and I do not
> care about how it is done as long as it is fast and correct. Make
> python int adapt according to size of the integer and underlying
> architecture. 8088-80286=16 bit integers, 386-586=32
> bit, x86-64=64bit. If number overflows the CPU architecture
> auto-magically use internal (long) representation.

In progress.  See PEP 217.

> 2.) Eliminate map (), filter (), reduce (). It can be replaced with
> list comprehensions and for loops, which are easier to read.

I'm wary of "eliminate" -- why break old code for no very good reason?
"discourage", maybe.

> 3.) Eliminate open (), use file () instead

Hmm.  I think "open" reads better, myself.

> 4.) Eliminate xrange(), replace range() with xrange() implementation

Backward compatibility again: some code really does expect to get a
list out of range().  But there are signs things are nudging in this
direction, slowly.

> 5.) Eliminate built-in functions buffer(), callable(), delattr(),
> dir(), getattr(), hasattr(), hash(), help(), id(), isinstance(),
> len(), max(), min(), repr(),  setattr(), sum(), str(), type(),
> unichr() and make them methods of the root or base object. 

Ye gods, no.  This would be pure churn.  And I'm not sure it's even a
good idea for some of those listed.

> 6.) Eliminate lambda, use local ‘def somename(param):return expr'
> instead.

With you here, modulo the usual "eliminate" concern.

> 7.) Eliminate locals(), globals() and replace with a vars() that
> defaults to locals, and accept a parameter to get globals().

Why?

[...]
> 10.) Eliminate the recursion limit on functions or better yet, include
> an option to change from the default to infinite. No need to change
> anything in the language. A lot of work in the implementation though.
> Could use regular method up to a number of calls and then switch to a
> less performant method.

See www.stackless.com :-)

> 11.) Add a big decimal type (something like java) in the standard
> library. To be able to do bean counter type math easily. Are there so
> few python applications that deal with money?

Again, there is movement here.

> 12.) Int division: return float (for engineers) or big decimal (for
> bean counters)

I really don't like the idea of having optional behaviour here.

> Some of them are blatantly copied from Guidos regrets slides btw. I
> just happen to agree with most of the points on them.

I thought some of them looked familiar :-)

 ----

There's a distinction between "how would I do things if I could go
back to the early 1990s and have a chat with Guido" and "what changes
are worth making now".  There's a price to any change (esp. ones like
"eliminate open()"...) and I think my limit may be set a little lower
than yours :-)

Cheers,
mwh

-- 
     ARTHUR:  Why are there three of you?
  LINTILLAS:  Why is there only one of you?
     ARTHUR:  Er... Could I have notice of that question?
                   -- The Hitch-Hikers Guide to the Galaxy, Episode 11