Mailing List Archive

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

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

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

On Mon, Feb 27, 2023 at 3:52?AM Roel Schroeven <roel@roelschroeven.net>
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?
--
https://mail.python.org/mailman/listinfo/python-list

On Mon, Feb 27, 2023 at 3:56?AM inhahe <inhahe@gmail.com> wrote:

>
>
> On Mon, Feb 27, 2023 at 3:52?AM Roel Schroeven <roel@roelschroeven.net>
> 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.
--
https://mail.python.org/mailman/listinfo/python-list

Op 27/02/2023 om 9:56 schreef inhahe:
> On Mon, Feb 27, 2023 at 3:52?AM Roel Schroeven <roel@roelschroeven.net>
> 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

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

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
--
https://mail.python.org/mailman/listinfo/python-list

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 <inhahe@gmail.com> 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=gmail.com@python.org> On Behalf Of Roel Schroeven
Sent: Monday, February 27, 2023 3:51 AM
To: python-list@python.org
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

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

On 28/02/23 7:40 am, avi.e.gross@gmail.com wrote:
> inhahe <inhahe@gmail.com> 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

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=gmail.com@python.org> On
Behalf Of Greg Ewing via Python-list
Sent: Monday, February 27, 2023 6:49 PM
To: python-list@python.org
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, avi.e.gross@gmail.com wrote:
> inhahe <inhahe@gmail.com> 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

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