«

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.

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

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

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

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. Transform
them into object.func(parameters). Most of them have as the first
parameter an object anyway. Some of them can be moved to sys. Various
other functions can be deprecated so that I do no have to scan over a
dozen of functions each time I am looking something up. Especially if
few people use them anyway and they can be replaced 1:1 with another
simple construct.

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

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

8.) Eliminate `x` for repr()

9.) Eliminate raw_input() and replace input() with raw_input()
implementation. Input can be done using eval(input()). Do NOT simply
eliminate input, print and put it in sys. Although it IS ugly, reading
and writing to standard input and output is the bread and butter of
admin scripts, CGI and all kinds of glue programs (python's core
usage) and should be readily available. It also makes for a quick and
dirty user input and output for debugging. sys.stdin.readline() is too
verbose IMHO.

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.

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?

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

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

Nestor

(nnes) wrote...
> 8.) Eliminate `x` for repr()

I have a different idea for backticks use: something like `foo` in
Unix shells. It would behave more or less like popen("foo"), just a
bit smarter. You could either:

>>> print `ls`

and get the whole output of /bin/ls

- or -

>>> for line in `ls`
.... print line

and read output of /bin/ls line by line.

I would add other behavior of string types, like % formatting, so you
could do:

>>> print `ls %s %s` % ('-a', '*foo*')

One potential problem is closing the underlying popen() object early
enough. And it's not really a big advantage over popen() either.

> 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?

I second that. We already have unlimited longs, but with floats we're
limited to platform-specific values.

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

Rational type also fits here to some extent. I wouldn't make it part
of the language though, but rather a standard library type,
rational(a, b=1).

AdSR

(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

(nnes) wrote in message news:<. com>...
> I have really no mayor gripes, and the few things I would change would
> break backward compatibility, but here is the list anyway:
>
> 2.) Eliminate map (), filter (), reduce (). It can be replaced with
> list comprehensions and for loops, which are easier to read.

How do you pass a list comprehension to a function? With map
as a function, you could do something wicked like

do_something_wicked([map, my_map, his_map])

Where my_map and his_map are alternative implementations for
map, and do_something_wicked would use all those functions
for something crazy. But sure, map could be implemented with
list comprehensions if it was really needed, probably like this:

def map(fn, *lists):
return [fn(*args) for args in zip(*lists)]

Soo.. Do I have an optinion? Maybe, maybe not.. I just wanted
to point out that some things are useful as being functions
instead of plain syntax.

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

Then people would have to use list(range[10]) to get the list when
needed.. I always use range() since Psyco seems to optimize it
to a simple for loop of integers (on my tests with Psyco,
"for x in range(n)" is -faster- than "for x in xrange(n)"!).
So xrange() could be removed, and then people would just rely
on JIT compiler optimizations to do the right thing.
Maybe not yet though.

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

Noo, lambda is so lovely and compact. It only obfuscates on
the purposedly obfuscated code. It's too long word for my taste
though.. A symbol for it would be better (I'm not joking).

A. Lloyd Flanagan:
> open() is deprecated [in favor of 'file'], I don't know about plans
> to eliminate it.

I think formally speaking it isn't deprecated. The docs say open
is "An alias for the file() function"

http://www.python.org/doc/2.3/lib/built-in-funcs.html


Andrew

A. Lloyd Flanagan wrote:
> (nnes) wrote in message news:<. com>...
> > I have really no mayor gripes, and the few things I would change would
> > break backward compatibility, but here is the list anyway:
> >
> > 3.) Eliminate open (), use file () instead
> open() is deprecated, I don't know about plans to eliminate it.

Doesn't 'deprecated' mean it will once be elimineted?

> > 5.) Eliminate built-in functions buffer(), callable(), delattr(),
> > dir(), getattr(), hasattr(), hash(), help(), id(), isinstance(),
> > len(), max(), min(), repr(), setattr(), sum(), str(), type(),
> Many of these are being superseded by object meathods. I don't know
> about eliminating them; you'd break nearly every old program.

Python 3.0...?

Gerrit.

--
173. If this woman bear sons to her second husband, in the place to
which she went, and then die, her earlier and later sons shall divide the
dowry between them.
-- 1780 BC, Hammurabi, Code of Law
--
Asperger Syndroom - een persoonlijke benadering:
http://people.nl.linux.org/~gerrit/
Het zijn tijden om je zelf met politiek te bemoeien:
http://www.sp.nl/

Gerrit Holl wrote:
>
> A. Lloyd Flanagan wrote:
> > (nnes) wrote in message news:<. com>...
> > > I have really no mayor gripes, and the few things I would change would
> > > break backward compatibility, but here is the list anyway:
> > >
> > > 3.) Eliminate open (), use file () instead
> > open() is deprecated, I don't know about plans to eliminate it.
>
> Doesn't 'deprecated' mean it will once be elimineted?

It doesn't mean "will be", but usually means "might be". Nobody,
except Guido with the time machine of course, can predict the
future, so it expresses only intent. And sometimes a thing can
be deprecated (as in "don't use this in new code") without anyone
actually planning to eliminate it, ever.

-Peter