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

2020-05-20 Thread Jim J. Jewett
David Mertz wrote:

> Fwiw, I don't think it changes my order, but 'strict' is a better word than
> 'equal' in all those places. I'd subtract 0.1 from each of those votes if
> they used "equal".

I would say that 'equal' is worse than 'strict'. but 'strict' is also wrong.  

Zipping to a potentially infinite sequence -- like a manual enumerate -- 
isn't wrong.  It may be the less common case, but it isn't wrong.  Using 
'strict' implies that there is something sloppy about the data in, for 
example, cases like Stephen J. Turnbull's lagged time series.

Unfortunately, the best I can come up with is 'same_length', or possibly 
'equal_len' or 'equal_length'.  While those are better semantically, they 
are also slightly too long or awkward.  I would personally still consider 
'same_length' the least bad option.

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


[Python-Dev] Re: Please welcome our next Release Manager, Pablo!

2020-05-20 Thread Serhiy Storchaka

20.05.20 01:54, Barry Warsaw пише:

In light of the release of Python 3.9b1, let’s take a moment to celebrate all 
the great work that our Python 3.8 and 3.9 release manager Łukasz has done.  
The role of Python Release Manager is hugely important to each successful 
release, and it can be a lot of work, often unseen and thankless to shepherd a 
new Python version through its first alpha release to its last security 
release.  With all of your immeasurable help, the Release Manager ensures 
solid, feature-full releases that the entire Python community eagerly awaits.

Łukasz carries on the fine tradition of all of our past release managers, and 
now that his second release has entered beta phase, I’m very happy to announce 
our next Release Manager, for Python 3.10 and 3.11: Pablo Galindo Salgado!

Since becoming a core developer in 2018, Pablo has contributed significantly to 
Python.  With the change to an annual release cycle (PEP 602, authored by 
Łukasz), the time commitment for release managers has been reduced as well, and 
we will continue to look for ways to make the selection process for release 
managers more transparent and accessible.  I know that in addition to admirably 
managing the releases for 3.10 and 3.11, Pablo will also help to continually 
improve the process of selecting and serving as release manager.

Please join me in welcoming Pablo in his new role!


Thanks to Łukasz and congratulations to Pablo!
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/FB64XQCROADC2MUZ4FHDDFBLBHP63JPD/
Code of Conduct: http://python.org/psf/codeofconduct/


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

2020-05-20 Thread Steve Holden
On Wed, May 20, 2020 at 7:11 PM Jim J. Jewett  wrote:

> David Mertz wrote:
>
> > Fwiw, I don't think it changes my order, but 'strict' is a better word
> than
> > 'equal' in all those places. I'd subtract 0.1 from each of those votes if
> > they used "equal".
>
> I would say that 'equal' is worse than 'strict'. but 'strict' is also
> wrong.
>
> Zipping to a potentially infinite sequence -- like a manual enumerate --
> isn't wrong.  It may be the less common case, but it isn't wrong.  Using
> 'strict' implies that there is something sloppy about the data in, for
> example, cases like Stephen J. Turnbull's lagged time series.
>
> Unfortunately, the best I can come up with is 'same_length', or possibly
> 'equal_len' or 'equal_length'.  While those are better semantically, they
> are also slightly too long or awkward.  I would personally still consider
> 'same_length' the least bad option.
>
> conformant? similar? parallel?
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/VWGV4RCZTZJYU6WP7UR4CEKCNVWEJNOG/
Code of Conduct: http://python.org/psf/codeofconduct/


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

2020-05-20 Thread Dennis Sweeney
What about "balanced", "uniform", or "rectangular"?
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/2XXSYMZELCV5EMAEIDFISLF7RDD6ICE5/
Code of Conduct: http://python.org/psf/codeofconduct/


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

2020-05-20 Thread Gregory P. Smith
On Wed, May 20, 2020 at 11:09 AM Jim J. Jewett  wrote:

> David Mertz wrote:
>
> > Fwiw, I don't think it changes my order, but 'strict' is a better word
> than
> > 'equal' in all those places. I'd subtract 0.1 from each of those votes if
> > they used "equal".
>
> I would say that 'equal' is worse than 'strict'. but 'strict' is also
> wrong.
>
> Zipping to a potentially infinite sequence -- like a manual enumerate --
> isn't wrong.  It may be the less common case, but it isn't wrong.  Using
> 'strict' implies that there is something sloppy about the data in, for
> example, cases like Stephen J. Turnbull's lagged time series.
>
> Unfortunately, the best I can come up with is 'same_length', or possibly
> 'equal_len' or 'equal_length'.  While those are better semantically, they
> are also slightly too long or awkward.  I would personally still consider
> 'same_length' the least bad option.
>
> -jJ
>

As we've come down to naming things... if you want it to read more like
English,

`zip(vorpal_rabbits, holy_hand_grenades, lengths_must_match=True)`

or another chosen variation of that such as `len_must_match=` or
`length_must_match=` reads nicely and is pretty self explanatory that an
error can be expected if the condition implied by the "must" is found
untrue without really feeling a need to look it up in documentation.

It is also harder to type or fit on a line.  Which is one advantage to a
short thing like `strict=`.

I don't care so much about the particular spelling here to argue among any
of those, I primarily want the feature to exist.

I expect we're entering steering council territory for a decision soon...

-gps

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


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

2020-05-20 Thread Joseph Jenne via Python-Dev
I'd like to suggest "len_eq" as a short but (rather) self-explanatory 
option.


On 5/20/20 3:16 PM, Gregory P. Smith wrote:



On Wed, May 20, 2020 at 11:09 AM Jim J. Jewett > wrote:


David Mertz wrote:

> Fwiw, I don't think it changes my order, but 'strict' is a
better word than
> 'equal' in all those places. I'd subtract 0.1 from each of those
votes if
> they used "equal".

I would say that 'equal' is worse than 'strict'. but 'strict' is
also wrong.

Zipping to a potentially infinite sequence -- like a manual
enumerate --
isn't wrong.  It may be the less common case, but it isn't wrong. 
Using
'strict' implies that there is something sloppy about the data in,
for
example, cases like Stephen J. Turnbull's lagged time series.

Unfortunately, the best I can come up with is 'same_length', or
possibly
'equal_len' or 'equal_length'.  While those are better
semantically, they
are also slightly too long or awkward.  I would personally still
consider
'same_length' the least bad option.

-jJ


As we've come down to naming things... if you want it to read more 
like English,


`zip(vorpal_rabbits, holy_hand_grenades, lengths_must_match=True)`

or another chosen variation of that such as `len_must_match=` or 
`length_must_match=` reads nicely and is pretty self explanatory that 
an error can be expected if the condition implied by the "must" is 
found untrue without really feeling a need to look it up in documentation.


It is also harder to type or fit on a line.  Which is one advantage to 
a short thing like `strict=`.


I don't care so much about the particular spelling here to argue among 
any of those, I primarily want the feature to exist.


I expect we're entering steering council territory for a decision soon...

-gps

___
Python-Dev mailing list -- python-dev@python.org

To unsubscribe send an email to python-dev-le...@python.org

https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at

https://mail.python.org/archives/list/python-dev@python.org/message/G5JTZI6SARFG5AA3H2XJUIUNXR2TBNQ4/
Code of Conduct: http://python.org/psf/codeofconduct/


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


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

2020-05-20 Thread Emily Bowman
Python has always preferred full-word over old-school C/Perl/PHP-style
abbreviated names. Clarity is paramount. (Or this whole discussion wouldn't
even be happening.)

I think this is *more* of a zip_shortest than zip_strict, but since you can
never have total clarity without a method name that doubles as a docstring,
whatever works will work as long as it's documented.

Em

On Wed, May 20, 2020 at 3:33 PM Joseph Jenne via Python-Dev <
python-dev@python.org> wrote:

> I'd like to suggest "len_eq" as a short but (rather) self-explanatory
> option.
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ENRSP4ZSA4D3X7MXQK43GJE3IE2RKEBD/
Code of Conduct: http://python.org/psf/codeofconduct/


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

2020-05-20 Thread MRAB

On 2020-05-21 00:29, Emily Bowman wrote:
Python has always preferred full-word over old-school C/Perl/PHP-style 
abbreviated names. Clarity is paramount. (Or this whole discussion 
wouldn't even be happening.)



[snip]
... apart from len, def, int, float, str, etc.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/CXRBJETQJNBE27K3ASEB4H47BD4NYHE7/
Code of Conduct: http://python.org/psf/codeofconduct/