Sujet : Re: Lprint = ( Lisp-style printing ( of lists and strings (etc.) ) in Python )
De : sebastian (at) *nospam* here.com.invalid (Sebastian Wells)
Groupes : comp.lang.python comp.lang.lisp comp.lang.schemeDate : 24. Jun 2024, 06:38:07
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <v5b0nv$7182$2@dont-email.me>
References : 1
User-Agent : Pan/0.154 (Izium; 517acf4)
On Thu, 30 May 2024 21:47:14 -0700, HenHanna wrote:
;;; Pls tell me about little tricks you use in Python or Lisp.
[('the', 36225), ('and', 17551), ('of', 16759), ('i', 16696), ('a',
15816), ('to', 15722), ('that', 11252), ('in', 10743), ('it', 10687)]
((the 36225) (and 17551) (of 16759) (i 16696) (a 15816) (to 15722) (that
11252) (in 10743) (it 10687))
The direct Lispification of the original expression would probably be
something like this:
#(#("the" 36225) #("and" 17551) #("of" 16759)
#("i" 16696) #("a" 15816))
..etc, taking into account that Python "lists" are really
arrays, and there's no real Lisp equivalent to tuples,
but they're essentially arrays also. And there's a distinction
between strings and symbols in Lisp that could be approximated
in Python by defining an empty class for each desired symbol.
But since strings are used in the Python example, they should
be used in the Lisp one, too.
That written, there's not much benefit in doing this in a Python
program, and you actually lose one of the advantages you started
out with: Like Lisp, the Python syntax is readable Python. Unlike
Lisp, there's no reader that will give you the original structure
from its string representation without having to also evaluate it
as code. Lispifying it doesn't bring that advantage unless you
also implement a reader, and even then you might be better off
convincing some insider to endorse a Python analogue to JSON. But
that insider would probably tell you to use JSON, ignoring
the lack of distinct array/tuple types in JSON, or he'd tell you
to use Pickle, ignoring the fact that it's a binary format.
Norvig was coping big time. He even called Python an "acceptable"
compromise between what Lisp delivers and whatever it is that's
supposed to be good about Python that it didn't directly copy
from Lisp.