[Python-ideas] Re: Keyword arguments self-assignment

Guys, is it really worth saving a few hits on the auto-complete key by adding even more mysterious twists to the existing Python function call syntax ? The current version already strikes me as way too complex. It's by far the most complex piece of grammar we have in Python: funcdef: 'def' NAME p

[Python-ideas] Re: Proposal: Keyword Unpacking Shortcut [was Re: Keyword arguments self-assignment]

On Sun, Apr 19, 2020 at 11:18 PM David Mertz wrote: > If this were in the library I or my project used, whatever limitations and > edge cases exist wouldn't really matter. If I REALLY cared about saving a > few duplicate names in function calls, I could easily include it with the > knowledge tha

[Python-ideas] Re: Proposal: Keyword Unpacking Shortcut [was Re: Keyword arguments self-assignment]

On Mon, Apr 20, 2020 at 2:48 AM Steven D'Aprano wrote: > On Sun, Apr 19, 2020 at 02:10:21PM +0200, Alex Hall wrote: > > > > > > And notice that there is absolutely no difficulty with some future > > > enhancement to allow positional arguments after keyword arguments. > > > > > > > We've already d

[Python-ideas] Re: Proposal: Keyword Unpacking Shortcut [was Re: Keyword arguments self-assignment]

On Mon, Apr 20, 2020 at 11:15:32AM +0200, Alex Hall wrote: > On Mon, Apr 20, 2020 at 2:48 AM Steven D'Aprano wrote: > > > On Sun, Apr 19, 2020 at 02:10:21PM +0200, Alex Hall wrote: > > > > > > > > And notice that there is absolutely no difficulty with some future > > > > enhancement to allow posi

[Python-ideas] Re: Keyword arguments self-assignment

On Mon, Apr 20, 2020 at 10:03:50AM +0200, M.-A. Lemburg wrote: > Guys, is it really worth saving a few hits on the auto-complete key > by adding even more mysterious twists to the existing Python function > call syntax ? > > The current version already strikes me as way too complex. > It's by far

[Python-ideas] Re: Proposal: Keyword Unpacking Shortcut [was Re: Keyword arguments self-assignment]

> I'm saying that the mode-shift suggestion: > > func(arg, name=value, > *, # change to auto-fill mode > alpha, beta, gamma, > ) > > will rule out any further relaxation on that restriction, and that is a > point against it. That's a concrete enhancement that we mig

[Python-ideas] Re: Keyword arguments self-assignment

On 4/20/2020 7:00 AM, Steven D'Aprano wrote: On Mon, Apr 20, 2020 at 10:03:50AM +0200, M.-A. Lemburg wrote: Guys, is it really worth saving a few hits on the auto-complete key by adding even more mysterious twists to the existing Python function call syntax ? The current version already strikes

[Python-ideas] Re: Keyword arguments self-assignment

On 20.04.2020 13:00, Steven D'Aprano wrote: > On Mon, Apr 20, 2020 at 10:03:50AM +0200, M.-A. Lemburg wrote: >> Guys, is it really worth saving a few hits on the auto-complete key >> by adding even more mysterious twists to the existing Python function >> call syntax ? >> >> The current version alr

[Python-ideas] Re: Keyword arguments self-assignment

On Mon, 20 Apr 2020 at 12:19, Eric V. Smith wrote: > On 4/20/2020 7:00 AM, Steven D'Aprano wrote: > > On Mon, Apr 20, 2020 at 10:03:50AM +0200, M.-A. Lemburg wrote: > >> Guys, is it really worth saving a few hits on the auto-complete key > >> by adding even more mysterious twists to the existing

[Python-ideas] Re: Keyword arguments self-assignment

On 4/20/2020 7:27 AM, Ivan Levkivskyi wrote: On Mon, 20 Apr 2020 at 12:19, Eric V. Smith > wrote: See PEP 3113, which doesn't mention parsing. My understanding is that it was the introspection problem that drove this. And on very rare occasions, I rea

[Python-ideas] Re: Proposal: Keyword Unpacking Shortcut [was Re: Keyword arguments self-assignment]

On 20.04.20 12:52, Steven D'Aprano wrote: On Mon, Apr 20, 2020 at 11:15:32AM +0200, Alex Hall wrote: On Mon, Apr 20, 2020 at 2:48 AM Steven D'Aprano wrote: I have an actual, concrete possible enhancement in mind: relaxing the restriction on parameter order. What? Do you think that the curre

[Python-ideas] Re: Proposal: Keyword Unpacking Shortcut [was Re: Keyword arguments self-assignment]

On Mon, Apr 20, 2020 at 12:57 PM Steven D'Aprano wrote: > On Mon, Apr 20, 2020 at 11:15:32AM +0200, Alex Hall wrote: > > On Mon, Apr 20, 2020 at 2:48 AM Steven D'Aprano > wrote: > > > > > On Sun, Apr 19, 2020 at 02:10:21PM +0200, Alex Hall wrote: > > > > > > > > > > And notice that there is abso

[Python-ideas] list.append(x) could return x

Hi all, Currently, list.append(x) mutates the list and returns None. It would be a little syntactic sugar to return x, for example: something = mylist.append(Something()) What do you think ? Thanks in advance for your replies -- ∞ ___ Python-id

[Python-ideas] Re: list.append(x) could return x

It is a standard convention in Python that mutating methods return None. While that does make chaining operations harder (impossible), it is a consistent convention that makes it much harder to get confused about whether a method mutates or not. It is not going to change. See previous threads ab

[Python-ideas] Re: list.append(x) could return x

On 20/04/2020 16:25, J. Pic wrote: Hi all, Currently, list.append(x) mutates the list and returns None. It would be a little syntactic sugar to return x, for example: something = mylist.append(Something()) What do you think ? I'm generally opposed to trying to do too many things on one

[Python-ideas] Re: list.append(x) could return x

On 4/20/20 11:25 AM, J. Pic wrote: Hi all, Currently, list.append(x) mutates the list and returns None. It would be a little syntactic sugar to return x, for example:     something = mylist.append(Something()) What do you think ? Now you can do this (but it could be unpopular):     mylist.

[Python-ideas] Re: list.append(x) could return x

On 20/04/2020 16:57, Christopher Barker wrote: It is a standard convention in Python that mutating methods return None. While that does make chaining operations harder (impossible), it is a consistent convention that makes it much harder to get confused about whether a method mutates or not. It

[Python-ideas] Re: list.append(x) could return x

On 4/20/20 11:25 AM, J. Pic wrote: > Hi all, > > Currently, list.append(x) mutates the list and returns None. > > It would be a little syntactic sugar to return x, for example: > >     something = mylist.append(Something()) > > What do you think ? > > Thanks in advance for your replies I think the

[Python-ideas] Re: list.append(x) could return x

On Apr 20, 2020, at 08:41, J. Pic wrote: > > > Currently, list.append(x) mutates the list and returns None. Yes, which is consistent with the vast majority of mutating methods in Python. It would be pretty weird to make lst.append(x) return x, while lst.extend(xs) still returns None, not to m

[Python-ideas] Re: list.append(x) could return x

On 4/20/2020 9:25 AM, J. Pic wrote: Hi all, Currently, list.append(x) mutates the list and returns None. It would be a little syntactic sugar to return x, for example:     something = mylist.append(Something()) What do you think ? Thanks in advance for your replies The following is not

[Python-ideas] Re: list.append(x) could return x

On Mon, Apr 20, 2020 at 10:07 AM gyro funch wrote: > On 4/20/2020 9:25 AM, J. Pic wrote: > The following is not currently possible, but is consistent with other > functions such as 'sorted': > > something = mylist.appended(Something()) > no, it's not -- sorted() is a function, not a method. and

[Python-ideas] Re: Keyword arguments self-assignment

