On Wed, Nov 18, 2020 at 7:45 PM Brett Cannon wrote:
>
>
> On Tue, Nov 17, 2020 at 10:16 PM Greg Ewing
> wrote:
>
>> On 18/11/20 4:36 pm, Larry Hastings wrote:
>> >
>> > But,
>> > the thinking went, you'd never want to examine the last value from a
>> > list generator, so it was more convenient
On Tue, Nov 17, 2020 at 10:16 PM Greg Ewing
wrote:
> On 18/11/20 4:36 pm, Larry Hastings wrote:
> >
> > But,
> > the thinking went, you'd never want to examine the last value from a
> > list generator, so it was more convenient if it behaved as if it had its
> > own scope.
>
> List
On 18/11/20 4:36 pm, Larry Hastings wrote:
But,
the thinking went, you'd never want to examine the last value from a
list generator, so it was more convenient if it behaved as if it had its
own scope.
List comprehensions used to leak, but apparently that was considered
surprising by enough
On 2020-11-18 03:36, Larry Hastings wrote:
[snip]
But then we get to generator expressions and list/dict/set
comprehensions. I think of those as doing an "assignment", but I have
to remember the assignment "doesn't leak":
x = 3
y = list(x**2 for x in range(5))
print(f"{x=}")
I think Python's rules about what constitutes a new scope are a touch
inconsistent--or, as the Zen might put it, "practical".
First, simple statements never create their own scope. That's easy.
Second, compound statements that create a new function, "def" and
"lambda", always create a new
On Tue, Nov 17, 2020 at 3:57 AM Mark Shannon wrote:
>
>
> On 17/11/2020 10:22 am, Cameron Simpson wrote:
> > On 17Nov2020 09:55, Mark Shannon wrote:
> >> I'm wondering why
> >> ```
> >> x = "value"
> >> try:
> >> 1/0
> >> except Exception as x:
> >> pass
> >> ```
> >>
> >> does not
I think we've fallen in the trap of assuming we all agree on the meaning of
"scope".
In Python, that word is typically used to refer to a bunch of behaviors
that go together. In particular, "the current scope" is where assignment
creates new variables. (It is also linked to the semantics of
On 18Nov2020 08:34, Steven D'Aprano wrote:
>As far as shadowing other variables, if someone has so much code in
>their function, or at the top level, that they are at risk of
>inadvertantly shadowing variables, they have far more serious problems
>than the use of the conventional "e for
On Wed, Nov 18, 2020 at 08:45:10AM +1100, Chris Angelico wrote:
> On Wed, Nov 18, 2020 at 8:38 AM Steven D'Aprano wrote:
> > To start with, what else are they using "e" for? Surely it would be more
> > important to use a better name *there* rather than change the exception
> > variable.
>
>
On Wed, Nov 18, 2020 at 8:38 AM Steven D'Aprano wrote:
> To start with, what else are they using "e" for? Surely it would be more
> important to use a better name *there* rather than change the exception
> variable.
2.718281828?
ChrisA
___
Python-Dev
On Tue, Nov 17, 2020 at 12:36:31PM -0500, Richard Damon wrote:
> My main thought on that variable, is I would expect it to have a good
> name that implies it is an exception,
Something like "e" or "err" then, which are the two most common choices
I have seen in exception handling code.
> not
On 11/17/20 12:16 PM, Chris Angelico wrote:
> On Wed, Nov 18, 2020 at 4:08 AM Richard Damon
> wrote:
>> One comment about having the exception handler 'save state' and restore
>> it is that frequently the purpose of the exception handler is TO make
>> changes to outer variable to fix things up
On Wed, Nov 18, 2020 at 4:08 AM Richard Damon wrote:
>
> One comment about having the exception handler 'save state' and restore
> it is that frequently the purpose of the exception handler is TO make
> changes to outer variable to fix things up based on the exception.
>
> I could see the desire
One comment about having the exception handler 'save state' and restore
it is that frequently the purpose of the exception handler is TO make
changes to outer variable to fix things up based on the exception.
I could see the desire of a way to create an internal scope of sorts and
create names
Hi,
It turns out that implementing the save and restore semantics in the
example I gave is not that difficult.
I was motivated to find out by the DLS 2020 paper on pattern matching.
It claims that introducing small scopes for variables would have to be
implemented as a function preventing
17.11.20 11:55, Mark Shannon пише:
> I'm wondering why
> ```
> x = "value"
> try:
> 1/0
> except Exception as x:
> pass
> ```
>
> does not restore "value" to x after
> the `except` block.
>
> There doesn't seem to be an explanation for this behavior in the docs or
> PEPs, that I can
On 17/11/2020 10:22 am, Cameron Simpson wrote:
On 17Nov2020 09:55, Mark Shannon wrote:
I'm wondering why
```
x = "value"
try:
1/0
except Exception as x:
pass
```
does not restore "value" to x after
the `except` block.
Because the except is not a new scope. So it is the same "x".
Hi Chris,
On 17/11/2020 11:03 am, Chris Angelico wrote:
On Tue, Nov 17, 2020 at 9:44 PM Steven D'Aprano wrote:
`try...except` is no different.
...
The only wrinkle in the case of `try...except` is that the error
variable is deleted, even if it wasn't actually used. If you look at the
On Tue, Nov 17, 2020 at 9:44 PM Steven D'Aprano wrote:
> `try...except` is no different.
> ...
> The only wrinkle in the case of `try...except` is that the error
> variable is deleted, even if it wasn't actually used. If you look at the
> byte-code generated, each compound try...except with an
On Tue, Nov 17, 2020 at 09:55:46AM +, Mark Shannon wrote:
> Hi,
>
> I'm wondering why
> ```
> x = "value"
> try:
> 1/0
> except Exception as x:
> pass
> ```
>
> does not restore "value" to x after
> the `except` block.
Because try, if, for, while, with etc. don't create a new scope.
On 17Nov2020 09:55, Mark Shannon wrote:
>I'm wondering why
>```
>x = "value"
>try:
>1/0
>except Exception as x:
>pass
>```
>
>does not restore "value" to x after
>the `except` block.
Because the except is not a new scope. So it is the same "x".
Here:
21 matches
Mail list logo
