Some more notes

[bearophile]

Thank you Josiah Carlson for all your comments.

>so argument over it is a moot point.
[...]
>Please stop advocating the removal of useful features.
[...]
>Stop complaining about them.

Well, I haven't done something bad, so I think I still have the rights
to discuss, suggest and ask things here.


>In my opinion, the syntax-less case statement described in the PEP is
>pure.  That is, no new syntax is needed, but if your if/elif/else
>statements are of a certain format, you gain the speed of dictionary
>dispatch.  I believe that any case-statement-like behavior in Python
>will likely be of this sort.

I'm still too much ignorant of Python to understand this :-)


>I could have sworn that either append or prepend was fast

On Mathematica (4.0 ore less) both append and prepends are O(n) and
quite slow, if you want to do a much faster "append" to Mathematica
lists, you have to create a nested list:
[a, [b, [c, [d]]]]
And then Flatten it. This can be hundred times faster for 10000
elements.
A group of functions to do it re-defining the heads of the structure:

Clear[h123456]
createL = h123456[];
apppendL[l_, x_] := h123456[l, x];
prepL[l_, x_] := h123456[x, l];
convertL[l_] := Flatten[l] /.
h123456 -> List;


>The only problem is education. Once one becomes educated about the
side-effects of append/extend/etc., one rarely has problems of this
kind,<

Okay. I'll take my time to learn more and I'll see if you are right.


>Honestly, I (and likely many others) don't care that Mathematica can
be faster. C can be faster, Java can be faster, Perl can be faster. 
We use Python for varying reasons and for varying purposes.<

I didn't meant to offend Python... I appreciate many languages at the
same time :-)
(Comparing the speed of C with python is probably of little use, but
comparisons between Mathematica and Python can be a bit more
interesting, because they are both interpreted, etc. And maybe
Mathematica can suggest things to improve Python.)


>For general programming, there are other better languages (in my
opinion, which I imagine is shared), nearly all of which are free.<

I agree.


> If you mean things like (I can't remember the exact syntax, perhaps this is it)...
> fib[a_] := If[a<3, Return[1], b=fib[a-1]+fib[a-2];fib[a]=b;Return[b]]

Something like this is probably nicer and/or more correct:
fib[1] = 1;
fib[2] = 1;
fib[x_] :=  fib[x] = fib[x - 1] + fib[x - 2]

Mathematica's global hash can contain the triads: (functions, params,
value)


>With a 'memoization decorator', it gets easier in the general case<

Nice :-)


>If you are talking about something else, perhaps you should describe
it.

I was talking about something different. I have found a page about it:
http://www.verbeia.com/mathematica/tips/HTMLLinks/Tricks_Misc_7.html
But this page is still quite basic: with the automatic rewriting rules
and pattern matching you can do lot of things.


>Funny, I found no mention of division operator breaking on the Python
3.0 wiki:

I'm sorry, I'm ignorant and I'm just confused about all this. I've
read the PEP238:
http://www.python.org/peps/pep-0238.html
And here:
http://python.fyxm.net/peps/pep-3000.html
I find:
>True division becomes default behavior


>> Case <name>:
>>     1: DoSomething1
>>     range(2,23): DoSomething2
>>     else: DoSomething3
>>
>>That is the worst syntax for case statements I have ever seen.<

It's just an idea, and it's similar to Delphi sintax... The PEP275
suggests something like:

switch EXPR:
	 case CONSTANT:
			 SUITE  
		 case CONSTANT:
			 SUITE  
	 ...
	 else:
		 SUITE  

And:
>Another proposed extension would allow ranges of values (e.g. case
10..14: ...)

I've just used the Python range(a,b) to express the half-open
interval... But probably the Pascal a..b syntax is better.


>Understand that 'obj.attr = val' implies that obj is mutable. Do you
>also want to remove object oriented programming in Python? Likely
not,
>but understand the implications for what you say.

I see.

A bear hug and thank you again,
Bearophile