diff options
Diffstat (limited to 'Doc/howto')
| -rw-r--r-- | Doc/howto/logging-cookbook.rst | 2 | ||||
| -rw-r--r-- | Doc/howto/pyporting.rst | 2 | ||||
| -rw-r--r-- | Doc/howto/webservers.rst | 2 |
3 files changed, 3 insertions, 3 deletions
diff --git a/Doc/howto/logging-cookbook.rst b/Doc/howto/logging-cookbook.rst index c201e87..0bd7bb3 100644 --- a/Doc/howto/logging-cookbook.rst +++ b/Doc/howto/logging-cookbook.rst @@ -960,7 +960,7 @@ and each time it reaches the size limit it is renamed with the suffix ``.1``. Each of the existing backup files is renamed to increment the suffix (``.1`` becomes ``.2``, etc.) and the ``.6`` file is erased. -Obviously this example sets the log length much much too small as an extreme +Obviously this example sets the log length much too small as an extreme example. You would want to set *maxBytes* to an appropriate value. .. _zeromq-handlers: diff --git a/Doc/howto/pyporting.rst b/Doc/howto/pyporting.rst index 124ef33..309f3f7 100644 --- a/Doc/howto/pyporting.rst +++ b/Doc/howto/pyporting.rst @@ -328,7 +328,7 @@ the bytes/string dichotomy. Because Python 2 allowed the ``str`` type to hold textual data, people have over the years been rather loose in their delineation of what ``str`` instances held text compared to bytes. In Python 3 you cannot be so care-free anymore and need to properly handle the difference. The key -handling this issue to to make sure that **every** string literal in your +handling this issue to make sure that **every** string literal in your Python 2 code is either syntactically of functionally marked as either bytes or text data. After this is done you then need to make sure your APIs are designed to either handle a specific type or made to be properly polymorphic. diff --git a/Doc/howto/webservers.rst b/Doc/howto/webservers.rst index c4ac2b2..74cdf4b 100644 --- a/Doc/howto/webservers.rst +++ b/Doc/howto/webservers.rst @@ -264,7 +264,7 @@ used for the deployment of WSGI applications. * `FastCGI, SCGI, and Apache: Background and Future <http://www.vmunix.com/mark/blog/archives/2006/01/02/fastcgi-scgi-and-apache-background-and-future/>`_ - is a discussion on why the concept of FastCGI and SCGI is better that that + is a discussion on why the concept of FastCGI and SCGI is better than that of mod_python. |