mirror of
https://github.com/kennethreitz/python-guide.git
synced 2026-06-05 23:00:18 +00:00
Merge remote-tracking branch 'upstream/master'
This commit is contained in:
@@ -31,17 +31,6 @@ Buildbot
|
||||
automate the compile/test cycle to validate code changes.
|
||||
|
||||
|
||||
Mule
|
||||
-----
|
||||
|
||||
`Mule <http://www.mulesoft.org/documentation/display/current/Mule+Fundamentals>`_
|
||||
is a lightweight integration platform that enables you to connect anything,
|
||||
anywhere. You can use Mule to intelligently manage message routing, data
|
||||
mapping, orchestration, reliability, security and scalability between nodes.
|
||||
Plug other systems and applications into Mule and let it handle all the
|
||||
communication between systems, enabling you to track and monitor everything
|
||||
that happens.
|
||||
|
||||
|
||||
Tox
|
||||
---
|
||||
|
||||
@@ -102,9 +102,9 @@ I do not recommend using Tornado unless you think you need it.
|
||||
Pyramid
|
||||
--------
|
||||
|
||||
`Pyramid <http://www.pylonsproject.org/>`_ is a lot like Django, except
|
||||
with a heavier focus on modularity. It comes with a smaller number of
|
||||
libraries ("batteries") built-in, and encourages users to extend its
|
||||
`Pyramid <http://www.pylonsproject.org/>`_ is a very flexible
|
||||
framework with a heavy focus on modularity. It comes with a small number
|
||||
of libraries ("batteries") built-in, and encourages users to extend its
|
||||
base functionality.
|
||||
|
||||
Pyramid does not have a large user base, unlike Django and Flask. It's a
|
||||
|
||||
@@ -48,7 +48,7 @@ your favorite OSX terminal emulator and run
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
|
||||
$ /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
|
||||
|
||||
The script will explain what changes it will make and prompt you before the
|
||||
installation begins.
|
||||
|
||||
@@ -658,8 +658,10 @@ And now the generator approach using Python's own
|
||||
@contextmanager
|
||||
def custom_open(filename):
|
||||
f = open(filename)
|
||||
yield f
|
||||
f.close()
|
||||
try:
|
||||
yield f
|
||||
finally:
|
||||
f.close()
|
||||
|
||||
with custom_open('file') as f:
|
||||
contents = f.read()
|
||||
@@ -667,7 +669,9 @@ And now the generator approach using Python's own
|
||||
This works in exactly the same way as the class example above, albeit it's
|
||||
more terse. The ``custom_open`` function executes until it reaches the ``yield``
|
||||
statement. It then gives control back to the ``with`` statement, which assigns
|
||||
whatever was ``yield``'ed to `f` in the ``as f`` portion.
|
||||
whatever was ``yield``'ed to `f` in the ``as f`` portion. The ``finally`` clause
|
||||
ensures that ``close()`` is called whether or not there was an exception inside
|
||||
the ``with``.
|
||||
|
||||
Since the two approaches appear the same, we should follow the Zen of Python
|
||||
to decide when to use which. The class approach might be better if there's
|
||||
|
||||
@@ -116,7 +116,7 @@ A simple doctest in a function:
|
||||
.. code-block:: python
|
||||
|
||||
def square(x):
|
||||
"""Squares x.
|
||||
"""Return the square of x.
|
||||
|
||||
>>> square(2)
|
||||
4
|
||||
|
||||
Reference in New Issue
Block a user