You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
57 lines
4.3 KiB
57 lines
4.3 KiB
There are three backports of ipaddress in the wild:
|
|
|
|
phihag/ipaddress ([ipaddress on PyPI](https://pypi.org/project/ipaddress/)):
|
|
> First commit: 2013-02-03<br>
|
|
> First release: 2013-02-04<br>
|
|
> Latest commit: 2018-06-10 (as of June 2018)
|
|
|
|
kwi/py2-ipaddress ([py2-ipaddress on PyPI](https://pypi.org/project/py2-ipaddress/))
|
|
> First commit: 2013-08-08<br>
|
|
> First release: 2013-08-08<br>
|
|
> Latest commit: 2015-07-14
|
|
|
|
sk-/backport_ipaddress ([backport_ipaddress on PyPI](https://pypi.org/project/backport_ipaddress/))
|
|
> First commit: 2014-08-15<br>
|
|
> First release: 2014-09-01<br>
|
|
> Latest commit: 2014-08-16 (!)
|
|
|
|
In addition, judging by http://pypi-ranking.info/search/ipaddress/ , this backport has about 5 times as many downloads as the other two combined (yes, some of those could be updates, but in my experience new downloads absolutely dwarf updates).
|
|
|
|
sk-/backport_ipaddress is a fork of kwi/py2-ipaddress. As you can see from the above dates, the project has basically never been updated after being released. So I'm just going to focus on my ipaddress vs py2-ipaddress. Mine has nearly 40x the download count.
|
|
|
|
As you can also see from the above stats, py2-ipaddress has not been updated for over two years. Sure, it's a backport and thus does not necessitate frequent updating, but for instance cPython has fixed a couple of bugs just recently, and they are certainly still present in py2-ipaddress. In contrast, I can and do regularly sync. Upstream cPython code is in the upstream branch and just gets merged, so you can sync if you need the bleeding-edge ipaddress code (but a pull request or issue would be fine too if that's what you need).
|
|
|
|
But I don't think it's even necessary to argument from metadata, when the technical facts speak for themselves:
|
|
|
|
ipaddress (my backport) replicates the Python 3.3+ experience. It works on Python 2.6, 2.7, 3.2, and in theory 3.3+, whereas py2-ipaddress is 2.6/2.7 only. In particular, these two lines are equivalent with my backport and the official Python 3.3+ module:
|
|
|
|
ipaddress.ip_address(u'8.9.10.11')
|
|
ipaddress.ip_address(b'\x08\x09\x0a\x0b') # packed representation
|
|
|
|
The other backport (py2-ipaddress), however, has decided that bytestrings ought to be treated as if the'd be unicode strings. This means that
|
|
|
|
ipaddress.ip_address(b'\x3a\x3a\x31\x32')
|
|
|
|
**returns `ipaddress.IPv4Address(u'58.58.49.50')` in Python 3 and my backport, but `ipaddress.IPv6Address(u'::12')` with py2-ipaddress**.
|
|
|
|
Since the original use case for the ipaddress module was network and firewall management code, it's needless to say that this incompatibility would have disastrous consequences.
|
|
|
|
It is possible to initialize from a packed representation in py2-ipaddress. As far as I understand, the correct code would be:
|
|
|
|
def ip_address(packed):
|
|
assert isinstance(packed, bytes)
|
|
try: # py2-ipaddress
|
|
return ipaddress.ip_address(bytearray(packed)))
|
|
except TypeError: # py 3.3+ ipaddress (or my backport)
|
|
return ipaddress.ip_address(packed)
|
|
|
|
In my opinion, a backport should not necessitate additional workarounds like this.
|
|
|
|
[Another incompability](https://github.com/maxmind/GeoIP2-python/issues/41) of py2-ipaddress is that `packed` property returns a `bytearray` object with that backport. Again, this backports strives to be compatible to the Python 3.3+ ipaddress.
|
|
|
|
I have discussed with the py2-ipaddress folks at length, but as far as I understand their position is that they're writing py2-only code anyways, and thus don't have to care about py3/py2-ipaddress compatibility. Apparently, their code is also consistently confused between unicode strings and byte strings. They simply write `ipaddress.ip_address(bytearray(packed)))` to initialize from a packed representation, since they don't expect their code to ever be ported to Python 3.
|
|
|
|
I prefer not to write new Python 2-only code in 2016 - with a ticking time bomb to boot, since 2to3ing py2-ipaddress code or outright running it under Python 3.5 would not throw any errors or warnings, and might even work sometimes.
|
|
|
|
**I want to enable new Python 3 code to run on Python 2.x**. Therefore, even if it wasn't for all these other reasons, and even if py2-ipaddress had been released 6 months earlier instead of 6 months later than my package, py2-ipaddress still would not be an option for me.
|