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
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
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 as having
Mark Dickinson wrote:
On Wed, Sep 30, 2009 at 10:52 AM, Paul Moore p.f.mo...@gmail.com wrote:
2009/9/30 Mark Dickinson dicki...@gmail.com:
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
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
On Wed, Sep 30, 2009 at 1:44 AM, Nick Coghlan ncogh...@gmail.com 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
2009/9/30 Mark Dickinson dicki...@gmail.com:
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 =
On Wed, Sep 30, 2009 at 10:52 AM, Paul Moore p.f.mo...@gmail.com wrote:
2009/9/30 Mark Dickinson dicki...@gmail.com:
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
On Wed, Sep 30, 2009 at 12:06 PM, Nick Coghlan ncogh...@gmail.com 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?
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('172.16.200.1/24')
On Wed, 30 Sep 2009 at 10:52, Paul Moore wrote:
2009/9/30 Mark Dickinson dicki...@gmail.com:
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
Mark Dickinson wrote:
On Wed, Sep 30, 2009 at 1:44 AM, Nick Coghlan ncogh...@gmail.com 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
On Wed, Sep 30, 2009 at 4:33 AM, Mark Dickinson dicki...@gmail.com wrote:
On Wed, Sep 30, 2009 at 12:06 PM, Nick Coghlan ncogh...@gmail.com 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
On Wed, 30 Sep 2009 at 13:11, Guido van Rossum wrote:
On Wed, Sep 30, 2009 at 4:33 AM, Mark Dickinson dicki...@gmail.com wrote:
On Wed, Sep 30, 2009 at 12:06 PM, Nick Coghlan ncogh...@gmail.com wrote:
Mark Dickinson wrote:
Okay, so maybe this is an abuse of IPv4Network. ?But I'd
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
[...@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
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
[...@google.com]
On Wed, Sep 30, 2009 at 2:51 PM, Raymond Hettinger pyt...@rcn.com 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]
.On Wed, Sep 30, 2009 at 3:33 PM, R. David Murray rdmur...@bitdance.comwrote:
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
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
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
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 common,
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 ints
On Tue, Sep 29, 2009 at 9:03 AM, Antoine Pitrou solip...@pitrou.net 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
On Tue, Sep 29, 2009 at 1:00 PM, Guido van Rossum gu...@python.org wrote:
On Tue, Sep 29, 2009 at 9:03 AM, Antoine Pitrou solip...@pitrou.net
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,
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
On Tue, Sep 29, 2009 at 11:30 AM, Stephen J. Turnbull
step...@xemacs.org 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
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
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
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
On Tue, Sep 29, 2009 at 2:05 PM, Terry Reedy tjre...@udel.edu 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
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
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 a hint
Guido van Rossum wrote:
On Tue, Sep 29, 2009 at 2:05 PM, Terry Reedy tjre...@udel.edu 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
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
On Tue, Sep 29, 2009 at 7:12 PM, R. David Murray rdmur...@bitdance.com 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
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 object you have
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?
What do you
Martin v. Löwis martin at 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
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.
Could
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')
y =
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:
x =
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, no, several
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
IPv4Address('192.168.1.1')
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
On Mon, Sep 28, 2009 at 5:34 AM, R. David Murray rdmur...@bitdance.com 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:
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). This is what
On Mon, Sep 28, 2009 at 7:24 AM, Nick Coghlan ncogh...@gmail.com 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 #
On Mon, Sep 28, 2009 at 3:04 PM, Daniel Stutzbach
dan...@stutzbachenterprises.com wrote:
On Mon, Sep 28, 2009 at 7:24 AM, Nick Coghlan ncogh...@gmail.com wrote:
I should note that I've softened my position slightly from what I posted
yesterday. I could live with the following compromise:
Mark Dickinson wrote:
On Mon, Sep 28, 2009 at 3:04 PM, Daniel Stutzbach
dan...@stutzbachenterprises.com wrote:
On Mon, Sep 28, 2009 at 7:24 AM, Nick Coghlan ncogh...@gmail.com wrote:
I should note that I've softened my position slightly from what I posted
yesterday. I could live with the
On Sun, 27 Sep 2009 at 10:06, David Moss wrote:
On 27 Sep 2009, at 07:56, Martin v. L??wis mar...@v.loewis.de 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
On Mon, Sep 28, 2009 at 8:04 AM, Daniel Stutzbach
dan...@stutzbachenterprises.com wrote:
On Mon, Sep 28, 2009 at 7:24 AM, Nick Coghlan ncogh...@gmail.com wrote:
I should note that I've softened my position slightly from what I posted
yesterday. I could live with the following compromise:
On Mon, Sep 28, 2009 at 7:42 AM, Dj Gilcrease digitalx...@gmail.com wrote:
On Mon, Sep 28, 2009 at 8:04 AM, Daniel Stutzbach
dan...@stutzbachenterprises.com wrote:
On Mon, Sep 28, 2009 at 7:24 AM, Nick Coghlan ncogh...@gmail.com wrote:
I should note that I've softened my position slightly
On Mon, Sep 28, 2009 at 3:42 PM, Dj Gilcrease digitalx...@gmail.com wrote:
On Mon, Sep 28, 2009 at 8:04 AM, Daniel Stutzbach
dan...@stutzbachenterprises.com wrote:
On Mon, Sep 28, 2009 at 7:24 AM, Nick Coghlan ncogh...@gmail.com wrote:
I should note that I've softened my position slightly
Dj Gilcrease digitalxero at 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 imply
On Mon, Sep 28, 2009 at 9:35 AM, R. David Murray rdmur...@bitdance.comwrote:
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
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 want to treat it as
2009/9/28 Peter Moody pe...@hda3.com:
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, Sep 28, 2009 at 8:56 AM, Guido van Rossum gu...@python.org 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
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 though, so
On Sun, Sep 27, 2009 at 5:32 PM, Antoine Pitrou solip...@pitrou.net wrote:
Peter Moody peter at 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*
[cc += david moss]
On Mon, Sep 28, 2009 at 9:39 AM, Guido van Rossum gu...@python.org wrote:
On Sun, Sep 27, 2009 at 5:32 PM, Antoine Pitrou solip...@pitrou.net wrote:
Peter Moody peter at hda3.com writes:
I've never said otherwise. In fact, from an email last night, If what
the community
Guido van Rossum guido at 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
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 have
2009/9/28 Peter Moody pe...@hda3.com
[cc += david moss]
On Mon, Sep 28, 2009 at 9:39 AM, Guido van Rossum gu...@python.org
wrote:
On Sun, Sep 27, 2009 at 5:32 PM, Antoine Pitrou solip...@pitrou.net
wrote:
Peter Moody peter at hda3.com writes:
I've never said otherwise. In fact, from
On Mon, Sep 28, 2009 at 11:17 AM, Antoine Pitrou solip...@pitrou.net wrote:
Guido van Rossum guido at 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,
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')
y =
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), and they will
Martin v. Löwis martin at 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 would
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 martin at 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
Martin v. Löwis wrote:
Martin v. Löwis martin at 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
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 its
On Mon, 28 Sep 2009 at 22:11, Martin v. L??wis wrote:
Martin v. L??wis martin at 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
On Mon, Sep 28, 2009 at 1:36 PM, R. David Murray rdmur...@bitdance.com wrote:
On Mon, 28 Sep 2009 at 22:11, Martin v. Löwis wrote:
Martin v. Löwis martin at v.loewis.de writes:
Could you explain what benefit there is for allowing the user to create
network objects that don't represent
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 desirable
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
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
On Mon, Sep 28, 2009 at 4:29 PM, Martin v. Löwis mar...@v.loewis.dewrote:
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
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 compromise then:
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 acceptance
On Mon, 28 Sep 2009 at 13:43, Guido van Rossum wrote:
On Mon, Sep 28, 2009 at 1:36 PM, R. David Murray rdmur...@bitdance.com 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
Peter Moody wrote:
what you want is strict=True, just checked in. I've been meaning to
send an update to the PEP explaining why this choice was made. I'm
hoping this will ameliorate your confusion.
If the ip property remains and equality is still broken as Steven
describes, then no, it won't
As a side note, I would be in favor of dropping the concept of a mask
from the library, and only support a prefix length.
-1
IPv6 doesn't support masks at all, and even for IPv4, I think there
are conventions (if not RFCs) against using them in a way that does
not correspond to a prefix
On 14 Sep 2009, at 17:44, Peter Moody wrote:
Folks, Guido,
I believe PEP 3144 is ready for your review. When you get a chance,
can you take a look/make a pronouncement?
x=ipaddr.IPv4Network( '192.168.1.1/240.255.0.0' )
x
IPv4Network('192.168.1.1/16')
You can decide on which bug this
On Sat, Sep 26, 2009 at 6:34 AM, Barry Scott ba...@barrys-emacs.org wrote:
On 14 Sep 2009, at 17:44, Peter Moody wrote:
Folks, Guido,
I believe PEP 3144 is ready for your review. When you get a chance,
can you take a look/make a pronouncement?
x=ipaddr.IPv4Network(
On Sat, Sep 26, 2009 at 11:08 PM, Nick Coghlan ncogh...@gmail.com wrote:
Peter Moody wrote:
what you want is strict=True, just checked in. I've been meaning to
send an update to the PEP explaining why this choice was made. I'm
hoping this will ameliorate your confusion.
If the ip property
Dave M.
On 27 Sep 2009, at 07:56, Martin v. Löwis mar...@v.loewis.de wrote:
As a side note, I would be in favor of dropping the concept of a
mask
from the library, and only support a prefix length.
-1
IPv6 doesn't support masks at all, and even for IPv4, I think there
are conventions
Peter Moody peter at hda3.com writes:
To be explicit though, unless I'm drastically misreading what you're
asking for, I consider the design you're proposing to be broken from a
usability perspective (striving for academic/pedantic correctness over
accepted practice).
It is certainly not
Antoine Pitrou writes:
There was a proposal to have a separate parse_address_and_mask
method which would return a (Address, Network) tuple, I still don't
know why you don't seem to consider it seriously, rather than
trying to make the Network class a kind of all-in-one type
conflating
I personally do not have a problem with that, except that you
apparently can't grasp his way of thinking, and he apparently can't
grasp yours.
If I was the only one disagreeing it wouldn't be that annoying (except
for me :-)).
I'm -1 on PEP 3144 primarily because of this
communications
On Sun, Sep 27, 2009 at 4:23 AM, Antoine Pitrou solip...@pitrou.net wrote:
Peter Moody peter at hda3.com writes:
To be explicit though, unless I'm drastically misreading what you're
asking for, I consider the design you're proposing to be broken from a
usability perspective (striving for
Peter Moody peter at hda3.com writes:
The reason (aside from the name) that I'm not going to include this in
ipaddr is that it would require the user to deal with two objects when
one would suffice.
You make it sound like it's a burden, but dealing with two objects is not
something
On Mon, 28 Sep 2009 02:47:27 am Peter Moody wrote:
There was a proposal to have a separate parse_address_and_mask
method which would return a (Address, Network) tuple, I still don't
know why you don't seem to consider it seriously, rather than
trying to make the Network class a kind of
On Sun, Sep 27, 2009 at 10:30 AM, Steven D'Aprano st...@pearwood.info wrote:
On Mon, 28 Sep 2009 02:47:27 am Peter Moody wrote:
There was a proposal to have a separate parse_address_and_mask
method which would return a (Address, Network) tuple, I still don't
know why you don't seem to
On Sun, Sep 27, 2009 at 10:22 AM, Antoine Pitrou solip...@pitrou.net wrote:
Peter Moody peter at hda3.com writes:
The reason (aside from the name) that I'm not going to include this in
ipaddr is that it would require the user to deal with two objects when
one would suffice.
You make it
Peter Moody peter at hda3.com writes:
(or would you argue that Address objects should have an optional
distinguishing
port number, for convenience reasons?)
I'm not sure what you're talking about, I've never argued to add layer
4 information to ipaddr.
It was an analogy, just like your
On Sun, Sep 27, 2009 at 11:17 AM, Antoine Pitrou solip...@pitrou.net wrote:
Peter Moody peter at hda3.com writes:
(or would you argue that Address objects should have an optional
distinguishing
port number, for convenience reasons?)
I'm not sure what you're talking about, I've never
On Sep 27, 2009, at 3:18 PM, Peter Moody wrote:
administrators) would use it, but it's doable. what you're claiming is
that my use case is invalid.
that's what I claim is broken.
He's claiming your solution to address your use case is confusing, not
that the use case is invalid.
I'm
On Sun, Sep 27, 2009 at 12:40 PM, James Y Knight f...@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 is
that my use case is invalid.
that's what I claim is broken.
He's claiming your solution to address
1 - 100 of 230 matches
Mail list logo
