On 7/24/2010 8:45 AM, francogrex wrote:
Hi, I'm not a Python programmer but I'm
interested in it and I found this table from
Norvig that dates for some years (I re-posted
it temporarily on my site below to take it out
of context a little). I'm not interested in
any comparisons only in the Python features (
last column), can someone whether the
information in the Python features column is
still correct today. Thanks
http://francoatgrex.tripod.com/
As other have said, mostly, but I would change the following:
Number of implementations should be "Many, one main'
add Set ............?? set() before Hashtable/dict
change Function entry to def f(x): return x+x \n lambda x: x+x
or even remove mention of lambda. Anyone who thinks the table is the
whole story and tries Python without knowing about def will think Python
braindead.
Other loops: '## works on any sequence ' change sequence to iterable.
Assignment: add x,*y = 1,2,3
Add augmented assignment: x += 1
"No other control structures" is simply wrong. 'and' and 'or' are
control structures as much as if-else expressions. Ditto for
list/set/dict comprehensions and generator expressions.
Comments "## hash mark to end of line" just one hash mark
Someone mentioned apply, execfile is now(3.x) exec(open())
"No other higher-order functions built-in" wrong. func.partial,
decorators, others mentioned
'No keywords on map/reduce/filter' ?? I do not know what these are, but
I suspect Python can produce the same effect somehow. this looks like
some lisp detail picked out as something Python does not directly have.
Someone mention nonlocal to write enclosed vars.
Compilation is an implementation, not a language feature. There have
been lisp inerpreters in the past, if not now, and there are Python
compilers now, if not in the past.
Declarations Standard Python has 2, the Cython dialect has 'declarations
for efficiency' just as do some lisp dialects.
Quotation: lambda quotes an entire expression, and is used for one of
the same purposes as list quotation, to suppress immediate execution.
Lisp has one
The Python equivalent of (cons x y) should just be the direct equivalent
y.append(x). Python grows and shrinks list as the 'tail', lisp at the
'head'. Or, the lisp column should include the O(n) lisp code equivalent
to [x]+y.
The python equivalent (car x) is x.pop(). That for (cdr x) is x.pop();x,
which is O(1), not O(n). Again, if the table ha the O(n) way to operate
on a Python list as the 'wrong' end, it should have the same slow way to
operate on the 'wrong' end of a lisp list. What that would show is that
it is a lot easier to operation on the 'wrong' end of a Python list that
the 'wrong' end of a Lisp list. Comparing the wrong Python way with the
right Lisp way is unfair if not dishonest.
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
