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

Mon Aug 31 21:02:04 CEST 2009

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:
