This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: A selection of spelling errors and typos throughout source
Type: Stage:
Components: Documentation Versions: Python 3.0, Python 3.1, Python 2.7, Python 2.6
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: mark.dickinson Nosy List: eric.araujo, georg.brandl, mark.dickinson, r.david.murray, rhettinger
Priority: low Keywords: patch

Created on 2009-02-21 19:24 by mark.dickinson, last changed 2022-04-11 14:56 by admin. This issue is now closed.

File name Uploaded Description Edit
spellings.patch mark.dickinson, 2009-02-21 19:23
fix-builtin_2.7.diff eric.araujo, 2010-02-04 17:28 Patch for trunk
fix-builtin_3.2.diff eric.araujo, 2010-02-04 17:28 Patch for py3k trunk
typo.diff eric.araujo, 2010-02-08 01:01 misplaced paren
moreboredom.diff eric.araujo, 2010-03-07 03:20 “builtin” fixes in Misc
doc.diff eric.araujo, 2010-03-07 05:52 “builtin” fixes in Doc
some-rewrapping.diff eric.araujo, 2010-03-07 06:30 patch that wraps long lines in some files
Messages (24)
msg82577 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-02-21 19:23
Here's a patch that represents the result of grepping through the source 
for some of my favo(u)rite spelling errors.

Georg, I reali(z/s)e that most of these fixes are outside the Doc/ 
directory, but are you interested in taking a look at these?  Please 
unassign if not.

Two notes:

- I'm pretty sure that all of these are genuine errors.  The only one
that may be controversial is 'builtin -> built-in' (when used as an 
adjective).  The 'Apple Publications Style Guide' seems to use built-in in 
preference to builtin.  I also think I missed a few of these.

- My (American English) spell-checker complains about 'signalled', but it 
looks fine when I put my British English eyes in.  The docs contain  
instances of both 'signalled' *and* 'signaled'.  Is there any consensus on 
whether American English or British English should be used for Python's 
documentation?  (Should also check for 'signalling' versus 'signaling'.)
msg82578 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2009-02-21 19:38
I reviewed the patch and found nothing wrong. (BTW, if you noticed the
almost-total lack of its<->it's errors, it's because I fixed all of them
some time ago :)

"built-in" is fine.

About AE/BE: I think we had a consensus somewhere that we have no fixed
variant, but if you write a larger chunk of text you may write in your
preferred spelling.  I guess that if you look for instances of "-or" vs
"-our" you might find lots of stuff too.  So I'd leave them alone.
msg82584 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2009-02-21 21:11
Please do not change builtin to built-in.  In a python context, it reads
fine as one word.
msg82597 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-02-22 09:34
Thanks, Georg.  And yes, I was indeed wondering why I found so few wayward 

Applied in r69846, r69847.  I'm not sure whether it's worth backporting 
these to 2.6 and 3.0.

> Please do not change builtin to built-in.  In a python context, it reads
> fine as one word.

"built-in" seems to be the more common spelling within the documentation.
Personally, in the context of Python I find "builtin" acceptable as a noun 
("don't shadow builtins"), but it still looks wrong when used as an 
adjective ("the builtin function open").  Anyway, I'll refrain from making 
any more of these changes.
msg96688 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2009-12-20 15:24
Short summary from a discussion on #python-dev:
- verb form: “This function is built in.”
- adjective form: “``str`` is a built-in function”
- noun form (not mainstream English, but usual in programming contexts):
“``repr`` is a builtin”, “prefer the builtins”.
msg98842 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2010-02-04 17:28

I fixed a few remaining misuses of “builtin” in the source. There is some diff noise due to reformatting paragraphs where the addition of the hyphen caused the line to get over 80 characters.

Note that I didn’t check the use of “built-in”, for fear of having too much files to review.

I looked only in Doc. I’ve found misuses in other places, but reviewing the whole source would take more time than I had on my hands.

Please review.

