date:20200520

> 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?

> Neither are we going to force function writers to accept None as a 
> default. So the way functions can be called will depend partially on the 
> function itself, and partially on the caller's personal choice for how 
> they prefer to handle defaults.

If it wasn't clear originally, I meant to ask, what is the best practice that
should be encouraged? And we're not 'forcing' anyone, we're just making
an easier syntax for doing something.

There's a thirty year tradition of doing that because there's no
terser way to do it. Out of the 85 instances I found in the STL, only 5 
instances
used "if arg is None: arg = " in one line. The others used a two-line form.
Having to read 2 lines to understand a common language pattern is inefficient.
___
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/VFRYCWBUXRMJFVG6PBCUK5D25M2ZUJOX/
Code of Conduct: http://python.org/psf/codeofconduct/

[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 
decent alternative. It can be remembered as "if not there? equal to" [! there? 
=].
___
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/NKJAS22WXD2A6RFKOZP7HO4QCCEZVFHA/
Code of Conduct: http://python.org/psf/codeofconduct/

[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 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/BW2A57QJZ357CYFOZPV5NB6OZSNEGRTH/
Code of Conduct: http://python.org/psf/codeofconduct/

[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 
> drawback of "hard to type/view" Unicode chars isn't as insurmountable as 
> some think:
> 
> - Word processors have had a palette to insert symbols for decades.

Not everyone is programming in a GUI environment all the time, and even 
when they are, GUI "insert symbol palettes" are of greatly variable 
quality.

> - Editors have had "snippets" for perhaps almost as long.

Sure, but like the "insert symbol" command, needing to use a snippet 
adds friction. Even in the best case, think of the difference between:

* type a minus sign `-`

* use a snippet or symbol palette to find and insert a `→` symbol.

> - Code formatters such as "go fmt", yapf, black, etc could update them.
> - All maintained OSs support a great majority of Unicode, with font support.

Which is still patchy, but getting better. I still come across 
monospaced fonts where certain symbols have annoying "off by one pixel" 
display bugs, or are missing the exact symbol you need.

I use a lot of arrows in my maths equations, and they are invariably too 
small, too big or placed too close to the baseline, depending on the 
font. At smaller font sizes, the arrow head tends to look like "grit on 
the monitor". In a word processor, I can manually tweak that, but in a 
programming environment using a text editor, there's not much I can do 
except search for that One Perfect Font.

Still not found it after decades of searching.

> - AltGr and Compose keys are available.

And require the editor or OS to support it, a keyboard to have the right 
compose key, and most importantly of all, for the user to remember a 
bunch of esoteric key codes to get the symbol needed.

I can remember Win key .. to give MIDDLE DOT · but it's the wrong dot, I 
need DOT PRODUCT ⋅ (which unfortunately is displayed as a missing- 
character glyph in my email client and editor). But I have no idea what 
key combination I need to press to get DOT PRODUCT.

Last night I had one of my students ask me how they are supposed to type 
maths symbols during an online test if they can't google for it and copy 
it from some website. I didn't have an answer.

So what is the key code for the → symbol?

> I've been using Unicode everywhere for about a decade—it's time to retire 
> the argument that input is still hard or rare.

I can sincerely say that I am very happy that your experience is so 
good, but I'm also exceedingly jealous of it. I don't think your 
experience scales to the majority of people.

-- 
Steven
___
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/C3GEUDZ7KAQKYHA345MGQJAXVHEZP4FY/
Code of Conduct: http://python.org/psf/codeofconduct/

[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 standard set of keyboard
> > shortcuts is more likely.
> 
> I'm pretty doubtful. Keyboards seem to be LOSING keys, not gaining
> them. Which is a trend that I deplore (where are my F1-F12 keys?? and
> I doubt I'll ever see F13-F16), but I still cling to the hope that not
> ALL keyboards are going that way.

Indeed. The ultimate expression of this trend is, of course, the 
smartphone, where you have no physical keyboard at all.

Even if people don't do their for-real development on their smartphone, 
they will insist on replying to emails, messages, Stackoverflow 
questions etc on them, and they won't necessarily have [insert name of 
app here]. So unless the symbol shows up on the smartphone's native 
keyboard emulator people won't be able to use it at least part of the 
time.

-- 
Steven
___
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/4PS3SCZBEIWT4CJEA3PTJDG5YHXZRTLT/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2020-05-20 Thread Mike Miller



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 as some think:


- Word processors have had a palette to insert symbols for decades.
- Editors have had "snippets" for perhaps almost as long.
- Code formatters such as "go fmt", yapf, black, etc could update them.
- All maintained OSs support a great majority of Unicode, with font support.
- AltGr and Compose keys are available.

I've been using Unicode everywhere for about a decade—it's time to retire the 
argument that input is still hard or rare.  Dedicated keys are not really necessary.


-Mike
___
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/OD4CI5WCB3YBGAWLT6WCHK3ZVATYID6O/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Optional keyword arguments

2020-05-20 Thread Thierry Parmentelat



> 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 
> other people will have different opinions.

I’d like to +1 on this one, not to mention that the walrus operator is still 
largely not-too-well-known, 
and this IMHO would add to the confusion; 
utterly is the word indeed :)
___
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/W5DK3T6TCRTRU3Y7SC4E74XO73IM4OQG/
Code of Conduct: http://python.org/psf/codeofconduct/

[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 that operators are difficult to
> > search for doesn't help either.
> >
> > Google for "python :=" and PEP 572 is the first hit.
> >
> > DuckDuckGo for "python :=" didn't give any good results; my next
> > thought was "python := operator" which didn't do much good. For most
> > of the common operators, you'd get it from "python operator
> > precedence", but unfortunately DDG is showing Python 2.7 search
> > results above Python 3, so you'd have to go down to the page eighth in
> > the search results, then browse the table. But when you do get there,
> > it's not too hard to glance over the table, find that ":=" is an
> > "assignment expression" and go from there.
> >
> > Bing for "python :=" has what looks like three paid search results,
> > and then the first real result is Stack Overflow asking what the colon
> > equal (:=) operator means, and even though the question is older than
> > PEP 572, the accepted answer has been updated to link to it.
> >
> > Yandex failed to find the := operator specifically, but as with DDG, I
> > had to go for "python operator precedence". Fortunately, it did give
> > the Py3 page as the first hit.
> >
> > I tried a few of the more obscure search engines, and most of them
> > seem to give the same results as one of the above. (I suspect quite a
> > few of them get their results from one of the big ones anyway.)
> >
> > So two very popular search engines (Google and Bing) give excellent
> > results straight away, and everything can at least find the operator
> > precedence table, which is a good way to get started. I have to
> > penalize DuckDuckGo a bit for not putting current version results at
> > the top, but even then, it WAS on the first page, and of course you
> > can always say "python 3 operator precedence".
> >
> > Operators ARE searchable.
>
> I think you meant ":= is searchable using half search engines I tried,
> both of which are very popular". Which might be good enough for this
> particular proposal, but I disagree.

Actually ":= is searchable using half the search engines I tried, and
with the other half, 'python operators' gets a page with all
operators, from which you can get the info you need". All the search
engines I tried DID get the results I wanted; some more easily than
others, but all got there.

> I couldn't get anywhere with single character operators and Google. So
> you haven't shaken my faith in my assertion.

Hmm, good point. You can Google for "python @=" but not "python @".
Strange. But you can still just look for all operators and go from
there.

And there are some word-based things that are also hard to search for,
so at that point it becomes a wash.

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/2HUXAQL66AF64KSJ4CUEYEFF3TX3FV6D/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Optional keyword arguments

2020-05-20 Thread Eric V. Smith

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 :=" and PEP 572 is the first hit.

DuckDuckGo for "python :=" didn't give any good results; my next
thought was "python := operator" which didn't do much good. For most
of the common operators, you'd get it from "python operator
precedence", but unfortunately DDG is showing Python 2.7 search
results above Python 3, so you'd have to go down to the page eighth in
the search results, then browse the table. But when you do get there,
it's not too hard to glance over the table, find that ":=" is an
"assignment expression" and go from there.

Bing for "python :=" has what looks like three paid search results,
and then the first real result is Stack Overflow asking what the colon
equal (:=) operator means, and even though the question is older than
PEP 572, the accepted answer has been updated to link to it.

Yandex failed to find the := operator specifically, but as with DDG, I
had to go for "python operator precedence". Fortunately, it did give
the Py3 page as the first hit.

I tried a few of the more obscure search engines, and most of them
seem to give the same results as one of the above. (I suspect quite a
few of them get their results from one of the big ones anyway.)

So two very popular search engines (Google and Bing) give excellent
results straight away, and everything can at least find the operator
precedence table, which is a good way to get started. I have to
penalize DuckDuckGo a bit for not putting current version results at
the top, but even then, it WAS on the first page, and of course you
can always say "python 3 operator precedence".

Operators ARE searchable.

I think you meant ":= is searchable using half search engines I tried,
both of which are very popular". Which might be good enough for this
particular proposal, but I disagree.

I couldn't get anywhere with single character operators and Google. So
you haven't shaken my faith in my assertion.

Eric
___
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/DWSDCYT75GXEE5QFOHSMEQGPR36XNDUW/
Code of Conduct: http://python.org/psf/codeofconduct/

[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 players were located in
> >>  other countries that would maybe be different.But that will change
> >>  over time, no matter the speed, some day that will be for granted.So
> >> again maybe 2020 is the right time to break that barrier ?
> >
> > The Dvorak keyboard was invented nearly a hundred years ago. How's it
> > looking as a viable alternative?
>
> Well, 25 years ago I had to write my own Dvorak device driver for use with
> MS-DOS, now it's included in at least Windows and Linux (a Dvorak mapping,
> not my device driver).
>
> So much more viable.  :)
>
> > 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 standard set of keyboard
> shortcuts is more likely.

I'm pretty doubtful. Keyboards seem to be LOSING keys, not gaining
them. Which is a trend that I deplore (where are my F1-F12 keys?? and
I doubt I'll ever see F13-F16), but I still cling to the hope that not
ALL keyboards are going that way.

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/EVTELEZWVETEFZ2GPCRTVBDI2SKWQKGT/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2020-05-20 Thread Ethan Furman

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 different.But that will change
over time, no matter the speed, some day that will be for granted.So
again maybe 2020 is the right time to break that barrier ?

The Dvorak keyboard was invented nearly a hundred years ago. How's it
looking as a viable alternative?

Well, 25 years ago I had to write my own Dvorak device driver for use with
MS-DOS, now it's included in at least Windows and Linux (a Dvorak mapping,
not my device driver).

So much more viable. :)

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 standard set of keyboard
shortcuts is more likely.

MUCH more practical will be to use vim conceal etc, leave your source
code unchanged, and just change the way it looks to you. There are
similar features available in a number of editors.

I'll have to look into that.

--
~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/DWAN3GPO5HWNCGWEZFTNGSDRTIFLTY3U/
Code of Conduct: http://python.org/psf/codeofconduct/

[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.

Yandex failed to find the := operator specifically, but as with DDG, I
had to go for "python operator precedence". Fortunately, it did give
the Py3 page as the first hit.

Operators ARE searchable.

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/OBQUX2TSXTLPV6TABXQFGTE46YTGIS5P/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2020-05-20 Thread Brandt Bucher

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@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/2VNWTHKEGCNEVP6ESHC6MWL5KEMIQJGU/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2020-05-20 Thread Antoine Pitrou

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 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/5EG6V7QUGIKK2WBNYYUY7RHCQJR6446A/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2020-05-20 Thread Guido van Rossum

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 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 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:
> >>
> >> https://www.python.org/dev/peps/pep-0618
> >>
> >> Please let me know what you think – I'd love to hear any *new* feedback
> that hasn't yet been addressed in the PEP!
> >>
> >> Brandt
> >> ___
> >> Python-ideas mailing list -- python...@python.org
> >> To unsubscribe send an email to python-id...@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/ZBB5L2I45PNLTRW7CCV4FDJO5DB7M5UT/
> >> Code of Conduct: http://python.org/psf/codeofconduct/
> >
> > ___
> > 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/3ZXTCHVRXDVWZ5VB6YBMZ2Z3FF7PL7RQ/
> > Code of Conduct: http://python.org/psf/codeofconduct/
> ___
> 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/HM43KBNXA6ZJ66N7WPRZXIKQ372DTXVZ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-- 
--Guido (mobile)
___
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/IB7DGTWVHMDVNOTQ7CQ24VULL2KZQQP4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Optional keyword arguments

2020-05-20 Thread Eric V. Smith


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 with the walrus operator?
- If you are confused and don't know what walrus operator is, you 
google it and find that in a function header it means late assignment.
- If you are confused and think it's referring to the walrus 
operator's use for inline variable assignment - well so what - it is 
being used as assignment here!
- If you are confused and think := is binding at import-time rather 
than call-time - well you already are a somewhat advanced python user 
to be thinking about that and the use of a different syntax to bind 
the argument should trigger you to google it.


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 other people will have different opinions.


The fact that operators are notoriously difficult to search for doesn't 
help any.


Eric

___
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/6SWOR62ONDY5EZ3J5MJDWQHCTVQ3G5PN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Optional keyword arguments

2020-05-20 Thread Peter O'Connor

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 operator is, you google it
and find that in a function header it means late assignment.
- If you are confused and think it's referring to the walrus operator's use
for inline variable assignment - well so what - it is being used as
assignment here!
- If you are confused and think := is binding at import-time rather than
call-time - well you already are a somewhat advanced python user to be
thinking about that and the use of a different syntax to bind the argument
should trigger you to google it.
___
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/BTEKWU7LXWL53AEH2MAYFWFDQJPSYADO/
Code of Conduct: http://python.org/psf/codeofconduct/

[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 condemn the 
proposal to die are now arguing that importing from itertools is an 
undue burden.

> I believe boolean mode switches are usually a bad design
> for Python.

I don't think that Python is unique in that regard.

> Not always, there are exceptions like open().

As Rhodi points out in another message, `open` is not an exception. In 
fact the opposite: `open` is an excellent example of *not* using bool 
flags. We have this:

open(file, mode='rt', ...)

not this:

open(file, 
 read=True,
 write=False, 
 exclusive=False,
 append=False, 
 binary=False,
 text=True,
 update=False, 
 universal=True,
 ...)

There are cases where bool flags are acceptable, even preferred. For 
example, the reverse=False parameter to sorted() seems to be okay 
because it is independent of, and orthogonal to, any other sorting 
parameters such as the key function, or the cmp function in Python 2.

If you can compose the behaviour of the flag with the other parameters, 
it might be okay. For example, back to open:

open(..., closefd=True, ...)

seems to be fine, since it is independent of any of the value of the 
other parameters. You can pass closefd=False, or True, regardless of 
everything else. (There is a technical limitation that it must be True 
if the file is given by name, but it is independent of everything else.)

This proposed mode is not a composable flag like reverse or closefd. If 
we treat it as a flag instead of a mode, then we either rule out future 
enhancements to zip (they *must* go into new functions), or commit to 
piling bool flag upon bool flag even though most of the combinations 
will be an error.

E.g. there were proposals to make `shortest` an explicit parameter. You 
can't have `zip(shortest=True, strict=True, longest=True, ...)`.

> And I think
> Guido made the good point that one of the things that makes mode switches
> bad is when they change the return type, which the `strict=True` API would
> not do (but it would create a new kind of exception to worry about).

I think that the return type is a red herring here. Here's a strawman 
function to demonstrate that the return type is not very important in 
and of itself:

def encode(obj, text=True):
if text:
return json.dumps(obj)
else:
return pickle.dumps(obj).decode('latin1')

Note: json.dumps is another case where the bool flags are acceptable, 
because they all control orthogonal, independent features of the call. 
Passing skipkeys=True doesn't prevent you from also passing 
ensure_ascii=False.

In contrast, you can't compose strict=True with other zip modes.

-- 
Steven
___
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/AV6TQFTIYCGZ2LU4IDXI3Q6DPI5K4YAF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Optional keyword arguments

2020-05-20 Thread Rhodri James


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 seeing the problem here.


--
Rhodri James *-* Kynesim Ltd
___
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/QHW6ZYGV2PC2ENM77RDRU3ERNSYBLEXB/
Code of Conduct: http://python.org/psf/codeofconduct/

[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 that we should, it does not follow that the only two 
possible choices are `:=` and `?=`.

They might be your preferred choice, but that doesn't mean that "only 
one of ... should be adopted". We could instead:

- choose something else;
- or choose nothing at all and stick to the status quo.

In any case, we should rule out `:=` of contention, because it already 
has a meaning as the "walrus operator" for assignment expressions, 
which makes it legal in function defaults:

def func(x=(a:=expression), y=a+1):

This is already valid in 3.8, so we should forget about overloading `:=` 
with a second meaning.

> Do we want to encourage callers to pass None to indicate default 
> arguments?

That isn't up to us, that's up the writer of the function being called. 
There is a thirty year tradition of functions using None for default 
arguments, that's not going to go away.

Neither are we going to force function writers to accept None as a 
default. So the way functions can be called will depend partially on the 
function itself, and partially on the caller's personal choice for how 
they prefer to handle defaults.

> Since Python is a strongly typed language, it seems more consistent to me that
> this code should throw an error:
> def getoptions():
> ... # code to get options
> # whoops! missing return statement
> #return os.environ

Being strongly typed, or weakly typed, has nothing to do with return 
statements. In Python, there is a 30 year tradition of being permitted 
to leave out the return statement in functions or methods intended to be 
used as "procedures" that operate by side-effect with no meaningful 
return value.

We aren't going to break thousands of programs by making it an error to 
leave out the return statement.

-- 
Steven
___
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/LY4M4PTXO4QKQXRJK2ZR3TYNWAJECZ4Z/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Optional keyword arguments

2020-05-20 Thread Eric V. Smith


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 etc etc. There are lots of bad syntaxes and very few that have any merit.
I'd love to have this as a feature, though.
ChrisA

What's wrong with my := proposal?


Confusion with unrelated uses of the walrus operator.

Eric
___
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/VFPQUVTGTPC4U2Y4HYQTH7NFWB2DTI57/
Code of Conduct: http://python.org/psf/codeofconduct/

[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 lots of bad syntaxes and very few that have any merit.
> I'd love to have this as a feature, though.
> ChrisA

What's wrong with my := proposal?
___
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/MTM4UELULM6NWOCA7X6WLZR5MDDKG2MJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[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 foo(a:=global_var):
> pass
> class_var = global_var
> # ok:
> def foo(a:=class_var):
> pass
>
> for a in [1, 2, 3]:
> # not ok:
> def callback(a:=a):
> pass
> local = a
> # ok:
> def callback2(a:=local):
> pass
>
> This way, the design space is kept open.

Another extremely plausible interpretation is that the expression is
evaluated inside the function itself.

def frobnicate(stuff, start=0, end=len(stuff)):
...

I don't think you can punt on this one. The semantics are going to
need to be well-defined from the start.

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/QYGQXI6ABXSVET6NCMENXCXV5OG2E67M/
Code of Conduct: http://python.org/psf/codeofconduct/

[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:
def foo(a:=class_var):
pass

for a in [1, 2, 3]:
# not ok:
def callback(a:=a):
pass
local = a
# ok:
def callback2(a:=local):
pass

This way, the design space is kept open.
___
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/3VXBWI7ZSYPBEXJJASWZUF5K2L7LDPZT/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2020-05-20 Thread Alex Hall

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='
>>> 'abc=='.removesuffix('=').removesuffix('=')
'abc'
>>> 'abc='.removesuffix('=').removesuffix('=')
'abc'
>>> 'abc'.removesuffix('=').removesuffix('=')
'abc'
```
___
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/X4J5UU44NCKOYURS45VQJWPJUJEU6A3F/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2020-05-20 Thread Henk-Jaap Wagenaar

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 would work, not sure what David is
> saying about needing to call twice. On the other hand, this example
> demonstrates well how a tuple is potentially confusing. What happens if you
> call `'abc=='.removesuffix(('=', '=='))`?
>

I assume that was the practical "how to do it now":

foobar.removesuffix('=').removesuffix('=')

would work right now in 3.9 (I think).


> ___
> 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/R6GIYPOULXBPWU2TO2ZLTNEUMILI5Z2B/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/FFRPCZP3RHNCD3SAO3ZM5AH4VJCX5B2E/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2020-05-20 Thread Alex Hall

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, 12:20:34)
[Clang 10.0.0 (clang-1000.11.45.5)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> 'abc=='.removesuffix('=')
'abc='
>>> 'abc=='.removesuffix(('==', '='))
Traceback (most recent call last):
  File "", line 1, in 
TypeError: removesuffix() argument must be str, not tuple
```

But if the API was there, I agree this would work, not sure what David is
saying about needing to call twice. On the other hand, this example
demonstrates well how a tuple is potentially confusing. What happens if you
call `'abc=='.removesuffix(('=', '=='))`?
___
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/R6GIYPOULXBPWU2TO2ZLTNEUMILI5Z2B/
Code of Conduct: http://python.org/psf/codeofconduct/

[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 extra 12 hours a day, and a lot fewer
> distractions and a lot more Round Tuits :-)

Ahh, don't we all...

> I may send you a draft over the weekend for comments.
>

Cool. If you do, I'll comment. If not, I won't. :)

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/WD75F35YRYW3E57QBHR5ZBQX6WEZ5UCF/
Code of Conduct: http://python.org/psf/codeofconduct/

[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 Tuits :-)

I may send you a draft over the weekend for comments.


-- 
Steven
___
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/DT7HHWS2MINMON2SVZMGIUJGBPTMR3QU/
Code of Conduct: http://python.org/psf/codeofconduct/

[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 performed on 
every function call?"

"What do you mean, my default value can change from one call to the 
next, if the ennvironment changes?"

Besides, there are at least two distinct semantics of late-binding for 
default values, and I guarantee that which ever one we pick, somebody is 
going to complain that it's the wrong one and "not intuitive".

- late-bound defaults are closures, like nested functions;
- late-bound defaults aren't closures, but like global lookups.

Trying to base programming semantics on "intuition" is a losing 
prospect, because people's intuition depends so critically on their 
level of knowledge. To me, it is intuitively obvious that of course 
function defaults use early binding.

Function definitions are executable statements, which implies that the 
default is evaluated at the same time the `def` is executed, not when 
the function is called.

If you can't have a choice between early and late binding in a language, 
the sensible choice is to use early binding:

- early binding is easier to implement and more efficient;

- given early binding at the language level, providing late binding 
  semantics in the function is trivial;

- but given late binding at the language level, providing early binding 
  semantics in the function is horrible.

So if you asked me, I would say that early binding is the obvious, 
intuitive choice for function defaults.

I've worked with people who insist that early binding is the "intuitive" 
choice in one context, and then insist that early binding is totally 
confusing and late binding is the "intuitive" choice in another context. 
And they don't like having their own words quoted back at them *wink*

-- 
Steven
___
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/BNBY64E7GUF3Q5TS3G7ZURUUFUNASLCY/
Code of Conduct: http://python.org/psf/codeofconduct/

[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 confused when it
> > > isn't)
> [...]
> > I'd love to have this as a feature, though.
>
> I have some ideas for that, and in my copious spare time I am gradually
> writing a proto-PEP.
>

Oh, sweet! Need a hand?

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/VXH7ISVE64M3OP3OBVXJ45V4FA54ZTH7/
Code of Conduct: http://python.org/psf/codeofconduct/

[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 feature, though.

I have some ideas for that, and in my copious spare time I am gradually 
writing a proto-PEP.



-- 
Steven
___
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/IXHXUZOV5TOUYCYBHFD4CWUVADGGLCGV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Optional keyword arguments

2020-05-20 Thread Neil Girdhar

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 3:23:59 PM UTC-4, 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 function 
>
> syntax if argument is not passed, evaluate {} and store to options 
> def foo(options:={}): pass 
> syntax if argument is not passed or is None, evaluate {} and store to 
> options* 
> def foo(options?={}): pass 
>
> The Zen of Python states "there shouldn't be two ways to do the same 
> thing." 
>
> Thus, only one of ":=" or "?=" should be adopted. They should be evalued 
> on: 
>  - Which encourages writing better code? 
>  - Which catches mistakes easier? 
>
> Do we want to encourage callers to pass None to indicate default 
> arguments? 
>
> spam = { data: True } if arg else None 
> bar(a1, a2, param=spam) 
>
> versus 
>
> bar(a1, a2, { data: True }) if arg else bar(a1, a2) 
>
> versus 
>
> _ = foo.curry(a1, a2) 
> _({data: True}) if arg else _(a1, a2) 
>
> Since Python is a strongly typed language, it seems more consistent to me 
> that 
> this code should throw an error: 
> def getoptions(): 
> ... # code to get options 
> # whoops! missing return statement 
> #return os.environ 
> foo(a1, a2, param=getoptions()) 
>
> := should be adopted because it catches mistakes more quickly. 
>
> On the other hand, ?= replaces the "if kwarg is not None: kwarg = ..." 
> idiom. 
>
> (I propose adopting only ":=". I show "?=" as a strawman.) 
> ___ 
> Python-ideas mailing list -- python...@python.org  
> To unsubscribe send an email to python-id...@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/MILIX6HSW3PRUNWWP6BN2G2D7PXYFZJ7/
>  
> Code of Conduct: http://python.org/psf/codeofconduct/ 
>
___
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/REIWV2QL42JVLJYLRBPCAINRJYMDWF6H/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2020-05-20 Thread Paul Moore

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 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:
>>
>> https://www.python.org/dev/peps/pep-0618
>>
>> Please let me know what you think – I'd love to hear any *new* feedback that 
>> hasn't yet been addressed in the PEP!
>>
>> Brandt
>> ___
>> Python-ideas mailing list -- python...@python.org
>> To unsubscribe send an email to python-id...@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/ZBB5L2I45PNLTRW7CCV4FDJO5DB7M5UT/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>
> ___
> 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/3ZXTCHVRXDVWZ5VB6YBMZ2Z3FF7PL7RQ/
> Code of Conduct: http://python.org/psf/codeofconduct/
___
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/HM43KBNXA6ZJ66N7WPRZXIKQ372DTXVZ/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2020-05-20 Thread Neil Girdhar

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: 
>
> https://www.python.org/dev/peps/pep-0618 
>
> Please let me know what you think – I'd love to hear any *new* feedback 
> that hasn't yet been addressed in the PEP! 
>
> Brandt
> ___
> Python-ideas mailing list -- python...@python.org 
> To unsubscribe send an email to python-id...@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/ZBB5L2I45PNLTRW7CCV4FDJO5DB7M5UT/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/3ZXTCHVRXDVWZ5VB6YBMZ2Z3FF7PL7RQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[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 function
> >
> > syntax if argument is not passed, evaluate {} and store to options
> > def foo(options:={}): pass
> > syntax if argument is not passed or is None, evaluate {} and store to 
> > options*
> > def foo(options?={}): pass
> >
> > The Zen of Python states "there shouldn't be two ways to do the same thing."
> >
> > Thus, only one of ":=" or "?=" should be adopted. They should be evalued on:
> >   - Which encourages writing better code?
> >   - Which catches mistakes easier?
> >
> > Do we want to encourage callers to pass None to indicate default arguments?
> >
> > spam = { data: True } if arg else None
> > bar(a1, a2, param=spam)
> >
> > versus
> >
> > bar(a1, a2, { data: True }) if arg else bar(a1, a2)
> >
> > versus
> >
> > _ = foo.curry(a1, a2)
> > _({data: True}) if arg else _(a1, a2)
> >
> > Since Python is a strongly typed language, it seems more consistent to me 
> > that
> > this code should throw an error:
> > def getoptions():
> >  ... # code to get options
> >  # whoops! missing return statement
> >  #return os.environ
> > foo(a1, a2, param=getoptions())
> >
> > := should be adopted because it catches mistakes more quickly.
> >
> > On the other hand, ?= replaces the "if kwarg is not None: kwarg = ..." 
> > idiom.
> >
> > (I propose adopting only ":=". I show "?=" as a strawman.)
> 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), and to use the idiom James quotes:
>
> def bar(a1, a2, options=None):
>  if options is None:
> options = {}
>
> Allowing `options:={}` will confuse beginners, but many of them are already 
> confused.:-)
>

It would be a major breaking change if ALL default arguments were
late-evaluated. Errors wouldn't be caught till later, performance
would suffer, and semantics would change. More plausible would be to
have a syntactic adornment that triggers this, making it completely
opt-in.

The semantics would be subtly different from the None variety, being
more like the similar variant involving a sentinel:

def spam(x, y, ham=object()):
if ham is spam.__defaults__[-1]:
ham = {}

But with actual language support, the sentinel object wouldn't be
visible anywhere, and anything involving docstrings would show the
original text used, which would be WAY more helpful.

This has been proposed frequently and never gone far, and I think it's
because nobody can settle on a really good syntax for it. Consider:

# 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 lots of bad syntaxes and very few that have any merit.

I'd love to have this as a feature, though.

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/LVTRPG7NBQGWDHAOOTSIFBWLDE6KDEJI/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2020-05-20 Thread Serhiy Storchaka


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 that seems to make sense


There are a lot of right arrows in Unicode.

>>> print(*[c for c in map(chr, range(0x2)) if 
unicodedata.category(c) in ('Sm', 'So') for n in [unicodedata.name(c, 
'')] if 'RIGHT' in n and 'ARROW' in n])
→ ↔ ↛ ↝ ↠ ↣ ↦ ↪ ↬ ↭ ↮ ↱ ↳ ↴ ↹ ⇄ ⇆ ⇉ ⇎ ⇏ ⇒ ⇔ ⇛ ⇝ ⇢ ⇥ ⇨ ⇰ ⇴ ⇶ ⇸ ⇹ ⇻ ⇼ ⇾ ⇿ 
⍈ ⍼ ➔ ➙ ➛ ➜ ➝ ➞ ➟ ➠ ➡ ➢ ➣ ➤ ➥ ➦ ➧ ➨ ➩ ➪ ➫ ➬ ➭ ➮ ➯ ➱ ➲ ➳ ➵ ➸ ➺ ➻ ➼ ➽ ➾ ⟴ 
⟶ ⟷ ⟹ ⟺ ⟼ ⟾ ⟿ ⤀ ⤁ ⤃ ⤄ ⤅ ⤇ ⤍ ⤏ ⤐ ⤑ ⤔ ⤕ ⤖ ⤗ ⤘ ⤚ ⤜ ⤞ ⤠ ⤳ ⤴ ⤵ ⤷ ⤸ ⤾ ⥂ ⥃ ⥄ ⥅ 
⥇ ⥈ ⥰ ⥱ ⥲ ⥴ ⥵ ⥸ ⥹ ⦨ ⦪ ⦬ ⦮ ⦳ ⬄ ⬌ ⬎ ⬏ ⭃ ⭄ ⭆ ⭇ ⭈ ⭌ ⭢ ⭤ ⭬ ⭲ ⭼ ⮀ ⮂ ⮆ ⮊ ⮌ ⮕ ⮙ 
⮚ ⮞ ⮡ ⮣ ⮥ ⮧ ⮩ ⮫ ⮭ ⮯ ⮱ ⮳ ⮵ ⮷ ⯮ ￫ ﮸ ﮸ ﮸ ﮸ ﮸ ﮸ ﮸ ﮸ ﮸ ﮸ ﮸ ﮸ ﮸ 
﮸ ﮸ ﮸ ﮸ ﮸ ﮸ ﮸ ﮸ ﮸ ﮸ ﮸ ﮸ ﮸ ﮸ ﮸ ﮸ ﮸ ﮸ ﮸ ﮸ ﮸ ﮸ ﮸ ﮸ 
﮸ ﮸ ﮸ ﮸ ﮸ ﮸ ﮸ ﮸


What of them do you want to accept as an alias of ->? And how would you 
distinguish similarly looking arrows (for example →, ➙, ➞, ⟶, ⭢)?

___
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/X5BINYPWL6JYMOU4VDKRRMH3TNCODX43/
Code of Conduct: http://python.org/psf/codeofconduct/

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