Plus parentheses rather than indentation to delimit expressions; parentheses are much more versatile once you get used to them.
In some cases, you can get around no-first-class-identifiers in Python by using strings and getattr(object, symbol) or locals()[symbol]. (What are other use cases of first-class identifiers, other than making some function arguments or macros look prettier?)
> Peter bravely repeated his claim that Python is a Lisp.
> Yes, John?" Peter said.
> I won't pretend to remember Lisp inventor John McCarthy's exact words which is odd because there were only about ten but he simply asked if Python could gracefully manipulate Python code as data.
> "No, John, it can't," said Peter and nothing more, graciously assenting to the professor's critique, and McCarthy said no more though Peter waited a moment to see if he would and in the silence a thousand words were said.
http://smuglispweeny.blogspot.pe/2008/02/ooh-ooh-my-turn-why...
You are completely missing the point. Not having identifiers be first-class objects with unique identity is how Python ended up being unable to reload code properly.
I am very experienced and proficient with Python. Common Lisp goes way, way beyond what Python brings to the table. Take CLOS for example and compare it with Python's OOP facilities. CLOS is light years ahead.
Another differences (among many): Python is a high-level language. In CL, you can be high level and low level at the same time. For example, in CL you can disassemble your code to machine language and apply optimization directives and declarations to produce the shortest code, which can approach C speeds if done right.
That said, I still like Python a lot.
>Python is basically simplified Lisp.
... and I thank you for this phrase, perhaps I can use it whenever I need to justify my usage of Common Lisp at my workplace.
Thankfully we have now Julia, as yet another Algol-Lisp attempt.
This video was awesome, and entertaining as well, Mr. Tarballs-are-good/Symbol1cs/Stylewarning ("stylewarning" as a twitter ID made me ROFL). In particular, the comparison between calligraphy and Lisp programming was a very good one.
I've sent you a LinkedIn request, by the way. I'm the bald one in business suit.
If you 'let people discover the truth' then you get a person who reads a couple chapters of SICP when they're 16, thinks they know Lisp, dismisses it as a cool idea language but not practical (compared to the more familiar and productive Python, Java, PHP..), and maybe just maybe ~10 years later they see an example like https://news.ycombinator.com/item?id=12222404 and say "I never knew Lisp, what have I missed out on?" But they could have been told what they were missing out on in the beginning! "Condescending Smug Lisp Weenies" may be Lisp Enemy #1, but I think Enemy #2, not far behind, is probably "People who think they know Lisp, but actually don't, write it off due to incorrect assumptions".
That said, I do think there's a certain something common to Lisp and Python that draws people to use both. e.g. Norvig. I think his page at https://norvig.com/python-lisp.html is a pretty balanced comparison.
Stanza feels like a Lisp with infix syntax. The closeness to Lisp explains why Stanza makes a semantic difference between "f(x)" (which is a function application) and "f (x)" which is a sequence of two elements (f and x). Unlike Nim which is strongly typed, Stanza allows to mix typed and untyped data freely.
[1] lbstanza.org
[2] nim-lang.org