mirror of
https://github.com/kennethreitz/python-guide.git
synced 2026-06-05 23:00:18 +00:00
Grammar and a couple line wraps for writing/style.
This commit is contained in:
+25
-21
@@ -101,7 +101,7 @@ calls to ``send('Hello', 'World')`` and ``point(1, 2)``.
|
|||||||
|
|
||||||
2. **Keyword arguments** are not mandatory and have default values. They are often
|
2. **Keyword arguments** are not mandatory and have default values. They are often
|
||||||
used for optional parameters sent to the function. When a function has more than
|
used for optional parameters sent to the function. When a function has more than
|
||||||
two or three positional parameters, its signature will be more difficult to remember
|
two or three positional parameters, its signature is more difficult to remember
|
||||||
and using keyword argument with default values is helpful. For instance, a more
|
and using keyword argument with default values is helpful. For instance, a more
|
||||||
complete ``send`` function could be defined as ``send(message, to, cc=None, bcc=None)``.
|
complete ``send`` function could be defined as ``send(message, to, cc=None, bcc=None)``.
|
||||||
Here ``cc`` and ``bcc`` are optional, and evaluate to ``None`` when they are not
|
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:
|
|||||||
|
|
||||||
However, all these options have many drawbacks and it is always better to use
|
However, all these options have many drawbacks and it is always better to use
|
||||||
the most straightforward way to achieve your goal. The main drawback is that
|
the most straightforward way to achieve your goal. The main drawback is that
|
||||||
readability suffers deeply from them. Many code analysis tools, such as pylint
|
readability suffers greatly when using these constructs. Many code analysis
|
||||||
or pyflakes, will be unable to parse this "magic" code.
|
tools, such as pylint or pyflakes, will be unable to parse this "magic" code.
|
||||||
|
|
||||||
We consider that a Python developer should know about these nearly infinite
|
We consider that a Python developer should know about these nearly infinite
|
||||||
possibilities, because it grows the confidence that no hard-wall will be on the
|
possibilities, because it instills confidence that no impassable problem will
|
||||||
way. However, knowing how to use them and particularly when **not** to use
|
be on the way. However, knowing how and particularly when **not** to use
|
||||||
them is the most important.
|
them is very important.
|
||||||
|
|
||||||
Like a Kungfu master, a Pythonista knows how to kill with a single finger, and
|
Like a kung fu master, a Pythonista knows how to kill with a single finger, and
|
||||||
never to actually do it.
|
never to actually do it.
|
||||||
|
|
||||||
We are all consenting adults
|
We are all consenting adults
|
||||||
@@ -195,10 +195,10 @@ dangerous. A good example is that any client code can override an object's
|
|||||||
properties and methods: there is no "private" keyword in Python. This
|
properties and methods: there is no "private" keyword in Python. This
|
||||||
philosophy, very different from highly defensive languages like Java, which
|
philosophy, very different from highly defensive languages like Java, which
|
||||||
give a lot of mechanisms to prevent any misuse, is expressed by the saying: "We
|
give a lot of mechanisms to prevent any misuse, is expressed by the saying: "We
|
||||||
are consenting adults".
|
are all consenting adults".
|
||||||
|
|
||||||
This doesn't mean that, for example, no properties are considered private, and
|
This doesn't mean that, for example, no properties are considered private, and
|
||||||
that no proper encapsulation is possible in Python. But, instead of relying on
|
that no proper encapsulation is possible in Python. Rather, instead of relying on
|
||||||
concrete walls erected by the developers between their code and other's, the
|
concrete walls erected by the developers between their code and other's, the
|
||||||
Python community prefers to rely on a set of conventions indicating that these
|
Python community prefers to rely on a set of conventions indicating that these
|
||||||
elements should not be accessed directly.
|
elements should not be accessed directly.
|
||||||
@@ -210,8 +210,8 @@ the code is modified is the responsibility of the client code.
|
|||||||
|
|
||||||
Using this convention generously is encouraged: any method or property that is
|
Using this convention generously is encouraged: any method or property that is
|
||||||
not intended to be used by client code should be prefixed with an underscore.
|
not intended to be used by client code should be prefixed with an underscore.
|
||||||
This will guarantee a better separation of duties and easier modifications of
|
This will guarantee a better separation of duties and easier modification of
|
||||||
existing code, and it will always be possible to publicize a private property,
|
existing code; it will always be possible to publicize a private property,
|
||||||
while privatising a public property might be a much harder operation.
|
while privatising a public property might be a much harder operation.
|
||||||
|
|
||||||
Returning values
|
Returning values
|
||||||
@@ -235,7 +235,7 @@ statement can assume the condition is met to further compute the function's main
|
|||||||
Having multiple such return statements is often necessary.
|
Having multiple such return statements is often necessary.
|
||||||
|
|
||||||
However, when a function has multiple main exit points for its normal course, it becomes
|
However, when a function has multiple main exit points for its normal course, it becomes
|
||||||
difficult to debug the returned result, and it may be preferable to keep a single exit
|
difficult to debug the returned result, so it may be preferable to keep a single exit
|
||||||
point. This will also help factoring out some code paths, and the multiple exit points
|
point. This will also help factoring out some code paths, and the multiple exit points
|
||||||
are a probable indication that such a refactoring is needed.
|
are a probable indication that such a refactoring is needed.
|
||||||
|
|
||||||
@@ -281,7 +281,7 @@ a tuple of two elements for each item in list:
|
|||||||
for index, item in enumerate(some_list):
|
for index, item in enumerate(some_list):
|
||||||
# do something with index and item
|
# do something with index and item
|
||||||
|
|
||||||
You can use this to swap variables, as well:
|
You can use this to swap variables as well:
|
||||||
|
|
||||||
.. code-block:: python
|
.. code-block:: python
|
||||||
|
|
||||||
@@ -360,9 +360,13 @@ Take the following code for example:
|
|||||||
def lookup_list(l):
|
def lookup_list(l):
|
||||||
return 's' in l
|
return 's' in l
|
||||||
|
|
||||||
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.
|
Even though both functions look identical, because *lookup_dict* is utilizing
|
||||||
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.
|
the fact that dictionaries in Python are hashtables, the lookup performance
|
||||||
For more information see this `StackOverflow <http://stackoverflow.com/questions/513882/python-list-vs-dict-for-look-up-table>`_ page.
|
between the two is very different. 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.
|
||||||
|
For more information see this `StackOverflow <http://stackoverflow.com/questions/513882/python-list-vs-dict-for-look-up-table>`_
|
||||||
|
page.
|
||||||
|
|
||||||
Zen of Python
|
Zen of Python
|
||||||
-------------
|
-------------
|
||||||
@@ -406,7 +410,7 @@ PEP 8
|
|||||||
|
|
||||||
Conforming your Python code to PEP 8 is generally a good idea and helps make
|
Conforming your Python code to PEP 8 is generally a good idea and helps make
|
||||||
code more consistent when working on projects with other developers. There
|
code more consistent when working on projects with other developers. There
|
||||||
exists a command-line program, `pep8 <https://github.com/jcrocholl/pep8>`_,
|
is a command-line program, `pep8 <https://github.com/jcrocholl/pep8>`_,
|
||||||
that can check your code for conformance. Install it by running the following
|
that can check your code for conformance. Install it by running the following
|
||||||
command in your Terminal:
|
command in your Terminal:
|
||||||
|
|
||||||
@@ -584,19 +588,19 @@ files for you.
|
|||||||
print line
|
print line
|
||||||
|
|
||||||
The ``with`` statement is better because it will ensure you always close the
|
The ``with`` statement is better because it will ensure you always close the
|
||||||
file, even if an exception is raised.
|
file, even if an exception is raised inside the ``with`` block.
|
||||||
|
|
||||||
Line Continuations
|
Line Continuations
|
||||||
~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
When a logical line of code is longer than the accepted limit, you need to
|
When a logical line of code is longer than the accepted limit, you need to
|
||||||
split it over multiple physical lines. Python interpreter will join consecutive
|
split it over multiple physical lines. The Python interpreter will join consecutive
|
||||||
lines if the last character of the line is a backslash. This is helpful
|
lines if the last character of the line is a backslash. This is helpful
|
||||||
sometimes but is preferably avoided, because of its fragility: a white space
|
in some cases, but should usually be avoided because of its fragility: a white space
|
||||||
added to the end of the line, after the backslash, will break the code and may
|
added to the end of the line, after the backslash, will break the code and may
|
||||||
have unexpected results.
|
have unexpected results.
|
||||||
|
|
||||||
A preferred solution is to use parentheses around your elements. Left with an
|
A better solution is to use parentheses around your elements. Left with an
|
||||||
unclosed parenthesis on an end-of-line the Python interpreter will join the
|
unclosed parenthesis on an end-of-line the Python interpreter will join the
|
||||||
next line until the parentheses are closed. The same behavior holds for curly
|
next line until the parentheses are closed. The same behavior holds for curly
|
||||||
and square braces.
|
and square braces.
|
||||||
|
|||||||
Reference in New Issue
Block a user