[issue8686] "This isn't defined beyond that" phrase is not friendly to non-native English speakers.

New submission from INADA Naoki <songofacandy@gmail.com>: http://docs.python.org/library/difflib.html#difflib.SequenceMatcher.quick_ra...
This isn’t defined beyond that it is an upper bound on ratio(), and is faster to compute.
"beyond" is a bit confusing because it also means "over" and this sentence refers upper bound. I think "This isn't defined in detail more than..." is easier. ---------- assignee: docs@python components: Documentation messages: 105498 nosy: docs@python, naoki priority: normal severity: normal status: open title: "This isn't defined beyond that" phrase is not friendly to non-native English speakers. versions: Python 2.6, Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue8686> _______________________________________

R. David Murray <rdmurray@bitdance.com> added the comment: Unfortunately that wouldn't be correct English, as far as I know. How about "This isn't defined other than that..." I think that reads a bit more clearly than "beyond that" even to a native speaker, even though beyond is valid in this context. ---------- nosy: +r.david.murray _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue8686> _______________________________________

Changes by R. David Murray <rdmurray@bitdance.com>: ---------- versions: +Python 3.1 -Python 3.3 _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue8686> _______________________________________

A.M. Kuchling <lists@amk.ca> added the comment: How about just dropping those words entirely, and writing "Return an approximate upper bound on ratio() very quickly. This is not as accurate as ratio(), but is faster to compute." (We'd make similar changes to real_quick_ratio()'s text.) ---------- nosy: +akuchling _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue8686> _______________________________________

Martin v. Löwis <martin@v.loewis.de> added the comment: I think it's important to note that this may err towards larger numbers (rather than being merely inaccurate). I also find this "an upper bound on ratio()" difficult to understand. IIUC, it is the correct value being bounded, not the result of the function under discussion that is bounded (by the correct value). ---------- nosy: +loewis _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue8686> _______________________________________

Tim Peters <tim.peters@gmail.com> added the comment: I find this whole discussion to be hilarious ;-) "Approximate upper bound" is gibberish - "upper bound" is a crisp concept that means what it says. It's not necessarily true that an upper bound is inaccurate - it may be exactly right. So "this is not as accurate as ratio()" overstates the case. "quick_ratio() returns an upper bound on what ratio() returns" is the truth, and can't be improved by adding more words. Appealing to a "correct" result would also be misleading (what ratio() returns is a more-or-less arbitrary computation whose only claim to "correctness" is that ratio() returns what it's documented to return). If people find the gloss in the docs confusing, remove the gloss entirely, leaving just the correct: "Return an upper bound on ratio() relatively quickly." ---------- nosy: +tim_one _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue8686> _______________________________________

Terry J. Reedy <tjreedy@udel.edu> added the comment: I agree with Tim. Drop the zero-info glosses. For real_quick_ratio(), "Return an upper bound on ratio() even more quickly." should be sufficient (assuming that it *is* always quicker. Just curious, The descriptions say ratio() <= quick_ratio() and ratio() <= very_quick_ratio. is it also guaranteed that quick_ratio() <= real_quick_ratio()? Or might one 'luck out' with a better answer from the faster method? (I can imagine either being true.) ---------- nosy: +tjreedy _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue8686> _______________________________________

Tim Peters <tim.peters@gmail.com> added the comment: Terry asks:
is it also guaranteed that quick_ratio() <= real_quick_ratio()
Nope! The docs don't say that, so it's not guaranteed. It's not the _intent_ of the code that it be true, either. The only point to quick_ratio() and real_quick_ratio() is speed. ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue8686> _______________________________________

Georg Brandl <georg@python.org> added the comment: Removed gloss in r85610. ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue8686> _______________________________________
participants (7)
-
A.M. Kuchling
-
Georg Brandl
-
INADA Naoki
-
Martin v. Löwis
-
R. David Murray
-
Terry J. Reedy
-
Tim Peters