On May 1, 2020, at 08:08, Christopher Barker <python...@gmail.com> wrote: > > Also please keep in mind that the members of this list, and the python-dev > list, are not representative of most Python users. Certainly not beginners > but also many (most?) fairly active, but more "casual" users. > > Folks on this list are very invested in the itertools module and iteration in > general. But many folks write a LOT of code without every touching > iterttools. Honestly, a lot of it is pretty esoteric (zip_longests is not) -- > I need to read the docs and think carefully before I know what they even do.
So what? Most of the os module is pretty esoteric, but that doesn’t stop you—or even a novice who just asked “how do I get my files like dir”—from using os.listdir. For that matter, zip is in the same place as stuff like setattr and memoryview, which are a lot harder to grok than chain. That novice will never guess to look in os. And if I told them “go look in os”, that would be useless and cruel. But I don’t, I tell them “that’s called os.listdir”, and they don’t have to learn about effective/real/saved user ids or the 11 different spawn functions to “get my files like dir” like they asked. > Example: Here's the docstring for itertools.chain: > > chain(*iterables) --> chain object > > Return a chain object whose .__next__() method returns elements from the > first iterable until it is exhausted, then elements from the next > iterable, until all of the iterables are exhausted. > > I can tell you that I have no idea what that means -- maybe folks wth CS > training do, but that is NOT most people that use Python. And here’s the docstring for zip: > 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 Most people have no idea what that means either. In fact, chain is simpler to grok than zip (it just doesn’t come up as often, so it doesn’t need to be a builtin). > Anyway, inscrutable docstrings are another issue, and one I keep hoping I'll > find the time to try to address one day, Yes, many of Python’s docstrings tersely explain the details of how the function does what it does, rather than telling you why it’s useful or how to use it. And yes, that’s less than ideal. But that isn’t an advantage to adding a flag to zip over adding a new function. Making zip more complicated certainly won’t magically fix its docstring, it’ll just make the docstring more complicated. > but the point is : > > "Folks will go look in itertools when zip() doesn't do what they want " just > does not apply to most people. But nobody suggested that they will. That’s exactly why people keep saying it should be mentioned in the docstring and the docs page and maybe even the tutorial. And you’re also right that it’s also not true that “folks will read the docstring for zip() when zip() doesn’t do what they want and figure it out from there”, but that’s equally a problem for both versions of the proposal. In fact, most people, unless they learned it from a tutorial or class or book or blog post or from existing code before they needed it, are going to go to a coworker, StackOverflow, the TA for their class, a general web search, etc. to find out how to do what they want. There’s only so much Python can do about that—the docstring, docs page, and official tutorial (which isn’t the tutorial most people learn from) is about it. We have to trust that if this really is something novices need, the people who teach classes and answer on StackOverflow and write tutorials and mentor interns and help out C# experts who only use Python twice a year and so on will teach it. There’s no way around that. But if those people can and do teach os.listdir and math.sin and so on, they can also teach zip_equal. > Finally, yes, a pointer to itertools in the docstring would help a lot, but > yes, it's still a heavier lift than adding a flag, 'cause you have to then go > and import a new module, etc. What’s the “etc.” here? What additional thing do they have to do besides import a new module? People have to import a new module to get a list of their files. And lots of other things that are builtins in other languages. In JavaScript, I don’t have to import anything to decode JSON, to do basic math functions like sin or mean, to create a simple object (where I don’t have to worry about writing __init__ and __repr__ and __eq__ and so on), to make a basic web request, etc. In Python, I have to import a module to do any of those things (for the last one, I even have to install a third-party package first). Namespaces are a honking great idea, but there is a cost to that idea, and that cost includes people having to learn import pretty early on. _______________________________________________ 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/MXLQT4EOO2PSJJR5H5LSHDSDKAB6AWF4/ Code of Conduct: http://python.org/psf/codeofconduct/