msg98898 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2010-02-05 19:34
Additional note to help reviewing: I changed occurrences of the form “builtin x” to “built-in function x” not because I think the noun “builtin” is incorrect, as you may guess from my first message in this thread, but because it seemed more readable for beginners. If core devs disagree for some reason I’ll back out these changes.

About the change from “the builtin set function” to “the built-in set class”: I stumbled about this occurrence and fixed it, but haven’t looked at the rest of the docs. Tell me if this belongs in a separate, more complete patch.
msg98950 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2010-02-06 18:47
Thanks, committed as r78024, r78025, respectively.
msg99035 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2010-02-08 01:01
I should have seen this when changing one use of “builtin”. Applies only to py3k, since the glossary for trunk does not mention the `next` function.
msg99564 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2010-02-19 09:10
Thanks, applied as r78238.
msg100559 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2010-03-07 03:20
Hello again

And now for something completely different: more builtin/built-in/built in fixes. I hope it’s okay to edit Misc/HISTORY and old Misc/NEWS entries.

Note that I fixed two unrelated typos that I noticed near “builtin” uses.

Some day I’ll do something more useful for Python.

msg100563 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2010-03-07 05:52
I grepped for “built-in” in Doc and found very few misuses. Patch attached.

Some lines needed rewrapping, I made another patch for this to ease reviewing.

msg100565 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2010-03-07 06:30
Here is the path that rewraps lines longer than 80 characters.

Note that it is possible than some lines were unnecessarily rewrapped; I’m not really sure whether my editor displays the characters count or the index of the next character. Sorry about that.

I’ve noticed that some parts were wrapped to 72 characters and other to 80. PEP 8 tells to wrap text to 72 characters in Python files; is there a similar guideline for the doc anywhere?

If anyone know of a tool that can report lines longer that a certain length (preferably encoding-aware, i.e. counting characters and not bytes), I’d be glad to hear of it.

msg100583 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2010-03-07 15:11
Georg can correct me if I'm wrong, but I believe we generally only rewrap lines when we change the text for some other reason.  My observation was that Georg re-wraps doc text to 79 chars, so that's what I've been doing.  PEP 8 really only applies to source files, the docs are (at least currently) Georg's demesne.
msg100584 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2010-03-07 15:24
David is correct, rewrapping while editing is intrusive enough.

The docs should be wrapped at 79/80 characters.  The reason that most files have longer lines is that the latex to rest converter tool had a flaw in the wrapping code that I didn't notice until after the conversion.

Applied the two other patches in r78760.
msg100585 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2010-03-07 15:25
> rewrap lines when we change the text for some other reason.
Doesn’t that make harder to review the real changes when they are mixed 
with rewrapping?

 > PEP 8 really only applies to source files, the docs are (at least
 > currently) Georg's demesne.
(domain?) I was only citing PEP 8 as a reference, since there are some 
indications about line length of text paragraphs.

msg100586 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2010-03-07 15:28
> > rewrap lines when we change the text for some other reason.
> Doesn’t that make harder to review the real changes when they are mixed 
> with rewrapping?

That's true. I wouldn't do it in patches I mean someone else to review. But many times it's the other way round: I apply doc changes from some patch, and then rewrap before committing.
msg100587 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2010-03-07 15:40
No, I meant demense (I even looked up the spelling).  The word is related to domain, but has a somewhat more precise shading of meaning :)

     A lord's chief manor place, with that part of the lands
     belonging thereto which has not been granted out in tenancy;
     a house, and the land adjoining, kept for the proprietor's
     own use. [Written also {demain}.] --Wharton's Law Dict.

In other words, Georg is lord of this particular manor, unless he assigns a piece to someone seemed in keeping with the Python tradition of having a BDFL.
msg100588 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2010-03-07 15:51
Thanks for the new word. (I checked with my local dictd but not on the 
Intertubes, should have).

Having designated active maintainers for modules and areas is indeed great.

msg102773 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2010-04-10 12:18
Hello spelling and doc people

(I hope it’s okay to use this bug as umbrella instead of opening a myriad bugs for typos.)

