;;; 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))

HenHanna <HenHanna@devnull.tb> writes:

> ;;; Pls tell me about little tricks you use in Python or Lisp.
> (...)
>
> 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))

This is a LISP group. Mind I say that Python is not a LISP, in case your
intelligence haven't reached there yet.

Don't post code in unrelated languages. Only LISP code is relevant here.

On Fri, 31 May 2024 13:58:07 +0100, Daniel Cerqueira wrote:

> Mind I say that Python is not a LISP, in case your
> intelligence haven't reached there yet.

Some of us do mind.

On 5/31/2024 5:24 PM, Lawrence D'Oliveiro wrote:
> On Fri, 31 May 2024 13:58:07 +0100, Daniel Cerqueira wrote:
>
>> Mind I say that Python is not a LISP, in case your
>> intelligence haven't reached there yet.
>
> Some of us do mind.

Python is not Lisp, but

( Lisp-style printing ( of lists and strings (etc.) ) in Python )

is Lisp

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.

On Mon, 24 Jun 2024 05:38:07 -0000 (UTC), Sebastian Wells wrote:

> 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.

If that means what I think it means, it’s wrong. You can indeed compile
Python source to AST form without going all the way to bytecode.