[Python-checkins] r76722 - peps/trunk/pep-0386.txt

[tarek.ziade]

Author: tarek.ziade
Date: Wed Dec  9 00:12:59 2009
New Revision: 76722

Log:
copy editing

Modified:
   peps/trunk/pep-0386.txt

Modified: peps/trunk/pep-0386.txt
==============================================================================
--- peps/trunk/pep-0386.txt	(original)
+++ peps/trunk/pep-0386.txt	Wed Dec  9 00:12:59 2009
@@ -21,13 +21,13 @@
 In Python there are no real restriction yet on how a project should manage its
 versions, and how they should be incremented.
 
-Distutile provides a `version` distribution meta-data field but it is freeform and
+Distutils provides a `version` distribution meta-data field but it is freeform and
 current users, such as PyPI usually consider the latest version pushed as the
 `latest` one, regardless of the expected semantics.
 
 Distutils will soon extend its capabilities to allow distributions to express a
 dependency on other distributions through the ``Requires-Dist`` metadata field
-(see PEP 345 [#pep345]_) and it will optionally allow to use that field to
+(see PEP 345 [#pep345]_) and it will optionally allow use of that field to
 restrict the dependency to a set of compatible versions. Notice that this field
 is replacing ``Requires`` that was expressing dependencies on modules and packages.
 
@@ -37,8 +37,8 @@
 
     Requires-Dist: zope.interface (>3.5.0)
 
-This means that the distribution requires ``zope.interface``, as long as its
-version is superior to ``3.5.0``.
+This means that the distribution requires ``zope.interface`` with a version
+greater than ``3.5.0``.
 
 This also means that Python projects will need to follow the same convention
 as the tool that will be used to install them, so they are able to compare
@@ -55,10 +55,10 @@
 Requisites and current status
 =============================
 
-It is not in the scope of this PEP to come with an universal versioning schema,
-intented to support many or all existing versioning schemas. There will always
-be competing grammars, either mandated by distro or project policies or by
-historical reasons and we cannot expect that to change.
+It is not in the scope of this PEP to provide a universal versioning schema intended
+to support many or all existing versioning schemas. There will always be competing
+grammars, either mandated by distro or project policies or by historical
+reasons and we cannot expect that to change.
 
 The proposed schema should be able to express the usual versioning semantics,
 so it's possible to parse any alternative versioning schema and transform it