[Python-ideas] Re: zip(x, y, z, strict=True)
On Apr 29, 2020, at 22:50, Stephen J. Turnbull wrote: > Andrew Barnert via Python-ideas writes: > >>> Also -1 on the flag. > > Also -1 on the flag, for the same set of reasons. > > I have to dissent somewhat from one of the complaints, though: > >> auto-complete won’t help at all, Thanks for pointing this out; I didn’t realize how misleadingly I stated this. What I meant to say is that auto-complete won’t help at all with the problem that flags are less discoverable and harder to type than separate functions. Not that it won’t help at all with typing flags—it will actually help a little, it’ll just help a lot less than with separate functions, making the problem even starker rather than eliminating it. It’s worth trying this out to see for yourself. > Many (most?) people use IDEs that will catch up more or less quickly, > though. In fact, most IDEs should just automatically work without needing to change anything, because they work off the signatures and/or typesheds in the first place. That’s not the issue; the issue is what they can actually do for you. And it’s not really any different from in your terminal. In an iPython REPL in my terminal, I enter these definitions: def spam(*args, equal=False): pass def eggs(*args): pass def eggs_equal(*args): pass I can now type eggs_equal(x, y) with `e TAB TAB x, y` or `eggs_ TAB x, y`. And either way, a pop up is showing me exactly the options I want to see when I ask for completion, I’m not just typing that blind. I can type spam(x, y, equal=True) with `s TAB x, y, e TAB T TAB`. That is better than typing out the whole thing, but notice that it requires three autocompletes rather than one, and they aren’t nearly as helpful. Why? Well, it has no idea that the third argument I want to pass is the equal keyword rather than anything at all, because *args takes anything all. And, even after it knows I’m passing the equal argument, it has no idea what value I want for it, so the only way to get suggestions for what to pass as the value is to type T and complete all values in scope starting with T (and usually True will be the first one). And it’s not giving me much useful information at each step; I had to know that I was looking to type equal=True before it could help me type that. The popup signature that shows *args, equal=False does clue me in, but still not nearly as well as offering eggs_equal did. Now repeat the same thing in a source file in PyCharm, and it’s basically the same. Sure, the popups are nicer, and PyCharm actually infers that equal is of type bool even though I didn’t annotate so it can show me True, False, and all bool variables in scope instead of showing me everything in scope, but otherwise, no difference. I still need to ask for help three times instead of once, and get less guidance when I do. And that’s with a bool (or Enum) flag. Change it to end="shortest", and it’s even worse. Strings aren’t code, they’re data, so PyCharm suggests nothing at all for the argument value, while iPython suggests generally-interesting strings like the files in my cwd. (I suppose they could add a special case for this argument of this function, although they don’t do that for anything else, not even the mode argument of open—and, even if they did, at best that makes things only a little worse than a bool or Enum instead of a lot worse…) ___ 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/ERRWSIQC5XQBMOY3WX2NR5HH426LYX5L/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: zip(x, y, z, strict=True)
On 1/05/20 2:58 am, Christopher Barker wrote: Imagine someone that uses zip() in code that works for a while, and then discovers a bug triggered by unequal length inputs. If it’s a flag, they look at the zip docstring, and find the flag, and their problem is solved. Why would they look at the docs for zip? The bug wasn't caused by incorrect use of zip. And using the flag isn't going to fix it. -- Greg ___ 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/XRM2753MALHNQI7O3623BKPLSNQN6YBO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: zip(x, y, z, strict=True)
On Apr 30, 2020, at 07:58, Christopher Barker wrote: > >> I think that the issue of searchability and signature are pretty >> compelling reasons for such a simple feature to be part of the >> function name. > > I would absolutely agree with that if all three function were in the same > namespace (like the string methods referred to earlier), but in this case, > one is a built in and the others will not be — which makes a huge difference > in discoverability. > > Imagine someone that uses zip() in code that works for a while, and then > discovers a bug triggered by unequal length inputs. > > If it’s a flag, they look at the zip docstring, and find the flag, and their > problem is solved. > > Is it’s in itertools, they have to think to look there. Granted, some > googling will probably lead them there, and the zip() docstring can point > them there, but it’s still a heavier lift. I don’t understand. You’re arguing that being discoverable in the docstring is sufficient for the flag, but being discoverable in the docstring is a heavier lift from the function. Why would this be true, unless you intentionally write the docstring badly? To make this more concrete, let’s say we want to just add on to the existing doc string (even though it seems aimed more at reminding experts of the exact details than at teaching novices) and stick to the same style. We’re then talking about something like this: > Return a zip object whose .__next__() method returns a tuple where > the i-th element comes from the i-th iterable argument. The .__next__() > method continues until the shortest iterable in the argument sequence > is exhausted and then it raises StopIteration, or, if equal is true, > it checks that the remaining iterables are exhausted and otherwise > raises ValueError. … vs. this: > Return a zip object whose .__next__() method returns a tuple where > the i-th element comes from the i-th iterable argument. The .__next__() > method continues until the shortest iterable in the argument sequence > is exhausted and then it raises StopIteration. If you need to check > that all iterables are exhausted, use itertools.zip_equal, > which raises ValueError if they aren’t. If they can figure out that equal=True is what they’re looking for from the first one, it’ll be just as easy to figure out that zip_equal is what they’re looking for from the second. Of course it might be better to rewrite the whole thing to be more novice-friendly and to describe what zip iterates at a higher level instead of describing how its __next__ method operates, but that applies to both versions. ___ 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/BGTNMWVD3THOYV2GILT7LNNYHMBGAW77/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: zip(x, y, z, strict=True)
On 2020-04-30 1:07 p.m., Ethan Furman wrote: On 04/30/2020 07:58 AM, Christopher Barker wrote: On 04/29/2020 10:51 PM, Stephen J. Turnbull wrote: I think that the issue of searchability and signature are pretty compelling reasons for such a simple feature to be part of the function name. I would absolutely agree with that if all three function were in the same namespace (like the string methods referred to earlier), but in this case, one is a built in and the others will not be — which makes a huge difference in discoverability. Imagine someone that uses zip() in code that works for a while, and then discovers a bug triggered by unequal length inputs. If it’s a flag, they look at the zip docstring, and find the flag, and their problem is solved. So update the `zip` docstring with a reference to `zip_longest`, `zip_equal`, and `zip_whatever`. -1 on using a flag. what about letting `zip` take a `leftover_func` with arguments `partial_results` and `remaining_iterators`, and then provide `zip_longest`, `zip_equal` and `zip_shortest` (default) as functions you can use with it? an iteration of `zip(a, b, c, leftover_func=foo)` would: 1. call next on the first iterator (internal iter(a)) 2. if it fails, call leftover_func with the () tuple as first arg and the (internal iter(b), internal iter(c)) tuple as second arg 3. call next on the second iterator (internal iter(b)) 4. if it fails, call leftover_func with the (result from a,) tuple as the first arg and the (internal iter(a), internal iter(c)) tuple as second arg 5. call next on the third iterator (internal iter(c)) 6. if it fails, call leftover_func with the (result from a, result from b) tuple as the first arg and the (internal iter(a), internal iter(b)) tuple as second arg 7. yield the (result from a, result from b, result from c) tuple the leftover_func should return an iterator that replaces the zip, or None. (zip_shortest would be the no_op function) -- ~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/T7OGRPXEU2UHGGL6FW42DIK7ZVHCMDUS/ 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/KKHW4ZUMIFPUVPQVWQD7KAHGSGBCCE6H/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: zip(x, y, z, strict=True)
On 04/30/2020 07:58 AM, Christopher Barker wrote: On 04/29/2020 10:51 PM, Stephen J. Turnbull wrote: I think that the issue of searchability and signature are pretty compelling reasons for such a simple feature to be part of the function name. I would absolutely agree with that if all three function were in the same namespace (like the string methods referred to earlier), but in this case, one is a built in and the others will not be — which makes a huge difference in discoverability. Imagine someone that uses zip() in code that works for a while, and then discovers a bug triggered by unequal length inputs. If it’s a flag, they look at the zip docstring, and find the flag, and their problem is solved. So update the `zip` docstring with a reference to `zip_longest`, `zip_equal`, and `zip_whatever`. -1 on using a flag. -- ~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/T7OGRPXEU2UHGGL6FW42DIK7ZVHCMDUS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: zip(x, y, z, strict=True)
> I think that the issue of searchability and signature are pretty > compelling reasons for such a simple feature to be part of the > function name. I would absolutely agree with that if all three function were in the same namespace (like the string methods referred to earlier), but in this case, one is a built in and the others will not be — which makes a huge difference in discoverability. Imagine someone that uses zip() in code that works for a while, and then discovers a bug triggered by unequal length inputs. If it’s a flag, they look at the zip docstring, and find the flag, and their problem is solved. Is it’s in itertools, they have to think to look there. Granted, some googling will probably lead them there, and the zip() docstring can point them there, but it’s still a heavier lift. -CHB > Steve > ___ > 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/YJ3PBENBNHXPQIEJVRTTXGQHHTSDY67B/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- 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/IZ3HYYEGGUUSCASTB2WMZMYD6QUP2AAU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: zip(x, y, z, strict=True)
Andrew Barnert via Python-ideas writes: > > Also -1 on the flag. Also -1 on the flag, for the same set of reasons. I have to dissent somewhat from one of the complaints, though: > auto-complete won’t help at all, Many (most?) people use IDEs that will catch up more or less quickly, though. Such catchup could be automated to some extent by using an Enum, although folks who would use the flag might prefer the string API. You could handle both, but that would add even more complexity to the function's initialization. I think that the issue of searchability and signature are pretty compelling reasons for such a simple feature to be part of the function name. Steve ___ 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/YJ3PBENBNHXPQIEJVRTTXGQHHTSDY67B/ Code of Conduct: http://python.org/psf/codeofconduct/
