Yeah I like <> because def f(…) is easier to the eyes to parse than def
f[T](…) but in python we use [] for the types so it might not be consistent.
Why can’t we attach the TypeVar as a class and function attributes?
Abdulla
Sent from my iPhone
> On 8 Feb 2022, at 1:02 PM, Jonathan
Very nice ideas. The plus and minus signs are much better than :: and :::. I am
glad people are working on that. [+T: (str, int)] would be similar to
TypeVar(“T”, str, int, covariant=True).
Abdulla
Sent from my iPhone
> On 8 Feb 2022, at 6:49 PM, Abdulla Al Kathiri
> wrote:
>
> Thank you
Thank you Stephan. Very fair points you brought. I will make sure to check the
typing-sig.
Sent from my iPhone
> On 8 Feb 2022, at 6:00 PM, James H-B wrote:
>
> I really like the idea as a whole presented here. I have a few concerns here
> though:
> 1. The support for constraints overlaps
I really like the idea as a whole presented here. I have a few concerns here
though:
1. The support for constraints overlaps with union which is undesireable, Jelle
has previously suggested using TypeVar in (constraint1, constraint2, ...) which
I think is much nicer.
2. The syntax for defining
Abdulla Al Kathiri writes:
> I thought this is called python-ideas,
It is, and if that's all you know, this is the *right* place to bring
this kind of idea. I'm sorry, I should have been more clear about
this.
> meaning it’s ok to bring ideas even if they are ugly or stupid.
What I was
*Your audience is really in the Typing SIG. Happy hunting!Steve*
Until I read that line I thought I was reading Typing-SIG
I was saying cool for once I found a discussion I completely follow,
but dear me, it turned out to be -ideas. Btw every time I read discussions
on Typing-SIG I'm like:
>
>> class Indexable[T_co::](Protocol[T_co]):
>>def __getitem__(self, n: int) -> T_co: …
>
> This is completely new syntax: between the class name and what it
> subclasses, you have a subscript-like syntax.
>
> This is new semantics for subclassing, I think, unless you want
> Indexable to
Personally, I very much like this approach, although I'd definitely prefer
<> brackets instead, like in other languages.
We could possibly think of it as being syntactic sugar for the current
TypeVar approach, and have it translated into TypeVars at runtime.
However, if we'd define it that way,
On Tue, 8 Feb 2022 at 18:59, Abdulla Al Kathiri
wrote:
>
> I thought this is called python-ideas, meaning it’s ok to bring ideas even if
> they are ugly or stupid. No need to introduce it in Python if it’s too much
> but it might induce discussions.
>
Yes, it's absolutely okay to bring ideas
I thought this is called python-ideas, meaning it’s ok to bring ideas even if
they are ugly or stupid. No need to introduce it in Python if it’s too much but
it might induce discussions. I am not per se convinced of the syntax I wrote.
Any suggestion to make it better is more than welcomed,
Hello all,
Why can’t we use the literals directly as types? For example,
x: Literal[1, 2, 3] = 3
name: Literal[“John”] | None = “John"
Become ….
x: 1 | 2 | 3 = 3
name: “John” | None = “John"
def open(file: Path | str, mode: “w” | “a” = “w”): …
Best Regards,
Abdulla
On Thu, Dec 2, 2021 at 12:42 PM David Lukeš wrote:
>
> > That's an oversimplification:
> >
> > foo = 42
> > def bar():
> > print(foo)
> > foo = 1
> >
> > This won't print 42.
>
> Oh, right. I've run afoul of this in the past, but clearly not often
> enough to make it second nature :)
On Thu, Dec 2, 2021 at 2:47 AM David Lukeš wrote:
>
> This was probably mentioned at some point (apologies, can't afford to
> read the entire thread), but since the issue of left-to-right vs.
> early-first-then-late binding was hotly debated, I just want to point out
> that left-to-right better
This was probably mentioned at some point (apologies, can't afford to
read the entire thread), but since the issue of left-to-right vs.
early-first-then-late binding was hotly debated, I just want to point out
that left-to-right better preserves scoping intuitions:
foo = 42
def
Yeah it makes sense the default_factory argument in the field object could be
utilized to support early bound defaults.
> On 26 Nov 2021, at 10:42 PM, Christopher Barker wrote:
>
> dataclasses use Field objects that can be created automatically, but also you
> can specify them if you need to
dataclasses use Field objects that can be created automatically, but also
you can specify them if you need to do something special. And one of the
special things you can do is set a default constructor -- I'm sure that
could be extended to support early bound defaults.
-CHB
On Thu, Nov 25, 2021
On Fri, Nov 26, 2021 at 6:22 PM Abdulla Al Kathiri
wrote:
>
> Chris,
>
> Will we able to use late-bound arguments in dataclass when it’s creating the
> __init__ function?
>
> @dataclass
> class C:
> x: int
> y: int
> ls: list[int] => [x, y]
>
With that syntax, no, because there's no
Chris,
Will we able to use late-bound arguments in dataclass when it’s creating the
__init__ function?
@dataclass
class C:
x: int
y: int
ls: list[int] => [x, y]
> On 10 Nov 2021, at 11:25 AM, Chris Angelico wrote:
>
> On Wed, Nov 10, 2021 at 6:02 PM Christopher Barker
On Wed, Nov 10, 2021 at 6:02 PM Christopher Barker wrote:
>
> On Mon, Nov 8, 2021 at 11:22 PM Rob Cliffe via Python-ideas
> wrote:
>>
>> I have more than once advocated
>> x:=default
>> (and there is no clash with the walrus operator, even if others have
>> said/implied that there is).
>
>
On Wed, Nov 10, 2021 at 6:02 PM Christopher Barker wrote:
>
> On Mon, Nov 8, 2021 at 11:22 PM Rob Cliffe via Python-ideas
> wrote:
>>
>> I have more than once advocated
>> x:=default
>> (and there is no clash with the walrus operator, even if others have
>> said/implied that there is).
>
>
On Mon, Nov 8, 2021 at 11:22 PM Rob Cliffe via Python-ideas <
python-ideas@python.org> wrote:
> I have more than once advocated
> x:=default
> (and there is no clash with the walrus operator, even if others have
> said/implied that there is).
not a clash, but you could have a walrus in the
On 05/11/2021 15:57, Stephen J. Turnbull wrote:
Still on the agenda as far as I can see:
1. Syntax. The proposals I can recall are
a. x=>default
b. *x=default
c. x=@default
d. maybe putting * or @ on the opposite component in b and c?
e. a keyword before
On Sat, Nov 6, 2021 at 10:46 AM David Mertz, Ph.D.
wrote:
>
> My "vote" if one has to be chosen:
Preferences are very important. This isn't a "vote" in the sense that
the one with the most choices will be selected, but I always want to
hear people's preferences.
> #1: x=defer default
> #2:
My "vote" if one has to be chosen:
#1: x=defer default
#2: @x=default
#3: x=@default
#4: x=>default
#5:. *x=default
Explicit is better than implicit.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to
On Sat, Nov 6, 2021 at 2:57 AM Stephen J. Turnbull
wrote:
> Still on the agenda as far as I can see:
>
> 1. Syntax. The proposals I can recall are
> a. x=>default
> b. *x=default
> c. x=@default
> d. maybe putting * or @ on the opposite component in b and c?
> e. a
Rob Cliffe via Python-ideas writes:
> So PEP 671 merely attempts to restore functionality that was
> (regrettably IMO) left out as a result of that early decision.
This is a *new* feature, which adds syntax. A lot of contributors to
this thread think it's useful enough to overcome the normal
On Fri, Nov 5, 2021 at 7:36 AM Rob Cliffe via Python-ideas
wrote:
> But consider this: AFAICS, *everything* you can do with early binding, you
> can do with late binding, but *not* vice versa. (To simulate early binding
> if you actually only have late binding, simply put the default value in
Taking a step back:
Suppose Python didn't have default values AT ALL for function
parameters? Say that unpassed parameters were always set to some
sentinel value (maybe None, maybe some special value NotPassed). Would
we want to add them to the language?
Surely almost everybody would say
Chris Angelico writes:
> What I mean is that pedantically correct language inevitably ends up
> way too verbose to be useful in an educational context.
Nonsense. If you leave out the part in brackets and the "FUD", it's
*much* shorter than what Steve wrote, and more accurate. What would
Rob Cliffe via Python-ideas writes:
> Some people clearly need it, viz. those who use a default such as
> `[]` and then ask on Stack Overflow why they get surprising
> results.
That's not a "need". That's a "misunderstanding".
> You say you don't need late binding, but I would be very
On Thu, Nov 4, 2021 at 3:56 PM Christopher Barker wrote:
> All that being said, like any other PEP, there are two questions:
>
> 1) will this be an improvement?
> 2) if so, is it worth the churn?
>
> And the SC will need to make those decisions.
>
> FWIW, I’m not totally sure where I come down on
> For example, even though I was only lukewarm in support of the walrus
> operator, I agree it makes a some code constructs more concise and more
> readable. But it WAS new syntax to do the same thing that was already
> possible with an extra line or two before.
>
> It's extra syntax to make a
On Wed, Nov 3, 2021, 2:40 PM MRAB wrote:
> On 2021-11-03 18:14, Ethan Furman wrote:
> > On 11/3/21 10:35 AM, Steven D'Aprano wrote:
> >
> > > I suppose that we could even add yet another overloaded meaning on
> the
> > > asterix:
> > >
> > > # with no default, * keeps the old
On Thu, Nov 4, 2021 at 12:42 PM David Mertz, Ph.D.
wrote:
> This seems exactly opposite the real situation. Late binding is completely
> and straightforwardly handled by a sentinel. Yes, it doesn't make the
> automatic help() that pretty. Yes it takes an extra line in the body. But the
>
On Wed, Nov 3, 2021, 9:19 PM Rob Cliffe via Python-ideas
> Some people clearly need it, viz. those who use a default such as `[]` and
> then ask on Stack Overflow why they get surprising results.
This is silly. All those folks on StackOverflow are told "use a sentinel."
The fact beginners can
On 03/11/2021 18:28, Stephen J. Turnbull wrote:
Chris Angelico writes:
> While it's possible to avoid some of those, we can't hold the
> language back because *someone who doesn't understand* might
> misunderstand.
Opposing the proposal wasn't the point of quoting Steve, the point was
On Thu, Nov 4, 2021 at 9:33 AM Ethan Furman wrote:
>
> On 11/3/21 2:31 PM, Chris Angelico wrote:
> > On Thu, Nov 4, 2021 at 5:54 AM Ethan Furman wrote:
> >> On 11/3/21 12:13 AM, Chris Angelico wrote:
>
> >>> Python has a strong policy of evaluating things immediately, or being
> >>> very
On 11/3/21 2:31 PM, Chris Angelico wrote:
> On Thu, Nov 4, 2021 at 5:54 AM Ethan Furman wrote:
>> On 11/3/21 12:13 AM, Chris Angelico wrote:
>>> Python has a strong policy of evaluating things immediately, or being
>>> very clear about when they will be evaluated
>>
>> Putting the marker in the
On Thu, Nov 4, 2021 at 5:54 AM Ethan Furman wrote:
>
> On 11/3/21 12:13 AM, Chris Angelico wrote:
>
> > Python has a strong policy of evaluating things immediately, or being
> > very clear about when they will be evaluated
>
> Putting the marker in the middle of the name binding expression is
On Thu, Nov 4, 2021 at 5:28 AM Stephen J. Turnbull
wrote:
>
> > And that's what happens when you need to be pedantically correct. Not
> > particularly useful to a novice, especially with the FUD at the
> > end.
>
> I have no idea what you mean by "that's what happens," except that
> apparently
On 11/3/21 12:13 AM, Chris Angelico wrote:
> Python has a strong policy of evaluating things immediately, or being
> very clear about when they will be evaluated
Putting the marker in the middle of the name binding expression is not "very clear" -- particularly since the advice is
"ne spaces
On 2021-11-03 18:14, Ethan Furman wrote:
On 11/3/21 10:35 AM, Steven D'Aprano wrote:
> I suppose that we could even add yet another overloaded meaning on the
> asterix:
>
> # with no default, * keeps the old meaning of collecting
> # extra positional values
>
>
There’s some conflict about whether it’s the name or the expression that’s
different, and thus should be adorned.
But it’s neither: it’s the “=“ that’s different— so that’s what should be a
different symbol.
As for “=>” — I like it now, but if that same symbol is adopted for lambda,
it would be
Chris Angelico writes:
> While it's possible to avoid some of those, we can't hold the
> language back because *someone who doesn't understand* might
> misunderstand.
Opposing the proposal wasn't the point of quoting Steve, the point was
to provide IMO improved language in case the proposal
On 11/3/21 10:35 AM, Steven D'Aprano wrote:
> I suppose that we could even add yet another overloaded meaning on the
> asterix:
>
> # with no default, * keeps the old meaning of collecting
> # extra positional values
>
> *parameter
>
> # with a default, * triggers
On Thu, Nov 4, 2021 at 4:56 AM Steven D'Aprano wrote:
>
> On Thu, Nov 04, 2021 at 04:36:27AM +1100, Chris Angelico wrote:
>
> > You use the name because you can't refer to it other than by name, and
> > that's fine. But it's the *default* that is different. Not the
> > parameter.
>
> Wait, are
On Thu, Nov 04, 2021 at 04:36:27AM +1100, Chris Angelico wrote:
> You use the name because you can't refer to it other than by name, and
> that's fine. But it's the *default* that is different. Not the
> parameter.
Wait, are you saying that the list display here:
parameter=[]
is different
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
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. Without the parameter, nothing gets bound at
> all.
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 syntax says, "run me later, after this function is
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 agree. (Well, I would, wouldn't I? :-)
But if people really, really
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. Without the parameter, nothing gets bound at
all.
> The [], not the name "list", not the name "spam".
The type
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 syntax says, "run me later, after this function is built"
>>
>> - late-bound argument syntax says, "run me later, just
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
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"
Because both mean "run me later" we can leverage the @ symbol to aid understanding;
> But then the question becomes: should we recommend late-binding by
> default, with early-binding as an easy optimization?
Given the decades of code that is using early binding now, I think it would
be a really bad idea not to teach that as the default— folks absolutely
need to understand early
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
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 need, use the
> first."
Which of course is ambiguous, since the
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
On Mon, Nov 01, 2021 at 09:39:01AM +0100, Evpok Padding wrote:
> I don't look forward to having to add yet another side note about syntactic
> sugar that does not really add much value (it saves a few characters but
> it's less clear
This proposal is not about saving a few characters. We could
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 default but rather use None as a sentinel. It's not that hard and
it
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
Agreed, class namespaces are weird. :-)
On Sun, Oct 31, 2021 at 23:38 Chris Angelico wrote:
> 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
> >
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
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.
--
Greg
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to
On 2021-10-31 15:08, Chris Angelico wrote:
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
On Sun, Oct 31, 2021, 6:11 PM Chris Angelico
> 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
On 31/10/2021 21:54, David Mertz, Ph.D. wrote:
On Sun, Oct 31, 2021, 5:39 PM Rob Cliffe via Python-ideas
PEP 671 will be USEFUL to Python programmers. We want it! (When
do we want it? Now!)
This feels dishonest. I believe I qualify as a Python programmer. I
started using Python
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
On 2021-10-31 14:38, Rob Cliffe via Python-ideas wrote:
Wonderful!
+1,000,000.
So are you going to write a PEP explaining exactly how you propose to
implement deferred expressions and how they would be used? And perhaps
provide a reference implementation? Then we can see how it works, and
how
On Sun, Oct 31, 2021, 5:39 PM Rob Cliffe via Python-ideas
> PEP 671 will be USEFUL to Python programmers. We want it! (When do we
> want it? Now!)
>
This feels dishonest. I believe I qualify as a Python programmer. I started
using Python 1.4 in 1998. The large majority of my work life since
On 31/10/2021 18:00, 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 not the same as properties, but we can implement
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
> not the same as properties, but
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
not the same as properties, but we can implement properties with
descriptors. Decorators are not the
On Mon, 1 Nov 2021, Chris Angelico wrote:
This is incompatible with the existing __get__ method, so it should
get a different name. Also, functions have a __get__ method, so you
definitely don't want to have everything that takes a callback run
into this. Let's say it's __delayed__ instead.
On 31/10/2021 08:05, 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
def f(a := (b :=
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?
>>
>> def foo2(a=defer [1,2,3], b=defer len(a)):
>> a.append(4)
>>
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?
>
> def foo2(a=defer [1,2,3], b=defer len(a)):
> a.append(4)
> print(b)
>
This is a nice example. I agree they are different in the
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 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
On Sun, 31 Oct 2021 at 12:45, Eric V. Smith wrote:
>
> I think it's safe to say people are opposed to the PEP as it current
> stands, not in it's final, as yet unseen, shape. But I'm willing to use
> other words that "I'm -1 on PEP 671". You can read my opposition as "as
> it currently stands,
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
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 to the PEP as it current
stands, not in it's final, as yet unseen,
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
> exception, as long as you use
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 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
> > didn't go to the effort of
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 like "def
> > f(a, n=len(a)):" to
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
> def f(a := (b := c)):
> which might be a tad confusing but
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
> didn't go to the effort of blocking them. But if you ever ACTUALLY do
> this, then.
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 like "def
> f(a, n=len(a)):" to be possible.
Agreed so far.
> Every piece of code in Python is
Brendan Barnwell writes:
> As I've said before, the problem is that the benefit of this
> feature is too small to justify this large change to the status quo.
I don't disagree with this (but the whole thing is a YAGNI fvo "you" =
"me" so I'm uncomfortable agreeing as long "as x = x or
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 at 18:54:51 -0700,
> > > Brendan Barnwell wrote:
>
On Sat, Oct 30, 2021 at 10:51:42PM -0700, 2qdxy4rzwzuui...@potatochowder.com
wrote:
> I still see anything more complicated than a constant or an extremely
> simple expression (len(a)? well, ok, maybe; (len(a) if is_prime((len(a))
> else next_larger_prime(len(a)))? don't push it) as no longer
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 a mistake there,
> > then please point it
On Sat, Oct 30, 2021 at 09:31:38PM -0400, David Mertz, Ph.D. wrote:
> Both the choice of syntax and the discussion of proposed implementation
> (both yours and Steven's) would make it more difficult later to advocate
> and implement a more general "deferred" mechanism in the future.
The choice
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
> > give a completely false
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
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 at 18:54:51 -0700,
> > Brendan Barnwell wrote:
> >
> > > On 2021-10-30 18:29, Chris Angelico wrote:
> >
> > > > Right. That is a very real
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 a mistake there,
> then please point it out so I can fix it). I'm using the term "default
> expression", or
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
> give a completely false signature.
>>> def func(arg="finest green eggs and ham"):
...
1 - 100 of 430 matches
Mail list logo