On Sun, Apr 19, 2020 at 3:37 AM Alex Hall wrote: > ``` > File "setup.py", line 2232 > self.add(Extension('_decimal', >include_dirs=include_dirs, >libraries=libraries, >define_macros=define_macros, >

[Python-ideas] zip(x, y, z, strict=True)

Here's something that would have saved me some debugging yesterday: >>> zipped = zip(x, y, z, strict=True) I suggest that `strict=True` would ensure that all the iterables have been exhausted, raising an exception otherwise. This is useful in cases where you're assuming that the iterables al

[Python-ideas] Re: Keyword arguments self-assignment

On Apr 20, 2020, at 01:06, M.-A. Lemburg wrote: > > The current version already strikes me as way too complex. > It's by far the most complex piece of grammar we have in Python: > > funcdef: 'def' NAME parameters ['->' test] ':' [TYPE_COMMENT] > func_body_suite But nobody’s proposing changing t

[Python-ideas] Re: zip(x, y, z, strict=True)

On Apr 20, 2020, at 10:42, Ram Rachum wrote: >  > Here's something that would have saved me some debugging yesterday: > > >>> zipped = zip(x, y, z, strict=True) > > I suggest that `strict=True` would ensure that all the iterables have been > exhausted, raising an exception otherwise. This

[Python-ideas] Re: list.append(x) could return x

On 4/20/2020 11:18 AM, Christopher Barker wrote: On Mon, Apr 20, 2020 at 10:07 AM gyro funch > wrote: On 4/20/2020 9:25 AM, J. Pic wrote: The following is not currently possible, but is consistent with other functions such as 'sorted': something =

[Python-ideas] Re: Keyword arguments self-assignment

On Sun, Apr 19, 2020 at 8:29 AM David Mertz wrote: > On Sun, Apr 19, 2020, 7:24 AM Richard Damon > wrote: > >> One of the key motivations of this proposal is to make nicer a call with >> a lot of key word arguments where the local variable name happens >> (intentionally) to match the keyword par

[Python-ideas] Re: zip(x, y, z, strict=True)

> This is definitely sometimes useful, but I think less often than zip_longest, > which we already decided long ago isn’t important enough to push into zip but > instead should be a separate function living in itertools. I disagree. In my own personal experience, ~80% of the time when I use `zip

[Python-ideas] Re: zip(x, y, z, strict=True)

On Mon, 20 Apr 2020 18:25:08 - "Brandt Bucher" wrote: > > This is definitely sometimes useful, but I think less often than > > zip_longest, which we already decided long ago isn’t important enough to > > push into zip but instead should be a separate function living in > > itertools. >

[Python-ideas] Re: list.append(x) could return x

TBH I had read about mutating methods returning None, and the fluent thread, I just didn't make the relation. Thanks Ned for the assignment operator reminder, that solves my use case perfectly. Have a great day Also, I love you <3 ___ Python-ideas mai

[Python-ideas] Re: Keyword arguments self-assignment

On Apr 20, 2020, at 11:01, Christopher Barker wrote: > > The JSON - related example is a good one -- JSON maps well to "data" in > Python, dicts and lists of numbers and strings. If you find yourself > converting a bunch of variable names to/from JSON, you probably should be > simply using a d

[Python-ideas] Re: zip(x, y, z, strict=True)

On Apr 20, 2020, at 11:25, Brandt Bucher wrote: > > I disagree. In my own personal experience, ~80% of the time when I use `zip` > there is an assumption that all of the iterables are the same length. Sure, but I think cases where you want that assumption _checked_ are a lot less common. There

[Python-ideas] Re: zip(x, y, z, strict=True)

+1. I implemented my own zip (because exceptions[1]) and it's so easy to accidentally have length-related bugs everywhere because your tests are just stopping short with no error. [1] https://creationix.github.io/http-clone/?https://soniex2.autistic.space/git-repos/abdl.git#cbdcd9dd71f3215520b

[Python-ideas] Re: zip(x, y, z, strict=True)

On 4/20/2020 3:39 PM, Andrew Barnert via Python-ideas wrote: On Apr 20, 2020, at 11:25, Brandt Bucher wrote: I disagree. In my own personal experience, ~80% of the time when I use `zip` there is an assumption that all of the iterables are the same length. Sure, but I think cases where you wan

[Python-ideas] Re: Keyword arguments self-assignment

On Mon, Apr 20, 2020 at 5:04 AM Steven D'Aprano wrote: > On Sun, Apr 19, 2020 at 06:06:50PM +0200, Alex Hall wrote: > > Sorry, what? How is there any doubt that the arguments being passed are > > dunder, invert, private, meta, and ignorecase? They're right there. > > That tells us the meaning of

