]> granicus.if.org Git - python/commitdiff
Docs: Improved phrasing (GH-14069)
authorAeros <44193521+aeros167@users.noreply.github.com>
Fri, 21 Jun 2019 04:43:07 +0000 (00:43 -0400)
committerCarol Willing <carolcode@willingconsulting.com>
Fri, 21 Jun 2019 04:43:07 +0000 (21:43 -0700)
* Docs: Improved phrasing

Removed usage of second person pronouns in the section and made the assumption of "uneasiness" in code style transition more neutral.

* Removed trailing whitespace on line 34

Doc/faq/design.rst

index e2d63a0323da661b043e6672b5c4e3e2df79df27..387420c17bd152800543ab0cae713b137f846db9 100644 (file)
@@ -24,14 +24,16 @@ programmers will encounter a fragment of code like this::
    z++;
 
 Only the ``x++`` statement is executed if the condition is true, but the
-indentation leads you to believe otherwise.  Even experienced C programmers will
-sometimes stare at it a long time wondering why ``y`` is being decremented even
+indentation leads many to believe otherwise.  Even experienced C programmers will
+sometimes stare at it a long time wondering as to why ``y`` is being decremented even
 for ``x > y``.
 
 Because there are no begin/end brackets, Python is much less prone to
 coding-style conflicts.  In C there are many different ways to place the braces.
-If you're used to reading and writing code that uses one style, you will feel at
-least slightly uneasy when reading (or being required to write) another style.
+After becoming used to reading and writing code using a particular style,
+it is normal to feel somewhat uneasy when reading (or being required to write)
+in a different one.
+
 
 Many coding styles place begin/end brackets on a line by themselves.  This makes
 programs considerably longer and wastes valuable screen space, making it harder