[Python-checkins] peps: Grammar fixes in the unicode vs bytes section of PEP 404

[nick.coghlan]

http://hg.python.org/peps/rev/5aaa1fa3fde1
changeset:   3990:5aaa1fa3fde1
user:        Nick Coghlan <ncoghlan at gmail.com>
date:        Tue Nov 15 20:32:12 2011 +1000
summary:
  Grammar fixes in the unicode vs bytes section of PEP 404

files:
  pep-0404.txt |  15 ++++++++-------
  1 files changed, 8 insertions(+), 7 deletions(-)


diff --git a/pep-0404.txt b/pep-0404.txt
--- a/pep-0404.txt
+++ b/pep-0404.txt
@@ -92,13 +92,14 @@
 sequences.  While Python 2 also has a unicode string type, the
 fundamental ambiguity of the core string type, coupled with Python 2's
 default behavior of supporting automatic coercion from 8-bit strings
-to unicodes when the two are combined, often leads to `UnicodeError`s.
-Python 3's standard string type is a unicode, and Python 3 adds a
-bytes type, but critically, no automatic coercion between bytes and
-unicodes is provided (the closest we get are a few text-based APIs that
-assume UTF-8 as the default encoding if no encoding is explicitly stated).
-Thus, the core interpreter, its I/O libraries, module names, etc. are clear
-in their distinction between unicode strings and bytes.  Python 3's unicode
+to unicode objects when the two are combined, often leads to
+`UnicodeError`s. Python 3's standard string type is Unicode based, and
+Python 3 adds a dedicated bytes type, but critically, no automatic coercion
+between bytes and unicode strings is provided. The closest the language gets
+to implicit coercion are a few text-based APIs that assume a default
+encoding (usually UTF-8) if no encoding is explicitly stated. Thus, the core
+interpreter, its I/O libraries, module names, etc. are clear in their
+distinction between unicode strings and bytes.  Python 3's unicode
 support even extends to the filesystem, so that non-ASCII file names are
 natively supported.
 

-- 
Repository URL: http://hg.python.org/peps