date:20211026

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

2021-10-26 Thread Brendan Barnwell


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 machine-readable signature, which is also what would
be used for tab completion or other tools, lo gets a very useful
default, but hi gets a default of None.


	How would tab completion work with this new feature?  How could a 
late-bound default be tab-completed?  Usually when I've used 
tab-completion with function arguments it's only completing the argument 
name, not the default value.



For the key argument, None makes a very meaningful default; it means
that no transformation is done. But in the case of hi, the default
really and truly is len(a), but because of a technical limitation,
that can't be written that way.


Here is some code:

def foo():
for a in x:
print(a)
for b in x:
print(b)

other_func(foo)

Due to a technical limitation, I cannot write foo as a lambda 
to pass it inline as an argument to foo.  Is this also a problem?  If 
so, should we develop the ever-whispered-about multiline lambda syntax?


	Yes, there are some kinds of default behaviors that cannot be 
syntactically written inline in the function signature.  I don't see 
that as a huge problem.  The fact that you want to write `len(a)` in 
such a case is not, for me, sufficient justification for all the other 
cans of worms opened by this proposal (as seen in various subthreads on 
this list), to say nothing of the additional burden on learners or on 
readers of code who now must add this to their list of things they have 
to grok when reading code.



Suppose this function were written as:

bisect_right(a, x, lo=None, hi=None, *, key=None)

Do we really need the ability to specify actual function defaults? I
mean, you can just have a single line of code "if lo is None: lo = 0"
and it'd be fine. Why do we need the ability to put "lo=0" in the
signature? I put it to you that the same justification should be valid
for hi.


	I understand what you're saying, but I just don't agree.  For one 
thing, functions are written once and called many times.  Normal default 
arguments provide a major leverage effect: a single default argument 
value can simplify many calls to the function from many call sites, 
because you can (potentially) omit certain arguments at every call. 
Late-bound defaults provide no additional simplicity at the call sites; 
all they do is permit a more terse spelling at the function definition 
site.  Since the definition only has to be written once, a bit more 
verbosity there is not so much of a burden.


	Also, the attempt to squeeze both kinds of defaults into the signature 
breaks the clear and simple rule we have, which is that the signature 
line is completely evaluated right away (i.e., it is part of the 
enclosing scope).  Right now we have a clean separation between the 
function definition and the body, which this proposal will muddy quite 
profoundly.  The problem is exacerbated by the proposed syntaxes, nearly 
all of which I find ugly to varying degrees.  But I think even with the 
best syntax, the underlying problem remains that switching back and 
forth between definition-scope and body-scope within the signature is 
confusing.


	Finally, I think a big problem with the proposal for me is that it 
really only targets what I see as a quite special case, which is 
late-bound expressions that are small enough to readably fit in the 
argument list.  All of the arguments (har har) about readability go out 
the window if people start putting anything complex in there.  Similarly 
if there is any more complex logic required (such as combinations of 
arguments whose defaults are interdependent in nontrivial ways) that 
cannot easily be expressed in separable argument defaults, we're still 
going to have to do it in the function body anyway.  So we are adding an 
entirely new complication to the basic argument syntax just to handle 
(what I see as) a quite narrow range of expressions.


--
Brendan Barnwell
"Do not follow where the path may lead.  Go, instead, where there is no 
path, and leave a trail."

   --author unknown
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/X3OO4KV4GSJ5CV7OCEZRZAAY7Z2T6V55/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

2021-10-26 Thread Christopher Barker

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 list that there should
be a way to get a slice view (or slice iterator, AKA islice) easily :-)

You can use itertools.islice for this though -- oops, no you can't:

TypeError Traceback (most recent call last)
 in 
> 1 result = bisect.bisect_right(islice(a, lo, hi), x)

TypeError: object of type 'itertools.islice' has no len()

We really do need a slice view :-)

-CHB

-- 
Christopher Barker, PhD (Chris)

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/F2CITCVKT3E3RHCH7UUFDUURIBQLJI65/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

2021-10-26 Thread Christopher Barker

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:
>  ...
>
> That function would be transformed to:
>
>  def bisect_right(a, x, lo=0, @hi=len(a), *, key=None):
>  if hi is None:
>  hi = len(a)
>  while lo < hi:
>

> Notice that the `None` check is still in the body -- why?  Backwards
> compatibility:

Of course. personally, I don't think there's any reason to go in and change
the standard library at all.

This is a feature for new code, new APIs. *maybe* a long time from now,
some stdlib APIs could be updated, but no hurry.

This seems like a lot of effort for a very marginal gain.
>

marginal gain to the stdlib, yes of course.

Though now that you mention it -- there would be some marginal game even to
functions like that, making the function signature a bit more clear.

Interestingly, though, here's bisect's docstring:

In [14]: bisect.bisect?
Docstring:
bisect_right(a, x[, lo[, hi]]) -> index

