Some more notes

[Josiah Carlson]

bearophileHUGS at lycos.com (bearophile) wrote:
> 
> 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.

Oh, yes, feel free to complain about features that are being used by
literally thousands (perhaps hundreds of thousands) of people today.
Maybe tomorrow we'll start considering removing something so useful as
list mutation, dictionary mutation, object mutation, etc.

Or maybe not.


> >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'll quote the section of the PEP:

         It should be possible for the compiler to detect an
         if-elif-else construct which has the following signature:

                      if x == 'first':...
                      elif x == 'second':...
                      else:...

         i.e. the left hand side always references the same variable,
         the right hand side a hashable immutable builtin type.  The
         right hand sides need not be all of the same type, but they
         should be comparable to the type of the left hand switch
         variable.


Immutables are anything with type of: int, long, str, unicode, tuple;
though tuples must contain only other immutables to still be immutable.


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

That was it.  Well, in Python you no longer need to create recursive
structures.  Just use list.append(), it is fast (you don't need to rely
on a Mathematica mis-feature *wink*). If you wanted to prepend instead,
just remember to list.reverse() it before you are done.


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

Think of it like this.  You had likely been reassigning lists to
themselves in order to repeatedly append or prepend to a Mathematica
list because standard appends and prepends were slow.  Now you don't
have to.  You were doing explicit mutation before, now you are doing
implicit mutation without need to flatten.  Will the wonders never cease?


> >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 :-)

Ahh, but you said was, "hey, this super duper language does things like
this, wouldn't it be great if Python did this too?"

Understand that people have been building Python for only 2 years
younger than Mathematica.  It gained some features and experience of C,
Modula and other languages which are far older than Mathematica, and
didn't limit the user to immutable types (thank god).


> (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.)

How would knowing about Mathematica help Python?  Mathematica is
closed-source, commercial, and proprietary; you can't even look at the
guts for implementation details.  We would be better off looking at
non-commercial implementations of Python, Perl, Lisp, Tcl, etc. for that.

And as for language features; it is of my opinion that the Mathematica
language leaves something to be desired, and I would prefer the
'features' of Mathematica language to be left there.


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

If the code runs, it is correct.  Is it in the Mathematica style?  No. 
I haven't written Mathematica code in around 3 years.


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

Hrm...lemme see...

global_hash = {}

def memoize(fcn):
    def call(*args):
        if (fcn, args) not in global_hash:
            global_hash[(fcn, args)] = fcn(*args)
        return global_hash[(fcn, args)]
    return call

@memoize
def foo(arg1, arg2):
    ...

@memoize
def goo(arg1, arg2):
    ...


Goodness, so can Python.  But it is not necessary, my original
declaration used individual dictionaries for each memoized function.


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

In the C/C++ world, that is called polymorphism.  You can do
polymorphism with Python, and decorators may make it easier...


@accepts(int, str, int, unicode)
def foo(a, b, c, d):
    pass

@accepts(str, int)
def foo(a, b):
    pass


With a properly implemented accepts decorator (I believe one is floating
around there somewhere, I would give one, but it is getting late, and I
need to wash dishes and shave).


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

If you want floor division on integers, you can use the floor division
operator: //  *gasp*

I believe that the standard division operator behavior on integers was
considered a misfeature in prior Python versions, a remnant of Python's
C roots, which is why it was slated for removal in 2.4, with documented
"it is going away" in the documentation for Python 2.3 .


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

Just because something fits with another language, doesn't mean that it
is even remotely Pythonic.


> A bear hug and thank you again,

Gah, no more hugs.  Please.
 - Josiah