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 -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/JGOKYNXFQA4OG4QR7DUB2TGHUYV3OYWY/
Code of Conduct: http://python.org/psf/codeofconduct/
