Changes by pmoody :
--
assignee: pmoody ->
___
Python tracker
<http://bugs.python.org/issue27628>
___
___
Python-bugs-list mailing list
Unsubscrib
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 f
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 exer
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 cid
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
<http://bugs.python.org/issue16
pmoody added the comment:
thanks.
--
___
Python tracker
<http://bugs.python.org/issue20815>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
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
<http://bugs.python.org/issue20
pmoody added the comment:
Yes, I think omitting the broadcast address in the usable hosts was a bug.
--
___
Python tracker
<http://bugs.python.org/issue19
pmoody added the comment:
Thanks!
--
___
Python tracker
<http://bugs.python.org/issue20825>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
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 ha
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
<http://bugs.python.org/issu
pmoody added the comment:
Nick, did you want me to apply this?
--
___
Python tracker
<http://bugs.python.org/issue20815>
___
___
Python-bugs-list mailin
Changes by pmoody :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue19157>
___
___
Python-bugs-list mailing list
Unsubscrib
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
pmoody added the comment:
Since there's no broadcast address for ipv6, should calling .broadcast* on an
ipv6 address raise an exception?
--
___
Python tracker
<http://bugs.python.org/is
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 o
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 t
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
<http://bugs.pyt
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
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
<http://bugs.pyt
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
<http://bugs.py
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 thi
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_n
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 o
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 net
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
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
<http://bugs.python.o
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 trac
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/file
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
<http://bugs.python.org/is
pmoody added the comment:
sorry, yes, I meant the interface classes.
--
___
Python tracker
<http://bugs.python.org/issue14814>
___
___
Python-bugs-list mailin
pmoody added the comment:
There's no reason why IPv?Network().with_prefixlen can't return str(self).
--
___
Python tracker
<http://bugs.python.o
pmoody 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-bytes-str-v6
pmoody added the comment:
Reported externally, ipaddress tries to parse 4 character strings as bytes.
https://groups.google.com/forum/?hl=en_US&fromgroups#!topic/ipaddr-py-dev/j6FkeJtsBz4
--
Added file: http://bugs.python.org/file26210/ipaddress-bytes-str.
pmoody added the comment:
Hynek, I don't see that error when I run the tests on a freshly built python.
--
___
Python tracker
<http://bugs.python.org/is
pmoody 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 constr
pmoody 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, outsid
pmoody added the comment:
On Mon, Jun 1, 2009 at 7:38 PM, Clay McClure wrote:
>
> Clay McClure added the comment:
>
> On Mon, Jun 1, 2009 at 9:03 PM, pmoody wrote:
>
>>> ifconfig: 255.255.255.0/32: bad value
>>>
>>> That's because ipaddr wrongly
pmoody added the comment:
On Mon, Jun 1, 2009 at 5:47 PM, Clay McClure wrote:
>
> Clay McClure added the comment:
>
> On Mon, Jun 1, 2009 at 4:54 PM, Martin v. Löwis
> wrote:
>
>> Do you have an application in mind where this lack of distinction
>> would preven
pmoody added the comment:
On Mon, Jun 1, 2009 at 4:41 PM, Clay McClure wrote:
>
> Clay McClure added the comment:
>
> On Mon, Jun 1, 2009 at 5:02 PM, R. David Murray
> wrote:
>
>>> >>> ipaddr.IPv4('192.168.1.1') == ipaddr.IPv4('192.168.1.
pmoody added the comment:
On Mon, Jun 1, 2009 at 1:33 PM, Clay McClure wrote:
>
> Clay McClure added the comment:
>
> On Mon, Jun 1, 2009 at 1:09 PM, Martin v. Löwis
> wrote:
>
>>> My hope is that now that a library has been selected, it can be improved
>>
pmoody 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 wrote:
>
> pmoody added the comment:
>
> I'll submit a change for this to trunk in a second.
>
> On Fri, May 1, 2009 at 1:16 PM
pmoody 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 wrote:
>
> Antoine Pitrou added the comment:
>
> Is there any chance the test methods in test_ipaddr
pmoody 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 wrote:
>
&g
pmoody 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 Go
pmoody added the comment:
(kicking an old thread)
On Mon, Jan 5, 2009 at 11:21 AM, Guido van Rossum
wrote:
>
> Guido van Rossum added the comment:
>
> I've been on vacation and unable to follow this, and won't have time to
> catch up now. Note that I have no ve
pmoody 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
pmoody 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 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(
pmoody 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
pmoody 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("
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 PROTECTE
Changes by pmoody <[EMAIL PROTECTED]>:
--
nosy: +pmoody
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3959>
___
___
Python-bugs
53 matches
Mail list logo