[Python-ideas] Re: zip(x, y, z, strict=True)

On Apr 20, 2020, at 13:03, Eric V. Smith wrote: > > On 4/20/2020 3:39 PM, Andrew Barnert via Python-ideas wrote: >> >> >> As I said, wanting to check does come up sometimes—I know I have written >> this myself at least once, and I’d be a little surprised if it’s not in >> more-itertools. >

[Python-ideas] Re: zip(x, y, z, strict=True)

On Apr 20, 2020, at 10:42, Ram Rachum wrote: > > Here's something that would have saved me some debugging yesterday: > > >>> zipped = zip(x, y, z, strict=True) > > I suggest that `strict=True` would ensure that all the iterables have been > exhausted, raising an exception otherwise. One q

[Python-ideas] Re: Keyword arguments self-assignment

On Mon, Apr 20, 2020 at 12:17 PM Andrew Barnert wrote: > On Apr 20, 2020, at 11:01, Christopher Barker wrote: > > The JSON - related example is a good one -- JSON maps well to "data" in > Python, dicts and lists of numbers and strings. If you find yourself > converting a bunch of variable names

[Python-ideas] Re: Keyword arguments self-assignment

On Mon, Apr 20, 2020 at 1:35 PM Alex Hall wrote: > > So let's assume that a beginner is likely to notice arguments out of order > and think that something is wrong, and focus on what happens from there. I > think it's fair to say that the main concern is that they will have to look > up and learn

[Python-ideas] Re: Keyword arguments self-assignment

