[Python-checkins] r74610 - peps/trunk/pep-3144.txt

[brett.cannon]

Author: brett.cannon
Date: Mon Aug 31 21:02:02 2009
New Revision: 74610

Log:
Update to PEP 3144 from Peter Moody.

Modified:
   peps/trunk/pep-3144.txt

Modified: peps/trunk/pep-3144.txt
==============================================================================
--- peps/trunk/pep-3144.txt	(original)
+++ peps/trunk/pep-3144.txt	Mon Aug 31 21:02:02 2009
@@ -137,10 +137,12 @@
     might guess, return the appropriately typed address or network objects for
     the given argument.
 
-    Finally, this distinction between IPv4 and IPv6 IP versions  means that
-    comparison operations on them return TypeError for py3k per Ordering
-    Comparisons [2]. In practice, this shouldn't pose a problem for the
-    developer who can easily write:
+    Finally, there is no meaningful natural ordering between IPv4 and IPv6
+    addresses ("these protocols are ships-in-the-night"), so rather than invent
+    a standard, ipaddr follows Ordering Comparisons [2] and returns a TypeError
+    when asked to compare objects of differing IP versions. In practice, there
+    are many ways a programmer may wish to order the addresses, so this this
+    shouldn't pose a problem for the developer who can easily write:
 
     v4 = [x for x in mixed_list if x._version == 4]
     v6 = [x for x in mixed_list if x._version == 6]
@@ -285,7 +287,7 @@
      IPv6Network('::4000:0/98'),
      IPv6Network('::8000:0/97')]
 
-    - IPv6 address compression. (in a pending changelist [3])
+    - IPv6 address compression.
 
     By default, IPv6 addresses are compressed internally (see the method
     BaseV6._compress_hextets), but ipaddr makes both the compressed and the
@@ -317,7 +319,6 @@
 
     [1] http://bugs.python.org/issue3959
     [2] http://docs.python.org/dev/3.0/whatsnew/3.0.html#ordering-comparisons
-    [3] http://codereview.appspot.com/110044
 
 
 Copyright: