On Apr 27, 2020, at 20:48, Soni L. <[email protected]> wrote
>
>> Here are four ways of doing this today:
…
>> So, why do we need another way to do something that’s probably pretty
>> uncommon and can already be done pretty easily? Especially if that new way
>> isn’t more readable or more powerful?
>
> the only one with equivalent semantics is the last one.
I won’t argue about whether two functions that give the exact same results in
every case but get there in different ways are “equivalent” or not, since one
is already good enough.
If you agree that there is obvious code that works in Python 3.8 (and even in
Python 2.7, for that matter) to get the semantics you want, why should we add a
new language feature that gives you a less readable, more verbose, and more
complicated way to do the same thing?
> tbh my particular case doesn't make a ton of practical sense.
That’s hardly a good argument for your proposal. Do you actually want the
things you propose to be added to the language, or even to be seriously
considered? If not, why are you proposing them?
>> > > see: why are we perfectly happy with ignoring extra lines at the end?
>>
>> Because there aren’t any. The file was made by catting together 2022 4-line
>> files, so it’s 8088 lines long. It will always be 8088 lines long. If I
>> really thought that was important to check, surely I’d want to check 8088
>> rather than just divisible by 4. But I didn’t think it was worth checking
>> either of those—or that the text is pure ASCII, or that the newlines are \n,
>> etc. For a more general purpose script (especially if it had to accept input
>> from potentially stupid or malicious end users and produce useful error
>> responses instead of just punting), I would have checked many of those
>> things and more, but for this script, it wasn’t worth it.
>
> that's what assert is for - making assumptions that you know are correct now,
> but might not remain so in the future!
Would you want to read, or maintain, code like this:
s = "spam"
assert isinstance(s, str)
assert isinstance(type(s), type)
assert len(s) == 4
assert len(set(s)) == len(s)
for c in s:
assert type(c) == type(s)
assert c is not None
assert len(c) == 1
assert s.count(c) == 1
assert 0 <= ord(c) < 0x110000
assert len(c.encode()) <= 4
assert not sys.stdout.closed()
print(f"{c}...")
if sys.implementation.name == "cpython”:
assert chr(ord(c)) is c
assert c == s[-1]
assert s == "spam"
I’m assuming all of those things are true, and hundreds more (from the fact
that s was unbound before the assignment to the fact that nobody has modified
the interned 0 value to mean 1), but that doesn’t mean they’re all worth
testing. Trying to test absolutely everything just means you’re more likely to
forget to test one of the important things, and more likely to miss it if you
do forget. (And that’s even assuming all of your tests are correct, which they
almost certainly won’t be if you’re trying to test everything you can imagine.
So you’ll also waste time debugging useless tests that could have been spent
verifying, debugging or improving the useful tests and/or the actual
functionality.)
On top of that, if my input file doesn’t have 8088
lines, that’s almost certainly not a bug in my code, but either user error (I
put the wrong file at that path) or corrupted data (I accidentally truncated
the file). So testing it with an assert would actually be misleading myself; it
should be something like a ValueError. Even if you never programmatically
handle the error, having the right error makes a big difference to ease of
debugging.
>> Even if you think Python should be doing more to encourage such checks, your
>> proposal doesn’t help that at all—what you want is something like Serhiy’s
>> proposal in the other thread (to eventually rename zip to zip_shortest and
>> either get rid of plain zip or make it an alias for zip_equal).
>
> ... why not? I know assert is discouraged by many, but I wouldn't say
> enabling ppl to do these checks doesn't help ppl do these checks...? unless I
> misunderstand what you mean by this?
Because people already are enabled to check, and they’re just choosing not to.
Giving them a harder and less discoverable way isn’t going to change that.
Anyone who’s decided it’s not worth using zip_equal instead of zip is not going
to think it’s worth adding an else and a test to the loop around that zip.
_______________________________________________
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/DNSURDEN67HDRYBBWV7FONVITNOKEC3J/
Code of Conduct: http://python.org/psf/codeofconduct/
