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/

Reply via email to