Skip to content

Commit 2e9ae21

Browse files
committed
Grammar and a couple line wraps for writing/style.
1 parent 707628d commit 2e9ae21

File tree

1 file changed

+25
-21
lines changed

1 file changed

+25
-21
lines changed

docs/writing/style.rst

Lines changed: 25 additions & 21 deletions
Original file line numberDiff line numberDiff line change
@@ -101,7 +101,7 @@ calls to ``send('Hello', 'World')`` and ``point(1, 2)``.
101101

102102
2. **Keyword arguments** are not mandatory and have default values. They are often
103103
used for optional parameters sent to the function. When a function has more than
104-
two or three positional parameters, its signature will be more difficult to remember
104+
two or three positional parameters, its signature is more difficult to remember
105105
and using keyword argument with default values is helpful. For instance, a more
106106
complete ``send`` function could be defined as ``send(message, to, cc=None, bcc=None)``.
107107
Here ``cc`` and ``bcc`` are optional, and evaluate to ``None`` when they are not
@@ -176,15 +176,15 @@ possible to do each of the following:
176176

177177
However, all these options have many drawbacks and it is always better to use
178178
the most straightforward way to achieve your goal. The main drawback is that
179-
readability suffers deeply from them. Many code analysis tools, such as pylint
180-
or pyflakes, will be unable to parse this "magic" code.
179+
readability suffers greatly when using these constructs. Many code analysis
180+
tools, such as pylint or pyflakes, will be unable to parse this "magic" code.
181181

182182
We consider that a Python developer should know about these nearly infinite
183-
possibilities, because it grows the confidence that no hard-wall will be on the
184-
way. However, knowing how to use them and particularly when **not** to use
185-
them is the most important.
183+
possibilities, because it instills confidence that no impassable problem will
184+
be on the way. However, knowing how and particularly when **not** to use
185+
them is very important.
186186

187-
Like a Kungfu master, a Pythonista knows how to kill with a single finger, and
187+
Like a kung fu master, a Pythonista knows how to kill with a single finger, and
188188
never to actually do it.
189189

190190
We are all consenting adults
@@ -195,10 +195,10 @@ dangerous. A good example is that any client code can override an object's
195195
properties and methods: there is no "private" keyword in Python. This
196196
philosophy, very different from highly defensive languages like Java, which
197197
give a lot of mechanisms to prevent any misuse, is expressed by the saying: "We
198-
are consenting adults".
198+
are all consenting adults".
199199

200200
This doesn't mean that, for example, no properties are considered private, and
201-
that no proper encapsulation is possible in Python. But, instead of relying on
201+
that no proper encapsulation is possible in Python. Rather, instead of relying on
202202
concrete walls erected by the developers between their code and other's, the
203203
Python community prefers to rely on a set of conventions indicating that these
204204
elements should not be accessed directly.
@@ -210,8 +210,8 @@ the code is modified is the responsibility of the client code.
210210

211211
Using this convention generously is encouraged: any method or property that is
212212
not intended to be used by client code should be prefixed with an underscore.
213-
This will guarantee a better separation of duties and easier modifications of
214-
existing code, and it will always be possible to publicize a private property,
213+
This will guarantee a better separation of duties and easier modification of
214+
existing code; it will always be possible to publicize a private property,
215215
while privatising a public property might be a much harder operation.
216216

217217
Returning values
@@ -235,7 +235,7 @@ statement can assume the condition is met to further compute the function's main
235235
Having multiple such return statements is often necessary.
236236

237237
However, when a function has multiple main exit points for its normal course, it becomes
238-
difficult to debug the returned result, and it may be preferable to keep a single exit
238+
difficult to debug the returned result, so it may be preferable to keep a single exit
239239
point. This will also help factoring out some code paths, and the multiple exit points
240240
are a probable indication that such a refactoring is needed.
241241

@@ -281,7 +281,7 @@ a tuple of two elements for each item in list:
281281
for index, item in enumerate(some_list):
282282
# do something with index and item
283283
284-
You can use this to swap variables, as well:
284+
You can use this to swap variables as well:
285285

286286
.. code-block:: python
287287
@@ -360,9 +360,13 @@ Take the following code for example:
360360
def lookup_list(l):
361361
return 's' in l
362362
363-
Even though both functions look identical, because *lookup_dict* is utilizing the fact that dictionaries in Python are hashtables, the lookup performance between the two is very different.
364-
Python will have to go through each item in the list to find a matching case, which is time consuming. By analysing the hash of the dictionary, finding keys in the dict can be done very quickly.
365-
For more information see this `StackOverflow <http://stackoverflow.com/questions/513882/python-list-vs-dict-for-look-up-table>`_ page.
363+
Even though both functions look identical, because *lookup_dict* is utilizing
364+
the fact that dictionaries in Python are hashtables, the lookup performance
365+
between the two is very different. Python will have to go through each item
366+
in the list to find a matching case, which is time consuming. By analysing
367+
the hash of the dictionary, finding keys in the dict can be done very quickly.
368+
For more information see this `StackOverflow <http://stackoverflow.com/questions/513882/python-list-vs-dict-for-look-up-table>`_
369+
page.
366370

367371
Zen of Python
368372
-------------
@@ -406,7 +410,7 @@ PEP 8
406410

407411
Conforming your Python code to PEP 8 is generally a good idea and helps make
408412
code more consistent when working on projects with other developers. There
409-
exists a command-line program, `pep8 <https://github.com/jcrocholl/pep8>`_,
413+
is a command-line program, `pep8 <https://github.com/jcrocholl/pep8>`_,
410414
that can check your code for conformance. Install it by running the following
411415
command in your Terminal:
412416

@@ -584,19 +588,19 @@ files for you.
584588
print line
585589
586590
The ``with`` statement is better because it will ensure you always close the
587-
file, even if an exception is raised.
591+
file, even if an exception is raised inside the ``with`` block.
588592

589593
Line Continuations
590594
~~~~~~~~~~~~~~~~~~
591595

592596
When a logical line of code is longer than the accepted limit, you need to
593-
split it over multiple physical lines. Python interpreter will join consecutive
597+
split it over multiple physical lines. The Python interpreter will join consecutive
594598
lines if the last character of the line is a backslash. This is helpful
595-
sometimes but is preferably avoided, because of its fragility: a white space
599+
in some cases, but should usually be avoided because of its fragility: a white space
596600
added to the end of the line, after the backslash, will break the code and may
597601
have unexpected results.
598602

599-
A preferred solution is to use parentheses around your elements. Left with an
603+
A better solution is to use parentheses around your elements. Left with an
600604
unclosed parenthesis on an end-of-line the Python interpreter will join the
601605
next line until the parentheses are closed. The same behavior holds for curly
602606
and square braces.

0 commit comments

Comments
 (0)