> inet_ntop and pton are not trivial for IPv6 addresses due to the > variety of textual representations required to be accepted as > valid input, e.g.: > > 1080::8:800:200C:417A > ffff:0000:0000:ffff:0000:0000:0000:ffff > ffff:0:0:ffff::ffff > ::1 > :: > 0:0:0:0:0:0:13.1.68.3 > > A good implementation must also detect and reject all of the invalid > cases, such as improper use of the "::" zero compression syntax. > > Finally, there is the desire to generate appropriately "minimized" > output when converting back to text (the two "ffff" examples above are > the same address; the second is the appropriately minimized form). > > I'm not saying it's rocket science; I'm just saying it's sufficiently > nontrivial that you don't want everyone who needs the functions to have > to write them themselves. > > It may be that the right answer is that not enough people care about > working with IPv6 addresses on non-IPv6 platforms to make doing > anything worthwhile. I don't know who (other than me) might care > about the issue, which is why I asked :). But the number of people who care will grow. Let's leave 2.3 alone because it's so close to release time, but I trust you (Bob) to come up with a review of the existing socket module and suggest improvements in API that will improve its usability and decrease its maintenance needs. --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4