Attached patch fixes small things in functools module and docs:
- Typos: “simplies” does not exist, “fills-in” needs no hyphen since it’s a verb;
- Unnecessary repetition of filename in docstring (doc tools are good enough to introspect it, see e.g. “pydoc functools”);
- Whitespace in keyword arguments;
- Use triple-quoted docstrings for consistency’s sake.

msg102934 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2010-04-12 09:44

r79951 fixes “simplies” and add the typo “specifyication” <Muphry’s Law wink>. Updated my patch to remove that and add this.

msg103002 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2010-04-13 02:17
I saw the author of functools on the chatroom and asked for feedback. Summary:

* Rewrapping, whitespace changes, quote changes and other minor PEP 8 stuff is not worth the trouble it creates (eats time without improving Python’s quality, and also disturbing use of $vcs blame);
* Doc changes have to apply to all four branches, not just trunk and py3k.

This leaves the two typos.  I’ll port the “built{-,}in” fixes to 2.6 and 3.1 later.
msg103114 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2010-04-14 08:57
OK, fixed the two typos in r80067, r80068.  Please open a new issue for further fixes, this one gets a bit confusing :)
msg103116 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2010-04-14 09:11
Raymond didn’t want the quote characters changed, sorry if I failed to channel him.

I’ll port the “builtin” typo fixes to the other branches and let this report closed. Thanks for the guidance.
Date User Action Args
2022-04-11 14:56:46adminsetgithub: 49591
2010-04-14 09:11:36eric.araujosetmessages: + msg103116
2010-04-14 08:57:42georg.brandlsetmessages: + msg103114
2010-04-13 02:17:16eric.araujosetmessages: + msg103002
2010-04-13 01:41:22eric.araujosetfiles: - functools-typos-pep8.diff
2010-04-13 01:41:17eric.araujosetfiles: - functools-typos-pep8.diff
2010-04-12 09:44:28eric.araujosetfiles: + functools-typos-pep8.diff

messages: + msg102934
2010-04-10 12:19:00eric.araujosetfiles: + functools-typos-pep8.diff

messages: + msg102773
2010-03-07 15:51:34eric.araujosetmessages: + msg100588
2010-03-07 15:40:53r.david.murraysetmessages: + msg100587
2010-03-07 15:28:19georg.brandlsetmessages: + msg100586
2010-03-07 15:25:56eric.araujosetmessages: + msg100585
2010-03-07 15:24:08georg.brandlsetmessages: + msg100584
2010-03-07 15:11:23r.david.murraysetnosy: + r.david.murray
messages: + msg100583
2010-03-07 06:30:16eric.araujosetfiles: + some-rewrapping.diff

messages: + msg100565
2010-03-07 05:53:02eric.araujosetfiles: + doc.diff

messages: + msg100563
2010-03-07 03:20:54eric.araujosetfiles: + moreboredom.diff

messages: + msg100559
2010-02-19 09:10:25georg.brandlsetmessages: + msg99564
2010-02-08 01:01:08eric.araujosetfiles: + typo.diff

messages: + msg99035
2010-02-06 18:47:13georg.brandlsetstatus: open -> closed

messages: + msg98950
2010-02-05 19:34:24eric.araujosetmessages: + msg98898
2010-02-04 17:29:10ezio.melottisetstatus: closed -> open
2010-02-04 17:28:39eric.araujosetfiles: + fix-builtin_3.2.diff
2010-02-04 17:28:07eric.araujosetfiles: + fix-builtin_2.7.diff

messages: + msg98842
2009-12-20 15:24:41eric.araujosetnosy: + eric.araujo
messages: + msg96688
2009-02-22 09:34:53mark.dickinsonsetstatus: open -> closed
resolution: accepted -> fixed
messages: + msg82597
2009-02-21 21:11:22rhettingersetnosy: + rhettinger
messages: + msg82584
2009-02-21 19:38:22georg.brandlsetassignee: georg.brandl -> mark.dickinson
resolution: accepted
messages: + msg82578
2009-02-21 19:24:09mark.dickinsoncreate