some comments for Python 3000

[Courageous]

> I agree with you! they are not _directly_ of any interest to the
> programmer - their results are. List as first class objects, functions
> like map, reduce etc were of no interest to the mainstream programmer -
> if you'd ask them nobody would vote for them - yet they were put in
> Python. Nowadays they allow much shorter as well as much safer code.

I'm not sure how many people are using these functions, actually.
But no matter; I do like them, don't get me wrong. As a lisp programmer,
map, reduce, remove-if, lambda, et al. are my friends.

> > Python ... needs a native compiler that compiles ...

> I do not argue that the language issues are the only ones - performance
> may be important in some areas.

Your average Python program is outperformed by C by 6:1 and
in some cases this is worse. It's an issue.

>     I would also propose that having higher level constructs may lead
> to speed improvements - as it enables different mappings into
> underlying implementation code. For example - far fetched, just to show
> the concept, the map function can be applied in parallel to all
> elements of the list - each in a separate thread. Not much win in the
> single processor environment - but Python is also used for scripting in
> multiprocessor servers...

This will become more important very, very soon. Within 2 cpu
generations, on-die SMP will be mainstream. Go to http://www.ibm.com
and do a search on "POWER4" to get a preview of things to come.

> > It doesn't have to be as fast a C, mind you.
> 
> I wouldn't mind Python being faster - for free :-). But if I need
> something _running_ fast I'll use C++ - hard to beat. 

But that's the point! Python is a wonderful environment! It's a
shame to be *forced* to switch. Makes me wanna cry, veritably.
Every time I write Python for a while and then have to go do
write in Lesser Languages (tm), I feel *dirty*. :)-

Anyway, regarding your comments via features versus performance:
I believe that the compiler effort has the right idea with optional
type tags and optional "strict" objects. Personally, I like the
notion of "strict"; it's a way for the programmer to say, "hey, I'm
done with this now". I think the concept could be deeply exploited;
one or more optional keywords which disable entire categories of
python dynamism both because doing so speeds things up and also
because it's no longer needed in that section of the code.



C//