On 18/11/20 5:29 pm, Stephen J. Turnbull wrote:
Glenn Linderman writes:
> Mathematics never came up with separate symbols for equality and
> assignment.
Mathematics doesn't need them, until we come to an age where we do
mathematics on algorithms.
Even then, when mathematicians describe
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
Glenn Linderman writes:
> Mathematics never came up with separate symbols for equality and
> assignment.
Mathematics doesn't need them, until we come to an age where we do
mathematics on algorithms. It's perfectly possible to do algebra
interpreting "let x = 3" as an equation of the form
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
Hi Brett,
Without having really looked at the history of all the languages we
mention in the PEPs, I have a hunch that most of them had pattern
matching from quite the beginning or an early stage on, indeed. That
being said, I think the question itself does not really make much
sense,
On Mon, Nov 16, 2020 at 9:03 AM Tobias Kohn wrote:
> Hi Mark,
>
> Thank you for your interest and the questions.
>
>
> 1. This really comes down to how you look at it, or how you define
> pattern matching. The issue here is that the concept of pattern matching
> has grown into a large and
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 Guido,
On 16/11/2020 4:41 pm, Guido van Rossum wrote:
Thanks Mark, this is a helpful and valuable contribution.
I will try to understand and review it in the coming weeks (there is no
hurry since the decision is up to the next SC) but I encourage you to
just put it in PEP form and check
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
In Mathematica, you might do this as (roughly):
rules = {
{x_, y_, z_} :> {x, y, z},
{x_, y_} :> {x, y, 0.0},
x_ :> {x, 0.0, 0.0}
}
process[Replace[obj, rules]]
Whatever you think of the particular syntax:
The ability to declare resuable rules seems good.
Thinking of replacement
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:
On Tue, Nov 17, 2020 at 08:49:28AM +0100, Marco Sulla wrote:
> PS: pattern matching, for a mere mortal like me, seems to be something very
> exotical.
Have you ever written code that looks like this?
if isinstance(obj, tuple) and len(obj) ==3:
x, y, z = obj
elif isinstance(obj,
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.
There doesn't seem to be an explanation for this behavior in the docs or
PEPs, that I can find.
Nor does there seem to be any good technical reason
27 matches
Mail list logo
