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: