On Tue, May 5, 2020 at 9:20 AM David Mertz <me...@gnosis.cx> wrote:

> I have no idea whether a flag on zip() or a function in itertools would
> get MORE USE.  I *ABSOLUTELY* think it is an anti-goal to get more use for
> its own sake though.
>

I'm not sure anyone was suggesting that -- *maybe* Alex, but I think his
statement was over-interpreted.

 I only want APPROPRIATE USE in any case.
>

I can't imagine we all don't agree with that.


> The real point, to me, is that users who use itertools.zip_strict() will
> use it for exactly the reason that they want that semantics. In contrast, a
> flag for `strict` or `truncate` or `equal` or whatever is a LOT more likely
> to be used in the "just in case" code where the programmer has not thought
> carefully about the semantics they want.
>

There's no way to really know, but I think this is being overblown -- folks
generally don't go use extra flags just for the heck of it -- particularly
one that won't be documented in anything but the latest documents for years
:-)


> The sky isn't falling, I certainly don't think everyone, nor even most
> developers, would use the flag wrong.  But a separate function just
> provides a better, more consistent, API.
>

Well, THAT IS the point of discussion, yes. I disagree, but can see both
points. But I do want folks to consider that having zip() as a builtin, and
zip_strict() and zip_longest() would be in itertools. Which is different
than if they were all in the same namespace (like the various string
methods, for example). Another key point is that if you want zip_longest()
functionality, you simply can not get it with the builtin zip() -- you are
forced to look elsewhere. Whereas most code that might want "strict"
behavior will still work, albeit less safely, with the builtin.

These considerations should be considered in evaluating the API options.

And this is why I personalty think if we add a flag to zip, we should add
one for longest functionality as well, unifying the API.

I don't think anyone in the huge discussion of the walrus operator, for
> example, tried to make the case that the goal should be encouraging it to
> be used AS MUCH AS POSSIBLE.
>

Indeed, the opposite was true: there was a lot of concern that it would be
overused. though I think think that's a much bigger concern than in this
case.

 A feature should be used *where appropriate*, and the design should not
> vacantly simply try to make it more common.
>

Agreed, but discoverability is still something to be considered in the API.
ANd it seems that there are folks arguing that we specifically want this to
be less discoveble due to concerns of overuse. Which does not seem like
good API design approach to me.

-CHB

-- 
Christopher Barker, PhD

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

Reply via email to