Are those features still the same?

[Terry Reedy]

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