On Mon, Jan 7, 2019 at 7:18 AM Brett Cannon wrote:
>
> Maybe someone can propose a code comment to explain this instead? I agree
> that this doesn't need to be explained in the language spec, but I don't see
> any harm in a comment where the opcodes are emitted to explain why it is the
> way it
On Sun, 6 Jan 2019 at 10:26, Guido van Rossum wrote:
> On Sun, Jan 6, 2019 at 9:40 AM Paul G wrote:
>
>> I am not familiar enough with the compiler logic, but would it be
>> possible to optimize this away by detecting whether the bound name has
>> already been deleted during the body of the exce
Hello,
On Mon, 7 Jan 2019 01:14:55 +1100
Steven D'Aprano wrote:
[]
> > Thanks, that summarizes it well. And well, my interest is also how
> > non-compliant would be for another Python implementation to act
> > differently, specifically to skip wrapping an except handler body in
> > try-finally
Hello,
On Sun, 6 Jan 2019 17:26:09 +0200
Serhiy Storchaka wrote:
[]
> Because there is a reason for such code.
>
> See issue1631942 [1] and the thread with the subject "self-contained
> exceptions" on the Python-3000 mailing list [2] for the rationale.
>
> In short, the code
>
> try:
>
06.01.19 18:05, Chris Angelico пише:
Which I read, and they do not explain the assignment of None. The only
reference is that the tracker issue mentions having a test case to
ensure that it's happening, which is further proof that it's
intentional, but still fails to explain *why*.
This is expl
On Sun, Jan 6, 2019 at 9:40 AM Paul G wrote:
> I am not familiar enough with the compiler logic, but would it be possible
> to optimize this away by detecting whether the bound name has already been
> deleted during the body of the except statement?
>
As was said before, it's not useful to optim
I am not familiar enough with the compiler logic, but would it be possible to
optimize this away by detecting whether the bound name has already been deleted
during the body of the except statement?
On January 6, 2019 4:18:00 PM UTC, Chris Angelico wrote:
>On Mon, Jan 7, 2019 at 3:13 AM Paul G
On Mon, Jan 7, 2019 at 3:13 AM Paul G wrote:
>
> I think Serhiy is saying that if you delete exc before the except body ends,
> when the compiled code goes to delete it it will fail. Binding to None
> guarantees that there is something to delete.
Ahh! Thank you. I interpreted that example as a
I think Serhiy is saying that if you delete exc before the except body ends,
when the compiled code goes to delete it it will fail. Binding to None
guarantees that there is something to delete.
On January 6, 2019 4:05:27 PM UTC, Chris Angelico wrote:
>On Mon, Jan 7, 2019 at 2:52 AM Serhiy Storc
On Mon, Jan 7, 2019 at 2:52 AM Serhiy Storchaka wrote:
>
> 06.01.19 17:35, Chris Angelico пише:
> > On Mon, Jan 7, 2019 at 2:27 AM Serhiy Storchaka wrote:
> >> Because there is a reason for such code.
> >
> > What reason though??
>
> I added references and excerpts in the previous message.
Which
06.01.19 17:35, Chris Angelico пише:
On Mon, Jan 7, 2019 at 2:27 AM Serhiy Storchaka wrote:
Because there is a reason for such code.
What reason though??
I added references and excerpts in the previous message.
In short, the code
try:
1/0
except Exception as e:
On Mon, Jan 7, 2019 at 2:27 AM Serhiy Storchaka wrote:
> > The "store None" behavior can be traced down to introduction of the
> > "del except target var" behavior back in 2007:
> > https://github.com/python/cpython/commit/b940e113bf90ff71b0ef57414ea2beea9d2a4bc0#diff-cb296cc5109f5640ff3f6d7198a6a
On 1/6/19 9:14 AM, Steven D'Aprano wrote:
> [...]
> But a better question is, why would you (generic, not you personally)
> imagine that, alone out of all flow control statements, ONLY "except"
> clauses introduce a new scope? Every other flow control statement (for,
> while, if, elif, else, try
06.01.19 13:10, Paul Sokolovsky пише:
Storing None looks superfluous. For example, DELETE_FAST explicitly
stores NULL on delete.
https://github.com/python/cpython/blob/master/Python/ceval.c#L2249
Likewise, for DELETE_NAME/DELETE_GLOBAL, PyObject_DelItem() is
called which translates to:
m->mp_as
On Mon, Jan 7, 2019 at 1:21 AM Steven D'Aprano wrote:
> > I would
> > definitely find a behavior of merely clearing an "except" target
> > variable to be more understandable than magic fiddling with namespaces.
>
> I don't understand what this means. What is "clearing an except target"?
> Do you m
On Sun, Jan 06, 2019 at 03:03:03PM +0200, Paul Sokolovsky wrote:
[...]
> Ack. Such an explanation makes sense, though semantics behind it is
> "magic". And given that variable deletion happens conditionally on
> whether exception happened or not, it's still pretty strange.
I don't think anyone *l
Hello,
On Sun, 6 Jan 2019 23:10:24 +1100
Steven D'Aprano wrote:
[]
> > # Where's my *global* variable?
> > # Worse, my variable can be gone or not, depending on whether
> > exception # triggered or not.
> > print(e)
>
> That's not "worse", that's BETTER.
>
> With e deleted, you get an immed
On Sun, Jan 06, 2019 at 01:10:48PM +0200, Paul Sokolovsky wrote:
[...]
> P.S.
> I actually wanted to argue that such an implementation is hardly ideal
> at all. Consider:
>
>
> e = "my precious data"
> try:
> 1/0
> except Exception as e:
> pass
>
> # Where's my *global* variable?
>
Hello,
On Sun, 6 Jan 2019 22:19:39 +1100
Chris Angelico wrote:
> > It's clear that what happens there is that first None is stored to
> > N, just to del it as the next step. Indeed, that's what done in the
> > compile.c:
> >
> > https://github.com/python/cpython/blob/master/Python/compile.c#L290
On Sun, Jan 6, 2019 at 10:12 PM Paul Sokolovsky wrote:
> It's clear that what happens there is that first None is stored to N,
> just to del it as the next step. Indeed, that's what done in the
> compile.c:
>
> https://github.com/python/cpython/blob/master/Python/compile.c#L2905
>
> Storing None l
Hello,
As explained in
https://docs.python.org/3/reference/compound_stmts.html#the-try-statement ,
except E as N:
foo
is actually compiled as:
except E as N:
try:
foo
finally:
del N
But looking at the generated bytecode, it's worse than that:
16 STORE_
21 matches
Mail list logo
