RE: it seems like a few weeks ago... but actually it was more like 30 years ago that i was programming in C, and
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 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.gr...@gmail.com wrote: > inhahe 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
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.gr...@gmail.com wrote: inhahe 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
RE: it seems like a few weeks ago... but actually it was more like 30 years ago that i was programming in C, and
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 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 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 > > fori 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
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 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
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 27/02/2023 om 9:56 schreef inhahe: On Mon, Feb 27, 2023 at 3:52 AM Roel Schroeven 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 > > > > fori 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
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 Mon, Feb 27, 2023 at 3:56 AM inhahe wrote: > > > On Mon, Feb 27, 2023 at 3:52 AM Roel Schroeven > 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 >> > >> > fori 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
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 Mon, Feb 27, 2023 at 3:52 AM Roel Schroeven 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 > > > > fori 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
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 fori 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
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 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 > > ofwas 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 fori 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
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 23/02/23 9:37 am, Hen Hanna wrote: for the first several weeks... whenever i used Python... all i could think ofwas 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 -- https://mail.python.org/mailman/listinfo/python-list
