Paul Moore wrote:
linus and snoopy are hosts not networks, so
making them IPv4Network classes seems wrong. I'd instinctively make
them IPv4Address objects (which, I believe, would work).
However, by allowing IPNetwork objects to also contain
a host address, we seem to be officially sanctioning
Peter Moody wrote:
it's useful to take an
address like 192.168.1.100/24 and derive a bunch of information from
it (like the network address, broadcast address, containing supernets,
etc), but still remember that the original address was 192.168.1.100.
having a separate class or two for this is ov
Stephen J. Turnbull wrote:
> Nick Coghlan writes:
>
> > However, while I'd still be a little happier if the .ip attribute
> > went away all together and another means was found to conveniently
> > associate an IPAddress and an IPNetwork, keeping it doesn't bother
> > me anywhere near as much a
Nick Coghlan writes:
> However, while I'd still be a little happier if the .ip attribute
> went away all together and another means was found to conveniently
> associate an IPAddress and an IPNetwork, keeping it doesn't bother
> me anywhere near as much as having network equivalence defined in
Mark Dickinson wrote:
> On Wed, Sep 30, 2009 at 10:52 AM, Paul Moore wrote:
>> 2009/9/30 Mark Dickinson :
>>> Please could someone who understands the uses of IPNetwork better than
>>> I do explain why the following wouldn't be a significant problem, if __eq__
>>> and __hash__ were modified to dis
Daniel Stutzbach writes:
> People have voiced support for the IPNetwork class
The obvious use cases are
1. parsing and validating strings that purport to describe networks,
2. providing a received for the result of a function that deduces the
network from an arbitrary address and a mask
.On Wed, Sep 30, 2009 at 3:33 PM, R. David Murray wrote:
>1) do not add another class, just pass around (IPvXAddress,
>IPVXNetwork) tuples when the address needs to be retained (or write
>your own tailored trivial class, like I did in my example).
>
I've been puzzled by objections to
[...@google.com]
On Wed, Sep 30, 2009 at 2:51 PM, Raymond Hettinger wrote:
>
>>> I don't know -- this is (from what Peter told me) a common use case so
>>> he (and presumably others) would from time to time have to write
>>> extra code to keep track of that IP address in a new app.
>
> [MvL]
>>
I don't know -- this is (from what Peter told me) a common use case so
he (and presumably others) would from time to time have to write
extra code to keep track of that IP address in a new app.
[MvL]
I, and probably others, would really, REALLY like to see one such
"common use case". I do fi
[...@google.com]
this is what I wrote:
it's not so much a need as it is useful. it's useful to take an
address like 192.168.1.100/24 and derive a bunch of information from
it (like the network address, broadcast address, containing supernets,
etc), but still remember that the original address wa
> I don't know -- this is (from what Peter told me) a common use case so
> he (and presumably others) would from time to time have to write
> extra code to keep track of that IP address in a new app.
I, and probably others, would really, REALLY like to see one such
"common use case". I do find it
On Wed, 30 Sep 2009 at 13:11, Guido van Rossum wrote:
On Wed, Sep 30, 2009 at 4:33 AM, Mark Dickinson wrote:
On Wed, Sep 30, 2009 at 12:06 PM, Nick Coghlan wrote:
Mark Dickinson wrote:
Okay, so maybe this is an abuse of IPv4Network. ?But I'd (mis?)understood
that the retention of the .ip att
On Wed, Sep 30, 2009 at 4:33 AM, Mark Dickinson wrote:
> On Wed, Sep 30, 2009 at 12:06 PM, Nick Coghlan wrote:
>> Mark Dickinson wrote:
>>> Okay, so maybe this is an abuse of IPv4Network. But I'd (mis?)understood
>>> that the retention of the .ip attribute was precisely a convenience to allow
>>
Mark Dickinson wrote:
On Wed, Sep 30, 2009 at 1:44 AM, Nick Coghlan wrote:
Please could someone who understands the uses of IPNetwork better than
I do explain why the following wouldn't be a significant problem, if __eq__
and __hash__ were modified to disregard the .ip attribute as suggested:
On Wed, 30 Sep 2009 at 10:52, Paul Moore wrote:
2009/9/30 Mark Dickinson :
Please could someone who understands the uses of IPNetwork better than
I do explain why the following wouldn't be a significant problem, if __eq__
and __hash__ were modified to disregard the .ip attribute as suggested:
Mark Dickinson writes:
> >> Please could someone who understands the uses of IPNetwork
> >> better than I do explain why the following wouldn't be a
> >> significant problem, if __eq__ and __hash__ were modified to
> >> disregard the .ip attribute as suggested:
> > linus = IPv4Network('1
On Wed, Sep 30, 2009 at 12:06 PM, Nick Coghlan wrote:
> Mark Dickinson wrote:
>> Okay, so maybe this is an abuse of IPv4Network. But I'd (mis?)understood
>> that the retention of the .ip attribute was precisely a convenience to allow
>> this sort of use. If not, then what's it for? I've read th
On Wed, Sep 30, 2009 at 10:52 AM, Paul Moore wrote:
> 2009/9/30 Mark Dickinson :
>> Please could someone who understands the uses of IPNetwork better than
>> I do explain why the following wouldn't be a significant problem, if __eq__
>> and __hash__ were modified to disregard the .ip attribute as
2009/9/30 Mark Dickinson :
> Please could someone who understands the uses of IPNetwork better than
> I do explain why the following wouldn't be a significant problem, if __eq__
> and __hash__ were modified to disregard the .ip attribute as suggested:
>
linus = IPv4Network('172.16.200.1/24')
>
On Wed, Sep 30, 2009 at 1:44 AM, Nick Coghlan wrote:
> Martin v. Löwis wrote:
>>> I would say that there certainly are precedents in other areas for
>>> keeping the information about the input form around. For example,
>>> occasionally it would be handy if parsing a hex integer returned an
>>> obj
Peter Moody writes:
> > > this is interesting. I would be open to doing this and making __lt__,
> > > __gt__, __eq__ and friends do the non-ip comparing by default. would
> > > this be sufficient or does the fact that the network has the .ip
> > > attribute break something pythonic?
> >
Greg Ewing writes:
> Peter Moody wrote:
>
> > I've mentioned at least once (and others have mentioned as well) that
> > it's very common, when describing the ip address/prefix of a NIC to
> > write, "192.168.1.100/24"
>
> Yes, but if you want to *retain* all of that information,
> the obj
On Tue, Sep 29, 2009 at 7:12 PM, R. David Murray wrote:
> On Wed, 30 Sep 2009 at 11:07, Nick Coghlan wrote:
>>
>> At the risk of bikeshedding a bit, I'm still somewhat uncomfortable with
>> the "net.network" and "net.ip" attribute names. RDMs example application
>> elicited the reason for that dis
On Wed, 30 Sep 2009 at 11:07, Nick Coghlan wrote:
At the risk of bikeshedding a bit, I'm still somewhat uncomfortable with
the "net.network" and "net.ip" attribute names. RDMs example application
elicited the reason for that discomfort pretty well: the current naming
seems like an invitation to w
Guido van Rossum wrote:
> On Tue, Sep 29, 2009 at 2:05 PM, Terry Reedy wrote:
>> I do not think the cognitive load of .ip
>> on learning the module is any greater than having a third class, especially
>> if it is somewhat isolated in the doc as suggested below.
>
> Here I disagree. I want users t
Martin v. Löwis wrote:
>> I would say that there certainly are precedents in other areas for
>> keeping the information about the input form around. For example,
>> occasionally it would be handy if parsing a hex integer returned an
>> object that was compatible with other integers but somehow kept
Peter Moody wrote:
I've mentioned at least once (and others have mentioned as well) that
it's very common, when describing the ip address/prefix of a NIC to
write, "192.168.1.100/24"
Yes, but if you want to *retain* all of that information,
the object you have isn't just a "network", it's more
Peter Moody wrote:
> On Sun, Sep 27, 2009 at 1:49 PM, Antoine Pitrou wrote:
>> Peter Moody hda3.com> writes:
>> def parse_net_and_addr(s):
>> return (IPNetwork(s), IPAddress(s.split('/')[0]))
> I've only heard talk of new classes and new methods, not new
> constructor functions.
On Tue, Sep 29, 2009 at 2:05 PM, Terry Reedy wrote:
>> this is interesting. I would be open to doing this and making __lt__,
>> __gt__, __eq__ and friends do the non-ip comparing by default. would
>> this be sufficient or does the fact that the network has the .ip
>> attribute break something pyth
This is my first post in this thread. I do not currently expect to
directly use ipaddr, but I am interested in Python having good modules
and a friendly development environment.
It strikes me that a module that meets the desiderata of broad community
support is going to have the 'baggage' of l
On Tue, 29 Sep 2009 at 15:24, R. David Murray wrote:
There's one place in this code where the inclusion of the 'ip' information
in the IPNetwork class could have been used. In the line that allows ICMP
traffic to the router's outside port, I could have written 'inside.ip'
instead of interfaces['
On Tue, 29 Sep 2009 at 14:19, Glyph Lefkowitz wrote:
In addition to the somebody-must-have-mentioned-this-already feeling that I
got, I hesitated to post this message because it doesn't actually seem that
important to me. While I'm firmly convinced that Network.ip is a design
mistake, it's not l
On Tue, Sep 29, 2009 at 11:30 AM, Stephen J. Turnbull
wrote:
> Let me first say that the module is overall quite nice; the
> implementation seems concise and very efficient, and the API is
> well-balanced. I'm sorry there's been such controversy (and for my
> part in it, as I managed to completel
Let me first say that the module is overall quite nice; the
implementation seems concise and very efficient, and the API is
well-balanced. I'm sorry there's been such controversy (and for my
part in it, as I managed to completely misunderstand what you
absolutely require), when AFAICT the only "li
On Tue, Sep 29, 2009 at 1:00 PM, Guido van Rossum wrote:
> On Tue, Sep 29, 2009 at 9:03 AM, Antoine Pitrou
> wrote:
>
> You say it yourself : it describes "the ip address/prefix of a NIC".
> > It isn't the job of a Network class. A Network shouldn't describe a
> > host, or a particular NIC.
>
>
On Tue, Sep 29, 2009 at 9:03 AM, Antoine Pitrou wrote:
>
>> I've mentioned at least once (and others have mentioned as well) that
>> it's very common, when describing the ip address/prefix of a NIC to
>> write, "192.168.1.100/24"
>
> You say it yourself : it describes "the ip address/prefix of a N
Responding to a few points here. David and I were discussing these
points off-list, I didn't mean to ignore.
re: assumed disconnect between the statement "Addresses and Networks
are distinct" and the implementation.
I don't actually see a disconnect. it seems analogous to stating
lists and int
> I've mentioned at least once (and others have mentioned as well) that
> it's very common, when describing the ip address/prefix of a NIC to
> write, "192.168.1.100/24"
You say it yourself : it describes "the ip address/prefix of a NIC".
It isn't the job of a Network class. A Network shouldn't d
Guido van Rossum writes:
> I don't doubt that Peter has a use case for denormalized IPNetwork
> objects.
If you know what it is, would you please describe it, or say "that's
proprietary"? Peter hasn't done either, despite repeated requests.
> I do note that if Peter's use case is at all comm
Guido van Rossum wrote:
I've never heard of someone who had a use case for
denormalized fractions, but I don't doubt that Peter has a use case
for denormalized IPNetwork objects. (Do you doubt that Peter has such
a use case? If so, we have a much more fundamental disagreement.)
It would be inte
On Mon, Sep 28, 2009 at 7:17 PM, R. David Murray wrote:
> On Mon, 28 Sep 2009 at 13:43, Guido van Rossum wrote:
>>
>> On Mon, Sep 28, 2009 at 1:36 PM, R. David Murray
>> wrote:
>> I would say that there certainly are precedents in other areas for
>> keeping the information about the input form ar
On Mon, 28 Sep 2009 at 13:43, Guido van Rossum wrote:
On Mon, Sep 28, 2009 at 1:36 PM, R. David Murray wrote:
I would say that there certainly are precedents in other areas for
keeping the information about the input form around. For example,
occasionally it would be handy if parsing a hex integ
>I've never said otherwise. In fact, from an email last night, "If what
>the community requires is the library you've described, then ipaddr is
>not that library." The changes *you* require make ipaddr significantly
>less useful to me. I'm not prepared to make those changes in an
>attempt seek acce
Peter Moody wrote:
>> Assuming the Network type loses the notion of a specific host (or host
>> address,
>> or `ip`) attached to it, yes.
>
> this is "less useful (strictly removing functionality)" and is an
> example of what I explicitly said I was not going to do with ipaddr.
A possible compro
On Mon, Sep 28, 2009 at 4:29 PM, "Martin v. Löwis" wrote:
> I guess a close case would be rational numbers: clearly, 3÷2 == 6÷4;
> would a Python library still remember (and repr) the original numerator
> and denominator?
>
No need for a hypothetical, rational numbers were added in Python 2.6:
P
> I would say that there certainly are precedents in other areas for
> keeping the information about the input form around. For example,
> occasionally it would be handy if parsing a hex integer returned an
> object that was compatible with other integers but somehow kept a hint
> that would cause
> You do find "address plus mask" when specifying an IP address for an
> interface. This is a shorthand for specifying the IP address plus the
> network, since the network can be derived from the IP plus the mask.
> But it is a _shorthand_
Just as he says.
Martin
On Mon, 28 Sep 2009 at 22:32, Antoine Pitrou wrote:
Le lundi 28 septembre 2009 ?? 22:11 +0200, "Martin v. L??wis" a ??crit :
That's not the question that was asked, though - the question asked
was "Under what circumstances would I want to specify...". I hope
most people agree that it is desirab
On Mon, Sep 28, 2009 at 1:36 PM, R. David Murray wrote:
> On Mon, 28 Sep 2009 at 22:11, "Martin v. Löwis" wrote:
>>>
>>> Martin v. Löwis v.loewis.de> writes:
>
> Could you explain what benefit there is for allowing the user to create
> network objects that don't represent networks? Is
On Mon, 28 Sep 2009 at 22:11, "Martin v. L??wis" wrote:
Martin v. L??wis v.loewis.de> writes:
Could you explain what benefit there is for allowing the user to create
network objects that don't represent networks? Is there a use-case
where these networks-that-aren't-networks are something other
Le lundi 28 septembre 2009 à 22:11 +0200, "Martin v. Löwis" a écrit :
>
> That's not the question that was asked, though - the question asked
> was "Under what circumstances would I want to specify...". I hope
> most people agree that it is desirable to be able to specify a network
> not just by i
Martin v. Löwis wrote:
>> Martin v. Löwis v.loewis.de> writes:
Could you explain what benefit there is for allowing the user to create
network objects that don't represent networks? Is there a use-case
where these networks-that-aren't-networks are something other than a
typo
Martin v. Löwis v.loewis.de> writes:
>
> Still, people proposing that 192.168.1.1/24 should be rejected (I still
> don't know whether anybody is actually proposing that) *have* to provide
> a proposal how this should be input instead.
It was proposed to have a dedicated function or class method
> Unfortunately, that would mean that we should provide two comparison
> operations, and have neither available as == (unless one is more clearly
> right than the other, which I'm skeptical about).
That's probably why some people have argued to have two separate classes for the
case of "networks"
> Martin v. Löwis v.loewis.de> writes:
>>> Could you explain what benefit there is for allowing the user to create
>>> network objects that don't represent networks? Is there a use-case
>>> where these networks-that-aren't-networks are something other than a
>>> typo? Under what circumstances w
>> It's fairly obvious to me why the library should support 192.168.1.1/24
>> as an input, and return a network.
>>
>> End-users are likely going to enter such things (e.g. 82.94.164.162/29),
>> as they will know one IP address in the network (namely, of one machine
>> that they are looking at), an
> The fundamental divide here is between two behaviors.
>
> ipaddr:
>
> >>> x = IPv4Network('192.168.1.1/24')
> >>> y = IPv4Network('192.168.1.0/24')
> >>> x == y
> False
> >>> x.ip
> IPv4Address('192.168.1.1')
>
> desired:
>
> >>> x = IPv4Network('192.168.1.1/24')
>
On Mon, Sep 28, 2009 at 11:17 AM, Antoine Pitrou wrote:
> Guido van Rossum python.org> writes:
>>
>> At the same time I don't think a complete reset of the proposed API is
>> necessary. I am rather more thinking of judicious API tweaks in order
>> to cover some new use cases, without requiring a
2009/9/28 Peter Moody
> [cc += david moss]
>
> On Mon, Sep 28, 2009 at 9:39 AM, Guido van Rossum
> wrote:
> > On Sun, Sep 27, 2009 at 5:32 PM, Antoine Pitrou
> wrote:
> >> Peter Moody hda3.com> writes:
> >>>
> >>> I've never said otherwise. In fact, from an email last night, "If what
> >>> the
On Tue, 29 Sep 2009 02:39:06 am Guido van Rossum wrote:
> I think Peter is pretty frustrated by the many attacks on "his"
> library. There are probably a number of different things going on
> simultaneous: Peter has been driven into the defense by attacks both
> reasonable and unreasonable, there
Guido van Rossum python.org> writes:
>
> At the same time I don't think a complete reset of the proposed API is
> necessary. I am rather more thinking of judicious API tweaks in order
> to cover some new use cases, without requiring a complete rewrite or
> destroying the usability of the proposa
[cc += david moss]
On Mon, Sep 28, 2009 at 9:39 AM, Guido van Rossum wrote:
> On Sun, Sep 27, 2009 at 5:32 PM, Antoine Pitrou wrote:
>> Peter Moody hda3.com> writes:
>>>
>>> I've never said otherwise. In fact, from an email last night, "If what
>>> the community requires is the library you've d
On Sun, Sep 27, 2009 at 5:32 PM, Antoine Pitrou wrote:
> Peter Moody hda3.com> writes:
>>
>> I've never said otherwise. In fact, from an email last night, "If what
>> the community requires is the library you've described, then ipaddr is
>> not that library." The changes *you* require make ipaddr
Ok updated patch so it meets the following conditions
>>> IPv4Network(192.168.1.1/24)
IPv4Network(192.168.1.0/24)
>>> x = IPv4Network('192.168.1.1/24')
>>> y = IPv4Network('192.168.1.0/24')
>>> x == y
True
>>> hash(x) == hash(y)
True
The ip you instantiated the Network with is still accessible t
On Mon, Sep 28, 2009 at 8:56 AM, Guido van Rossum wrote:
> Hold it right there! That's wrong. You can't have two objects that
> compare equal but whose hashes differ. It will break dict lookup. The
> other way around is fine: two objects may differ and still have the
> same hash.
mm I never knew
2009/9/28 Peter Moody :
>> That is, you've rejected the idea of having:
>>
> IPv4Network(192.168.1.1/24)
>> IPv4Network(192.168.1.0/24)
>
> yes, I and everyone have rejected that idea. this should either raise
> an error, or do what it does now, that is, return
> IPv4Network('192.168.1.1/24')
On Mon, 28 Sep 2009 01:57:04 pm Martin v. Löwis wrote:
> >> Finally, to Stephen's point about seeing the other side of the
> >> argument, I wrote this offlist a week ago:
> >>
> >> I *understand* what you're saying, I *understand* that
> >> 192.168.1.1/24 isn't a network,
> >
> > But you still wa
On Mon, Sep 28, 2009 at 9:35 AM, R. David Murray wrote:
> A little googling produced this hit:
>
>
> http://tools.ietf.org/wg/mip4/draft-ietf-mip4-nemo-v4-base/draft-ietf-mip4-nemo-v4-base-11-from-10.diff.txt
>
> which while not a standard itself clearly believes that non-contiguous
> netmasks are
Dj Gilcrease gmail.com> writes:
>
> >>> net1 = IPNetwork("10.1.2.3/24")
> >>> net2 = IPNetwork("10.1.2.0/24")
> >>> print hash(net1) == hash(net2)
> False
> >>> print net1 == net2
> True
Ouch :-)
It is very bad practice for equal objects to hash differently. Differing hashes
are supposed to impl
On Mon, Sep 28, 2009 at 3:42 PM, Dj Gilcrease wrote:
> On Mon, Sep 28, 2009 at 8:04 AM, Daniel Stutzbach
> wrote:
>> On Mon, Sep 28, 2009 at 7:24 AM, Nick Coghlan wrote:
>>>
>>> I should note that I've softened my position slightly from what I posted
>>> yesterday. I could live with the followin
On Mon, Sep 28, 2009 at 7:42 AM, Dj Gilcrease wrote:
> On Mon, Sep 28, 2009 at 8:04 AM, Daniel Stutzbach
> wrote:
>> On Mon, Sep 28, 2009 at 7:24 AM, Nick Coghlan wrote:
>>>
>>> I should note that I've softened my position slightly from what I posted
>>> yesterday. I could live with the followin
On Mon, Sep 28, 2009 at 8:04 AM, Daniel Stutzbach
wrote:
> On Mon, Sep 28, 2009 at 7:24 AM, Nick Coghlan wrote:
>>
>> I should note that I've softened my position slightly from what I posted
>> yesterday. I could live with the following compromise:
>>
>> >>> x = IPv4Network('192.168.1.1/24')
>
On Sun, 27 Sep 2009 at 10:06, David Moss wrote:
On 27 Sep 2009, at 07:56, "Martin v. L??wis" wrote:
I wouldn't ask for that: it should certainly be possible to supply
masks. However, I would want to reject masks that don't correspond to
a prefix, and have only the prefix length in the intern
Mark Dickinson wrote:
On Mon, Sep 28, 2009 at 3:04 PM, Daniel Stutzbach
wrote:
On Mon, Sep 28, 2009 at 7:24 AM, Nick Coghlan wrote:
I should note that I've softened my position slightly from what I posted
yesterday. I could live with the following compromise:
>>> x = IPv4Network('192.168.
On Mon, Sep 28, 2009 at 3:04 PM, Daniel Stutzbach
wrote:
> On Mon, Sep 28, 2009 at 7:24 AM, Nick Coghlan wrote:
>>
>> I should note that I've softened my position slightly from what I posted
>> yesterday. I could live with the following compromise:
>>
>> >>> x = IPv4Network('192.168.1.1/24')
>
On Mon, Sep 28, 2009 at 7:24 AM, Nick Coghlan wrote:
> I should note that I've softened my position slightly from what I posted
> yesterday. I could live with the following compromise:
>
>>>> x = IPv4Network('192.168.1.1/24')
>>>> y = IPv4Network('192.168.1.0/24')
> >>> x == y # Equal
Greg Ewing wrote:
> Nick Coghlan wrote:
>
>> The use case for "given a netmask and an arbitrary host on that network,
>> give me the appropriate IPNetwork object" has been well established by
>> this discussion (although still isn't particularly well described even
>> in the latest PEP update). Th
On Mon, Sep 28, 2009 at 5:34 AM, R. David Murray wrote:
> The fundamental divide here is between two behaviors.
>
> ipaddr:
>
> >>> x = IPv4Network('192.168.1.1/24')
> >>> y = IPv4Network('192.168.1.0/24')
> >>> x == y
> False
> >>> x.ip
> IPv4Address('192.168.1.1')
>
> desired:
On 03:57 am, mar...@v.loewis.de wrote:
Finally, to Stephen's point about seeing the other side of the
argument, I wrote this offlist a week ago:
I *understand* what you're saying, I *understand* that
192.168.1.1/24 isn't a network,
But you still want to treat it as one.
Could you explain wh
R. David Murray wrote:
> On Mon, 28 Sep 2009 at 07:34, R. David Murray wrote:
>> The fundamental divide here is between two behaviors.
>>
>> ipaddr:
>>
>>> > > x = IPv4Network('192.168.1.1/24')
>>> > > y = IPv4Network('192.168.1.0/24')
>>> > > x == y
>> False
>>> > > x.ip
>>
Peter Moody wrote:
>> That is, you've rejected the idea of having:
>>
> IPv4Network(192.168.1.1/24)
>> IPv4Network(192.168.1.0/24)
>
> yes, I and everyone have rejected that idea. this should either raise
> an error, or do what it does now, that is, return
> IPv4Network('192.168.1.1/24')
Um,
On Mon, 28 Sep 2009 at 07:34, R. David Murray wrote:
The fundamental divide here is between two behaviors.
ipaddr:
> > > x = IPv4Network('192.168.1.1/24')
> > > y = IPv4Network('192.168.1.0/24')
> > > x == y
False
> > > x.ip
IPv4Address('192.168.1.1')
desired:
> > >
R. David Murray wrote:
The fundamental divide here is between two behaviors.
ipaddr:
>>> x = IPv4Network('192.168.1.1/24')
>>> y = IPv4Network('192.168.1.0/24')
>>> x == y
False
>>> x.ip
IPv4Address('192.168.1.1')
desired:
>>> x = IPv4Network('192.168.1.1/24')
On Mon, 28 Sep 2009 at 05:57, "Martin v. L?wis" wrote:
Finally, to Stephen's point about seeing the other side of the
argument, I wrote this offlist a week ago:
I *understand* what you're saying, I *understand* that
192.168.1.1/24 isn't a network,
But you still want to treat it as one.
Coul
Martin v. Löwis v.loewis.de> writes:
>
> > Could you explain what benefit there is for allowing the user to create
> > network objects that don't represent networks? Is there a use-case
> > where these networks-that-aren't-networks are something other than a
> > typo? Under what circumstances
>> Finally, to Stephen's point about seeing the other side of the
>> argument, I wrote this offlist a week ago:
>>
>> I *understand* what you're saying, I *understand* that
>> 192.168.1.1/24 isn't a network,
>
> But you still want to treat it as one.
>
> Could you explain what benefit there is
Looking though the tests you have setup for ipaddr it is clear that
you want the following to be True
ip1 = ipaddr.IPv4Network('1.1.1.0/24')
ip2 = ipaddr.IPv4Network('1.1.1.1/24')
ip1 == ip2
based on this test
self.assertEquals(ip1.compare_networks(ip2), 0)
but your ><= operators all compare ag
On Sun, Sep 27, 2009 at 9:26 PM, Greg Ewing wrote:
> Would you be kind enough to explain exactly what use
> case you have for retaining this information?
>
> Apologies if you've done so before -- I've been
> trying to follow this discussion, but that point
> doesn't seem to have come through clear
Peter Moody wrote:
On Sun, Sep 27, 2009 at 1:49 PM, Antoine Pitrou wrote:
>
Assuming the Network type loses the notion of a specific host (or host address,
or `ip`) attached to it, yes.
this is "less useful (strictly removing functionality)" and is an
example of what I explicitly said I was
On Sun, 27 Sep 2009 at 13:59, Peter Moody wrote:
On Sun, Sep 27, 2009 at 1:49 PM, Antoine Pitrou wrote:
Peter Moody hda3.com> writes:
def parse_net_and_addr(s):
?return (IPNetwork(s), IPAddress(s.split('/')[0]))
I've only heard talk of new classes and new methods, not new
constructor func
Nick Coghlan wrote:
The use case for "given a netmask and an arbitrary host on that network,
give me the appropriate IPNetwork object" has been well established by
this discussion (although still isn't particularly well described even
in the latest PEP update). This is what "strict=False" covers
Peter Moody hda3.com> writes:
>
> I've never said otherwise. In fact, from an email last night, "If what
> the community requires is the library you've described, then ipaddr is
> not that library." The changes *you* require make ipaddr significantly
> less useful to me. I'm not prepared to make
On Sun, Sep 27, 2009 at 5:13 PM, Steven D'Aprano wrote:
> On Mon, 28 Sep 2009 03:53:27 am Peter Moody wrote:
>
>> >> I *understand* what you're saying, I *understand* that
>> >> 192.168.1.1/24 isn't a network,
>> >
>> > But you still want to treat it as one.
>> >
>> > Could you explain what bene
On Mon, 28 Sep 2009 03:53:27 am Peter Moody wrote:
> >> I *understand* what you're saying, I *understand* that
> >> 192.168.1.1/24 isn't a network,
> >
> > But you still want to treat it as one.
> >
> > Could you explain what benefit there is for allowing the user to
> > create network objects t
On Sun, Sep 27, 2009 at 3:32 PM, Antoine Pitrou wrote:
> Peter Moody hda3.com> writes:
>>
>> this is "less useful (strictly removing functionality)" and is an
>> example of what I explicitly said I was not going to do with ipaddr.
>
> (please note the conditional wording here) Assuming that a sig
Peter Moody hda3.com> writes:
>
> this is "less useful (strictly removing functionality)" and is an
> example of what I explicitly said I was not going to do with ipaddr.
(please note the conditional wording here) Assuming that a significant number of
people agree that there is a design problem,
Peter Moody wrote:
> Steven D'Aprano wrote:
>
> Could you explain what benefit there is for allowing the user to create
> network objects that don't represent networks? Is there a use-case
> where these networks-that-aren't-networks are something other than a
> typo? Under what circumstanc
On Sun, Sep 27, 2009 at 1:49 PM, Antoine Pitrou wrote:
> Peter Moody hda3.com> writes:
>>
>> >> > def parse_net_and_addr(s):
>> >> > return (IPNetwork(s), IPAddress(s.split('/')[0]))
>> >>
>> >> I've only heard talk of new classes and new methods, not new
>> >> constructor functions.
>> >
>> > W
Peter Moody hda3.com> writes:
>
> >> > def parse_net_and_addr(s):
> >> > return (IPNetwork(s), IPAddress(s.split('/')[0]))
> >>
> >> I've only heard talk of new classes and new methods, not new
> >> constructor functions.
> >
> > Well, "method" in that context meant "class method" since the resu
On Sun, Sep 27, 2009 at 1:15 PM, Antoine Pitrou wrote:
> Peter Moody hda3.com> writes:
>>
>> On Sun, Sep 27, 2009 at 12:40 PM, James Y Knight fuhm.net> wrote:
>> >
>> > On Sep 27, 2009, at 3:18 PM, Peter Moody wrote:
>> >
>> >> administrators) would use it, but it's doable. what you're claiming
1 - 100 of 249 matches
Mail list logo
