tag:blogger.com,1999:blog-3888382143307542639.post8144945872399458155..comments2023-02-02T03:36:20.483+00:00Comments on Lacking Rhoticity: Four Python variable binding odditiesMark Seabornhttp://www.blogger.com/profile/08046205947658697263noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-3888382143307542639.post-69151463883466184702010-12-23T21:15:28.622+00:002010-12-23T21:15:28.622+00:00Also strange (excuse the somewhat convoluted way, ...Also strange (excuse the somewhat convoluted way, but I just wanted to be sure):<br /><br />fs = []<br /><br />i = 0<br />for q in range(2):<br />..f = lambda : i<br />..del i<br />..i = 1<br />..fs.append(f)<br /><br />for f in fs:<br />..print(f())<br /><br />(substitute ".." for space)<br /><br />I'd expect that to print<br />0<br />1<br /><br />But it prints<br />1<br />1<br /><br />... in both Python 2 and Python 3. Weird...<br /><br />A harder-to-understand oneliner would be:<br />[lambda: x for x in range(2)][0]()<br /><br />I would expect that to give 0 but it gives 1.Dannyhttps://www.blogger.com/profile/16778361867510270581noreply@blogger.comtag:blogger.com,1999:blog-3888382143307542639.post-70437121519351121892008-09-21T22:39:00.000+01:002008-09-21T22:39:00.000+01:00@rouli: The reason for the first case is so that v...@rouli: The reason for the first case is so that variables defined in the class are not visible as variables inside methods. See <A HREF="http://mail.python.org/pipermail/python-dev/2000-November/010598.html" REL="nofollow">this post from python-dev</A>.<BR/><BR/>Anything that introduces a new scope ignores the bindings from the class scope. So "lambda" and generators are simply behaving consistently with "def".Mark Seabornhttps://www.blogger.com/profile/08046205947658697263noreply@blogger.comtag:blogger.com,1999:blog-3888382143307542639.post-72514950735500823062008-09-19T21:09:00.000+01:002008-09-19T21:09:00.000+01:00ITT: functional language devotee discovers the wor...ITT: functional language devotee discovers the world doesn't revolve around himAnonymoushttps://www.blogger.com/profile/11442714620753651697noreply@blogger.comtag:blogger.com,1999:blog-3888382143307542639.post-53287657271721366502008-09-19T18:57:00.000+01:002008-09-19T18:57:00.000+01:00Can you explain what's the "good reason" behind th...Can you explain what's the "good reason" behind the first case?<BR/>Coming to Python from other languages (c++), I find it very unintuitive.roulihttps://www.blogger.com/profile/00461875881900424172noreply@blogger.comtag:blogger.com,1999:blog-3888382143307542639.post-11012684885735765792008-08-17T08:24:00.000+01:002008-08-17T08:24:00.000+01:00I think you could avoid the need to rewrite/transf...I think you could avoid the need to rewrite/transform code, and stick to a simple static verifier, with the following trick: forbid all shadowing. If the same variable name appears at multiple scopes, reject the whole Python file, and tell the user "don't do that". Assuming that CapPython is intended for new code (not for neutering piles of legacy code), it seems a simple solution that would should be straightforward for programmers -- unless I'm missing something.<BR/><BR/>I mentioned this to Mark in private email, and Mark points out that for robustness and future-proofing it would be a good idea to treat list comprehensions as if they introduced new scopes, even though they currently do not. I agree: this is a nice improvement on my suggestion.Anonymousnoreply@blogger.com