On 2021-10-26 20:15, Chris Angelico wrote:
One truism of language design is that the simpler the language is (and
the easier to explain to a novice), the harder it is to actually use.
For instance, we don't *need* async/await, or generators, or list
comprehensions, or for loops, or any of those o
On 2021-10-26 19:47, Chris Angelico wrote:
help(bisect.bisect)
bisect_right(a, x, lo=0, hi=None, *, key=None)
...
Optional args lo (default 0) and hi (default len(a)) bound the
slice of a to be searched.
In the docstring, both lo and hi are given useful, meaningful
defaults. In the m
a bit OT:
If you want to bisect a slice, then bisect a slice:
>
> result = bisect_right(a[lo:hi], x)
>
> Oh, wait, what if a has billions of elements and creating a slice
> containing a million or two out of the middle is too expensive?
Yup, that's why Iproposed about a year ago on this li
On Tue, Oct 26, 2021 at 8:29 PM Ethan Furman wrote:
> Using the `bisect()` function as a stand-in for the 20+ years worth of
> Python APIs in existence:
>
> def bisect_right(a, x, lo=0, hi=None, *, key=None):
> if hi is None:
> hi = len(a)
> while lo < hi:
>
On 2021-10-27 at 13:47:31 +1100,
Chris Angelico wrote:
> 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 i
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
> already (sorry, I don't remember who)
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 already (sorry, I don't remember who) and
I don't think it has yet been addressed.
Using the `bisect()`
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 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 2021-10-26 19:50, 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 biggest reason why I
don't want t
>From a "hobbyist / programming aesthete" perspective, I think this is a great
>idea. I think pattern matching in ML-descended languages is wonderfully
>elegant. Packing and unpacking tuples is already a common syntactic idiom in
>Python, and now that we have Structural Pattern Matching (SPM), i
On Tue, Oct 26, 2021 at 10:44 PM Chris Angelico wrote:
> 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 i
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 biggest reason why I
don't want this "feature" (or any of another gazillion features that
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: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 27/10/2021 00:26, Christopher Barker wrote:
I'm very confused about the apparent convergence on the token "=>" for
deferred parameter assignment.
1) As others have said, it sure feels like the arrow is going the
wrong way.
But the bigger question I have is with the similarity to lambda
On Tue, Oct 26, 2021, 9:54 PM Rob Cliffe via Python-ideas <
python-ideas@python.org> wrote:
>
>
> On 27/10/2021 01:47, Chris Angelico wrote:
> > The idea that a
> > parameter is optional, but doesn't have a value, may itself be worth
> > exploring (maybe some way to say "arg=pass" and then have an
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 gazillion features that have been
suggested and/or accepted here, inclu
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:
> > >
> > >> There has been support for evaluating all early-bo
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
> >> all late-bound defaults. I have been persuaded tha
On 27/10/2021 01:47, Chris Angelico wrote:
The idea that a
parameter is optional, but doesn't have a value, may itself be worth
exploring (maybe some way to say "arg=pass" and then have an operator
"if unset arg:" that returns True if it's unbound), but that's for
another day.
ChrisA
Indeed.
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
all late-bound defaults. I have been persuaded that this is a
reasonable option. AFAICS there would be little practical differ
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 Tue, Oct 26, 2021 at 5:24 PM Chris Angelico wrote:
> > How could that be avoided? by definition, early bound is evaluated
> "earlier" than late-bound :-)
> >
> > This could cause a bit of confusion with "getting" that it's not a
> simple left-to-right rule, but that's the same potential confu
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 Tue, Oct 26, 2021 at 4:46 PM Rob Cliffe via Python-ideas <
python-ideas@python.org> 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.
How could that be avoided? by definition, ea
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 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,
> >>> those WOULD be quite inconsistent, and some of t
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 superclass. The
"use None" convention works fine:
def __init__(self, somethin
On Tue, Oct 26, 2021 at 4:42 PM Chris Angelico wrote:
> Oops, I missed seeing that that's actually an early-bound, so my
> response was on the misinterpretation that the function was written
> thus:
>
> def fun(x, y=>(z:=3)):
>
> In which case it *would* add it to the function's namespace.
>
Tha
On Tue, Oct 26, 2021 at 4:37 PM 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)
> >...:
> >...:
>
> It doesn't. It adds it to the namespace in which t
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,
those WOULD be quite inconsistent, and some of them would make little
sense. It would also mean that there is a distinct semant
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 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 seems odd to me.
>
> In [9]: fun(2)
> 2 3 3
It doesn't. It adds it to the na
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 Tue, Oct 26, 2021, 7:20 PM Chris Angelico
> The truth is that there is no value that can be a truly universal
> representation of absence, so it *always* has to be specific to each API.
>
That's a fact about Python rather than a fact of programming in general.
For example, R has a NULL that is
Well, you just repeated what I said, and then again asserted:
On Tue, Oct 26, 2021 at 4:21 PM Chris Angelico wrote:
> The truth is that there is no value that can be a truly universal
> representation of absence, so it *always* has to be specific to each
> API.
>
But I don't see what that's the
I'm very confused about the apparent convergence on the token "=>" for
deferred parameter assignment.
1) As others have said, it sure feels like the arrow is going the wrong
way.
But the bigger question I have is with the similarity to lambda:
2) As I understand it, there's a good chance that "
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, you're going to need to talk about
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, you're going to need to talk about the _missing
> object, and you'll need to distinguish it from the abse
On Tue, Oct 26, 2021 at 1:35 PM Ethan Furman wrote:
> > to PASS SOMETHING that says "give me the default". With this proposed
> API, we don't
> > have that; the only want to say "give me the default" is to NOT pass
> something.
>
but that, in fact, is all that Python provides. yes, None indica
Greetings, this use case interests me.
Is anyone interested in coauthoring this with me? Anyone who has
> strong interest in seeing this happen - whether you've been around the
> Python lists for years, or you're new and interested in getting
> involved for the first time, or anywhere in between!
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 Tue, 26 Oct 2021, Ricky Teachey wrote:
At bottom I guess I'd describe the problem this way: with most APIs, there is a
way to PASS SOMETHING that says "give me the default". With this proposed API,
we
don't have that; the only want to say "give me the default" is to NOT pass
something.
I do
On 10/26/21 12:08 PM, Ricky Teachey wrote:
> On Tue, Oct 26, 2021 at 2:40 PM Chris Angelico wrote:
>> Do you have any examples where this isn't the case?
>
> I don't. I only have a niggling feeling that maybe this is a bigger problem
than
> we're giving it credit for.
>
> At bottom I guess I'd d
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 Tue, 26 Oct 2021 at 19:25, Chris Angelico wrote:
>
> 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
On Tue, Oct 26, 2021 at 2:40 PM Chris Angelico wrote:
> 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:
>
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 2021-10-25 18:56, Steven D'Aprano wrote:
Modifying the assignment symbol is wrong. This is not a new kind of
assignment, it should use the same `=` regular assignment. We are
tagging the parameter to use late-binding, not using a different sort of
assignment. The tag should be on the parameter
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 deferred objects. They're argument defaults. Consider:
> >
> >
On Tue, Oct 26, 2021 at 2:05 PM 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 Python
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 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 deferred objects. They're argument defaults. Consider:
def f(x=>print("Hello")):
...
When should that print happen? Argument defa
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 Python. I'll grant you that they might
> (might!) be more newbie-fri
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.
>> With this change, some would be v
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. With this change, some would be values and some would be markers
> saying that code would be executed.
On 26.10.2021 18:36, Erik Demaine wrote:
> On Tue, 26 Oct 2021, Marc-Andre Lemburg wrote:
>
>> Now, it may not be obvious, but the key advantage of such
>> deferred objects is that you can pass them around, i.e. the
>> "defer os.listdir(DEFAULT_DIR)" could also be passed in via
>> another function
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 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 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, 26 Oct 2021, Eric V. Smith wrote:
You may or may not recall that a big reason for the removal of "tuple
parameter unpacking" in PEP 3113 was that they couldn't be supported by the
inspect module. Quoting that PEP: "Python has very powerful introspection
capabilities. These extend to fu
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 main use
of early-bound defaults) together with late-bound def
On 10/26/2021 11:19 AM, Chris Angelico wrote:
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
BEst thing you can do is create an issue on bugs.python.org and attach a
pull request that makes _BaseNetwork a subclass of Sequence. Then maybe the
advantages will be clear -- or maybe in the process of writing the code you
realize that the idea is not so good after all. (I'm not a user of this
cl
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
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.
At the very least, the PEP needs to talk about inspect.Signature
objects, and how they would sup
Currently, ipaddress._BaseNetwork (and by extension, ipaddress.IPv4Network and
ipaddress.IPv6Network) does not have a __len__ method, it only has
num_addresses.
This makes the following code not work:
>>> random.choice(ipaddress.ip_network('6.0.0.0/8'))
Traceback (most recent call last):
File
On Tue, Oct 26, 2021 at 05:27:49PM +1100, Chris Angelico wrote:
> 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 expla
On 26.10.2021 10:54, Marc-Andre Lemburg wrote:
> [...]
> For the object version, the string would have to be compiled
> as well and then executed at the top of the function somehow :-)
>
> I think for the latter, we'd need a more generic concept of
> deferred execution in Python, but even then, yo
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
> > (could be a programmer new to Python
On 26/10/2021 02:56, Steven D'Aprano wrote:
On Tue, Oct 26, 2021 at 01:32:58AM +0100, Rob Cliffe via Python-ideas wrote:
Syntax bikeshedding: I still favour
var := expr
That clashes with the walrus operator. Remember that the walrus operator
can appear inside the expression:
var:=
On 26/10/2021 02:56, Steven D'Aprano wrote:
On Tue, Oct 26, 2021 at 01:32:58AM +0100, Rob Cliffe via Python-ideas wrote:
Syntax bikeshedding: I still favour
var := expr
That clashes with the walrus operator. Remember that the walrus operator
can appear inside the expression:
var:=
For the backwards compatibility section, it would be good to analyze how the
change impacts error reporting.
(1) is the suggested syntax currently a 'common error' that will become harder
to detect once it's not a syntax error?
(2) would adding this syntax impact the parser's ability to provide
On 25.10.2021 15:44, Chris Angelico wrote:
> 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 a
75 matches
Mail list logo
