On Mon, Oct 25, 2021 at 6:13 PM Steven D'Aprano wrote:
>
> On Mon, Oct 25, 2021 at 05:23:38AM +1100, Chris Angelico wrote:
> > On Mon, Oct 25, 2021 at 4:29 AM Erik Demaine wrote:
> > >
> > > On Sun, 24 Oct 2021, Erik Demaine wrote:
> > >
> >
On Mon, Oct 25, 2021 at 7:40 PM Jeremiah Vivian
wrote:
>
> I DO expect this thread to be bombarded with negative replies.
>
> Currently, there are `in`/`not in` operators which work like this in Python:
> > def contains(contains_value, iterable, not_in):
> > for element in iterable:
> >
On Mon, Oct 25, 2021 at 7:51 PM Barry Scott wrote:
>
> Clarification please:
>
> What is the bytecode that will be generated?
Equivalent to:
if argument not provided:
argument =
except that we don't have a way of saying "not provided".
> Does the bytecode only run the default code if the
On Mon, Oct 25, 2021 at 8:09 PM Jeremiah Vivian
wrote:
>
> Something like this:
> > \>\>\> class Movement:
> > ... def __eq__(self, x):
> > ... return type(x) is Movement
> > ...
Uhh, why are you defining equality in this bizarre way? Every Movement
is equal to every other?
ChrisA
__
On Mon, Oct 25, 2021 at 8:35 PM Steven D'Aprano wrote:
>
> Otherwise, it would silently do the wrong thing. And then the coder who
> accidentally inserts an unneeded `is` into the test will have to deal
> with weird implementation-dependent silent failures due to caching of
> small ints and string
On Mon, Oct 25, 2021 at 9:33 PM Jeremiah Vivian
wrote:
>
> > It's worth noting that "in" is defined by the container. Object
> > identity and equality aren't actually part of the definition. A lot of
> > containers will behave as the OP describes, but strings, notably, do
> > not - if you iterate
On Mon, Oct 25, 2021 at 10:39 PM Marc-Andre Lemburg wrote:
> I would prefer to not go down this path.
>
> "Explicit is better than implicit" and this is too much "implicit"
> for my taste :-)
>
> For simple use cases, this may save a few lines of code, but as soon
> as you end up having to think w
On Mon, Oct 25, 2021 at 11:20 PM Marc-Andre Lemburg wrote:
>
> On 25.10.2021 13:53, Chris Angelico wrote:
> > On Mon, Oct 25, 2021 at 10:39 PM Marc-Andre Lemburg wrote:
> >> I would prefer to not go down this path.
> >>
> >> "Explicit is better t
On Mon, Oct 25, 2021 at 11:41 PM Jon Kiparsky wrote:
> I would prefer to build on the fact that arguments already come in two
> flavors with somewhat different behaviors, and that the ordering of these is
> determined. Going by this analogy, it would make sense to have late-binding
> arguments
On Mon, Oct 25, 2021 at 11:53 PM Marc-Andre Lemburg wrote:
>
> On 25.10.2021 14:26, Chris Angelico wrote:
> > On Mon, Oct 25, 2021 at 11:20 PM Marc-Andre Lemburg wrote:
> >>
> >> On 25.10.2021 13:53, Chris Angelico wrote:
> >>> On Mon, Oct 25, 2021 at
On Tue, Oct 26, 2021 at 3:32 AM Erik Demaine wrote:
> As Jonathan Fine mentioned, if you defined the order to be a linearization of
> the partial order on arguments, (a) this would be complicated and (b) it would
> be ambiguous. I think, if you're going to forbid `def f(a := b, b:= a)` at
> the c
On Tue, Oct 26, 2021 at 4:36 AM Guido van Rossum wrote:
>
> On Mon, Oct 25, 2021 at 10:28 AM Chris Angelico wrote:
>>
>> [...] The two options on the table are:
>>
>> 1) Allow references to any value that has been provided in any way
>> 2) Allow refer
On Tue, Oct 26, 2021 at 4:54 AM Guido van Rossum wrote:
>
> There are other options. Maybe you can't combine early and late binding
> defaults in the same signature. Or maybe all early binding defaults must
> precede all late binding defaults.
>
All early must precede all late would make a dece
precise syntax, but I think the
semantics of pure left-to-right make very good sense.
Will have to get an implementation together before being sure, though.
> On Tue, 26 Oct 2021, Chris Angelico wrote:
>
> >> Personally, I'd expect to use late-bound defaults almost all or all the
On Tue, Oct 26, 2021 at 6:46 AM Mike Miller wrote:
>
>
> On 2021-10-23 17:13, Chris Angelico wrote:
> > def bisect_right(a, x, lo=0, hi=>len(a), *, key=None):
>
>
> Sounds like deferred execution could be useful, but I wanted to complain about
> the example ab
On Tue, Oct 26, 2021 at 10:20 AM Kyle Lahnakoski wrote:
> I was concerned with this proposal at first because an inner function
> definition may be ambiguous:
>
> > def do_work():
> > a = ['this', 'is', 'a', 'list']
> > def range(a, min=0, max = defer len(a)):
> > return a[min:
On Tue, Oct 26, 2021 at 11:44 AM Rob Cliffe via Python-ideas
wrote:
> I prefer 1). Easier to understand and debug in examples with side-effects
> such as
> def f(a := enter_codes(), b = assign_targets(), c := unlock_missiles(), d
> = FIRE()):
> (not that this is something to be particularly
On Tue, Oct 26, 2021 at 12:40 PM <2qdxy4rzwzuui...@potatochowder.com> wrote:
>
> On 2021-10-26 at 12:12:47 +1100,
> Chris Angelico wrote:
>
> > On Tue, Oct 26, 2021 at 11:44 AM Rob Cliffe via Python-ideas
> > wrote:
> > > I prefer 1). Easier to understand
On Tue, Oct 26, 2021 at 1:20 PM <2qdxy4rzwzuui...@potatochowder.com> wrote:
>
> On 2021-10-26 at 12:51:43 +1100,
> Chris Angelico wrote:
>
> > On Tue, Oct 26, 2021 at 12:40 PM <2qdxy4rzwzuui...@potatochowder.com> wrote:
> > >
> > > On 2021-10-2
On Tue, Oct 26, 2021 at 1:10 PM David Mertz, Ph.D.
wrote:
>
> I like this. I think explicitly discussing order of inclusion would be
> worthwhile. I know it's implied by the approximate equivalents, but actually
> stating it would improve the PEP, IMO.
>
> For example:
>
> nums = [(1, 2, 3), (1.
On Tue, Oct 26, 2021 at 3:00 PM Steven D'Aprano wrote:
>
> On Tue, Oct 26, 2021 at 04:48:17AM +1100, Chris Angelico wrote:
>
> > The problem is the bizarre inconsistencies that can come up, which are
> > difficult to explain unless you know exactly how everything is
On Mon, Oct 25, 2021 at 11:26 PM Chris Angelico wrote:
>
> On Mon, Oct 25, 2021 at 11:20 PM Marc-Andre Lemburg wrote:
> > So whenever new syntax is discussed, I think it's important to
> > look at it from the perspective of a user who hasn't seen it before
>
On Wed, Oct 27, 2021 at 2:05 AM Eric V. Smith wrote:
>
> Among my objections to this proposal is introspection: how would that
> work? The PEP mentions that the text of the expression would be
> available for introspection, but that doesn't seem very useful.
Doesn't it? It would certainly be usef
On Wed, Oct 27, 2021 at 2:47 AM Eric V. Smith wrote:
> Okay. I look forward to your thoughts. Omitting late-bound arguments or
> defaults would not be acceptable.
No, I agree. We have to still be able to introspect them.
At the moment, when you look at a function's defaults, they are all
values.
On Tue, Oct 26, 2021 at 11:10 PM Steven D'Aprano wrote:
> > Based on the multi-pass assignment model, which you still favour,
> > those WOULD be quite inconsistent, and some of them would make little
> > sense. It would also mean that there is a distinct semantic difference
> > between:
> >
> > d
On Wed, Oct 27, 2021 at 3:39 AM Erik Demaine wrote:
>
> On Tue, 26 Oct 2021, Steven D'Aprano wrote:
>
> >def func(x=x, y=>x) # or func(x=x, @y=x)
>
> This makes me think of a "real" use-case for assigning all early-bound
> defaults before late-bound defaults: consider using closure hacks (my
On Wed, Oct 27, 2021 at 4:51 AM David Mertz, Ph.D.
wrote:
>
> On Tue, Oct 26, 2021, 1:08 PM Chris Angelico wrote:
>>
>> No, I agree. We have to still be able to introspect them.
>>
>> At the moment, when you look at a function's defaults, they are all values.
On Wed, Oct 27, 2021 at 5:05 AM Paul Moore wrote:
>
> On Tue, 26 Oct 2021 at 16:48, Eric V. Smith wrote:
> >
> > And also the "No Loss of Abilities If Removed" section sort of applies
> > to late-bound function arguments: there's nothing proposed that can't
> > currently be done in existing Pytho
On Wed, Oct 27, 2021 at 5:21 AM Brendan Barnwell wrote:
>
> On 2021-10-26 10:55, Chris Angelico wrote:
> >> >So why on earth NOT make these general "deferred" objects that can be
> >> >used in other contexts?!
> > Because they're NOT de
On Wed, Oct 27, 2021 at 5:30 AM Ricky Teachey wrote:
> But with function k below, where the b parameter is deferred, you can't get
> the default b parameter by dynamically unpacking some values; you would have
> to pass c as a kwd arg:
>
> def k(a, b=>len(a), c=None):
> ...
>
> Seems like it
On Wed, Oct 27, 2021 at 6:15 AM Paul Moore wrote:
> Having the code stop working just because I changed the way the called
> function handles its defaults would be a nuisance (again, I'm not
> saying this would happen often, just that I could easily imagine it
> happening if this feature was avail
On Wed, Oct 27, 2021 at 8:06 AM Erik Demaine wrote:
> I wonder if it would make sense to offer a "missing argument" object (builtin?
> attribute of inspect.Parameter? attribute of types.FunctionType?) that
> actually simulates the behavior of that argument not being passed. Let me
> call it `_mis
On Wed, Oct 27, 2021 at 10:14 AM Christopher Barker wrote:
>
> Hmm, it seems our notes crossed paths, sorry.
>
> On Tue, Oct 26, 2021 at 2:12 PM Chris Angelico wrote:
>>
>> The trouble with sentinel values is that you always need another one.
>> Sooner or later
On Wed, Oct 27, 2021 at 10:27 AM Christopher Barker wrote:
>
> I'm very confused about the apparent convergence on the token "=>" for
> deferred parameter assignment.
The current text of the PEP uses that. It's not particularly important
to me *what* symbol is used, so I just use the same one as
On Wed, Oct 27, 2021 at 10:37 AM Carl Meyer wrote:
>
> On Tue, Oct 26, 2021 at 5:29 PM Christopher Barker
> wrote:
> > BTW: was it intentional that this:
> >
> > In [8]: def fun(x, y=(z:=3)):
> >...: print(x,y,z)
> >...:
> >...:
> >
> > adds z to the function namespace -- sure se
On Wed, Oct 27, 2021 at 10:38 AM Rob Cliffe wrote:
>
>
>
> On 26/10/2021 18:25, Chris Angelico wrote:
> > On Tue, Oct 26, 2021 at 11:10 PM Steven D'Aprano
> > wrote:
> >
> >>> Based on the multi-pass assignment model, which you still favour,
>
On Wed, Oct 27, 2021 at 10:40 AM Christopher Barker wrote:
>
> subclassing and defaults.
>
> There is one use case I'm not sure how to wrap my head around.
>
> Say a class and subclass have different default arguments. And we want to
> pass the fact that the argument wasn't set along to the super
On Wed, Oct 27, 2021 at 11:17 AM Christopher Barker wrote:
>
> On Tue, Oct 26, 2021 at 4:46 PM Rob Cliffe via Python-ideas
> wrote:
>>
>> There has been support for evaluating all early-bound defaults before
>> all late-bound defaults. I have been persuaded that this is a
>> reasonable option.
On Wed, Oct 27, 2021 at 11:41 AM Christopher Barker wrote:
> I've been thinking about this from the perspective of a teacher or Python.
> I"m not looking forward to having one more thing to teach about function
> definitions -- I struggle enough with cover all of the *args, **kwargs,
> keyword-
On Wed, Oct 27, 2021 at 12:50 PM Rob Cliffe wrote:
>
>
>
> On 27/10/2021 00:50, Chris Angelico wrote:
> > On Wed, Oct 27, 2021 at 10:38 AM Rob Cliffe
> > wrote:
> >
> >> There has been support for evaluating all early-bound defaults before
> >>
On Wed, Oct 27, 2021 at 12:59 PM Chris Angelico wrote:
>
> On Wed, Oct 27, 2021 at 12:50 PM Rob Cliffe wrote:
> >
> >
> >
> > On 27/10/2021 00:50, Chris Angelico wrote:
> > > On Wed, Oct 27, 2021 at 10:38 AM Rob Cliffe
> > > wrote:
> > &g
On Wed, Oct 27, 2021 at 1:13 PM Ricky Teachey wrote:
>
> I'll try to summarize why I still have pause even though after thinking about
> it I still can't really think of a solid example showing that this "give me
> the default" issue is a concrete problem:
>
> Until this point, exactly how to pr
On Wed, Oct 27, 2021 at 1:15 PM Brendan Barnwell wrote:
>
> On 2021-10-26 17:41, Christopher Barker wrote:
> > Python used to be such a simple language, not so much anymore :-(
>
> I quite agree, and I feel like this is my biggest reason why I don't
> want this "feature" (or any of another
On Wed, Oct 27, 2021 at 1:52 PM Ricky Teachey wrote:
>
> If I might paraphrase Agrippa from the book of Acts: "Almost thou persuadest
> me..." ;) It's a fine answer.
>
> Thanks for the attentiveness to my concern, Chris. Very much appreciated!
>
My pleasure. This has been a fairly productive dis
On Wed, Oct 27, 2021 at 1:52 PM Rob Cliffe via Python-ideas
wrote:
>
> On 27/10/2021 03:12, Brendan Barnwell wrote:
> > On 2021-10-26 17:41, Christopher Barker wrote:
> >> Python used to be such a simple language, not so much anymore :-(
> >
> > I quite agree, and I feel like this is my bigges
On Wed, Oct 27, 2021 at 2:30 PM Ethan Furman wrote:
>
> On 10/23/21 5:13 PM, Chris Angelico wrote:
>
> > PEP: 671
> > Title: Syntax for late-bound function argument defaults
>
> I have a major concern about the utility of this addition -- it was mentioned
> alread
On Wed, Oct 27, 2021 at 4:07 PM Christopher Barker wrote:
>
> It's not actually documented that None indicates "use the default".
>
> Which, it turns out is because it doesn't :-)
>
> In [24]: bisect.bisect([1,3,4,6,8,9], 5, hi=None)
> --
On Wed, Oct 27, 2021 at 5:14 PM Brendan Barnwell wrote:
> Now it's true that we have asymmetry, in that SIMPLE logic can be
> readably inlined as an early-bound default, whereas even simple logic
> cannot be inlined as a late-bound default because there is no inline way
> to express late-b
On Thu, Oct 28, 2021 at 4:52 PM Jeremiah Vivian
wrote:
>
> All containers do have a concept of iterators though, and the `is in`
> operator can check using the iterator of the container.
>
But the "in" operator isn't built on iteration, so that would be in-consistent.
What you're asking for can
On Thu, Oct 28, 2021 at 10:09 PM Jeremiah Vivian
wrote:
>
> I don't quite understand completely the major first part of your reply...
Please quote text so we know who you're replying to.
ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
T
On Thu, Oct 28, 2021 at 9:05 PM Steven D'Aprano wrote:
>
> On Thu, Oct 28, 2021 at 05:25:52PM +1100, Chris Angelico wrote:
>
> > But the "in" operator isn't built on iteration, so that would be
> > in-consistent.
>
> "In-"consist
https://github.com/Rosuav/cpython/tree/pep-671
So uhh... anyone who knows about the internals of CPython and wants to
join me on this, I would *really* appreciate coauthors!
The implementation ended up a lot more invasive than I originally
planned. Some of that is inherent to the problem, but oth
On Fri, Oct 29, 2021 at 8:11 PM Steven D'Aprano wrote:
>
> On Fri, Oct 29, 2021 at 07:17:05PM +1100, Chris Angelico wrote:
>
> > * Argument defaults (either in __defaults__ or __kwdefaults__) are now
> > tuples of (desc, value) or (desc,) for early-bound and l
On Fri, Oct 29, 2021 at 11:52 PM Steven D'Aprano wrote:
> > Except that that's still backward-incompatible, since None is a very
> > common value.
>
> How is it backwards incompatible? Any tool that looks at __defaults__
> finds *exactly* what was there before: a tuple of default values, not a
> t
Second version of the POC implementation in response to feedback.
On Fri, Oct 29, 2021 at 7:17 PM Chris Angelico wrote:
>
> https://github.com/Rosuav/cpython/tree/pep-671
>
> So uhh... anyone who knows about the internals of CPython and wants to
> join me on this, I would *rea
On Sat, Oct 30, 2021 at 10:32 PM Jonathan Fine wrote:
> I suggest that an implementation which provides additional flexibility in the
> manner in which the code frame is initialised would be less invasive.
> Necessarily, PEP 671 allows programmer supplied code to be used in the
> 'initialisatio
On Sun, Oct 31, 2021 at 9:09 AM David Mertz, Ph.D.
wrote:
>
> I'm -100 now on "deferred evaluation, but contorted to be useless outside of
> argument declarations."
>
> At first I thought it might be harmless, but nothing I really care about.
> After the discussion, I think the PEP would be acti
On Sun, Oct 31, 2021 at 9:17 AM Brendan Barnwell wrote:
>
> On 2021-10-26 20:15, Chris Angelico wrote:
> > One of my goals here is to ensure that the distinction between
> > early-bound and late-bound argument defaults is, again, orthogonal
> > with everything else. You
On Sun, Oct 31, 2021 at 9:20 AM Paul Moore wrote:
>
> On Sat, 30 Oct 2021 at 23:13, Brendan Barnwell wrote:
> >
> > On 2021-10-30 15:07, David Mertz, Ph.D. wrote:
> > > I'm -100 now on "deferred evaluation, but contorted to be useless
> > > outside of argument declarations."
> > >
> > > At first
On Sun, Oct 31, 2021 at 9:54 AM Brendan Barnwell wrote:
>
> On 2021-10-30 15:35, Chris Angelico wrote:
> > Bear in mind that the status quo is, quite honestly, a form of white
> > lie. In the example of bisect:
> >
> > def bisect(a, hi=None): ...
> > def bisect
On Sun, Oct 31, 2021 at 12:17 PM Brendan Barnwell wrote:
>
> On 2021-10-30 16:12, Chris Angelico wrote:
> >> > Increasingly it seems to me as if you are placing inordinate
> >> > weight on
> >> >the idea that the benefit of default argu
On Sun, Oct 31, 2021 at 12:31 PM David Mertz, Ph.D.
wrote:
>
> On Sat, Oct 30, 2021, 6:29 PM Chris Angelico wrote:
>>
>> > At first I thought it might be harmless, but nothing I really care about.
>> > After the discussion, I think the PEP would be actively
On Sun, Oct 31, 2021 at 1:03 PM Brendan Barnwell wrote:
>
> On 2021-10-30 18:29, Chris Angelico wrote:
> >> > What I am saying is that there is a qualitative difference
> >> > between "I
> >> >know now (at function definition time) wh
On Sun, Oct 31, 2021 at 1:28 PM David Mertz, Ph.D.
wrote:
>
> On Sat, Oct 30, 2021, 9:40 PM Chris Angelico wrote:
>>
>> > I'm not sure what I think of a general statement like:
>> >
>> > @do_later = fun1(data) + fun2(data)
>> >
>> &g
On Sun, Oct 31, 2021 at 1:52 PM Steven D'Aprano wrote:
> I believe that the PEP should declare that how the unevaluated defaults
> are stored prior to evaluation is a private implementation detail. We
> need an API (in the inspect module? as a method on function objects?) to
> allow consumers to q
On Sun, Oct 31, 2021 at 2:20 PM Rob Cliffe via Python-ideas
wrote:
> As for deferred evaluation objects:
> First, Python already has various ways of doing deferred evaluation:
> Lambdas
> Strings, which can be passed to eval / exec / compile.
> You can write decorator(s
On Sun, Oct 31, 2021 at 2:23 PM Brendan Barnwell wrote:
>
> On 2021-10-30 19:11, Chris Angelico wrote:
> >> > I mean, here's another way to come at this. Suppose we have
> >> > this under
> >> >the proposal (using some random syntax pick
On Sun, Oct 31, 2021 at 2:43 PM <2qdxy4rzwzuui...@potatochowder.com> wrote:
>
> On 2021-10-30 at 18:54:51 -0700,
> Brendan Barnwell wrote:
>
> > On 2021-10-30 18:29, Chris Angelico wrote:
>
> > > Right. That is a very real difference, which is why there is
On Sun, Oct 31, 2021 at 2:52 PM David Mertz, Ph.D.
wrote:
>
>
> On Sat, Oct 30, 2021, 11:03 PM Chris Angelico
>>
>> That's if you were to create a deferred *type*. An object which can be
>> evaluated later. My proposal is NOT doing that, because there is n
On Sun, Oct 31, 2021 at 3:08 PM Brendan Barnwell wrote:
>
> On 2021-10-30 20:44, Chris Angelico wrote:
> >> The default of every argument should be a first-class value.
> >> That's
> >> how things are now, and I think that's a very useful invar
On Sun, Oct 31, 2021 at 3:16 PM Steven D'Aprano wrote:
>
> On Sun, Oct 31, 2021 at 12:29:18PM +1100, Chris Angelico wrote:
>
> > That's optional parameters. It's entirely possible to have optional
> > parameters with no concept of defaults; it means the functi
On Sun, Oct 31, 2021 at 3:31 PM Steven D'Aprano wrote:
> >>> inspect.signature(bisect.bisect_left)
>
>
> I challenge anyone to honestly say that if that signature read:
>
>
>
> they would not be able to infer the meaning, or that Python would be a
> worse language if the interpreter
On Sun, Oct 31, 2021 at 3:57 PM Steven D'Aprano wrote:
> Kind of like functions themselves :-)
>
> >>> (lambda x, y: 2*x + 3**y).__code__.co_code
> b'd\x01|\x00\x14\x00d\x02|\x01\x13\x00\x17\x00S\x00'
>
> The internal structure of that co_code object is a mystery, it is not
> part of the P
On Sun, Oct 31, 2021 at 4:15 PM Steven D'Aprano wrote:
>
> On Sun, Oct 31, 2021 at 03:43:25PM +1100, Chris Angelico wrote:
>
> > There is a downside: it is possible to flat-out lie to the
> > interpreter, by mutating bisect_left.__defaults__, so that help() will
&
On Sun, Oct 31, 2021 at 4:37 PM Steven D'Aprano wrote:
>
> On Sun, Oct 31, 2021 at 02:56:36PM +1100, Chris Angelico wrote:
>
> > Current versions of the PEP do not use the term "default value" when
> > referring to late binding (or at least, if I've made
On Sun, Oct 31, 2021 at 4:55 PM <2qdxy4rzwzuui...@potatochowder.com> wrote:
>
> On 2021-10-31 at 14:56:36 +1100,
> Chris Angelico wrote:
>
> > On Sun, Oct 31, 2021 at 2:43 PM <2qdxy4rzwzuui...@potatochowder.com> wrote:
> > >
> > > On 2021-10-30
On Sun, Oct 31, 2021 at 7:01 PM Jonathan Fine wrote:
>
> Hi
>
> I've just had a brainwave that may give an even less invasive implementation
> of PEP 671. It relies on every function having a dict, as provided by
> https://www.python.org/dev/peps/pep-0232/.
>
> Consider:
> def fn(a, b, c): p
On Sun, Oct 31, 2021 at 6:36 PM Steven D'Aprano wrote:
>
> On Sun, Oct 31, 2021 at 02:24:10PM +1100, Chris Angelico wrote:
>
> > That last part is the most important here: it has to be evaluated *in
> > the context of the function*. That's the only way for things li
On Sun, Oct 31, 2021 at 6:50 PM Steven D'Aprano wrote:
>
> On Sun, Oct 31, 2021 at 03:10:56PM +1100, Chris Angelico wrote:
>
> > (Side point: The current reference implementation allows assignment
> > expressions inside default argument expressions, mainly because I
>
On Sun, Oct 31, 2021 at 7:10 PM Steven D'Aprano wrote:
>
> On Tue, Oct 26, 2021 at 08:59:51AM +0100, Rob Cliffe via Python-ideas wrote:
>
> > And I don't understand what point you're making here. Yes, the walrus
> > operator can appear in various places, how is that relevant? You could write
> >
On Sun, Oct 31, 2021 at 9:24 PM Sven R. Kunze wrote:
>
> Actually, the "defer:"-syntax is really readable and searchable compared to
> the cryptic comparison operator used in the proposal. Just thinking towards
> "googleability".
>
Google's smarter than that. I've searched for symbols before an
On Sun, Oct 31, 2021 at 6:25 PM Steven D'Aprano wrote:
>
> I have a suggestion for the implementation.
>
> I think that Chris' current approach is to compile the late-bound
> defaults in the function body. So if we have a function like this:
>
> def func(a, b=early_expression, @c=late_expressi
On Sun, Oct 31, 2021 at 5:25 PM Chris Angelico wrote:
> I don't think this is a major problem. It's no worse than other things
> you can mess with, and if you do that sort of thing, you get only what
> you asked for; there's no way you can get a segfault or even an
> ex
On Sun, Oct 31, 2021 at 11:47 PM Eric V. Smith wrote:
>
> On 10/30/2021 10:08 PM, Christopher Barker wrote:
> > I'm a bit confused as to why folks are making pronouncements about
> > their support for this PEP before it's even finished, but, oh well.
> I think it's safe to say people are opposed t
On Mon, Nov 1, 2021 at 2:39 AM Erik Demaine wrote:
>
> 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
On Mon, Nov 1, 2021 at 2:59 AM David Mertz, Ph.D. wrote:
>
> On Sun, Oct 31, 2021, 8:59 AM Chris Angelico
>>
>> def foo1(a=>[1,2,3], b=>len(a)):
>> a.append(4)
>> print(b)
>>
>> And what is the correct behaviour here?
>>
>>
On Mon, Nov 1, 2021 at 5:03 AM Brendan Barnwell wrote:
>
> On 2021-10-31 05:57, Chris Angelico wrote:
> > Deferred expressions are not the same as late-bound argument defaults.
>
> You keep saying this, but I still don't get the point. Descriptors
> are
> no
On Mon, Nov 1, 2021 at 8:56 AM David Mertz, Ph.D. wrote:
> I am not on the SC, so indeed I won't make the decision. But I *will*
> continue to teach Python. New syntax adds a burden to learners, and it should
> not be introduced without sufficient benefit to merit that burden. This
> proposal d
On Mon, Nov 1, 2021 at 11:26 AM Steven D'Aprano wrote:
> What sort of testing and maintenance perspective are you referring to?
> Testing and maintenance of the Python interpreter? Or your own code?
>
> If it is your own code then this proposal will have no effect on your
> testing and maintenance
On Sun, Oct 31, 2021 at 4:50 AM Eric V. Smith wrote:
>
> On 10/30/2021 10:40 AM, Chris Angelico wrote:
> > And, seeing something in help(fn) largely necessitates that the source
> > code be retained. I don't know of any other way to do it. If you say
> > that t
On Mon, Nov 1, 2021 at 5:15 PM Greg Ewing wrote:
>
> On 1/11/21 4:59 am, David Mertz, Ph.D. wrote:
> > b = b
>
> I don't want to live in a universe where this could be anything
> other than a no-op in Python.
>
Be careful what you say: there are some technicalities. If you mean
that it won't
On Mon, Nov 1, 2021 at 5:57 PM Guido van Rossum wrote:
>
> Agreed, class namespaces are weird. :-)
>
Ah yes, I forgot about class namespaces. I was thinking about
deliberately wonky namespaces where the ns dict has a __missing__
method or something, but inside a class, "b = b" actually has a very
On Mon, Nov 1, 2021 at 7:39 PM Evpok Padding wrote:
>
> I definitely agree with that sentiment, with beginners I don't even talk
> about function defaults at first, and when I do, it's when we have already
> have a talk about mutables so I can just say that you almost never want a
> mutable def
On Tue, Nov 2, 2021 at 1:31 PM Evan Greenup via Python-ideas
wrote:
>
> It would be nice to add the following syntax sugar in Python "Print and Eval"
>
> like `ptev a == b` It is same as `statement = "a == b"; print(f"{statement} ?
> {eval(statement)}")`.
>
> It would super nice for debugging and
On Wed, Nov 3, 2021 at 1:39 AM Florian Wetschoreck
wrote:
> I guess, one potential solution would be to change the import resolution
> order. But of course, this is a breaking change (at least in implicit
> semantics - not sure if it will actually lead to too many real-world problems
> - but pr
On Wed, Nov 3, 2021 at 6:01 PM Stephen J. Turnbull
wrote:
>
> Steven D'Aprano writes:
>
> > "Write `arg=default` if you want the default to be evaluated just once,
> > and `arg=late default` if you want the default to be evaluated each time
> > it is needed. If you are not sure which one you ne
On Thu, Nov 4, 2021 at 2:29 AM Ethan Furman wrote:
>
> One similarity that I don't think has been mentioned yet:
>
> - decorator syntax says, "run me later, after this function is built"
>
> - late-bound argument syntax says, "run me later, just before each function
> call"
Hmm, I more think of
On Thu, Nov 4, 2021 at 4:25 AM Ethan Furman wrote:
>
> On 11/3/21 9:07 AM, Chris Angelico wrote:
> > On Thu, Nov 4, 2021 at 2:29 AM Ethan Furman wrote:
>
> >> One similarity that I don't think has been mentioned yet:
> >>
> >> - decorator syn
On Thu, Nov 4, 2021 at 4:30 AM Steven D'Aprano wrote:
>
> On Thu, Nov 04, 2021 at 03:07:22AM +1100, Chris Angelico wrote:
>
> > def func(spam: list = []) -> str: ...
> >
> > Which part of that becomes late bound?
>
> The name "spam" of course.
On Thu, Nov 4, 2021 at 4:38 AM Steven D'Aprano wrote:
>
> On Wed, Nov 03, 2021 at 10:25:02AM -0700, Ethan Furman wrote:
>
> > Which is horrible. Put the @ at the front:
> >
> > - its relation to decorators, and delayed evaluation, is much more clear
> > - it stands out better to the reader
>
> I
401 - 500 of 2716 matches
Mail list logo
