However, some extension modules, either standard or third-party, are designed so as to release the GIL when doing computationally-intensive tasks such as compression or hashing.
The phrase “computationally intensive” doesn’t need a hyphen, because it isn’t ambiguous. Now that I’ve noticed it, it seems there are about a hundred similarly over-hyphenated phrases. I can fix them all, but I wonder if it would be considered too minor a fix to the docs?
Others: “externally-usable name”, “locally-developed modules”, “statically-declared type object”, and so on.
At least for me, the hyphenation makes those sentences easier to parse. I would leave them hyphenated unless the hyphenation is orthographically incorrect.
To me[1] the hyphenated form simply looks wrong. Generally, when I see hyphenated forms like this, I just assume it’s incorrect (but I tend not to make an issue of it, because it’s relatively innoccuous). I’d personally be +0.5 on a PR to remove the hyphens (only +0.5 because it’s a minor improvement and the churn may not be worth it).
As a native English speaker, for what it’s worth (which may not be much…) ↩︎
I never knew there was a rule about this. I’ve learned English by watching what others write, from technical manuals through USENET forums to Twitter, never by being taught specific rules by English teachers or grammar manuals. Apparently this particular hypercorrection is common enough that it doesn’t strike me as wrong, and in fact some of the examples read better to me with the hyphen, despite it being technically redundant. I wonder if this is one of those cases where the people complaining about hypercorrectness are themselves being overly picky, and we should just allow both forms? (Also, why does spell correction claim that hypercorrect needs a hyphen? It looks better to me as one word.
Yeah, English is crazy, and I’m technically a native speaker (born/raised in the USA to Finnish parents who spoke Swedish at home, so that’s native too). All languages evolve, borrow from other languages, try to synthesize rules of grammar from existing usage and leave things that break those rules - because the implementation wins over the standard . This doesn’t seem “incorrect” enough to be worth making changes for, IMO - nor to reject new content that does (or doesn’t) hyphenate in this context.
For what its worth, I’m an English native, consider myself a fairly competent technical writer and I’ve worked a number of gigs as a technical writer, copyeditor, proofreader and writing tutor, and at least as far as grades, essays and tests go, English reading and writing was by far and away my strongest subject from elementary through graduate level.
However, I can’t even name all the parts of speech, don’t think much about grammar rules and only rarely reach for a style manual for fairly esoteric pedantic issues. Virtually all of my writing ability is purely intuitive and derived from “knowing” what sounds right based on the large amount of material I’ve read, coupled with a keen eye for pattern recognition. (That said, I do resort to double-checking the appropriate style guide from time to time when necessary)
In this case, while I do have an understanding of the justification of the particular hyphenation rule in question, and try to apply the appropriate pattern in my own writing and reviewing when needed, it ultimately comes down to whether the hyphen, if syntactically correct, meaningfully reduces ambiguity.
However, IMO, it is sufficiently pedantic and stylistic that to me, there seems to be far more meaningful and valuable quality issues we could address (and discuss) with the docs than this, at least on its own.
I agree it is minor, but a meaningful benefit. We’ve begun to adopt (I believe) a position that for documentation ‘churn’ is not as much of a problem, as the benefits for the millions [1] of readers of the documentation outweigh the minor additional cost in browsing git history.
For this change it seems Ned has already done the work, and it is a net improvement (also speaking as a native [British] English speaker), so I would support it. We’ve probably spent more time debating it here than it would take to create + review the PR!
A
Entirely unquantified statistic alert; I don’t actually know if we publish hit counts for docs/peps/devguide/python.org/etc. ↩︎
After reading in context the changes suggested by the PR, I agree that the hyphen is unnecessary in almost all the cases (and only barely helpful in the remaining ones).
I just caught myself adding one such hyphen and promptly removed it (“similarly named functions”), and I’ll try to keep this in mind in the future.
I’m a native English speaker with a decent level of literacy and an interest in foreign languages (and computer ones, obviously). My understanding of English grammar remains “instinctive”, since we were never taught it systematically.
When it comes to the writing dilemma, instead of “externally-usable name”, “locally-developed modules”, “statically-declared type object”, and so on, I would probably write “a name usable externally”, “modules developed locally”, “a type object declared statically”. I just think it sounds nicer.
. This doesn’t seem “incorrect” enough to be worth making changes for, IMO - nor to reject new content that does (or doesn’t) hyphenate in this context.