Re: [Python-Dev] Issues with Py3.1's new ipaddr

2009-06-03 Thread Clay McClure
On Wed, Jun 3, 2009 at 11:16 AM, R. David Murray wrote: > I think this hits the nail on the head.  Rather than network engineers > having a less precise understanding of IP, what we have is two different > sets of domain requirements.  Network engineers deal with networks, with > IPs being a nece

Re: [Python-Dev] Issues with Py3.1's new ipaddr

2009-06-02 Thread Clay McClure
On Tue, Jun 2, 2009 at 10:41 PM, Gregory P. Smith wrote: > ipaddr could be changed to yield IPv4 /32 or IPv6 /128 objects when > iterating over it instead of strings and this example would work > properly. I have opened an issue in the ipaddr bug tracker that I think addresses this issue. There

Re: [Python-Dev] Issues with Py3.1's new ipaddr

2009-06-02 Thread Clay McClure
On Tue, Jun 2, 2009 at 4:53 PM, R. David Murray wrote: > Having thought more about this, I will agree with you that it would > be useful to have an address-without-netmask class. Not only useful, but necessary. It seems there are few people on this list who understand IP well enough to realize h

Re: [Python-Dev] Issues with Py3.1's new ipaddr

2009-06-02 Thread Clay McClure
On Tue, Jun 2, 2009 at 2:08 AM, "Martin v. Löwis" wrote: >> That doesn't solve much. IPv4 objects still always use CIDR notation >> when coerced to strings, meaning that IP addresses will always be >> rendered with a trailing "/32". > > That's not true: > > py> x = ipaddr.IP("30.40.50.60") > py>

Re: [Python-Dev] Issues with Py3.1's new ipaddr

2009-06-02 Thread Clay McClure
On Tue, Jun 2, 2009 at 2:15 AM, "Martin v. Löwis" wrote: > We could remove it, but then what we have wouldn't really be a release > candidate anymore, so the release would get delayed. How long do release candidates soak in the field before being accepted? I'm curious if an exception could be m

Re: [Python-Dev] Issues with Py3.1's new ipaddr

2009-06-02 Thread Clay McClure
On Tue, Jun 2, 2009 at 9:22 AM, R. David Murray wrote: > ip[0] >> >> '10.33.11.17' > > Actually I find that very intuitive if I understand that the objects > are always networks. I suspect the authors would disagree with you on this point, since they insist that host routes and host addresse

Re: [Python-Dev] Issues with Py3.1's new ipaddr

2009-06-01 Thread Clay McClure
On Tue, Jun 2, 2009 at 1:47 AM, "Martin v. Löwis" wrote: >> If this were a core feature that many developers were anxiously >> awaiting, I could understand the desire to release and iterate. But is >> there really a pressing need for an IP library in the stdlib? > > You should have asked this que

Re: [Python-Dev] Issues with Py3.1's new ipaddr

2009-06-01 Thread Clay McClure
On Tue, Jun 2, 2009 at 1:38 AM, "Martin v. Löwis" wrote: > For the net-vs-host issue, I think a backwards-compatible solution > is possible: just give the IP() function an option parameter that > makes it reject a netmask during parsing. That doesn't solve much. IPv4 objects still always use CID

[Python-Dev] Issues with Py3.1's new ipaddr

2009-06-01 Thread Clay McClure
On Mon, Jun 1, 2009 at 11:32 AM, Guido van Rossum wrote: > I haven't read the bug, but given the extensive real-life use that > ipaddr.py has seen at Google before inclusion into the stdlib, I think > "deep conceptual flaws" must be an overstatement. When the users of the library are also the au