• it seems like a few weeks ago... but actually it was more like 30 years

    From Hen Hanna@21:1/5 to All on Wed Feb 22 12:37:30 2023
    it seems like a few weeks ago... but
    actually it was more like 30 years ago
    that i was programming in C, and

    i'd get
    [Segmentation Fault] (core dumped)
    [Bus Error] (core dumped)
    [access violation] (core dumped)
    [bad address]

    and, yes, some of us sometimes analyzed the core file.



    i (vaguely) fantasized that someday programming would be much more pleasant ---------- and that programming language would be something like Common Lisp with a more Algol, Pascal (C) like syntax.


    i've been using Python for 3,4 years and ..............

    for the first several weeks... whenever i used Python... all i could think of....was -------- this is really Lisp (inside) with a thin veil of Java/Pascal syntax..........

    ----- that everything is first converted (macro-expanded) into (intermediated) Lisp code, and then.........

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Greg Ewing@21:1/5 to Hen Hanna on Thu Feb 23 19:37:37 2023
    On 23/02/23 9:37 am, Hen Hanna wrote:
    for the first several weeks... whenever i used Python... all i could think of....was -------- this is really Lisp (inside) with a thin veil of Java/Pascal syntax..........

    ----- that everything is first converted (macro-expanded) into (intermediated) Lisp code, and then.........

    I once toyed with the idea of implementing a Python compiler
    by translating it into Scheme and then feeding it to a Scheme
    compiler.

    But I quickly realised that, although Scheme and Python are
    both dynamically-typed languages, Python is way *more* dynamic
    than Scheme.

    So without doing some very serious static analysis, the best
    I could do would be just putting together calls to runtime
    support routines that implement all the dynamic dispatching
    that Python does for its operators, etc., and the result
    wouldn't be much better than an interpreter.

    There are some similarities between Python and Lisp-family
    languages, but really Python is its own thing.

    --
    Greg

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stefan Ram@21:1/5 to Greg Ewing on Thu Feb 23 10:35:13 2023
    Greg Ewing <[email protected]> writes:
    I once toyed with the idea of implementing a Python compiler
    by translating it into Scheme and then feeding it to a Scheme
    compiler.

    You can choose the goal to translate Python into "the SICP language".

    Since SICP is being taught in Python today¹, you have achieved it.

    ¹ at least at Berkeley

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Hen Hanna@21:1/5 to Greg Ewing on Sat Feb 25 21:53:12 2023
    On Wednesday, February 22, 2023 at 10:38:00 PM UTC-8, Greg Ewing wrote:
    On 23/02/23 9:37 am, Hen Hanna wrote:
    for the first several weeks... whenever i used Python... all i could think of....was -------- this is really Lisp (inside) with a thin veil of Java/Pascal syntax..........

    ----- that everything is first converted (macro-expanded) into (intermediated) Lisp code, and then.........
    I once toyed with the idea of implementing a Python compiler
    by translating it into Scheme and then feeding it to a Scheme
    compiler.

    But I quickly realised that, although Scheme and Python are
    both dynamically-typed languages, Python is way *more* dynamic
    than Scheme.

    So without doing some very serious static analysis, the best
    I could do would be just putting together calls to runtime
    support routines that implement all the dynamic dispatching
    that Python does for its operators, etc., and the result
    wouldn't be much better than an interpreter.

    There are some similarities between Python and Lisp-family
    languages, but really Python is its own thing.

    --
    Greg



    Scope (and extent ?) of variables is one reminder that Python is not Lisp

         for i in range(5):   print( i )
    .........
         print( i )

    ideally, after the FOR loop is done, the (local) var i should also disappear. (this almost caused a bug for me)


    Maybe in a future ver. of Python, it will be just like:

    (dotimes  (i 5)  (print i))

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Roel Schroeven@21:1/5 to All on Mon Feb 27 09:51:18 2023
    Op 26/02/2023 om 6:53 schreef Hen Hanna:
    There are some similarities between Python and Lisp-family
    languages, but really Python is its own thing.


    Scope (and extent ?) of variables is one reminder that Python is not Lisp

         for i in range(5):   print( i )
    .........
         print( i )

    ideally, after the FOR loop is done, the (local) var i should also disappear.
    (this almost caused a bug for me)
    I wouldn't say "i *should* also disappear". There is no big book of
    programming language design with rules like that that all languages have
    to follow. Different languages have different behavior. In some
    languages, for/if/while statements introduce a new scope, in other
    languages they don't. In Python, they don't. I won't say one is better
    than the other; they're just different.

    --
    "Most of us, when all is said and done, like what we like and make up
    reasons for it afterwards."
    -- Soren F. Petersen

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From inhahe@21:1/5 to [email protected] on Mon Feb 27 04:05:56 2023
    On Mon, Feb 27, 2023 at 3:56 AM inhahe <[email protected]> wrote:



    On Mon, Feb 27, 2023 at 3:52 AM Roel Schroeven <[email protected]> wrote:

    Op 26/02/2023 om 6:53 schreef Hen Hanna:
    There are some similarities between Python and Lisp-family
    languages, but really Python is its own thing.


    Scope (and extent ?) of variables is one reminder that Python is
    not Lisp

    for i in range(5): print( i )
    .........
    print( i )

    ideally, after the FOR loop is done, the (local) var i should also
    disappear.
    (this almost caused a bug for me)
    I wouldn't say "i *should* also disappear". There is no big book of
    programming language design with rules like that that all languages have
    to follow. Different languages have different behavior. In some
    languages, for/if/while statements introduce a new scope, in other
    languages they don't. In Python, they don't. I won't say one is better
    than the other; they're just different.

    --


    I'm not sure, but I think I remember this was actually a bug in the interpreter, and presumably they didn't fix it because they didn't want to break backward compatibility?


    Maybe I'm thinking of a variable scope leak after list comprehensions.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From inhahe@21:1/5 to All on Mon Feb 27 03:56:22 2023
    On Mon, Feb 27, 2023 at 3:52 AM Roel Schroeven <[email protected]> wrote:

    Op 26/02/2023 om 6:53 schreef Hen Hanna:
    There are some similarities between Python and Lisp-family
    languages, but really Python is its own thing.


    Scope (and extent ?) of variables is one reminder that Python is
    not Lisp

    for i in range(5): print( i )
    .........
    print( i )

    ideally, after the FOR loop is done, the (local) var i should also
    disappear.
    (this almost caused a bug for me)
    I wouldn't say "i *should* also disappear". There is no big book of programming language design with rules like that that all languages have
    to follow. Different languages have different behavior. In some
    languages, for/if/while statements introduce a new scope, in other
    languages they don't. In Python, they don't. I won't say one is better
    than the other; they're just different.

    --


    I'm not sure, but I think I remember this was actually a bug in the interpreter, and presumably they didn't fix it because they didn't want to break backward compatibility?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Roel Schroeven@21:1/5 to All on Mon Feb 27 10:07:54 2023
    Op 27/02/2023 om 9:56 schreef inhahe:
    On Mon, Feb 27, 2023 at 3:52 AM Roel Schroeven <[email protected]> wrote:

    Op 26/02/2023 om 6:53 schreef Hen Hanna:
    There are some similarities between Python and Lisp-family
    languages, but really Python is its own thing.


    Scope (and extent ?) of variables is one reminder that Python is
    not Lisp

    for i in range(5): print( i )
    .........
    print( i )

    ideally, after the FOR loop is done, the (local) var i should also
    disappear.
    (this almost caused a bug for me)
    I wouldn't say "i *should* also disappear". There is no big book of programming language design with rules like that that all languages have
    to follow. Different languages have different behavior. In some
    languages, for/if/while statements introduce a new scope, in other languages they don't. In Python, they don't. I won't say one is better
    than the other; they're just different.

    --


    I'm not sure, but I think I remember this was actually a bug in the interpreter, and presumably they didn't fix it because they didn't want to break backward compatibility?
    I'm guessing you're thinking about variables leaking out of list comprehensions. I seem to remember (but I could be wrong) it was a
    design mistake rather than a bug in the code, but in any case it's been
    fixed now (in the 2 to 3 transition, I think).

    For loops (and while loops, and if statements) not introducing a new
    scope is a deliberate decision and is not subject to change.

    --
    "Ever since I learned about confirmation bias, I've been seeing
    it everywhere."
    -- Jon Ronson

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Greg Ewing@21:1/5 to Roel Schroeven on Tue Feb 28 01:41:07 2023
    On 27/02/23 10:07 pm, Roel Schroeven wrote:
    I'm guessing you're thinking about variables leaking out of list comprehensions. I seem to remember (but I could be wrong) it was a
    design mistake rather than a bug in the code, but in any case it's been
    fixed now (in the 2 to 3 transition, I think).

    The semantics of list comprehensions was originally defined
    in terms of nested for loops. A consequence was that the loop
    variables ended up in the local scope just as with ordinary for
    loops. Later it was decided to change that.

    --
    Greg

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [email protected]@21:1/5 to All on Mon Feb 27 13:40:42 2023
    I am not a big fan of religions or philosophies that say a road to salvation is for the "I" to disappear.

    But on a more serious note, as Roel said, there is NO RULE being violated unless the documentation of the language says it is supposed to do something different.

    There are many excellent reasons to keep the final value of a loop variable around. On the other hand, there are also many good reasons to make such variables be totally kept within the context of the loop so they can mask a variable with the same name
    only temporarily within the loop.

    Neither choice is wrong as long as it is applied consistently.

    Now, having said that, does python allow you to in some way over-ride the behavior?

    Well, first, you can simply choose an odd name like local______loopy___variable that is not used elsewhere in your code, except perhaps in the next loop downstream where it is re-initialized.

    You can also use "del Variable" or reset it to null or something in every way you can exit the loop such as before a break or in an "else" clause if it bothers you.

    inhahe <[email protected]> made the point that this may not have been the original intent for python and may be a sort of bug that it is too late to fix. Perhaps so, but insisting it be changed now is far from a simple request as I bet some people depend
    on the feature. True, it could be straightforward to recode any existing loops to update a secondary variable at the top of each loop that is declared before the loop and persists after the loop.

    Alas, that might force some to use the dreaded semicolon!

    Final note is to look at something like the "with" statement in python as a context manager where it normally allows the resource to be closed or removed at the end. Of course you can set up an object that does not do the expected closure and preserves
    something, but generally what is wanted is to make sure the context exits gracefully.

    Avi

    -----Original Message-----
    From: Python-list <python-list-bounces+avi.e.gross=[email protected]> On Behalf Of Roel Schroeven
    Sent: Monday, February 27, 2023 3:51 AM
    To: [email protected]
    Subject: Re: it seems like a few weeks ago... but actually it was more like 30 years ago that i was programming in C, and

    Op 26/02/2023 om 6:53 schreef Hen Hanna:
    There are some similarities between Python and Lisp-family
    languages, but really Python is its own thing.


    Scope (and extent ?) of variables is one reminder that Python is not Lisp

         for i in range(5):   print( i )
    .........
         print( i )

    ideally, after the FOR loop is done, the (local) var i should also disappear.
    (this almost caused a bug for me)
    I wouldn't say "i *should* also disappear". There is no big book of programming language design with rules like that that all languages have to follow. Different languages have different behavior. In some languages, for/if/while statements introduce a
    new scope, in other languages they don't. In Python, they don't. I won't say one is better than the other; they're just different.

    --
    "Most of us, when all is said and done, like what we like and make up reasons for it afterwards."
    -- Soren F. Petersen

    --
    https://mail.python.org/mailman/listinfo/python-list

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Greg Ewing@21:1/5 to [email protected] on Tue Feb 28 12:48:40 2023
    On 28/02/23 7:40 am, [email protected] wrote:
    inhahe <[email protected]> made the point that this may not have been the original intent for python and may be a sort of bug that it is too late to fix.

    Guido has publically stated that it was a deliberate design choice.
    The merits of that design choice can be debated, but it wasn't a
    bug or an accident.

    --
    Greg

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [email protected]@21:1/5 to [email protected] on Mon Feb 27 19:08:28 2023
    Yes, Greg, you are correct. After I posted, I encountered a later message
    that suggested it was list comprehensions that had accidentally left a
    variable behind in a context when theoretically you got ALL you asked for in the resulting list, so it fixed eventually.

    You live and learn till you don't.


    -----Original Message-----
    From: Python-list <python-list-bounces+avi.e.gross=[email protected]> On Behalf Of Greg Ewing via Python-list
    Sent: Monday, February 27, 2023 6:49 PM
    To: [email protected]
    Subject: Re: it seems like a few weeks ago... but actually it was more like
    30 years ago that i was programming in C, and

    On 28/02/23 7:40 am, [email protected] wrote:
    inhahe <[email protected]> made the point that this may not have been the
    original intent for python and may be a sort of bug that it is too late to
    fix.

    Guido has publically stated that it was a deliberate design choice.
    The merits of that design choice can be debated, but it wasn't a bug or an accident.

    --
    Greg
    --
    https://mail.python.org/mailman/listinfo/python-list

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)