ding scopes.
Sure. Explore anything you like! But I don't think that this is any less
ugly than either the status quo or PEP 671, both of which involve actual
real code being parsed by the compiler.
This proposal was meant to help define what the compiler with PEP 671 parsed
code
On Sat, 30 Oct 2021, Erik Demaine wrote:
Functions are already a form of deferred evaluation. PEP 671 is an
embellishment to this mechanism for some of the code in the function
signature to actually get executed within the body scope, *just like the body
of the function*.
I was thinking
ore. I don't recall
enjoying it. But maybe I missed a proposal, or someone has an idea for how to
fix these issues.
Erik
--
Erik Demaine | edema...@mit.edu | http://erikdemaine.org/
___
Python-ideas mailing list -- python-ideas@python.org
To
1a7b9f
On the plus side, this probably means that there aren't many people using the
hi=None API. :-) So it might be safe to change to a late-bound default.
Erik
--
Erik Demaine | edema...@mit.edu | http://erikdemaine.org/___
Python-ideas mai
ate-binding defaults:
```
f(_missing, {'more'})
g(_missing, {'more'})
```
I started thinking about `_missing` when thinking about how to implement
late-binding defaults. It's at least one way to do it (then the function
itself co
quot;There are no hidden details as to what a function's call
signature is."? (This may be a very short-lived thread.)
Erik
--
Erik Demaine | edema...@mit.edu | http://erikdemaine.org/
___
Python-ideas mailing list -- python-ideas@pyt
7;t solve the default parameter problem, because they'll be evaluated
in the function's enclosing scope instead of the function's scope.
Erik
--
Erik Demaine | edema...@mit.edu | http://erikdemaine.org/
___
Python-ideas mail
On Sat, 16 Oct 2021, Erik Demaine wrote:
Assuming the support remains relatively unanimous for [*...], {*...}, and
{**...} (thanks for all the quick replies!), I'll put together a PEP.
As promised, I put together a pre-PEP (together with my friend and coteacher
Adam Hartz, not curr
ed, `y` won't get assigned.) This would suggest evaluating default
expressions in their own scope would be beneficial. Intuitively, the parens
are indicating a separate scope, in the same way that `(x for x in it)`
creates its own scope and thus doesn't leak `x`. On the other h
no_a, b = _no_b, c = _no_c):
(a := expr1 if a is _no_a else a,
b := expr2 if b is _no_b else b,
c := expr3 if c is _no_c else c)
```
Given that `=` assignments within a function's parameter spec already only
means "assign when another value isn't specified", this i
On Sun, 24 Oct 2021, Erik Demaine wrote:
I think the semantics are easy to specify: the argument defaults get
evaluated for unspecified order, in left to right order as specified in the
def. Those may trigger exceptions as usual.
Sorry, that should be:
I think the semantics are easy to
On Mon, 25 Oct 2021, Chris Angelico wrote:
On Mon, Oct 25, 2021 at 3:47 AM Chris Angelico wrote:
On Mon, Oct 25, 2021 at 3:43 AM Jonathan Fine wrote:
Please forgive me if it's not already been considered. Is the following valid
syntax, and if so what's the semantics? Here it is:
def
@, not
an argument, more like `def f(@later arg = default)`.
* I'm not very familiar with thunks, but they seem a bit too magical for my
liking. Evaluating argument defaults only sometimes (when they get read in
the body) feels a bit unpredictable.
Erik
--
Erik Demaine | edema...
On Sun, 17 Oct 2021, Steven D'Aprano wrote:
On Sat, Oct 16, 2021 at 11:42:49AM -0400, Erik Demaine wrote:
I guess the question is whether to define `(*it for it in its)` to mean
tuple or generator comprehension or nothing at all.
I don't see why that is even a question. We don&#x
On Sat, 16 Oct 2021, David Mertz, Ph.D. wrote:
On Sat, Oct 16, 2021, 10:10 AM Erik Demaine
(*it1, *it2, *it3) # tuple with the concatenation of three
iterables
[*it1, *it2, *it3] # list with the concatenation of three
iterables
{*it1, *it2, *it3} # set with the
nt to `list1.extend([a, b])`?
It is in JavaScript (`Array.push`). And I don't see why one would expect
it to append a tuple `(a, b)`; that's what `list1.append((a, b))` is for.
I think the main argument against this is to avoid programming errors,
which is fine, but I don't see why i
ell.) I wonder about some generalized mechanism for automatically setting
the __name__ of an assigned object (like def and class), but I'm not sure what
it would look like...
Erik
--
Erik Demaine | edema...@mit.edu | http://erikdemaine.org/
___
what we have now, and is far more flexible than just extracting the first
element. The distinction from the existing methods (with e.g. `*_`) is that
it wouldn't waste time extracting elements you don't want. And it could work
well with things like `dict` (and `dict
ome related discussion in
https://mail.python.org/archives/list/python-ideas@python.org/thread/QVTGZD6USSC34D4IJG76UPKZRXBBB4MM/
but not this exact idea.
Erik
--
Erik Demaine | edema...@mit.edu | http://erikdemaine.org/
___
Python-ideas mai
19 matches
Mail list logo
