I'm sure you can find examples of modes. For example open() obviously has a
string mode and binary mode which are importantly different. I myself use
Pandas a lot, and it is absolutely thick with modes (but is very unpythonic
in numerous ways). Even print() with sep and end options has a kind of mode.

Nonetheless, I think it is a clear guiding principle in Python that a new
function name is better than a mode when there are only two or three
behaviors... Other things being equal (which they often are not).

On Sat, Apr 25, 2020, 1:25 PM Christopher Barker <python...@gmail.com>
wrote:

> On Sat, Apr 25, 2020 at 10:11 AM David Mertz <me...@gnosis.cx> wrote:
>
>> I have no objection to adding a zip_strict() or zip_exact() to itertools.
>> I am used to the current behavior, and am apparently in minority in not
>> usually assuming common length iterators. Say +0 on a new function.
>>
>
> I'd say I'm +0 also -- I don't think it'll get used much.
>
> But I'm definitely -1 on adding a mode switch to the built-in. This is not
>> the way Python is usually done. zip_longest() is a clear example,
>>
>
> Yes, indeed. But there is a difference here. If you want zip_longest
> capability, your code simply can not work with zip(). So folks will make
> the effort to go import it from itertools.
>
> But most code that could benefit from "strict" behavior will run fine with
> zip() -- just with less safely, or making a safety check separately. So I
> don't think a function in itertools would get used much
>
> Granted, that doesn't say anything about the API consistency (or lack
> thereof) of adding a "mode flag" -- if that's important, then, well, I
> guess it's not an option. Are there really no mode flags in Python? (I do
> recall a quote attributed to Guido about not using a two-mnode flag, when
> another function will do).
>
>
>> but so is the recent cut_suffix (or whatever final spelling was chosen).
>> Some folks wanted a mode switch on .rstrip(), and that was appropriately
>> rejected.
>>
>
> In my mind that was more about consistency with the rest of the string API
> than about a global "that's not how we do things in Python" -- but It may
> have been both.
>
> - 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/TXPJCYODALV4XDXYMF3I7C6GNIENEP54/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to