Return the index where to insert item x in list a, assuming a is sorted.

The return value i is such that all e in a[:i] have e <= x, and all e in
a[i:] have e > x.  So if x already appears in the list, i points just
beyond the rightmost x already there

Optional args lo (default 0) and hi (default len(a)) bound the
slice of a to be searched.
Type:  builtin_function_or_method

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)
---
TypeError Traceback (most recent call last)
 in 
> 1 bisect.bisect([1,3,4,6,8,9], 5, hi=None)

TypeError: 'NoneType' object cannot be interpreted as an integer

I guess that's because in C there is a way to define optional other than
using a sentinel? or it's using an undocumented sentinal?

Note: that's python 3.8 -- I can't imagine anything;s changed, but ...

-CHB

-- 
Christopher Barker, PhD (Chris)

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/NUYBMMBIEHLLIJL6M36OKIGWI3E5DIBZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

2021-10-26 Thread 2QdxY4RzWzUUiLuE

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 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, including the walrus).  The benefit of
> > this PEP simply does not justify the added complexity of the language as
> > a whole.  Using None (or some sentinel) and including code to check for
> > it works fine.  It's not worth it to add a whole new layer of behavior
> > to something as basic as argument-passing just to avoid having to type
> > `if arg is None`.
> >
> 
> >>> 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.

[...]

> Suppose this function were written as:
> 
> bisect_right(a, x, lo=None, hi=None, *, key=None)
> 
> Do we really need the ability to specify actual function defaults? I
> mean, you can just have a single line of code "if lo is None: lo = 0"
> and it'd be fine. Why do we need the ability to put "lo=0" in the
> signature? I put it to you that the same justification should be valid
> for hi.

I agree.  Why do we need the ability to put "lo=0" in the signature?  If
we have to rewrite parts of bisect_right for late binding anyway, then
why not go all out?  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?  Then
provide two functions:

def bisect_right(a, x, key=None):
return bisect_slice_right(a, x, 0, len(a), key)

def bisect_slice_right(a, x, lo, hi, key=None):
"actual guts of bisect function go here"
"don't actually slice a; that might be really expensive"

No extraneous logic to (re)compute default values at all.  Probably
fewer/simpler units tests, too, but that might depend on the programmer
or other organizational considerations.  On the other side, parts of doc
strings may end up being duplicated, and flat is better than nested.

(No, I don't know the backwards compatibility issues that might arise
from re-writing bisect_right in this manner, nor do I know what the
options are to satisfy IDEs and/or users thereof.)

Running with Brandon Barnwell's point, is there a lot of code that gets
a lot simpler (and who gets to define "simpler"?) with late binding
default values?  Can that same code achieve the same outcome by being
refactored the same way as I did bisect_right?  I'm willing to accept
that my revised bisect_right is horrible by some reasonably objective
standard, too.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/JYKWRN6KMW4KOSFFTXAZ3EDFETQKIAEP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

2021-10-26 Thread Chris Angelico

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) and
> I don't think it has yet been addressed.
>
> 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:
>  ...
>
> That function would be transformed to:
>
>  def bisect_right(a, x, lo=0, @hi=len(a), *, key=None):
>  if hi is None:
>  hi = len(a)
>  while lo < hi:
>  ...
>
>
> Notice that the `None` check is still in the body -- why?  Backwards 
> compatibility: there is code out there that
> actually passes in `None` for `hi`, and removing the None-check in the body 
> will suddenly cause TypeErrors.
>
> This seems like a lot of effort for a very marginal gain.
>

The question then becomes: How important is this feature of being able
to pass None as a stand-in for the length of the list? If it's
important, then don't change the style of the code at all. But since
help(bisect) clearly states that the default is len(a), and doesn't
say anything about passing None, so it would be just as valid to deem
such code to be buggy. Obviously that decision has to be made
individually for each use-case, but one thing is clear: newly-defined
APIs will not need to have None-pollution in this way. Also, anything
that uses a dedicated sentinel should be safe to convert; consider:

# Inspired by socket.create_connection, but simplified:
_USE_GLOBAL_DEFAULT = object()
def connect(timeout=_USE_GLOBAL_DEFAULT):
if timeout is _USE_GLOBAL_DEFAULT:
timeout = default_timeout

If any outside caller is reaching into the module and referring to
this underscore-preceded name, it is buggy, and I would have no qualms
in breaking that code. (The inspiration for this can't actually be
converted, since socket.create_connection with the global default just
doesn't call the settimeout() method, but there will be other cases
where the same applies.)

As with every new feature, a decision has to be made as to whether old
code should be changed. This is no different, but I do believe that in
many cases, it will be safe to do so.

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/YBJS3EJOLRKS4FSJDGXNVBMHRM6LQQZH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