On Mon, Apr 20, 2020 at 7:37 PM Christopher Barker wrote: > On Sun, Apr 19, 2020 at 3:37 AM Alex Hall wrote: > >> ``` >> File "setup.py", line 2232 >> self.add(Extension('_decimal', >>include_dirs=include_dirs, >>libraries=libraries

[Python-ideas] Re: zip(x, y, z, strict=True)

Good point. It would have to be dependent on position. In other words, you would never pass an iterator into zip with any expectation that it would be in a usable condition by the time it's done. Actually, I can't think of any current scenario in which someone would want to do this, with the exist

[Python-ideas] Re: Keyword arguments self-assignment

On 2020-04-20 18:43, Andrew Barnert via Python-ideas wrote: On Apr 20, 2020, at 01:06, M.-A. Lemburg wrote: The current version already strikes me as way too complex. It's by far the most complex piece of grammar we have in Python: funcdef: 'def' NAME parameters ['->' test] ':' [TYPE_COMMENT]

[Python-ideas] Re: Keyword arguments self-assignment

On Apr 20, 2020, at 13:42, Christopher Barker wrote: > > On Mon, Apr 20, 2020 at 12:17 PM Andrew Barnert wrote: >> >> A lot of JSON is designed to be consumed by JavaScript, where there is no >> real line (there is no dict type; objects have both dict-style and dot-style >> access). So in pr

[Python-ideas] Re: Keyword arguments self-assignment

On Mon, Apr 20, 2020 at 10:46 PM Christopher Barker wrote: > On Mon, Apr 20, 2020 at 1:35 PM Alex Hall wrote: > >> >> So let's assume that a beginner is likely to notice arguments out of >> order and think that something is wrong, and focus on what happens from >> there. I think it's fair to say

[Python-ideas] Re: zip(x, y, z, strict=True)

> > x = iter(range(5)) > y = [0] > try: > zipped = zip(x, y, strict=True) > except ValueError: # assuming that’s the exception you want? > print(next(x)) > > Should this print 1 or 2 or raise StopIteration or be a don’t-care? Surely no exception is raised because

[Python-ideas] Re: zip(x, y, z, strict=True)

On Apr 20, 2020, at 13:49, Ram Rachum wrote: > > Good point. It would have to be dependent on position. In other words, you > would never pass an iterator into zip with any expectation that it would be > in a usable condition by the time it's done. > > Actually, I can't think of any current sc

[Python-ideas] Re: zip(x, y, z, strict=True)

Alex Hall wrote: > Surely no exception is raised because zip is lazy? Ack, you're right. The same problem would come up wherever you actually _use_ the zip, of course, but it's harder to demonstrate and reason about. So change that toy example to `zipped = list(zip(x, y, strict=True))`. (Fortun

[Python-ideas] Re: Keyword arguments self-assignment

On 20.04.2020 19:43, Andrew Barnert via Python-ideas wrote: > On Apr 20, 2020, at 01:06, M.-A. Lemburg wrote: >> >> The current version already strikes me as way too complex. >> It's by far the most complex piece of grammar we have in Python: >> >> funcdef: 'def' NAME parameters ['->' test] ':' [T

[Python-ideas] Re: Keyword arguments self-assignment

On Mon, Apr 20, 2020 at 3:13 PM Andrew Barnert wrote: > Sure, it’s a declarative format, it’s just that often it’s intended to be understood as representing an object graph. I"m not sure the point here -- I was not getting onto detail nor expalingnoi myself well, but I think there are (kind of) t

[Python-ideas] Re: Keyword arguments self-assignment

On Mon, Apr 20, 2020 at 1:47 PM Alex Hall wrote: > On Mon, Apr 20, 2020 at 7:37 PM Christopher Barker > wrote: > >> On Sun, Apr 19, 2020 at 3:37 AM Alex Hall wrote: >> >>> ``` >>> File "setup.py", line 2232 >>> self.add(Extension('_decimal', >>>include_dirs=i

[Python-ideas] Re: zip(x, y, z, strict=True)

On Mon, Apr 20, 2020 at 03:28:09PM -0700, Andrew Barnert via Python-ideas wrote: > Admittedly, such cases are almost surely not that common, but I > actually have some line-numbering code that did something like this > (simplified a bit from real code): > > yield from enumerate(itertools.ch

[Python-ideas] Re: zip(x, y, z, strict=True)

On Mon, Apr 20, 2020 at 08:42:00PM +0300, Ram Rachum wrote: > Here's something that would have saved me some debugging yesterday: > > >>> zipped = zip(x, y, z, strict=True) > > I suggest that `strict=True` would ensure that all the iterables have been > exhausted, raising an exception otherwi

[Python-ideas] Re: Keyword arguments self-assignment

On Mon, Apr 20, 2020 at 10:23:29PM +0200, Alex Hall wrote: > On Mon, Apr 20, 2020 at 5:04 AM Steven D'Aprano wrote: > > > On Sun, Apr 19, 2020 at 06:06:50PM +0200, Alex Hall wrote: > > > Sorry, what? How is there any doubt that the arguments being passed are > > > dunder, invert, private, meta, a

[Python-ideas] Re: Keyword arguments self-assignment

On Apr 20, 2020, at 16:46, Christopher Barker wrote: > On Mon, Apr 20, 2020 at 3:13 PM Andrew Barnert wrote: > > Sure, it’s a declarative format, it’s just that often it’s intended to be > > understood as representing an object graph. > > I"m not sure the point here -- I was not getting onto de

[Python-ideas] Re: Keyword arguments self-assignment

On Apr 20, 2020, at 16:24, M.-A. Lemburg wrote: > > On 20.04.2020 19:43, Andrew Barnert via Python-ideas wrote: >>> On Apr 20, 2020, at 01:06, M.-A. Lemburg wrote: >>> >>> The current version already strikes me as way too complex. >>> It's by far the most complex piece of grammar we have in Py

[Python-ideas] Re: zip(x, y, z, strict=True)

> On Apr 20, 2020, at 17:22, Steven D'Aprano wrote: > > On Mon, Apr 20, 2020 at 03:28:09PM -0700, Andrew Barnert via Python-ideas > wrote: > >> Admittedly, such cases are almost surely not that common, but I >> actually have some line-numbering code that did something like this >> (simplified

[Python-ideas] Re: Keyword arguments self-assignment

On Tue, Apr 21, 2020 at 9:27 AM M.-A. Lemburg wrote: > But arguing that f(a=, b=, c=, d=) is any better than > f(a=a, b=b, c=c, d=d) does not really solve anything. > > The problem is with the code design, not with the syntax. > > You'd be better off putting your variables combined into a context