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/
