[Python-ideas] Re: [Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

On Wed, May 20, 2020 at 6:46 AM Steven D'Aprano wrote: > I find it remarkable how people on this > list who often argue "just put it on PyPI" as if that didn't condemn the > proposal to die are now arguing that importing from itertools is an > undue burden. > are you sure it's the SAME people?

[Python-ideas] Re: PEP 618: Add Optional Length-Checking To zip

On Wed, May 20, 2020 at 7:56 AM Guido van Rossum wrote: > No, it's because the message speaks English, not Python, and in English we > count starting from one. Users would be very confused you counted from zero > here, > And we can tell users that speak Geek more fluently that English that it's

[Python-ideas] Re: Optional keyword arguments

On 2020-05-20 23:16, James Lu wrote: "<:" Does not give the user any intuition about what it does. "<~" Ok, but same problems as "<:" and precludes the use of "<~~" due to Python's parser. "::" Could be confused with Haskell's type declaration operator. If we want to avoid confusion with the

[Python-ideas] Re: Optional keyword arguments

> This is already valid in 3.8, so we should forget about overloading := > with a second meaning. def func(x=(a:=expression), y=a+1): def func(x:=options): These two syntaxes do not conflict with each other. > Do we want to encourage callers to pass None to > indicate default > arguments? >

[Python-ideas] Re: Optional keyword arguments

"<:" Does not give the user any intuition about what it does. "<~" Ok, but same problems as "<:" and precludes the use of "<~~" due to Python's parser. "::" Could be confused with Haskell's type declaration operator. If we want to avoid confusion with the walrus operator, "options!?=..." is a

[Python-ideas] Re: Optional keyword arguments

I don't see myself using := for a few years, because support for Python 3.8 is not widespread yet among PyPy. However, that doesn't mean I oppose evolving the language further so that down the line when Python 3.10 is ready, I'll have juicy new features to use.

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

On Wed, May 20, 2020 at 01:13:10PM -0700, Mike Miller wrote: > > On 2020-05-20 00:44, Chris Angelico wrote: > >If you think that a keyboard with fancy arrows on it will take off any > >quicker, you're extremely hopeful. > > While I'm not sure how useful this is in the long run, the oft mentioned

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

On Thu, May 21, 2020 at 01:58:29AM +1000, Chris Angelico wrote: > On Thu, May 21, 2020 at 1:48 AM Ethan Furman wrote: > > > If you think that a keyboard with fancy arrows on it will take off any > > > quicker, you're extremely hopeful. > > > > I wouldn't be surprised if it did, although a

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

On 2020-05-20 00:44, Chris Angelico wrote: If you think that a keyboard with fancy arrows on it will take off any quicker, you're extremely hopeful. While I'm not sure how useful this is in the long run, the oft mentioned drawback of "hard to type/view" Unicode chars isn't as insurmountable

[Python-ideas] Re: Optional keyword arguments

> On 20 May 2020, at 16:08, Eric V. Smith wrote: > > I think every proposal, especially for syntax and operators, should be judged > on how confusing it is to new and experienced users alike. In my mind, using > the walrus operator for early binding utterly fails that test, but of course >

[Python-ideas] Re: Optional keyword arguments

On Thu, May 21, 2020 at 2:27 AM Eric V. Smith wrote: > > On 5/20/2020 11:26 AM, Chris Angelico wrote: > > On Thu, May 21, 2020 at 12:11 AM Eric V. Smith wrote: > >> The fact that operators are notoriously difficult to search for doesn't > >> help any. > >> > > The fact that people STILL think

[Python-ideas] Re: Optional keyword arguments

On 5/20/2020 11:26 AM, Chris Angelico wrote: On Thu, May 21, 2020 at 12:11 AM Eric V. Smith wrote: The fact that operators are notoriously difficult to search for doesn't help any. The fact that people STILL think that operators are difficult to search for doesn't help either. Google for

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

On Thu, May 21, 2020 at 1:48 AM Ethan Furman wrote: > > On 05/20/2020 12:44 AM, Chris Angelico wrote: > > On Wed, May 20, 2020 at 4:36 PM Thierry Parmentelat wrote: > > >> I also reckon it is still cumbersome to simply enter Unicode characters > >> from a keyboard sometimes; I guess if the big

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

On 05/20/2020 12:44 AM, Chris Angelico wrote: On Wed, May 20, 2020 at 4:36 PM Thierry Parmentelat wrote: I also reckon it is still cumbersome to simply enter Unicode characters from a keyboard sometimes; I guess if the big players were located in other countries that would maybe be

[Python-ideas] Re: Optional keyword arguments

On Thu, May 21, 2020 at 12:11 AM Eric V. Smith wrote: > The fact that operators are notoriously difficult to search for doesn't help > any. > The fact that people STILL think that operators are difficult to search for doesn't help either. Google for "python :=" and PEP 572 is the first hit.

[Python-ideas] Re: PEP 618: Add Optional Length-Checking To zip

Guido van Rossum wrote: > No, it's because the message speaks English, not Python, and in English we > count starting from one. Yep. For precedent, try passing invalid arguments to `isinstance` and `issubclass`. ___ Python-ideas mailing list --

[Python-ideas] Re: PEP 618: Add Optional Length-Checking To zip

On Wed, 20 May 2020 07:52:22 -0700 Guido van Rossum wrote: > No, it's because the message speaks English, not Python, and in English we > count starting from one. Users would be very confused you counted from zero > here, Agreed. I would be confused myself. Regards Antoine.

[Python-ideas] Re: PEP 618: Add Optional Length-Checking To zip

No, it's because the message speaks English, not Python, and in English we count starting from one. Users would be very confused you counted from zero here, On Wed, May 20, 2020 at 02:24 Paul Moore wrote: > I suspect it's because zip() is actually a class constructor, so > argument zero is

[Python-ideas] Re: Optional keyword arguments

On 5/20/2020 9:48 AM, Peter O'Connor wrote: On Wed, May 20, 2020 at 5:35 AM Eric V. Smith > wrote: On 5/20/2020 8:23 AM, James Lu wrote: > What's wrong with my := proposal? Confusion with unrelated uses of the walrus operator. What's wrong with confusion

[Python-ideas] Re: Optional keyword arguments

On Wed, May 20, 2020 at 5:35 AM Eric V. Smith wrote: > On 5/20/2020 8:23 AM, James Lu wrote: > > What's wrong with my := proposal? > Confusion with unrelated uses of the walrus operator. > What's wrong with confusion with the walrus operator? - If you are confused and don't know what walrus

[Python-ideas] Re: [Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

On Sun, May 17, 2020 at 02:43:52PM -0400, David Mertz wrote: > To me, itertools is not some hidden vault only accessible after performing > Herculean labors. +1 to David's observation here. I find it remarkable how people on this list who often argue "just put it on PyPI" as if that didn't

[Python-ideas] Re: Optional keyword arguments

On 20/05/2020 02:13, James Lu wrote: The "if arg is None: arg = " pattern occurs in the standard library eighty-five (85) times. You say that like it's a bad thing. Given that it's completely clear what's going on -- you don't need to understand or guess at the syntax -- I'm really not

[Python-ideas] Re: Optional keyword arguments

On Sun, May 17, 2020 at 07:17:00PM -, James Lu wrote: > Thus, only one of ":=" or "?=" should be adopted. They should be evalued on: That does not logically follow. Even if we accept your idea that we should have special syntax for late-binding of function defaults, and that's not clear

[Python-ideas] Re: Optional keyword arguments

On 5/20/2020 8:23 AM, James Lu wrote: # Looks like an old Py2 repr def spam(x, y, ham={}): # Way too magical, although it parses currently and might # be done with the help of a magic built-in def spam(x, y, ham=LATE%{}): # wut? def spam(x, y, ham=>{}): # even worse def spam(x, y, ham=->{}): etc

[Python-ideas] Re: Optional keyword arguments

> # Looks like an old Py2 repr > def spam(x, y, ham={}): > # Way too magical, although it parses currently and might > # be done with the help of a magic built-in > def spam(x, y, ham=LATE%{}): > # wut? > def spam(x, y, ham=>{}): > # even worse > def spam(x, y, ham=->{}): > etc etc etc. There are

[Python-ideas] Re: Optional keyword arguments

On Wed, May 20, 2020 at 10:19 PM James Lu wrote: > > Thank you for raising a good point. I think we should ban referencing > variables > not in the nearest outer enclosing scope until best practices regarding > closures emerge. For example: > > global_var = 5 > class A: > # not ok: > def

[Python-ideas] Re: Optional keyword arguments

Thank you for raising a good point. I think we should ban referencing variables not in the nearest outer enclosing scope until best practices regarding closures emerge. For example: global_var = 5 class A: # not ok: def foo(a:=global_var): pass class_var = global_var # ok:

[Python-ideas] Re: str.strip: argument maxstrip

On Wed, May 20, 2020 at 12:44 PM Henk-Jaap Wagenaar < wagenaarhenkj...@gmail.com> wrote: > foobar.removesuffix('=').removesuffix('=') > > would work right now in 3.9 (I think). > > Can confirm: ``` >>> 'abc==='.removesuffix('=').removesuffix('=') 'abc='

[Python-ideas] Re: str.strip: argument maxstrip

On Wed, 20 May 2020 at 11:34, Alex Hall wrote: > On Wed, May 20, 2020 at 2:46 AM Cameron Simpson wrote: > >> On 19May2020 15:43, David Mertz wrote: >> Reiterating the Python 3.9 suggestion, what about: >> >> salt2 = salt.cutsuffix(('==', '=')) >> > > But if the API was there, I agree this

[Python-ideas] Re: str.strip: argument maxstrip

On Wed, May 20, 2020 at 2:46 AM Cameron Simpson wrote: > On 19May2020 15:43, David Mertz wrote: > Reiterating the Python 3.9 suggestion, what about: > > salt2 = salt.cutsuffix(('==', '=')) > Tuple arguments were rejected in the PEP. ``` Python 3.10.0a0 (heads/master:bac170cd93, May 20 2020,

[Python-ideas] Re: Late binding of default arguments [was Re: Re: Optional keyword arguments]

On Wed, May 20, 2020 at 8:04 PM Steven D'Aprano wrote: > > On Wed, May 20, 2020 at 07:56:32PM +1000, Chris Angelico wrote: > > > > I have some ideas for that, and in my copious spare time I am gradually > > > writing a proto-PEP. > > > > > > > Oh, sweet! Need a hand? > > What I really need is an

[Python-ideas] Re: Late binding of default arguments [was Re: Re: Optional keyword arguments]

On Wed, May 20, 2020 at 07:56:32PM +1000, Chris Angelico wrote: > > I have some ideas for that, and in my copious spare time I am gradually > > writing a proto-PEP. > > > > Oh, sweet! Need a hand? What I really need is an extra 12 hours a day, and a lot fewer distractions and a lot more Round

[Python-ideas] Re: Optional keyword arguments

On Mon, May 18, 2020 at 11:32:29AM -0700, Caleb Donovick wrote: > Certainly the way default arguments work with mutable types is not the most > intuitive Neither is the alternative. def function(arg=calculate_default_value()): "What do you mean that extremely expensive calculation is

[Python-ideas] Re: Late binding of default arguments [was Re: Re: Optional keyword arguments]

On Wed, May 20, 2020 at 7:34 PM Steven D'Aprano wrote: > > On Wed, May 20, 2020 at 05:54:25PM +1000, Chris Angelico wrote: > > > > This seems to have some merit. It is quite common, I believe, to want > > > an argument's default value to > > > be evaluated on each call (and beginners are often

[Python-ideas] Late binding of default arguments [was Re: Re: Optional keyword arguments]

On Wed, May 20, 2020 at 05:54:25PM +1000, Chris Angelico wrote: > > This seems to have some merit. It is quite common, I believe, to want > > an argument's default value to > > be evaluated on each call (and beginners are often confused when it > > isn't) [...] > I'd love to have this as a

[Python-ideas] Re: Optional keyword arguments

Have you seen PEP 505? https://www.python.org/dev/peps/pep-0505/ I'm still praying they add "??=" every time I need it. Maybe if someone proposed just that operator, it would go a long way towards simplifying code without resulting in endless debates? Best, Neil On Sunday, May 17, 2020 at

[Python-ideas] Re: PEP 618: Add Optional Length-Checking To zip

I suspect it's because zip() is actually a class constructor, so argument zero is self... Paul On Wed, 20 May 2020 at 10:10, Neil Girdhar wrote: > > I'm just curious, but is it usual for errors to be one-based rather than > zero-based? If I do zip(*iterables, strict=True), then "argument 1 is

[Python-ideas] Re: PEP 618: Add Optional Length-Checking To zip

I'm just curious, but is it usual for errors to be one-based rather than zero-based? If I do zip(*iterables, strict=True), then "argument 1 is too long" refers to iterables[0]? On Friday, May 1, 2020 at 2:20:12 PM UTC-4, Brandt Bucher wrote: > > I have pushed a first draft of PEP 618: > >

[Python-ideas] Re: Optional keyword arguments

On Wed, May 20, 2020 at 12:23 PM Rob Cliffe via Python-ideas wrote: > > > > On 17/05/2020 20:17, James Lu wrote: > > Many a python programmer have tired to see code written like: > > > > def bar(a1, a2, options=None): > > if options is None: > > options = {} > > ... # rest of

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

17.05.20 13:47, Thierry Parmentelat пише: well it’s all in the title the specific character that I am referring to is this one In [1]: print("\u2192”) → https://unicode-table.com/en/2192/ —— just curious about how people would feel about taking better advantage of non-ascii characters when

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

On Wed, May 20, 2020 at 4:36 PM Thierry Parmentelat wrote: > I also reckon it is still cumbersome to simply enter Unicode characters from > a keyboard sometimes; I guess if the big players were located in other > countries that would maybe be different > But that will change over time, no

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

> On 19 May 2020, at 20:27, Brett Cannon wrote: > > I'm going to ask that people please try to keep this thread on-topic to the > question of using Unicode characters directly for things that we currently > use two ASCII characters to represent. Other ideas that spring up from this >