On Sat, Jun 04, 2022 at 11:16:18PM +1000, Chris Angelico wrote: > > Redundancy is good: > > > > # Obviously, clearly wrong: > > spam, eggs, cheese = islice(myvalues, 5) > > Yes but which part is wrong?
You're a professional programmer, so I am confident that you know the answer to that :-) It's a logic error. Unlike trivial and obvious spelling errors ('import colections'), most logic errors are not amenable to trivial fixes. You have to read the code (which may be as little as the surrounding one or two lines, or as much as the entire damn program) to understand what the logic is supposed to be before you can fix it. Welcome to programming :-) A day may come when computers will write and debug their own code, making human programmers obsolete, but it is not this day. Until then, I will take all the help I can get. I'm not going to introduce unnecessary redundancy for no reason, but nor am I going to go out of my way to remove it when it is helpful. > Redundancy introduces possibilities of desynchronization. Indeed, and that is why I never write documentation or comments -- they are redundant when you have the source. *wink* All joking aside, of course you are correct. But we don't typically worry too much about such minor risks when we do things like imports: from collections import Counter # oh no, now Counter and collections.Counter may become desynced! or assertions (which should always succeed, and so they are redundant -- right up to the moment when they fail). Or when we grab a temporary reference to a sub-expression to avoid repeating ourselves. We balance the risks against the benefits, and if the risks are small compared to the benefits, we don't fret about redundancy. And sometimes, in the face of noisy communication channels, hardware failure, or hostile environments, redundancy is all but essential. > ANY code can be wrong, but it's entirely possible for the second one > to be right, and the first one is undoubtedly wrong. Indeed. When all else is equal -- which it may not always be -- we should prefer code which is obviously correct over code which merely has no obvious bugs. A line of code like `spam, eggs, cheese = islice(myvalues, 3)` is obviously correct in the sense that there is no discrepency between the left and right hand sides of the assignment, and any change which fails to keep that invariant is an obvious bug. The proposed equivalent `spam, eggs, cheese, * = myvalues` may be more convenient to write, but you no longer have that invariant. How much you care about that loss will depend on your risk tolerance compared to your laziness (one of Larry Wall's three virtues of programmers -- although opinions differ on whether he is right or not). > Obviously sometimes it's unavoidable, but I don't think we can > genuinely accept that the redundancy is *good*. You have convinced me! I'm now removing all my RAID devices! *wink* Would it have helped if I had said redundancy is *sometimes* good? -- 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/JGOKYNXFQA4OG4QR7DUB2TGHUYV3OYWY/ Code of Conduct: http://python.org/psf/codeofconduct/