Discussion:
Lprint = ( Lisp-style printing ( of lists and strings (etc.) ) in Python )
(too old to reply)
HenHanna
2024-05-31 04:47:14 UTC
Permalink
;;; 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))


i think the latter is easier-to-read, so i use this code
(by Peter Norvig)

def lispstr(exp):
# "Convert a Python object back into a Lisp-readable string."
if isinstance(exp, list):
return '(' + ' '.join(map(lispstr, exp)) + ')'
else:
return str(exp)

def Lprint(x): print(lispstr(x))
Peter J. Holzer
2024-06-01 08:24:14 UTC
Permalink
[('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))
i think the latter is easier-to-read, so i use this code
(by Peter Norvig)
This doesn't work well if your strings contain spaces:

Lprint(
[
["Just", "three", "words"],
["Just", "three words"],
["Just three", "words"],
["Just three words"],
]
)

prints:

((Just three words) (Just three words) (Just three words) (Just three words))

Output is often a compromise between readability and precision.
# "Convert a Python object back into a Lisp-readable string."
This won't work for your example, since you have a list of tuples, not a
list of lists and a tuple is not an instance of a list.
return '(' + ' '.join(map(lispstr, exp)) + ')'
return str(exp)
def Lprint(x): print(lispstr(x))
I like to use pprint, but it's lacking support for user-defined types. I
should be able to add a method (maybe __pprint__?) to my classes which
handle proper formatting (with line breaks and indentation).

hp
--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | ***@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
Gilmeh Serda
2024-06-04 17:01:37 UTC
Permalink
Newsgroups: comp.lang.python,comp.lang.lisp,comp.lang.scheme
Stupid idea.

*PLONK* + all references to any replies.
--
Gilmeh

Isn't it interesting that the same people who laugh at science fiction
listen to weather forecasts and economists? -- Kelvin Throop III
Sebastian Wells
2024-06-24 05:38:07 UTC
Permalink
Post by HenHanna
;;; 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.

Loading...