2021-10-26 Thread Ethan Furman

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()` 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:
...

That function would be transformed to:

def bisect_right(a, x, lo=0, @hi=len(a), *, key=None):
if hi is None:
hi = len(a)
while lo < hi:
...

Notice that the `None` check is still in the body -- why?  Backwards compatibility: there is code out there that 
actually passes in `None` for `hi`, and removing the None-check in the body will suddenly cause TypeErrors.

This seems like a lot of effort for a very marginal gain.

--
~Ethan~
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/VGCI7N3NHB4HBPKFBV2DWTJSJBRT3SGV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

2021-10-26 Thread Chris Angelico

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 biggest reason why I
> > don't want this "feature" (or any of another gazillion features that
> > have been suggested and/or accepted here, including the walrus).  The
> > benefit of this PEP simply does not justify the added complexity of
> > the language as a whole.  Using None (or some sentinel) and including
> > code to check for it works fine.  It's not worth it to add a whole new
> > layer of behavior to something as basic as argument-passing just to
> > avoid having to type `if arg is None`.
> >
> While I disagree with you re this particular feature, I sympathise with
> the general sentiment.  Perhaps the first objective of Python 4 should
> be to get rid of as many features as possible.  Just like when you're
> forced to throw out all your precious old junk (school reports, prizes,
> the present from Aunt Maud, theatre programmes, books you never read,
> clothes you never wear .).
>
> Nah, who am I kidding?  Each feature will have its band of devotees that
> will defend it TO THE DEATH!  Of course, what it should REALLY have are
> all MY favorite features, including some that haven't been added yet.

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 other tools for
processing partial data; all we really need is a class with the
appropriate state management. And there are people who genuinely
prefer coding a state machine to writing a generator function. No
problem! You're welcome to. But the language is richer for having
these tools, and we can more easily express our logic using them.

Each feature adds to the complexity of the language, but if they are
made as orthogonal as possible, they generally add linearly. But they
add exponentially to the expressiveness. Which ultimately means that
orthogonality is the greatest feature in language design; it allows
you to comprehend features one by one, and build up your mental
picture of the code in simple ways, while still having the full power
that it offers.

As an example of orthogonality, Python's current argument defaults
don't care whether you're working with integers, strings, lists, or
anything else. They always behave the same way: using one specific
value (object) to be the value given if one is not provided. They're
also completely orthogonal with argument passing styles (positional
and keyword), and which ones are valid for which parameters. And
orthogonal again with type annotations and type comments. All these
features go in the 'def' statement - or 'lambda', which has access to
nearly all the same features (it can't have type comments, but
everything else works) - but you don't have to worry about exponential
complexity, because there's no conflicts between them.

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 should be able to change "x=None" to "x=>[]"
without having to wonder whether you're stopping yourself from adding
a type annotation in the future. This is why I'm strongly inclined to
syntaxes that adorn the equals sign, rather than those which put
tokens elsewhere (eg "@x=[]"), because it keeps the default part
self-contained.

(It's actually quite fascinating how language design and game design
work in parallel. The challenges in making a game fair, balanced, and
fun are very similar to the challenges in making a language usable,
elegant, and clean. I guess it's because, ultimately, both design
challenges are about the humans who'll use the thing, and humans are
still humans.)

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/5MGUXX6RBADE7VLQ3DFTGIENQ22PVXHW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

2021-10-26 Thread Chris Angelico

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 discussion thread, and
highly informative; thank you for being a part of that! Now, if I
could just figure out what's going on in the grammar...

(Actually, the PEG parser is a lot easier to understand than Python's
older grammar was. But this is my first time messing with it, so I'm
going through all the stages of brand-new discovery.)

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/23ZL6RIKAA75V2OHFYL62CLBGJL4SCFT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

2021-10-26 Thread Brendan Barnwell

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 this "feature" (or any of another gazillion features that
have been suggested and/or accepted here, including the walrus). The
benefit of this PEP simply does not justify the added complexity of
the language as a whole. Using None (or some sentinel) and including
code to check for it works fine. It's not worth it to add a whole new
layer of behavior to something as basic as argument-passing just to
avoid having to type `if arg is None`.

While I disagree with you re this particular feature, I sympathise with
the general sentiment. Perhaps the first objective of Python 4 should
be to get rid of as many features as possible. Just like when you're
forced to throw out all your precious old junk (school reports, prizes,
the present from Aunt Maud, theatre programmes, books you never read,
clothes you never wear .).

Nah, who am I kidding? Each feature will have its band of devotees that
will defend it TO THE DEATH! Of course, what it should REALLY have are
all MY favorite features, including some that haven't been added yet.
Rob Cliffe

Now you're talking! 100% agree! Assuming of course that by "MY
favorite features" you mean, well, MY favorite features. . . :-)

--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."

--author unknown
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/HPUIM75DTUALTSOKHEIJK4SVFNFK3YXL/
Code of Conduct: http://python.org/psf/codeofconduct/

76 matches

Mail list logo