Repository navigation
canonicalize "upper-case" -> "uppercase"; "lower-case" -> "lowercase" #88211
Description
Activity
Yesterday, I was bitten by ConfigParser' default behavior to lowercase keys on reading.
When I looked in the documentation and the source code, I found that lowercase was sometimes written as "lower-case", e.g. here
https://docs.python.org/3/library/configparser.html#configparser.ConfigParser.optionxformThe webster dictionary only accepts "lowercase" as a valid English word:
https://www.merriam-webster.com/dictionary/lowercaseBefore I wanted to create a pull request for this one, I also grepped the complete source code with the following result:
lower-case 24
lowercase 207
upper-case 9
uppercase 201I'd like to create a pull request which canonicalizes the writing to a consistent "lowercase" resp. "uppercase".
Is there any core dev out there willing to review / merge this kind of PR?
I think we'd want to look at the 33 uses with hyphens to make sure removing the hyphen is correct (as opposed to just blindly make a change). But I'm generally supportive.
I don’t think that there is a problem to be fixed.
Separated «lower case» could be unfriendly, but the hyphen is there in the adjective forms so it seems that changing these instances would add churn for no benefit.I did some more research.
It looks like US English tends to use
lowercase, while British English tends tolower case, and as an alternative tolowercaseyou can also uselower-casewhen using it as an adjective.See also https://en.wiktionary.org/wiki/lowercase
So, to wrap up:
- you could use lowercase and uppercase as a noun, as an adjective and as a verb
- you can use lower case and upper case only as a noun
- you can use lower-case and upper-case only as an adjective
If that is true - I am no native English speaker, and Éric does not like to convert them all to single words, it gets a bit tougher.
Some - to me - obvious wrong usages would be:
"All IMAP4rev1 commands are supported by methods of the same name (in lower-case)."
=> in lower case or in lowercase"All POP3 commands are represented by methods of the same name, in lower-case; most return the response text sent by the server."
=> in lower case or in lowercase"Wrapper around a file that converts output to upper-case."
=> to upper case or to uppercase"Return a new UUID, in the format that MSI typically requires (i.e. in curly braces, and with all hexdigits in upper-case)."
=> in upper case or in uppercase"Hostnames are compared lower case."
=> lower-case or lowercaseÉric, are you ok with my suggested changes or do you want me to close the issue?
That's exactly the kind of manual check I had in mind. After all "anal retentive doesn't have a hyphen unless it's used as a compound adjective".
I think we should go with "lowercase" when a noun, and "lower-case" as an adjective.
Thank you for the feedback. I created a PR.
https://dictionary.cambridge.org/us/dictionary/english/lower-case lists lower-case as a valid variant for nouns as well as adjectives.
The stdlib seems to have settled on lowercase for the noun version, though. My two cents: no sense not being consist just because lower-case might also work.
On Sat, May 8, 2021 at 10:38 PM Eric V. Smith <report@bugs.python.org>
wrote:Eric V. Smith <eric@trueblade.com> added the comment:
The stdlib seems to have settled on lowercase for the noun version,
though. My two cents: no sense not being consist just because lower-case
might also work.Sounds good to me, I'm not opposed to consistency!
- addeddocsDocumentation in the Doc dirDocumentation in the Doc dirtype-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error
on Apr 10, 2022 In imaplib, the first sentence in that section there is this:
All IMAP4rev1 commands are represented by methods of the same name, either upper-case or lower-case.Should that be changed over too, or is this issue good to close?
In imaplib, the first sentence in that section there is this:
All IMAP4rev1 commands are represented by methods of the same name, either upper-case or lower-case.Should that be changed over too, or is this issue good to close?
Yes, makes sense, you can open a PR if can.
- added a commit that references this issue
on Nov 20, 2022 PR Submitted. Please let me know if there are any issues.
- added a commit that references this issue
on Dec 20, 2022 - added a commit that references this issue
on Dec 28, 2022
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
Linked PRs