variable scope in try ... EXCEPT block.
suppose following code running with Python-3.4.8 and Python-3.6.5
# -*- coding: utf-8 -*-
def hello():
err = None
print('0: {}'.format(locals()))
try:
b = 2
print('1: {}'.format(locals()))
raise ValueError()
print('2: {}'.format(locals()))
except ValueError as err:
print('3: {}'.format(locals()))
pass
print('4: {}'.format(locals()))
return '', err
hello()
got output:
0: {'err': None}
1: {'err': None, 'b': 2}
3: {'err': ValueError(), 'b': 2}
4: {'b': 2}
Traceback (most recent call last):
File "err.py", line 19, in
hello()
File "err.py", line 16, in hello
return '', err
UnboundLocalError: local variable 'err' referenced before assignment
But without this UnboundLocalError with Python-2.7.14
My question is, does except ... as ... create a new scope from outer block,
causing 'err' be hidden from outer scope? Is this intentional?
Thanks.
--
https://mail.python.org/mailman/listinfo/python-list
Re: variable scope in try ... EXCEPT block.
aleiphoenix writes:
> suppose following code running with Python-3.4.8 and Python-3.6.5
>
>
> # -*- coding: utf-8 -*-
>
>
> def hello():
> err = None
> print('0: {}'.format(locals()))
> try:
> b = 2
> print('1: {}'.format(locals()))
> raise ValueError()
> print('2: {}'.format(locals()))
> except ValueError as err:
> print('3: {}'.format(locals()))
> pass
> print('4: {}'.format(locals()))
> return '', err
>
>
> hello()
>
>
>
> got output:
>
> 0: {'err': None}
> 1: {'err': None, 'b': 2}
> 3: {'err': ValueError(), 'b': 2}
> 4: {'b': 2}
> Traceback (most recent call last):
> File "err.py", line 19, in
> hello()
> File "err.py", line 16, in hello
> return '', err
> UnboundLocalError: local variable 'err' referenced before assignment
>
>
> But without this UnboundLocalError with Python-2.7.14
>
>
> My question is, does except ... as ... create a new scope from outer
> block, causing 'err' be hidden from outer scope? Is this intentional?
Yes, it's intentional, but it's not exactly a scope. In
https://docs.python.org/3/reference/compound_stmts.html#try
you will find:
When an exception has been assigned using as target, it is cleared at
the end of the except clause. This is as if
except E as N:
foo
was translated to
except E as N:
try:
foo
finally:
del N
This means the exception must be assigned to a different name to be
able to refer to it after the except clause. Exceptions are cleared
because with the traceback attached to them, they form a reference
cycle with the stack frame, keeping all locals in that frame alive
until the next garbage collection occurs.
This appears to be a change from Python 2. That wording is not present
in
https://docs.python.org/2/reference/compound_stmts.html#try
--
Ben.
--
https://mail.python.org/mailman/listinfo/python-list
Re: variable scope in try ... EXCEPT block.
On Thu, 12 Jul 2018 01:37:24 -0700, aleiphoenix wrote:
> My question is, does except ... as ... create a new scope from outer
> block, causing 'err' be hidden from outer scope? Is this intentional?
No, it is not a new scope, and yes, it is intentional. It's a nasty hack,
but a *necessary* nasty hack: when the except block exits, the "err"
local variable (or whatever it happens to be called) is implicitly
deleted.
You can work around this by explicitly assigning to another local
variable:
try:
...
except Exception as e:
err = e # only "e" will be deleted when we exit the block
This is necessary in Python 3 (but not Python 2) because exception
objects form a reference cycle with something (the traceback?) which is a
big, heavyweight object. Allowing random exception objects to stay alive
for long periods was consuming unacceptable amounts of memory, so it was
decided to hit this problem with a hammer and fix it in the simplest,
although least elegant, way: just delete the exception when leaving the
except block.
You can see the disassembled byte-code here. Here's the output from
Python 3.5:
py> dis.dis("try: pass\nexcept Exception as err: pass")
1 0 SETUP_EXCEPT 4 (to 7)
3 POP_BLOCK
4 JUMP_FORWARD37 (to 44)
2 >>7 DUP_TOP
8 LOAD_NAME0 (Exception)
11 COMPARE_OP 10 (exception match)
14 POP_JUMP_IF_FALSE 43
17 POP_TOP
18 STORE_NAME 1 (err)
21 POP_TOP
22 SETUP_FINALLY5 (to 30)
25 POP_BLOCK
26 POP_EXCEPT
27 LOAD_CONST 0 (None)
>> 30 LOAD_CONST 0 (None)
33 STORE_NAME 1 (err)
36 DELETE_NAME 1 (err)
39 END_FINALLY
40 JUMP_FORWARD 1 (to 44)
>> 43 END_FINALLY
>> 44 LOAD_CONST 0 (None)
47 RETURN_VALUE
--
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson
--
https://mail.python.org/mailman/listinfo/python-list
Re: Feasibility of console based (non-Gui) Tkinter app which can accept keypresses?
Hi All thanks for the comments and confirmation that this is not really possible in a Tkinter environment. I had thought of using ncurses but was shying clear of learning about another set of widgets etc. just now. The output of the simulator is simple enough that it could just accept simple keystrokes for control, and every second or so there will be an output string saying what is happening - a sort of concatenation of the various output widgets in the Tkinter-based version. I have hoped to keep this text view so similar to the Tkinter one that it was using the same mechanisms (after(), Tk keyevents etc). Instead I think I will just write a simple mainloop() which is 'inspired by' Tkinter. I could then look at adding ncurses as a third alternative. Thanks again J^n -- https://mail.python.org/mailman/listinfo/python-list
Re: variable scope in try ... EXCEPT block.
On 2018-07-12 10:59, Steven D'Aprano wrote: > On Thu, 12 Jul 2018 01:37:24 -0700, aleiphoenix wrote: > >> My question is, does except ... as ... create a new scope from outer >> block, causing 'err' be hidden from outer scope? Is this intentional? > > No, it is not a new scope, and yes, it is intentional. It's a nasty hack, > but a *necessary* nasty hack: when the except block exits, the "err" > local variable (or whatever it happens to be called) is implicitly > deleted. > > You can work around this by explicitly assigning to another local > variable: > > try: > ... > except Exception as e: > err = e # only "e" will be deleted when we exit the block > > > This is necessary in Python 3 [...] "necessary" is debatable. When we have reference counting, general garbage collection, *and* nasty hacks like this, one could be forgiven for thinking Python has chosen the worst of all memory-management worlds. That said, in this case it's entirely livable-with once one knows about it. Unrelatedly, having stared at this email for a moment, I really wish Thunderbird had an option to avoid orphan words Ed -- https://mail.python.org/mailman/listinfo/python-list
Re: variable scope in try ... EXCEPT block.
On Thu, Jul 12, 2018 at 10:31 PM, Ed Kellett wrote: > On 2018-07-12 10:59, Steven D'Aprano wrote: >> On Thu, 12 Jul 2018 01:37:24 -0700, aleiphoenix wrote: >> >>> My question is, does except ... as ... create a new scope from outer >>> block, causing 'err' be hidden from outer scope? Is this intentional? >> >> No, it is not a new scope, and yes, it is intentional. It's a nasty hack, >> but a *necessary* nasty hack: when the except block exits, the "err" >> local variable (or whatever it happens to be called) is implicitly >> deleted. >> >> You can work around this by explicitly assigning to another local >> variable: >> >> try: >> ... >> except Exception as e: >> err = e # only "e" will be deleted when we exit the block >> >> >> This is necessary in Python 3 [...] > > "necessary" is debatable. When we have reference counting, general > garbage collection, *and* nasty hacks like this, one could be forgiven > for thinking Python has chosen the worst of all memory-management worlds. I don't understand you. Are you saying that there are other memory management systems that are perfect, without any tradeoffs? Because the problem here is a reference cycle thus: >>> def f(): ... try: 1/0 ... except Exception as e: print(e is e.__traceback__.tb_frame.f_locals["e"]) ... >>> f() True Dealing with reference cycles is generally done *periodically* rather than immediately (CPython disposes of unreferenced objects immediately upon last deref). You can avoid having a dedicated cycle detection pass by using a mark-and-sweep GC, but that just means that *all* garbage is dealt with periodically rather than immediately. I can imagine having some sort of flag on every object that's involved in a cycle, and then doing a mini-GC every time any of those objects gets any dereferencing, but that would be ridiculously expensive. There are ALWAYS tradeoffs. How is Python's arrangement "the worst"? Personally, I think this would be better with an *actual* subscope. But apparently that's a ridiculously insane suggestion with no chance whatsoever of being accepted. Kinda like assignment expressions. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: variable scope in try ... EXCEPT block.
On 2018-07-12 14:03, Chris Angelico wrote: > Dealing with reference cycles is generally done *periodically* rather > than immediately (CPython disposes of unreferenced objects immediately > upon last deref). You can avoid having a dedicated cycle detection > pass by using a mark-and-sweep GC, but that just means that *all* > garbage is dealt with periodically rather than immediately. I can > imagine having some sort of flag on every object that's involved in a > cycle, and then doing a mini-GC every time any of those objects gets > any dereferencing, but that would be ridiculously expensive. There are > ALWAYS tradeoffs. How is Python's arrangement "the worst"? It pays the cost of a reference counter and a garbage collector and the language designers *still* feel like they have to add weird hacks like the implicit del. I agree there are always tradeoffs. But it feels like Python has made tradeoffs that should allow it to never worry about cycles ever, and then it goes ahead and worries about cycles anyway. > Personally, I think this would be better with an *actual* subscope. > But apparently that's a ridiculously insane suggestion with no chance > whatsoever of being accepted. Kinda like assignment expressions. FWIW, I'd vastly prefer some kind of reconsidering of the scoping approach to assignment expressions. I don't want to have a 1th iteration of the same old argument about them, but I think subscoping is way more applicable: at least to me, it'd make all code more readable by default, because it'd tend to make namespaces emptier and therefore easier to hold in memory. Could we fix: for x in something: blah(lambda a: a + x) while we're at it? Also, since we're well into the realm of crazy here, when are we making nonlocal the default? Ed -- https://mail.python.org/mailman/listinfo/python-list
EuroPython 2018: Call for On-site Volunteers
Ever wanted to help out during Europython ? Do you want to *really* take part in EuroPython, meet new people and help them at the same time ? We have just the right thing for you: apply as EuroPython Volunteer and be part of the great team that is making EuroPython 2018 a reality this year. EuroPython Volunteers - Glad you want to help ! Please see our volunteers page for details on how to sign up: * EuroPython 2018 Volunteers * https://ep2018.europython.eu/en/registration/volunteers/ We are using a volunteer management app for the organization and a Telegram group for communication. https://ep2018.europython.eu/volunteer-app We have a few exciting tasks to offer such as helping out setting up and tearing down the conference space, giving out goodie bags and t-shirts, and being at the conference desk to answer all questions about EuroPython, session chairing or helping as room manager. We also have some perks for you, to give something back. Please check our volunteers page for details. Hope to see you there ! Help spread the word Please help us spread this message by sharing it on your social networks as widely as possible. Thank you ! Link to the blog post: https://blog.europython.eu/post/175814086737/europython-2018-call-for-on-site-volunteers Tweet: https://twitter.com/europython/status/1017407947134066689 Enjoy, -- EuroPython 2018 Team https://ep2018.europython.eu/ https://www.europython-society.org/ -- https://mail.python.org/mailman/listinfo/python-list
EuroPython 2018: Conference App available
We are pleased to announce the conference app for EuroPython 2018, again hosted on the Attendify platform: * EuroPython 2018 Conference App * https://ep2018.europython.eu/en/events/conference-app/ Engage with the conference and its attendees The mobile app gives you access to the conference schedule (even offline), helps you in planing your conference experience (create your personal schedule with reminders) and provides a rich social engagement platform for all attendees. You can create a profile within the app or link this to your existing social accounts, share messages and photos, and easily reach out to other fellow attendees - all from within the app. Vital for all EuroPython 2018 attendees --- We will again use the conference app to keep you updated by sending updates of the schedule and inform you of important announcements via push notifications, so please consider downloading it. Many useful features Please see our EuroPython 2018 Conference App page for more details on features and guides on how to use them. https://ep2018.europython.eu/en/events/conference-app/ Don’t forget to get your EuroPython ticket -- If you want to join the EuroPython fun, be sure to get your tickets as soon as possible, since ticket sales have picked up a lot this and we may have to close sales prior to the event. Help spread the word Please help us spread this message by sharing it on your social networks as widely as possible. Thank you ! Link to the blog post: https://blog.europython.eu/post/175817504647/europython-2018-conference-app-available Tweet: https://twitter.com/europython/status/1017444062306193409 Enjoy, -- EuroPython 2018 Team https://ep2018.europython.eu/ https://www.europython-society.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: variable scope in try ... EXCEPT block.
On Thu, Jul 12, 2018 at 11:23 PM, Ed Kellett wrote: > Could we fix: > > for x in something: > blah(lambda a: a + x) > > while we're at it? What do you mean by "fix"? Make the 'x' bind eagerly? That would break basically every other use of closures. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Python 3.6 can find cairo libs but not Python 2.7
$ python2.7 -c "import ctypes.util;
print(ctypes.util.find_library('cairo'))"
libcairo.so.2
$ python3.6 -c "import ctypes.util;
print(ctypes.util.find_library('cairo'))"
None
I have the 3.6 version of py-cairo installed. Any thoughts?
NetBSD 7.1.2
Cheers.
--
D'Arcy J.M. Cain
System Administrator, Vex.Net
http://www.Vex.Net/ IM:da...@vex.net
VoIP: sip:da...@vex.net
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.6 can find cairo libs but not Python 2.7
On 7/12/2018 3:52 PM, D'Arcy Cain wrote:
$ python2.7 -c "import ctypes.util;
print(ctypes.util.find_library('cairo'))"
libcairo.so.2
$ python3.6 -c "import ctypes.util;
print(ctypes.util.find_library('cairo'))"
None
I have the 3.6 version of py-cairo installed. Any thoughts?
NetBSD 7.1.2
what is sys.path? Where in py-cairo installed?
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
Re: variable scope in try ... EXCEPT block.
On Thursday, July 12, 2018 at 5:45:52 AM UTC-4, Ben Bacarisse wrote: > aleiphoenix writes: > > [snip] > > When an exception has been assigned using as target, it is cleared at > the end of the except clause. This is as if > > except E as N: > foo > > was translated to > > except E as N: > try: > foo > finally: > del N Is there a downside of implementing it similarly to this (untested): # generate a unique name for __except_N except E as __except_N: if 'N' in locals() or N in globals(): __original_N = N N = __except_N try: foo() finally: del __except_N if '__original_N' in locals(): N = __original_N del __original_N else: del N Regards, Igor. -- https://mail.python.org/mailman/listinfo/python-list
Guido van Rossum resigns as Python leader
Yes, you read that right: Guido van Rossum resigns as Python leader. See his mail: (https://mail.python.org/pipermail/python-committers/2018-July/005664.html) Now that PEP 572 is done, I don't ever want to have to fight so hard > for a PEP and find that so many people despise my decisions. I would like to remove myself entirely from the decision process. I'll still be there for a while as an ordinary core dev, and I'll still be available to mentor people -- possibly more available. But I'm basically giving myself a permanent vacation from being BDFL, and you all will be on your own. After all that's eventually going to happen regardless -- there's still that bus lurking around the corner, and I'm not getting younger... (I'll spare you the list of medical issues.) I am not going to appoint a successor. So what are you all going to do? Create a democracy? Anarchy? A > dictatorship? A federation? I'm not worried about the day to day decisions in the issue tracker or on GitHub. Very rarely I get asked for an opinion, and usually it's > not actually important. So this can just be dealt with as it has > always been. The decisions that most matter are probably > - How are PEPs decided > - How are new core devs inducted We may be able to write up processes for these things as PEPs (maybe > those PEPs will form a kind of constitution). But here's the catch. > I'm going to try and let you all (the current committers) figure it > out for yourselves. Note that there's still the CoC -- if you don't like that document your only option might be to leave this group voluntarily. Perhaps there are issues to decide like when should someone be kicked out (this could be banning people from python-dev or python-ideas too, since those are also covered by the CoC). Finally. A reminder that the archives of this list are public ( https://mail.python.org/pipermail/python-committers/) although > membership is closed (limited to core devs). I'll still be here, but I'm trying to let you all figure something out for yourselves. I'm tired, and need a very long break. > -- --Guido van Rossum (python.org/~guido) -- "Honest criticism is hard to take, particularly from a relative, a friend, an acquaintance, or a stranger." -- Franklin P. Jones Roel Schroeven -- https://mail.python.org/mailman/listinfo/python-list
Re: variable scope in try ... EXCEPT block.
Just word on quoting... codewiz...@gmail.com writes: > On Thursday, July 12, 2018 at 5:45:52 AM UTC-4, Ben Bacarisse wrote: >> >> [snip] You cut everything I wrote. What you left is what I quoted from the Python documentation. In fairness to the authors you should probably have cut the attribution line and left the URL I posted. -- Ben. -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido van Rossum resigns as Python leader
if linux boasts commits, python boasts community in any sphere, the human aspect of things reoccurs. python has not it's parallel in languages, for it has set up the pattern for rapid and effective amelioration besides those words, the core-devs said all what i had to say leader or not, you remain a steering guide Abdur-Rahmaan Janhangeer https://github.com/Abdur-rahmaanJ > > -- https://mail.python.org/mailman/listinfo/python-list
Re: variable scope in try ... EXCEPT block.
On Fri, Jul 13, 2018 at 8:10 AM, wrote:
> On Thursday, July 12, 2018 at 5:45:52 AM UTC-4, Ben Bacarisse wrote:
>> aleiphoenix writes:
>>
>> [snip]
>>
>> When an exception has been assigned using as target, it is cleared at
>> the end of the except clause. This is as if
>>
>> except E as N:
>> foo
>>
>> was translated to
>>
>> except E as N:
>> try:
>> foo
>> finally:
>> del N
>
> Is there a downside of implementing
> it similarly to this (untested):
>
> # generate a unique name for __except_N
> except E as __except_N:
> if 'N' in locals() or N in globals():
> __original_N = N
>
> N = __except_N
> try:
> foo()
> finally:
> del __except_N
>
> if '__original_N' in locals():
> N = __original_N
> del __original_N
> else:
> del N
Not sure, but here's a simpler implementation:
except Exception as .err.0:
print(.err.0)
.err.0 = None
del .err.0
In other words, exactly the same as the current behaviour, except that
(sorry, pun intended) inside the block, the name is modified to
something that can't actually be used. (The token ".err.0" functions
like an actual local name, just one that's syntactically invalid and
thus cannot ever conflict.) Once you exit the except block, the
previous value will magically reappear, because it didn't go anywhere.
Multiple except blocks - nested or separate - would have separate
names (".err.1", ".err.2"), so they won't conflict with each other.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.6 can find cairo libs but not Python 2.7
D'Arcy Cain wrote:
> $ python2.7 -c "import ctypes.util;
> print(ctypes.util.find_library('cairo'))"
> libcairo.so.2
> $ python3.6 -c "import ctypes.util;
> print(ctypes.util.find_library('cairo'))"
> None
>
> I have the 3.6 version of py-cairo installed. Any thoughts?
>
> NetBSD 7.1.2
Wild guess: one Python is 64 bit and the other is 32 bit, and you have only
one version of the library installed.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Guido van Rossum resigns as Python leader
On 2018-07-12 23:20, Roel Schroeven wrote: Yes, you read that right: Guido van Rossum resigns as Python leader. See his mail: (https://mail.python.org/pipermail/python-committers/2018-July/005664.html) [snip] That's very sad news. I believe the usual practice in a dictatorship is for the eldest child to take over. BTW, I've identified some places in the code for the regex module where I'll be able to make use of := when the time comes... -- https://mail.python.org/mailman/listinfo/python-list
Re: variable scope in try ... EXCEPT block.
On Thursday, July 12, 2018 at 5:45:52 PM UTC+8, Ben Bacarisse wrote: > > Yes, it's intentional, but it's not exactly a scope. In > > https://docs.python.org/3/reference/compound_stmts.html#try > > -- > Ben. Thank you for the reply. Never thought of this kind of problem in Python3. On Thursday, July 12, 2018 at 6:02:27 PM UTC+8, Steven D'Aprano wrote: > > You can work around this by explicitly assigning to another local > variable: > > try: > ... > except Exception as e: > err = e # only "e" will be deleted when we exit the block > I ended up with workaround like this. > This is necessary in Python 3 (but not Python 2) because exception > objects form a reference cycle with something (the traceback?) which is a > big, heavyweight object. Allowing random exception objects to stay alive > for long periods was consuming unacceptable amounts of memory, so it was > decided to hit this problem with a hammer and fix it in the simplest, > although least elegant, way: just delete the exception when leaving the > except block. > > You can see the disassembled byte-code here. Here's the output from > Python 3.5: > > [assembly code] And thanks for the kind answer here. Guest I should dig into Python3 deeper. On Friday, July 13, 2018 at 6:10:57 AM UTC+8, codew...@gmail.com wrote: > > Is there a downside of implementing > it similarly to this (untested): > > # generate a unique name for __except_N > except E as __except_N: > if 'N' in locals() or N in globals(): > __original_N = N > > N = __except_N > try: > foo() > finally: > del __except_N > > if '__original_N' in locals(): > N = __original_N > del __original_N > else: > del N I prefer it like this. Thus, like said Python3 have chosen "fix it in the simplest, although least elegant", I guess. -- https://mail.python.org/mailman/listinfo/python-list
Hey Ranting Rick, this is your moment to shine!
Hey Rick, if you're reading this, now that Guido has resigned, this is your opportunity to declare yourself as the true Heir and take over as BDFL. *runs and hides* Sorry-sometimes-I-can't-help-myself-I-would-have-deleted-this-post-but-I- already-hit-send-ly y'rs, -- Steven D'Aprano -- https://mail.python.org/mailman/listinfo/python-list
Is this a known futurize problem?
I'm using futurize to update the SpamBayes codebase to Python 3. It doesn't seem to properly handle code which already has __future__ imports. When it wants to insert imports, it blindly puts them ahead of the earliest import, even if it happens to be a __future__ import. For example, here's the first diff chunk of spambayes/testtools/timtest.py: diff --git a/spambayes/testtools/timtest.py b/spambayes/testtools/timtest.py index 12eee81..5d8936f 100644 --- a/spambayes/testtools/timtest.py +++ b/spambayes/testtools/timtest.py @@ -31,7 +31,10 @@ If you only want to use some of the messages in each set, In addition, an attempt is made to merge bayescustomize.ini into the options. If that exists, it can be used to change the settings in Options.options. """ +from __future__ import print_function +from builtins import zip +from builtins import range from __future__ import generators import os I'm using version 0.16.0 (which appears to be the latest) with just the -0 and -w flags. Skip -- https://mail.python.org/mailman/listinfo/python-list
Google weirdness
I somehow managed to trigger the dialog below by typing in a certain Python phrase to Google. Anyone know what it's about? It shows up in what appears to be terminal screen. Viz: Google has a code challenge ready for you. Been here before? This invitation will expire if you close this page. Success! You've managed to infiltrate Commander Lambda's evil organization, and finally earned yourself an entry-level position as a Minion on her space station. From here, you just might be able to subvert her plans to use the LAMBCHOP doomsday device to destroy Bunny Planet. Problem is, Minions are the lowest of the low in the Lambda hierarchy. Better buck up and get working, or you'll never make it to the top... For a list of commands type help. To get started with your first challenge type request. foobar:~/ guest$ -- https://mail.python.org/mailman/listinfo/python-list
Re: variable scope in try ... EXCEPT block.
On Thursday, July 12, 2018 at 7:16:48 PM UTC-4, Chris Angelico wrote:
> On Fri, Jul 13, 2018 at 8:10 AM Igor wrote:
> > On Thursday, July 12, 2018 at 5:45:52 AM UTC-4, Ben Bacarisse wrote:
> >> aleiphoenix writes:
> >>
> >> [snip]
> >>
> >> When an exception has been assigned using as target, it is cleared at
> >> the end of the except clause. This is as if
> >>
> >> except E as N:
> >> foo
> >>
> >> was translated to
> >>
> >> except E as N:
> >> try:
> >> foo
> >> finally:
> >> del N
> >
> > Is there a downside of implementing
> > it similarly to this (untested):
> >
> > # generate a unique name for __except_N
> > except E as __except_N:
> > if 'N' in locals() or N in globals():
> > __original_N = N
> >
> > N = __except_N
> > try:
> > foo()
> > finally:
> > del __except_N
> >
> > if '__original_N' in locals():
> > N = __original_N
> > del __original_N
> > else:
> > del N
>
> Not sure, but here's a simpler implementation:
>
> except Exception as .err.0:
> print(.err.0)
> .err.0 = None
> del .err.0
>
> In other words, exactly the same as the current behaviour, except that
> (sorry, pun intended) inside the block, the name is modified to
> something that can't actually be used. (The token ".err.0" functions
> like an actual local name, just one that's syntactically invalid and
> thus cannot ever conflict.) Once you exit the except block, the
> previous value will magically reappear, because it didn't go anywhere.
> Multiple except blocks - nested or separate - would have separate
> names (".err.1", ".err.2"), so they won't conflict with each other.
>
> ChrisA
Simpler is better. The point is that something like this would accomplish both:
1. Break the reference cycle.
2. Avoid what is (IMHO) an unexpected behavior of a variable declared prior to
try/except disappearing after getting shadowed by "except as".
Regards,
Igor.
--
https://mail.python.org/mailman/listinfo/python-list
Re: variable scope in try ... EXCEPT block.
On Fri, Jul 13, 2018 at 2:44 PM, wrote:
> On Thursday, July 12, 2018 at 7:16:48 PM UTC-4, Chris Angelico wrote:
>> Not sure, but here's a simpler implementation:
>>
>> except Exception as .err.0:
>> print(.err.0)
>> .err.0 = None
>> del .err.0
>>
>> In other words, exactly the same as the current behaviour, except that
>> (sorry, pun intended) inside the block, the name is modified to
>> something that can't actually be used. (The token ".err.0" functions
>> like an actual local name, just one that's syntactically invalid and
>> thus cannot ever conflict.) Once you exit the except block, the
>> previous value will magically reappear, because it didn't go anywhere.
>> Multiple except blocks - nested or separate - would have separate
>> names (".err.1", ".err.2"), so they won't conflict with each other.
>>
>> ChrisA
>
> Simpler is better. The point is that something like this would accomplish
> both:
>
> 1. Break the reference cycle.
>
> 2. Avoid what is (IMHO) an unexpected behavior of a variable declared prior
> to try/except disappearing after getting shadowed by "except as".
>
Added bonus: I've already implemented the version I described. So if
you want it, dig around on python-ideas and find where I posted it.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
