On Wed, Dec 1, 2021 at 6:43 PM Abdulla Al Kathiri
wrote:
> > On 1 Dec 2021, at 10:16 AM, Chris Angelico wrote:
> > 3) If "yes" to question 1, would you use it for any/all of (a) mutable
> > defaults, (b) referencing things that might have changed, (c)
> > referencing other arguments, (d) somethin
On Wed, Dec 1, 2021 at 7:07 PM Chris Angelico wrote:
>
> On Wed, Dec 1, 2021 at 6:58 PM Steven D'Aprano wrote:
> > You say that now, but if you read function definitions that looked
> > like this:
> >
> > def process(func:List->int=>xs=>expression)->int:
> > ...
> >
> >
> > would you
> I'll reply to this comment once I've done so.
I just realized that this message replied on a comment instead of the thread.
Anyways, it's a really impressive implementation (hope this statement doesn't
spark some sort of debate).
___
Python-ideas mail
On Wed, Dec 1, 2021 at 6:58 PM Steven D'Aprano wrote:
>
> On Wed, Dec 01, 2021 at 07:47:49AM -, Jeremiah Vivian wrote:
>
> > > 2) Independently: Is the syntactic distinction between "=" and "=>" a
> > > cognitive burden?
> > No, it isn't much of a cognitive burden.
>
> You say that now, but if
On Wed, Dec 1, 2021 at 7:12 PM Jeremiah Vivian
wrote:
>
> > I'll reply to this comment once I've done so.
> I just realized that this message replied on a comment instead of the thread.
> Anyways, it's a really impressive implementation (hope this statement doesn't
> spark some sort of debate).
Sometimes when I do complicated regular expressions, I like to divide the
patterns from a big pattern to small patterns until I reach what I want. re
module functions take the text as a second argument. Furthermore, you can’t
pass the Match object directly, you need to extract the group/text fr
On Wed, Dec 1, 2021 at 7:35 PM Abdulla Al Kathiri
wrote:
>
>
> Sometimes when I do complicated regular expressions, I like to divide the
> patterns from a big pattern to small patterns until I reach what I want. re
> module functions take the text as a second argument. Furthermore, you can’t
>
> On 1 Dec 2021, at 12:01 PM, Chris Angelico wrote:
>
> On Wed, Dec 1, 2021 at 6:43 PM Abdulla Al Kathiri
> wrote:
>>> On 1 Dec 2021, at 10:16 AM, Chris Angelico wrote:
>>> 3) If "yes" to question 1, would you use it for any/all of (a) mutable
>>> defaults, (b) referencing things that might h
On Wed, Dec 1, 2021 at 8:18 PM Abdulla Al Kathiri
wrote:
>
>
>
> > On 1 Dec 2021, at 12:01 PM, Chris Angelico wrote:
> >
> > On Wed, Dec 1, 2021 at 6:43 PM Abdulla Al Kathiri
> > wrote:
> >>> On 1 Dec 2021, at 10:16 AM, Chris Angelico wrote:
> >>> 3) If "yes" to question 1, would you use it for
On Wednesday, December 1, 2021 at 1:18:33 AM UTC-5 Chris Angelico wrote:
> I've just updated PEP 671 https://www.python.org/dev/peps/pep-0671/
> with some additional information about the reference implementation,
> and some clarifications elsewhere.
>
> *PEP 671: Syntax for late-bound functi
On Wed, Dec 01, 2021 at 07:07:20PM +1100, Chris Angelico wrote:
> > def process(func:List->int=>xs=>expression)->int:
> > ...
> I'm not sure what that's supposed to mean.
You did a pretty good job of working it out :-)
> Is List->int an annotation,
> and if so, who's deciding on th
On Wed, Dec 1, 2021 at 8:57 PM Neil Girdhar wrote:
>
>
>
> On Wednesday, December 1, 2021 at 1:18:33 AM UTC-5 Chris Angelico wrote:
>>
>> I've just updated PEP 671 https://www.python.org/dev/peps/pep-0671/
>> with some additional information about the reference implementation,
>> and some clarific
On Wed, Dec 1, 2021 at 9:09 PM Steven D'Aprano wrote:
>
> On Wed, Dec 01, 2021 at 07:07:20PM +1100, Chris Angelico wrote:
>
> > > def process(func:List->int=>xs=>expression)->int:
> > > ...
>
> > I'm not sure what that's supposed to mean.
>
> You did a pretty good job of working it out
Matt D wrote:
> In your comprehension example, I'm fairly certain the filtering should be on
> the post incremented remainder
> [ x+1 for x in [1,2,3] if (x+1) % 2 == 0]
how about
[ sum for num in [1,2,3] if ((sum := num + 1) %2 == 0]
___
Python-ideas m
On Wed, Dec 1, 2021 at 2:17 AM Chris Angelico wrote:
> I've just updated PEP 671 https://www.python.org/dev/peps/pep-0671/
> with some additional information about the reference implementation,
> and some clarifications elsewhere.
>
> *PEP 671: Syntax for late-bound function argument defaults*
>
On Wed, Dec 1, 2021 at 10:30 PM André Roberge wrote:
> On Wed, Dec 1, 2021 at 2:17 AM Chris Angelico wrote:
>>
>> I've just updated PEP 671 https://www.python.org/dev/peps/pep-0671/
>> with some additional information about the reference implementation,
>> and some clarifications elsewhere.
>>
>>
>
> 1) If this feature existed in Python 3.11 exactly as described, would
> you use it?
>
Absolutely!
> 2) Independently: Is the syntactic distinction between "=" and "=>" a
> cognitive burden?
>
Nope, I don't think this is an undue cognitive burden. If anything I think
the symmetry between the
On Wed, Dec 1, 2021 at 1:18 AM Chris Angelico wrote:
> 1) If this feature existed in Python 3.11 exactly as described, would
> you use it?
>
No.
... except in the sense that as I trainer I have to teach the warts in
Python, and would need to warn students they might see that.
> 2) Independent
On Wed, 1 Dec 2021 at 06:19, Chris Angelico wrote:
>
> I've just updated PEP 671 https://www.python.org/dev/peps/pep-0671/
> with some additional information about the reference implementation,
> and some clarifications elsewhere.
>
> *PEP 671: Syntax for late-bound function argument defaults*
>
>
On Wed, Dec 1, 2021 at 7:51 AM Chris Angelico wrote:
> On Wed, Dec 1, 2021 at 10:30 PM André Roberge
> wrote:
>
> >> 2) Independently: Is the syntactic distinction between "=" and "=>" a
> >> cognitive burden?
> >
> > Yes.
> > I really think that using a keyword like defer, or from_calling_scope
On Thu, Dec 2, 2021 at 12:42 AM David Mertz, Ph.D.
wrote:
>> 4) If "no" to question 1, is there some other spelling or other small
>> change that WOULD mean you would use it? (Some examples in the PEP.)
>
>
> Yes, the delay/later/defer keyword approach is not confusing, and does not
> preempt a l
On Thu, Dec 2, 2021 at 1:21 AM Paul Moore wrote:
>
> On Wed, 1 Dec 2021 at 06:19, Chris Angelico wrote:
> > 3) If "yes" to question 1, would you use it for any/all of (a) mutable
> > defaults, (b) referencing things that might have changed, (c)
> > referencing other arguments, (d) something else?
On Wed, Dec 1, 2021 at 9:24 AM Paul Moore wrote:
> I think that the only
> thing I might use it for is to make it easier to annotate defaults (as
> f(a: list[int] => []) rather than as f(a: list[int] | None = None).
>
Why not `f(a: Optional[list[int]] = None)`?
I'm not counting characters, but
On Thu, Dec 2, 2021 at 2:24 AM David Mertz, Ph.D. wrote:
>
> On Wed, Dec 1, 2021 at 9:24 AM Paul Moore wrote:
>>
>> I think that the only
>> thing I might use it for is to make it easier to annotate defaults (as
>> f(a: list[int] => []) rather than as f(a: list[int] | None = None).
>
>
> Why not
On Thu, Dec 2, 2021 at 1:33 AM André Roberge wrote:
> On Wed, Dec 1, 2021 at 7:51 AM Chris Angelico wrote:
>>
>> On Wed, Dec 1, 2021 at 10:30 PM André Roberge
>> wrote:
>>
>> >> 2) Independently: Is the syntactic distinction between "=" and "=>" a
>> >> cognitive burden?
>> >
>> > Yes.
>> > I r
On Wed, Dec 1, 2021 at 10:12 AM Chris Angelico wrote:
> On Thu, Dec 2, 2021 at 12:42 AM David Mertz, Ph.D.
> wrote:
> >> 4) If "no" to question 1, is there some other spelling or other small
> >> change that WOULD mean you would use it? (Some examples in the PEP.)
> >
> > Yes, the delay/later/de
On Wed, 1 Dec 2021 at 15:24, David Mertz, Ph.D. wrote:
>
> On Wed, Dec 1, 2021 at 9:24 AM Paul Moore wrote:
>>
>> I think that the only
>> thing I might use it for is to make it easier to annotate defaults (as
>> f(a: list[int] => []) rather than as f(a: list[int] | None = None).
>
>
> Why not `f
Chris Angelico wrote:
> I've just updated PEP 671 https://www.python.org/dev/peps/pep-0671/
> Questions, for you all:
> 1) If this feature existed in Python 3.11 exactly as described, would
> you use it?
When needed, but I'm uncomfortable with the syntax.
> 2) Independently: Is the syntactic dist
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 bar(@baz=fo
On 11/30/21 10:16 PM, Chris Angelico wrote:
> *PEP 671: Syntax for late-bound function argument defaults*
>
> Questions, for you all:
>
> 1) If this feature existed in Python 3.11 exactly as described, would
> you use it?
No.
> 2) Independently: Is the syntactic distinction between "=" and "=>"
> *PEP 671: Syntax for late-bound function argument defaults*
>
> Questions, for you all:
>
> 1) If this feature existed in Python 3.11 exactly as described, would
> you use it?
Yes
> 2) Independently: Is the syntactic distinction between "=" and "=>" a
> cognitive burden?
No, but it will be co
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 pr
On Thu, Dec 2, 2021 at 2:40 AM David Mertz, Ph.D. wrote:
>
> On Wed, Dec 1, 2021 at 10:12 AM Chris Angelico wrote:
>>
>> On Thu, Dec 2, 2021 at 12:42 AM David Mertz, Ph.D.
>> wrote:
>> >> 4) If "no" to question 1, is there some other spelling or other small
>> >> change that WOULD mean you would
> On 1 Dec 2021, at 06:16, Chris Angelico wrote:
>
> I've just updated PEP 671 https://www.python.org/dev/peps/pep-0671/
> with some additional information about the reference implementation,
> and some clarifications elsewhere.
>
> *PEP 671: Syntax for late-bound function argument defaults*
>
On Thu, Dec 2, 2021 at 4:40 AM Barry Scott wrote:
>
> On 1 Dec 2021, at 06:16, Chris Angelico wrote:
> 3) If "yes" to question 1, would you use it for any/all of (a) mutable
> defaults, (b) referencing things that might have changed, (c)
> referencing other arguments, (d) something else?
>
>
> ye
> On 1 Dec 2021, at 17:59, Chris Angelico wrote:
>
> On Thu, Dec 2, 2021 at 4:40 AM Barry Scott wrote:
>>
>> On 1 Dec 2021, at 06:16, Chris Angelico wrote:
>> 3) If "yes" to question 1, would you use it for any/all of (a) mutable
>> defaults, (b) referencing things that might have changed,
On Thu, Dec 2, 2021 at 8:50 AM Barry Scott wrote:
>
>
>
> > On 1 Dec 2021, at 17:59, Chris Angelico wrote:
> >
> > On Thu, Dec 2, 2021 at 4:40 AM Barry Scott wrote:
> >>
> >> On 1 Dec 2021, at 06:16, Chris Angelico wrote:
> >> 3) If "yes" to question 1, would you use it for any/all of (a) mutab
On 2/12/21 4:40 am, Paul Moore wrote:
the
intended use is that people must supply a list[int] or not supply the
argument *at all*.
I don't think this is a style of API that we should be encouraging
people to create, because it results in things that are very
awkward to wrap.
--
Greg
__
To be honest, I like the `@param=value` syntax. It is sort of easier to read
than `param=>value`, though I do not have problems with distinguishing the
arrow `=>` from other things.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe
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 :) Thank
On Wed, Dec 01, 2021 at 12:26:33PM +, Matt del Valle wrote:
> If anything I think
> the symmetry between the proposed '=>' syntax and the arrow syntax for
> lambdas in other languages (potentially even in python in the future)
> reduces the cognitive burden significantly, given the there is an
On Thu, Dec 2, 2021 at 1:30 PM Steven D'Aprano wrote:
>
> On Wed, Dec 01, 2021 at 12:26:33PM +, Matt del Valle wrote:
>
> > If anything I think
> > the symmetry between the proposed '=>' syntax and the arrow syntax for
> > lambdas in other languages (potentially even in python in the future)
>
On Wed, Dec 01, 2021 at 05:16:34PM +1100, Chris Angelico wrote:
> 1) If this feature existed in Python 3.11 exactly as described, would
> you use it?
Yes I would, but probably not as often as counting cases of the "if
param is None: ..." idiom might lead you to expect.
The problem is, as Neil a
On Wed, Dec 1, 2021, 10:38 PM Steven D'Aprano
> "If param is missing **or None**, the default if blah..."
> I reject Chris' characterisation of this as a hack. There are function
> parameters where None will *never* in any conceivable circumstances become
> a valid argument value, and it is safe t
I like the => syntax and would use it probably 80% of the time for mutable
defaults.
I don't think it causes cognitive load.
I especially disagree with the argument that it looks like arbitrary
symbols and adds more 'line noise' than a keyword. My eye picks it up as a
distinct arrow rather than a
Steven D'Aprano
""If param is missing **or None**, the default if blah..."
I reject Chris' characterisation of this as a hack. There are function
parameters where None will *never* in any conceivable circumstances
become a valid argument value, and it is safe to use it as a sentinel."
Yes, we kno
2% of functions is a lot of functions. We're talking about a language
that's been around 30 years. The feature set is pretty mature. If it were
lacking features that would improve a much larger percent of code for so
long, I don't think it would be as popular. It's not like the next PIP is
goin
Exactly like you. I can read => to mean late-bound or supposedly lambda
function and I can distinguish it from the callable typing -> but
"@param=value” is definitely better in my eyes. => won’t prevent me from using
it for default mutable objects.
> On 2 Dec 2021, at 3:45 AM, Jeremiah Vivian
On 2021-11-30 22:16, Chris Angelico wrote:
I've just updated PEP 671 https://www.python.org/dev/peps/pep-0671/
with some additional information about the reference implementation,
and some clarifications elsewhere.
*PEP 671: Syntax for late-bound function argument defaults*
Questions, for you a
Brendan Barnwell wrote:
> > No. As I mentioned in the earlier thread, I don't support any proposal
> in which an argument can "have a default" but that default is not a
> first-class Python object of some sort.
What if a default is a function?
I was inspired by learning Django and saw in model
On 2021-12-01 18:35, Chris Angelico wrote:
In my reference implementation, there is no object that stores it;
it's simply part of the function. A good parallel is the if/else
expression:
x = float("inf") if z == 0 else y/z
Is there an object that represents the if/else expression (or the
deferr
On Thu, Dec 2, 2021 at 6:12 PM wrote:
>
> Brendan Barnwell wrote:
> > > No. As I mentioned in the earlier thread, I don't support any proposal
> > in which an argument can "have a default" but that default is not a
> > first-class Python object of some sort.
>
> What if a default is a function?
>
On Thu, Dec 2, 2021 at 6:27 PM Brendan Barnwell wrote:
>
> On 2021-12-01 18:35, Chris Angelico wrote:
> > In my reference implementation, there is no object that stores it;
> > it's simply part of the function. A good parallel is the if/else
> > expression:
> >
> > x = float("inf") if z == 0 else
On 2021-12-01 23:36, Chris Angelico wrote:
That's exactly why it's such a close parallel. The late-evaluated
default is just code, nothing else. It's not "stored" in any way - it
is evaluated as part of the function beginning execution.
But it IS stored! There is no way for it to be evaluated
54 matches
Mail list logo
