pmoody [EMAIL PROTECTED] added the comment:
as one of the owners listed in the code.google.com project (same name),
and the original author, you certainly have my approval for inclusion in
python.
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org
pmoody pyt...@hda3.com added the comment:
I'm biased ;) but I don't see what netaddr provides over ipaddr. it
also seems to be in the neighborhood of 50% slower (at least on my mac
mini).
pmo...@mini - 04:52 PM - ~/Downloads/ipaddr-1.0.1
- python -m timeit 'import ipaddr;\
ipaddr.IP(1.1.1.1
pmoody pyt...@hda3.com added the comment:
hm, all addresses have a subnet, even if its an implied /32, so
specifying a network as (1.1.1.0, 1.1.1.255) seems a lot more
off-putting than 1.1.1.0/24. You're also much more likely to see the
latter in network devices. I guess I don't see the utility
pmoody pyt...@hda3.com added the comment:
I'm not sure which API in netaddr you're referring to. If you want to
construct that /24 with netaddr, then I would use
netaddr.address.CIDR(1.1.1.0/24). Offhand, I can't find an API which
netaddr.AddrRange
class AddrRange(__builtin__.object
pmoody pyt...@hda3.com added the comment:
That is not sufficient for inclusion to Python. We also want support
from the author (along with a promise to eventually give up the external
project).
As Guido had mentioned in a previous message, this is along the lines
of my thinking wrt ipaddr
pmoody pyt...@hda3.com added the comment:
Good idea.
Peter M. and the ipaddr contributors, are you all happy to proceed in
accordance with Duncan's suggestions? If so, let's kick off a thread on
python-dev to get the ball rolling and see what we can come up with.
I'm fine
pmoody pyt...@hda3.com added the comment:
(kicking an old thread)
On Mon, Jan 5, 2009 at 11:21 AM, Guido van Rossum
rep...@bugs.python.org wrote:
Guido van Rossum gu...@python.org added the comment:
I've been on vacation and unable to follow this, and won't have time to
catch up now. Note
pmoody pyt...@hda3.com added the comment:
I could live with such a choice if the netaddr authors agree that it
is the right choice (them being experts themselves in the domain).
I don't want to be accused of drkjam's accusation of fast-tracking
code just because it comes from Google (which
pmoody added the comment:
This patch is for (address, prefixlen). I now see that the original request was
(address, netmask). I'll fix this up. In the meantime, let me know if this is
what you had in mind.
Cheers,
peter
--
keywords: +patch
Added file: http://bugs.python.org/file28233
pmoody added the comment:
Sorry. I thought I'd uploaded this earlier. I'm working on a version that
pushes the parsing into _split_optional_netmask
--
Added file: http://bugs.python.org/file28402/issue16531-2.patch
___
Python tracker rep
pmoody added the comment:
I don't see anyway to actually assign this bug to myself, but I'll get a patch
for this.
--
nosy: +pmoody
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17400
pmoody added the comment:
Is the request that is_private should return true for all reserved/non-routable
addresses? The docstrings refer to specific rfcs which don't cover most of the
addresses listed in the wikipedia page. I haven't done a lot of network
programming in the last couple
pmoody added the comment:
So I'm not convinced that 6598 space should be treated like 1918 space.
Specifically, the second paragraph of the rfc states:
Shared Address Space is distinct from RFC 1918 private address space
because it is intended for use on Service Provider networks
pmoody pyt...@hda3.com added the comment:
I'm not sure if this is still an issue, but returning the address in a packed
format was an early issue
(http://code.google.com/p/ipaddr-py/issues/detail?id=14). No objections from me
for removing it from the network objects or for removing the packed
pmoody pyt...@hda3.com added the comment:
Hynek, I don't see that error when I run the tests on a freshly built python.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14814
pmoody pyt...@hda3.com added the comment:
Reported externally, ipaddress tries to parse 4 character strings as bytes.
https://groups.google.com/forum/?hl=en_USfromgroups#!topic/ipaddr-py-dev/j6FkeJtsBz4
--
Added file: http://bugs.python.org/file26210/ipaddress-bytes-str.diff
pmoody pyt...@hda3.com added the comment:
one more patch, superseding the last patch.
also reported externally, the v6 parser would incorrectly parse some v6
addresses.
http://code.google.com/p/ipaddr-py/issues/detail?id=97
--
Added file: http://bugs.python.org/file26211/ipaddress
pmoody added the comment:
There's no reason why IPv?Network().with_prefixlen can't return str(self).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14814
pmoody added the comment:
sorry, yes, I meant the interface classes.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14814
___
___
Python-bugs
pmoody added the comment:
I'm still not convinced. The rfc still says in essence It's not private like
rfc1918 space, but sometimes certain people can treat it similarly. and I
think it would be pretty surprising for ipaddress to return True if it's not a
network operator running the query
pmoody added the comment:
is_private was, as you note, basically shorthand for is_RFC1918 (and is_RFC4193
for v6). It's not a particularly well-named method, but at the time that I
wrote it (~5 years ago?), it did what I needed it to do.
I'm not sure what you mean by an 'is_natted()' method
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
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
http
pmoody added the comment:
I've got a patch from pmarks that I've applied to ipaddr and the google code
version of ipaddress-py. I'll get it applied to the hg ipaddress.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18805
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:
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
pmoody added the comment:
on it.
I'm not a huge fan of integer args for the first argument because of possible
confusion between v4/v6.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16531
pmoody pyt...@hda3.com added the comment:
Are there any committers who'd be able to help get this integrated?
Martin is booked solid until April and that would apparently
jeopardize the inclusion of ipaddr in python 3.1.
Cheers,
/peter
On Wed, Feb 4, 2009 at 11:27 AM, Martin v. Löwis rep
pmoody pyt...@hda3.com added the comment:
I'll submit a change for this to trunk in a second.
On Fri, May 1, 2009 at 1:16 PM, Antoine Pitrou rep...@bugs.python.org wrote:
Antoine Pitrou pit...@free.fr added the comment:
Is there any chance the test methods in test_ipaddr can be PEP8-ified
pmoody pyt...@hda3.com added the comment:
well, sent it for review anyway. is this a showstopper for submission?
On Fri, May 1, 2009 at 1:19 PM, pmoody rep...@bugs.python.org wrote:
pmoody pyt...@hda3.com added the comment:
I'll submit a change for this to trunk in a second.
On Fri, May
pmoody pyt...@hda3.com added the comment:
On Mon, Jun 1, 2009 at 1:33 PM, Clay McClure rep...@bugs.python.org wrote:
Clay McClure c...@daemons.net added the comment:
On Mon, Jun 1, 2009 at 1:09 PM, Martin v. Löwis rep...@bugs.python.org
wrote:
My hope is that now that a library has been
pmoody pyt...@hda3.com added the comment:
On Mon, Jun 1, 2009 at 4:41 PM, Clay McClure rep...@bugs.python.org wrote:
Clay McClure c...@daemons.net added the comment:
On Mon, Jun 1, 2009 at 5:02 PM, R. David Murray rep...@bugs.python.org
wrote:
ipaddr.IPv4('192.168.1.1') == ipaddr.IPv4
pmoody pyt...@hda3.com added the comment:
On Mon, Jun 1, 2009 at 5:47 PM, Clay McClure rep...@bugs.python.org wrote:
Clay McClure c...@daemons.net added the comment:
On Mon, Jun 1, 2009 at 4:54 PM, Martin v. Löwis rep...@bugs.python.org
wrote:
Do you have an application in mind where
pmoody pyt...@hda3.com added the comment:
On Mon, Jun 1, 2009 at 7:38 PM, Clay McClure rep...@bugs.python.org wrote:
Clay McClure c...@daemons.net added the comment:
On Mon, Jun 1, 2009 at 9:03 PM, pmoody rep...@bugs.python.org wrote:
ifconfig: 255.255.255.0/32: bad value
That's because
pmoody pyt...@hda3.com added the comment:
I should think you would seek the opinion of those developers who
actually do have plans to use an IP address library.
That's what this has been doing for the last 8 1/2 months.
As far as I can
tell, every developer in that category, outside
pmoody added the comment:
Ack. My first impression is that #1 is probably the right way to do this. I'm
arguing with hg about the right way to stash a change, but I'll get this fixed.
--
assignee: - pmoody
___
Python tracker rep...@bugs.python.org
pmoody added the comment:
Works for me.
I was going to say that there was still the issue with the mask parsing which
turned out to be more difficult than simply applying the ipaddress-py patch but
it looks like you've managed to get that applied. I spent a few hours banging
my head
pmoody added the comment:
Hey Michiel, the patch looks good to me. Have you signed the contributor
license agreement?
http://www.python.org/psf/contrib/contrib-form/
Nick, is there anyway for me to check if this has been signed?
--
___
Python
Changes by pmoody pyt...@hda3.com:
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19157
___
___
Python-bugs-list mailing
pmoody added the comment:
Nick, did you want me to apply this?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20815
___
___
Python-bugs-list
pmoody added the comment:
Hey Exhuma, thanks for the patch.
Can you give me an example list on which this shift reduce approach works much
better?
--
assignee: - pmoody
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20826
pmoody added the comment:
subnet_of and supernet_of also avoid confusion with the IP?Interface classes
(which incidentally can be used in 'a in b' containment tests).
Michael, have you signed the contributor license agreement? I don't think I
have anyway of seeing if you have or not and I
pmoody added the comment:
Thanks!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20825
___
___
Python-bugs-list mailing list
Unsubscribe:
https
pmoody added the comment:
Yes, I think omitting the broadcast address in the usable hosts was a bug.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19157
pmoody added the comment:
Will Do.
Michael, would you mind signing the contributor agreement so I can apply your
patch?
http://www.python.org/psf/contrib/contrib-form/
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20815
pmoody added the comment:
thanks.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20815
___
___
Python-bugs-list mailing list
Unsubscribe:
https
pmoody added the comment:
fine by me. this has been on my todo list forever by $payingjob and $family
have prevented me from devoting any time.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16531
pmoody added the comment:
# We only support CIDR for IPv6, because expanded netmasks are not
# standard notation.
Yes, that's correct. I can double check this, but when I wrote ipaddress, I had
yet to encounter a v6 netmask in anything other than cider notation
pmoody added the comment:
Hey Chris,
What's the usecase for this? the netmask notation doesn't appear to be common
for v6 (at all), so I'm hesitant to add support for this if it's just something
like an academic exercise.
Cheers,
peter
pmoody added the comment:
If you have the ability to use cidr, then closing this as wontfix is my
preference. I've heard that there might be some network vendors that are
starting support the mask notation for v6 addresses though, so this may end up
getting implemented at some point in future
Changes by pmoody <pyt...@hda3.com>:
--
assignee: pmoody ->
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27628>
___
___
51 matches
Mail list logo
