Nick Coghlan added the comment:
Just updating the issue state to reflect the fact Peter committed this a while
ago.
--
resolution: - fixed
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
Roundup Robot added the comment:
New changeset b9623fa5a0dd by Peter Moody in branch 'default':
#17400: correct handling of 100.64.0.0/10, fixing the docs and updating NEWS
http://hg.python.org/cpython/rev/b9623fa5a0dd
--
___
Python tracker
Nick Coghlan added the comment:
The docs patch doesn't look quite right - Peter, did you mean to copy the
is_private docs before modifying them?
As far as caching goes, perhaps we can just drop functools.lru_cache into the
relevant property implementations?
@property
@lru_cache()
Antoine Pitrou added the comment:
Sorry for chiming in a bit late, but what's the rationale for including
100.64.0.0/10 in the is_private set, rather than *only* excluding it from the
is_global set?
The rationale for RFC 6598 is precisely that 100.64.0.0/10 is *not* private in
the common
Roundup Robot added the comment:
New changeset 365fd677856f by Peter Moody in branch 'default':
#17400: fix documentation, add cache to is_global and correctly handle
100.64.0.0/10
http://hg.python.org/cpython/rev/365fd677856f
--
___
Python tracker
pmoody added the comment:
antoine, quite right. I've updated is_global.
Nick, I've added lru_cache() to is_private and updated the docs (hope it's
right this time).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17400
Nick Coghlan added the comment:
Thanks Peter, just a couple more tweaks:
- tests need to ensure the carrier private range is neither global *nor*
private (it looks to me like they will still show up as private at this
point)
- looks like the docs for is_private still need to be restored (and
Antoine Pitrou added the comment:
antoine, quite right. I've updated is_global.
Nick, I've added lru_cache() to is_private and updated the docs (hope it's
right this time).
Mmmh... I actually meant the reverse. IIUC, 100.64.0.0/10 isn't global
(i.e. globally routable) and isn't private
Roundup Robot added the comment:
New changeset 2e8dd5c240b7 by Peter Moody in branch 'default':
#17400; ipaddress should make it easy to identify rfc6598 addresses
http://hg.python.org/cpython/rev/2e8dd5c240b7
--
nosy: +python-dev
___
Python tracker
Christian Heimes added the comment:
About 2e8dd5c240b7
It might be a good idea to cache the two lists in a class or module variable in
order to speed things up. It might also be a good idea to move the most common
networks like 192.168.0.0/16 to the top of the list.
--
Roundup Robot added the comment:
New changeset 07a5610bae9d by Peter Moody in branch 'default':
#17400; NEWS and ipaddress.rst change
http://hg.python.org/cpython/rev/07a5610bae9d
--
___
Python tracker rep...@bugs.python.org
pmoody added the comment:
I have a change that needs to be submitted for the parser then I'll come back
to the caching.
The pedant in me would like like to keep the addresses ordered because that
makes it clear where to add new networks as iana changes classifications, but
it may just make
pmoody added the comment:
ok, here's an is_global/is_private patch using the iana special registry for
ipv4 and ipv6.
--
keywords: +patch
Added file: http://bugs.python.org/file31851/issue.17400.patch
___
Python tracker rep...@bugs.python.org
pmoody added the comment:
The problem is that 'shared' describes exactly one network, unless you mean
that we should try to start 'private' as 'shared'. That's something I really
don't want to do because it leads to confusion like this.
Do you not think that is_global or is_forwardable (per
Nick Coghlan added the comment:
I'd also be fine with is_carrier_private, or, as you say, the inverse
is_global for not is_private and not is_carrier_private and not (any of
the other private addresses) (assuming I understood that suggestion
correctly).
I guess the is_global one is the most
Nick Coghlan added the comment:
Reopening this - rewording the issue title to cover the problem to be solved
(i.e. accounting for RFC 6598 addresses) rather than a specific solution (which
isn't appropriate, since the RFC *explicitly* states that shared addresses and
private addresses aren't
16 matches
Mail list logo
