This reminds me of a previous proposal I can't remember if I hit the list with,
allowing
with open(filename.json, "r") as f:
my_dict = json.load(f)
to be spelt as a single expression:
my_dict = (json.load(f) with open(filename.json, "r") as f)
Obviously this would be more usefu
I can offer another example where the new syntax is likely to be of use to
numpy. We currently have the following as synonyms:
```
np.copyto(a, b, casting='unsafe')
a[...] = b
```
Obviously, it would be nice if we could allow other casting rules for `[]`
assignment:
```
np.copyto(a, b, casting='s
Would another option be to just stop using the tuple-less index in the presence
of new syntax - so by example,
```
SYNTAXINDEX KWARGS
d[*[]]() {}
d[*[],] () {}
d[**{}] () {}
d[**{},] () {}
d[foo=1] () {'foo': 1}
d[foo=1,] () {'foo
Thanks for the PEP, and for pinging the numpy list about it. Some comments:
Sequence unpacking remains a syntax error inside subscripts:
Reason: unpacking items would result it being immediately repacked into a
tuple
A simple counter-example is [:, *args, :], which could be treated as
[(slice(Non
gt; `Expr(DeleteExpr(x))` (as `(x := 0)` ->
`Expr(NamedExpr(...))`)
Eric
On Fri, 12 Jun 2020 at 17:21, Guido van Rossum wrote:
> On Fri, Jun 12, 2020 at 4:55 AM Eric Wieser
> wrote:
>
>> > He thought that the change of del he proposed will give him that
>> behavior
> He thought that the change of del he proposed will give him that behavior,
> but this is not true.
Unless I'm forgetting part of the conversation, that's not true. Note that the
numpy patch is merged. Today, you get the optimization with `z = a + b + c +
d`. What you don't get is the same opt
I've realized that I've actually seen code use a trick to enable exactly this
optimization in the past, without needing language extensions (although I don't
remember where). Taking two of my motivating examples from elsewhere in the
thread:
bc = b*c
a = bc + d
f = get_f_long_name(
> And as I understand it (from a quick scan) the reason it can’t tell isn’t
> that the refcount isn’t 1 (which is something CPython could maybe fix if it
> were a problem, but it isn’t). Rather, it is already 1, but a refcount of 1
> doesn’t actually prove a temporary value
This is at odds with
This was exactly what I was thinking of when I said
> This is unavoidable in a for loop without breaking existing code, but I think
> could (and
should?) be changed in a list comprehension
Unfortunately, I was wrong in the last half of this statement.
> since the comprehension control variable
It looks like actually this can be be built as a function today:
def move(name):
return inspect.currentframe().f_back.f_locals.pop(name)
Which works as follows, but it feels awkward to pass variable names by strings
(and will confuse linters):
>>> for v in itertools.combinations
> You can get the same effect by not naming the value being thrown away
This is absolutely true, although I don't think that's a particularly strong
argument against it. The same can be said of `std::move` in C++. The purpose
of this suggestion is primarily to allow introducing names without it
Marco Sulla wrote:
> I can be wrong, but for what I know, del variable_name does not
> optimize the code, in the sense of performance.
Correct, by itself `del variable_name` does not optimize the code - however,
there exist functions implemented in C (which I gave examples of) with special
cases
TL;DR: should we make `del x` an expression that returns the value of `x`.
## Motivation
I noticed yesterday that `itertools.combinations` has an optimization for when
the returned tuple has no remaining ref-counts, and reuses it - namely, the
following code:
>>> for v in itertools.combina
13 matches
Mail list logo
