Peter Moody peter at hda3.com writes:
On Sun, Sep 27, 2009 at 12:40 PM, James Y Knight foom at 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
On Sun, Sep 27, 2009 at 1:15 PM, Antoine Pitrou solip...@pitrou.net wrote:
Peter Moody peter at hda3.com writes:
On Sun, Sep 27, 2009 at 12:40 PM, James Y Knight foom at fuhm.net wrote:
On Sep 27, 2009, at 3:18 PM, Peter Moody wrote:
administrators) would use it, but it's doable. what
Peter Moody peter at 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 results aren't
On Sun, Sep 27, 2009 at 1:49 PM, Antoine Pitrou solip...@pitrou.net wrote:
Peter Moody peter at 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,
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 circumstances
Peter Moody peter at 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
On Sun, Sep 27, 2009 at 5:13 PM, Steven D'Aprano st...@pearwood.info 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
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* require make ipaddr significantly
less useful to me. I'm not prepared to make
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,
On Sun, 27 Sep 2009 at 13:59, Peter Moody wrote:
On Sun, Sep 27, 2009 at 1:49 PM, Antoine Pitrou solip...@pitrou.net wrote:
Peter Moody peter at 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
Peter Moody wrote:
On Sun, Sep 27, 2009 at 1:49 PM, Antoine Pitrou solip...@pitrou.net 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
On Sun, Sep 27, 2009 at 9:26 PM, Greg Ewing greg.ew...@canterbury.ac.nz 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
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
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 for allowing
- Masks are also 32- (128-) bit integers, which happen to have the
property that their leftmost N bits are all zero and the rest are all
one.
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.
IPv6 doesn't support
I don't think the RFCs forbid the zero address being used
RFC 1122 does: IP addresses are not permitted to have the value 0 or -1
for any of the Host-number, Network-number, or Subnet-
number fields (except in the special cases listed above).
RFC 3021 modifies this requirement, allowing the
2009/9/26 Martin v. Löwis mar...@v.loewis.de
I don't think the RFCs forbid the zero address being used
RFC 1122 does: IP addresses are not permitted to have the value 0 or -1
for any of the Host-number, Network-number, or Subnet-
number fields (except in the special cases listed above).
On Sat, Sep 26, 2009 at 2:07 PM, DrKJam drk...@gmail.com wrote:
The current version of the PEP and reference implementation do not mention
or deal with IPv4 classful addressing (A, B, C, D and E). It would be good
to know if any of this (admittedly older yet no less important)
functionality
2009/9/26 Daniel Stutzbach dan...@stutzbachenterprises.com
On Sat, Sep 26, 2009 at 2:07 PM, DrKJam drk...@gmail.com wrote:
The current version of the PEP and reference implementation do not mention
or deal with IPv4 classful addressing (A, B, C, D and E). It would be good
to know if any of
On Sat, Sep 26, 2009 at 4:57 PM, DrKJam drk...@gmail.com wrote:
2009/9/26 Daniel Stutzbach dan...@stutzbachenterprises.com
On Sat, Sep 26, 2009 at 2:07 PM, DrKJam drk...@gmail.com wrote:
The current version of the PEP and reference implementation do not
mention or deal with IPv4 classful
On Sun, 27 Sep 2009 03:44:45 am Martin v. Löwis wrote:
- Masks are also 32- (128-) bit integers, which happen to have the
property that their leftmost N bits are all zero and the rest
are all one.
As a side note, I would be in favor of dropping the concept of a mask
from the library,
On Sat, 26 Sep 2009 11:23:14 pm Barry Scott wrote:
I've seen user interfaces accept 192.168.1.1/24 as a short cut
to set the ipaddr and netmask on an interface.
For that use being able to parse that string into an IP Address and
a Net Mask is what they want.
I think you're at least the
I again invite interested parties to continue this discussion on
ipaddr-py-...@googlegroups.com. we're pushing 250 messages on PEP
3144 at this point; well beyond what most folks would call a long
open-ended discussion.
anyway:
The current behaviour is confusing to me. For example:
netw1 =
Peter Moody wrote:
I again invite interested parties to continue this discussion on
ipaddr-py-...@googlegroups.com. we're pushing 250 messages on PEP
3144 at this point; well beyond what most folks would call a long
open-ended discussion.
anyway:
The current behaviour is confusing to
On Sat, Sep 26, 2009 at 10:38 PM, Nick Coghlan ncogh...@gmail.com wrote:
Peter Moody wrote:
I again invite interested parties to continue this discussion on
ipaddr-py-...@googlegroups.com. we're pushing 250 messages on PEP
3144 at this point; well beyond what most folks would call a long
On 18Sep2009 07:48, Nick Coghlan ncogh...@gmail.com wrote:
| Eric Smith wrote:
| Peter Moody wrote:
| indexing is plenty efficient, but the problem is that these names for
| these attributes are common to the point of causing confusion if
| they're omitted.
|
| After thinking about it some
Cameron Simpson wrote:
On 18Sep2009 07:48, Nick Coghlan ncogh...@gmail.com wrote:
| Eric Smith wrote:
| Peter Moody wrote:
| indexing is plenty efficient, but the problem is that these names for
| these attributes are common to the point of causing confusion if
| they're omitted.
|
|
2009/9/18 R. David Murray rdmur...@bitdance.com:
On Fri, 18 Sep 2009 at 11:04, Andrew McNamara wrote:
[attribution lost; apparently Steven D'Aprano given the CC]
To a non-specialist, the network address is ambiguous. There are many
addresses in a network, and none of them are the entire
Eric Smith wrote:
My only concern with this is a possible performance issue with v6
networks. Would this be implemented such that [-1] doesn't need to
iterate through the (possibly large) address space of a v6 network?
I'm not familiar with v6, but if netmasks work the same
way as they do in
Andrew McNamara writes:
As the module stands, we have a pair of address-without-mask classes
called *Address, and a pair of address-with-mask classes called
*Network. So, sometimes when you want to record an *address* you use
a class called Network, and that class comes with a behaviours
As the module stands, we have a pair of address-without-mask classes
called *Address, and a pair of address-with-mask classes called
*Network. So, sometimes when you want to record an *address* you use
a class called Network, and that class comes with a behaviours that
make no sense in
2009/9/17 Peter Moody pe...@hda3.com:
On Wed, Sep 16, 2009 at 8:21 PM, Andrew McNamara
andr...@object-craft.com.au wrote:
I think we're in a painful middle ground now - we should either go back
to the idea of a single class (per protocol), or make the distinctions
clear (networks are
Peter Moody peter at hda3.com writes:
the address with all of the hosts bits masked to zero is most commonly
referred to as the network address. same as the address with all of
the host bits set to one is called the broadcast address. calling it
something like base_address or min_address
Antoine Pitrou wrote:
Peter Moody peter at hda3.com writes:
the address with all of the hosts bits masked to zero is most commonly
referred to as the network address. same as the address with all of
the host bits set to one is called the broadcast address. calling it
something like
On Wed, 16 Sep 2009 at 20:26, Peter Moody wrote:
On Wed, Sep 16, 2009 at 7:48 PM, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
I'm not sure what usefulness the zero address on its own
has, but if it's considered useful enough to have an
attribute for it, calling it something like
Please can we have the following RFCs added to the references section that
cover many of the aspects covered by this PEP?
RFC 791 - Internet Protocol
RFC 1918 - Address Allocation for Private Internets
RFC 3330 - Special-Use IPv4 Addresses
RFC 4291 - IPv6 Addressing Architecture
RFC 4632 -
Le Mon, 14 Sep 2009 09:44:12 -0700, Peter Moody a écrit :
Folks, Guido,
I believe PEP 3144 is ready for your review. When you get a chance, can
you take a look/make a pronouncement?
I might add that, according to the whole discussion, it seems not all of
the API is exposed in the PEP.
On Thu, Sep 17, 2009 at 9:26 AM, DrKJam drk...@gmail.com wrote:
Please can we have the following RFCs added to the references section that
cover many of the aspects covered by this PEP?
RFC 791 - Internet Protocol
RFC 1918 - Address Allocation for Private Internets
RFC 3330 - Special-Use
On Thu, Sep 17, 2009 at 7:26 AM, DrKJam drk...@gmail.com wrote:
Please can we have the following RFCs added to the references section that
cover many of the aspects covered by this PEP?
RFC 791 - Internet Protocol
RFC 1918 - Address Allocation for Private Internets
RFC 3330 - Special-Use
On Thu, Sep 17, 2009 at 7:32 AM, Antoine Pitrou solip...@pitrou.net wrote:
Le Mon, 14 Sep 2009 09:44:12 -0700, Peter Moody a écrit :
Folks, Guido,
I believe PEP 3144 is ready for your review. When you get a chance, can
you take a look/make a pronouncement?
I might add that, according to
On Thu, Sep 17, 2009 at 6:25 AM, Eric Smith e...@trueblade.com wrote:
Nick Coghlan wrote:
To be honest, given the indexing behaviour, I'm -1 on the idea of giving
the network address or broadcast address attribute names *at all*.
Consider:
network_address = my_net[0]
broadcast_address =
Peter Moody wrote:
indexing is plenty efficient, but the problem is that these names for
these attributes are common to the point of causing confusion if
they're omitted.
After thinking about it some more, I'm okay with names for [-1] and [0].
I like .broadcast, and I can live with .network
On Thu, Sep 17, 2009 at 10:50 AM, David Moss drk...@gmail.com wrote:
On 17 Sep 2009, at 15:40, Peter Moody pe...@hda3.com wrote:
On Thu, Sep 17, 2009 at 7:26 AM, DrKJam drk...@gmail.com wrote:
Please can we have the following RFCs added to the references section
that
cover many of the
On Thu, 17 Sep 2009 05:15:16 pm Andrew McNamara wrote:
Conceptually, you sometimes need a bare address, and other times,
you need an address with an associated network (host interface
configs, router configs, etc). By AddressWithMask, I really mean
On Thu, Sep 17, 2009 at 10:59:22AM -0700, Peter Moody wrote:
currently have, or do you feel that simply adding 5 rfc's to the
references section adds to the overall readability of the PEP?
I would list them simply because it's not obvious which RFC specifies
the format of IP addresses or how
188 (check that, 190) people have downloaded the 2.0 release in the
last week (numbers publicly available from the code.google.com). I
can't tell you how many (if any) have downloaded it via svn.
Downloading and using are not the same thing.
Correct, but there is a strong positive
On Thu, 17 Sep 2009 10:41:37 am Andrew McNamara wrote:
In the olden days, the mask was spelled out in octets (eg
255.255.255.0). But we've moved to a more compact and logical
notation where the number of leading significant bits is specified
(eg /24).
I hope you're not suggesting the older
On Thursday, September 17, 2009, Daniel Fetchinson
fetchin...@googlemail.com wrote:
188 (check that, 190) people have downloaded the 2.0 release in the
last week (numbers publicly available from the http://code.google.com). I
can't tell you how many (if any) have downloaded it via svn.
Andrew McNamara writes:
Conceptually, you sometimes need a bare address, and other times,
you need an address with an associated network (host interface
configs, router configs, etc). By AddressWithMask, I really mean
AddressWithEnoughInformationToDeriveNetworkWhenNeeded. Conveniently,
Eric Smith wrote:
Peter Moody wrote:
indexing is plenty efficient, but the problem is that these names for
these attributes are common to the point of causing confusion if
they're omitted.
After thinking about it some more, I'm okay with names for [-1] and [0].
I like .broadcast, and I
Peter Moody wrote:
the address with all of the hosts bits masked to zero is most commonly
referred to as the network address.
Then call the attribute 'network_address', not just 'network'.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
On Thu, Sep 17, 2009 at 3:27 PM, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Peter Moody wrote:
the address with all of the hosts bits masked to zero is most commonly
referred to as the network address.
Then call the attribute 'network_address', not just 'network'.
from an earlier email:
On Thu, 17 Sep 2009 10:41:37 am Andrew McNamara wrote:
In the olden days, the mask was spelled out in octets (eg
255.255.255.0). But we've moved to a more compact and logical
notation where the number of leading significant bits is specified
(eg /24).
I hope you're not suggesting the older
Conceptually, you sometimes need a bare address, and other times,
you need an address with an associated network (host interface
configs, router configs, etc). By AddressWithMask, I really mean
AddressWithEnoughInformationToDeriveNetworkWhenNeeded. Conveniently,
IPv4 and IPv6 addressing
To a non-specialist, the network address is ambiguous. There are many
addresses in a network, and none of them are the entire network. It's
like saying, given a list [2, 4, 8, 12], what's the list item?
A network address is an IP address and mask, but I understand your
confusion - we're mixing
On Fri, 18 Sep 2009 at 11:04, Andrew McNamara wrote:
[attribution lost; apparently Steven D'Aprano given the CC]
To a non-specialist, the network address is ambiguous. There are many
addresses in a network, and none of them are the entire network. It's
like saying, given a list [2, 4, 8, 12],
On Fri, 18 Sep 2009 11:04:46 am Andrew McNamara wrote:
To a non-specialist, the network address is ambiguous. There are
many addresses in a network, and none of them are the entire
network. It's like saying, given a list [2, 4, 8, 12], what's the
list item?
A network address is an IP
On Tue, Sep 15, 2009 at 09:35:13PM +0200, Sebastian Rittau wrote:
On Tue, Sep 15, 2009 at 01:16:06PM -0400, Scott Dial wrote:
I have to concur with the opinions above. I was very confused by the
following error:
addr = ipaddr.IPAddress(10.1.2.3/255.255.240.0)
...
I've been skimming emails in this thread, since most of them go over my
head and I have no current need for an ipaddress module. But one thing
I noticed stands out and needs commenting on:
On Wed, 16 Sep 2009 11:05:26 am Peter Moody wrote:
On Tue, Sep 15, 2009 at 6:02 PM, Eric Smith
2009/9/16 Steven D'Aprano st...@pearwood.info:
I've been skimming emails in this thread, since most of them go over my
head and I have no current need for an ipaddress module.
Same here.
As an outsider to this argument, and judging from the lack of agreement
here, it seems to me that some
Steven D'Aprano wrote:
I've been skimming emails in this thread, since most of them go over my
head and I have no current need for an ipaddress module. But one thing
I noticed stands out and needs commenting on:
On Wed, 16 Sep 2009 11:05:26 am Peter Moody wrote:
On Tue, Sep 15, 2009 at
Stephen J. Turnbull stephen at xemacs.org writes:
Rather, don't you want to just give IPv4Address an attribute
'network'? This could then be filled in by the indexing method on
IPv4Network.
It doesn't make sense to me. An address, conceptually, doesn't have a network.
If I say 213.5.4.68,
On Tue, Sep 15, 2009 at 11:36 AM, Peter Moody pe...@hda3.com wrote:
On Tue, Sep 15, 2009 at 11:33 AM, Jake McGuire mcgu...@google.com wrote:
On Tue, Sep 15, 2009 at 10:36 AM, Peter Moody pe...@hda3.com wrote:
On Tue, Sep 15, 2009 at 10:16 AM, Jake McGuire mcgu...@google.com
wrote:
On
On 11:10 am, ncogh...@gmail.com wrote:
Steven D'Aprano wrote:
I've been skimming emails in this thread, since most of them go over
my
head and I have no current need for an ipaddress module. But one thing
I noticed stands out and needs commenting on:
On Wed, 16 Sep 2009 11:05:26 am Peter
On Wed, 16 Sep 2009 at 12:50, exar...@twistedmatrix.com wrote:
On 11:10 am, ncogh...@gmail.com wrote:
Or, to put it another way, given an arbitrary host in a network (e.g.
your own machine or the default gateway) and the netmask for that
network, calculate the network address.
With a lax
On Wed, 16 Sep 2009 at 12:04, Paul Moore wrote:
Of course, the discussion seems to imply that even the experts have a
confused view, so maybe I'm being too ambitious here :-)
Part of the problem, as we discovered in the last go-round on
ipaddr, is that there are two types of experts: those
Le Mon, 14 Sep 2009 09:44:12 -0700, Peter Moody a écrit :
Folks, Guido,
I believe PEP 3144 is ready for your review. When you get a chance, can
you take a look/make a pronouncement?
Besides what has already been said in the thread, I have a bunch of
comments:
It should be noted
On Wed, Sep 16, 2009 at 1:35 PM, Antoine Pitrou solip...@pitrou.net wrote:
Le Mon, 14 Sep 2009 09:44:12 -0700, Peter Moody a écrit :
Folks, Guido,
I believe PEP 3144 is ready for your review. When you get a chance, can
you take a look/make a pronouncement?
Besides what has already been
Peter Moody wrote:
On Wed, Sep 16, 2009 at 1:35 PM, Antoine Pitrou solip...@pitrou.net wrote:
Le Mon, 14 Sep 2009 09:44:12 -0700, Peter Moody a écrit :
Folks, Guido,
I believe PEP 3144 is ready for your review. When you get a chance, can
you take a look/make a pronouncement?
Besides what
Nick Coghlan wrote:
Or, to put it another way, given an arbitrary host in a network (e.g.
your own machine or the default gateway) and the netmask for that
network, calculate the network address.
Some people have claimed that the gateway address of a
network isn't necessarily the zero address
Eric.
Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Nick Coghlan wrote:
Or, to put it another way, given an arbitrary host in a network (e.g.
your own machine or the default gateway) and the netmask for that
network, calculate the network address.
Some people have claimed that the gateway
On 15Sep2009 13:16, Scott Dial scott+python-...@scottdial.com wrote:
| It just happened that I needed a tool today to calculate the gateway IP
| for an interface, and I took it as an opportunity to try out this ipaddr
| module. I'll attempt to relate my experience below...
|
| I have to concur
On Thu, 17 Sep 2009 at 09:59, Greg Ewing wrote:
Nick Coghlan wrote:
Or, to put it another way, given an arbitrary host in a network (e.g.
your own machine or the default gateway) and the netmask for that
network, calculate the network address.
Some people have claimed that the gateway
On Wed, Sep 16, 2009 at 4:59 PM, Greg Ewing greg.ew...@canterbury.ac.nzwrote:
Some people have claimed that the gateway address of a
network isn't necessarily the zero address in that network.
I'll go further: I don't think it's even legal for the gateway address to be
the zero address of the
R. David Murray wrote:
A network is conventionally represented by an IP address in which the
bits corresponding to the one bits in the netmask are set to zero, plus
the netmask.
Okay, that's clarified things for me, thanks.
In that case, we shouldn't be talking about a network address
at
R. David Murray wrote:
A network is conventionally represented by an IP address in which the
bits corresponding to the one bits in the netmask are set to zero, plus
the netmask.
Okay, that's clarified things for me, thanks.
Put another way, an Address describes a single end-point and a
Some people have claimed that the gateway address of a
network isn't necessarily the zero address in that network.
It almost never is - conventions vary, but it is often the network address
plus one, or the broadcast address minus one.
I'll go further: I don't think it's even legal for the
On Wed, Sep 16, 2009 at 5:30 PM, Andrew McNamara
andr...@object-craft.com.au wrote:
R. David Murray wrote:
A network is conventionally represented by an IP address in which the
bits corresponding to the one bits in the netmask are set to zero, plus
the netmask.
Okay, that's clarified things
This proposal actually leads to 6 entities (3 for IPv4 and 3 for IPv6).
Yes, I know - I was just trying to keep to the point.
It's still unclear to me what is gained by pulling AddressWithMask
functionality out of the current network classes. It's easy enough for
the concerned developer who to
On Wed, Sep 16, 2009 at 6:32 PM, Andrew McNamara
andr...@object-craft.com.au wrote:
This proposal actually leads to 6 entities (3 for IPv4 and 3 for IPv6).
Yes, I know - I was just trying to keep to the point.
It's still unclear to me what is gained by pulling AddressWithMask
functionality out
Andrew McNamara wrote:
I also suggest the AddressWithMask classes not have any network/container
behaviours for a similar reason. If the developer needs these, the
.network attribute is only a lookup away.
Another way to approach this would be for the Address
object to potentially have a
Peter Moody wrote:
I don't see where the confusion lies. You have an address
+ netmask. ergo, you have a Network object. The single address that
defines the base address (most commonly referred to as the network
address) is an Address object. there is no netmask associated with
that single
I think we're in a painful middle ground now - we should either go back
to the idea of a single class (per protocol), or make the distinctions
clear (networks are containers and addresses are singletons).
Personally, I think I would be happy with a single class (but I suspect
that's just my
On Wed, Sep 16, 2009 at 7:48 PM, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Peter Moody wrote:
I don't see where the confusion lies. You have an address
+ netmask. ergo, you have a Network object. The single address that
defines the base address (most commonly referred to as the network
Another way to approach this would be for the Address object to
potentially have a 'network' attribute referencing a Network object.
Yes - that's reasonable.
Then there are only two classes, but three use cases are covered:
1) a Network
2) a plain, network-agnostic Address with network == None
On Wed, Sep 16, 2009 at 8:36 PM, Peter Moody pe...@hda3.com wrote:
On Wed, Sep 16, 2009 at 8:21 PM, Andrew McNamara
andr...@object-craft.com.au wrote:
I think we're in a painful middle ground now - we should either go back
to the idea of a single class (per protocol), or make the distinctions
Peter Moody wrote:
On Wed, Sep 16, 2009 at 8:21 PM, Andrew McNamara
andr...@object-craft.com.au wrote:
I think we're in a painful middle ground now - we should either go back
to the idea of a single class (per protocol), or make the distinctions
clear (networks are containers and addresses
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Scott Dial wrote:
The purpose is to avoid conflating IPNetwork with an IPAddress that has
a mask.
I'm not confused by anything in this discussion except the repeated
harping on the (to me imaginary) concept of address with a mask.
Conceptually:
I argue that we're not actually adding any complexity: yes, we add
a class (per protocol), but we then merely relocate functionality to
clarify the intended use of the classes.
And I argue the moving this functionality to new classes (and adding
new restrictions to existing classes) doesn't
On Mon, Sep 14, 2009 at 7:11 PM, Andrew McNamara
andr...@object-craft.com.au wrote:
I believe PEP 3144 is ready for your review. When you get a chance,
can you take a look/make a pronouncement?
In my experience it is common to leave out the masked octets when
referring to an IPv4 network (the
Andrew McNamara andrewm at object-craft.com.au writes:
ipaddr.IPv4Network('192.168.1.1/16').network
IPv4Address('192.168.0.0')
Er, does this mean that taking the `network` attribute from a network object
actually gives an address object (not a network)?
It looks horribly misleading
On Tue, 15 Sep 2009 at 14:28, Antoine Pitrou wrote:
Andrew McNamara andrewm at object-craft.com.au writes:
ipaddr.IPv4Network('192.168.1.1/16').network
IPv4Address('192.168.0.0')
Er, does this mean that taking the `network` attribute from a network object
actually gives an address
R. David Murray wrote:
On Tue, 15 Sep 2009 at 14:28, Antoine Pitrou wrote:
Andrew McNamara andrewm at object-craft.com.au writes:
ipaddr.IPv4Network('192.168.1.1/16').network
IPv4Address('192.168.0.0')
Er, does this mean that taking the `network` attribute from a network
object
On Mon, Sep 14, 2009 at 9:54 AM, Guido van Rossum gu...@python.org wrote:
What's the opinion of the other interested party or parties? I don't
want a repeat of the events last time, where we had to pull it at the
last time because there hadn't been enough discussion.
How many other people
On Tue, Sep 15, 2009 at 10:16 AM, Jake McGuire mcgu...@google.com wrote:
On Mon, Sep 14, 2009 at 9:54 AM, Guido van Rossum gu...@python.org wrote:
What's the opinion of the other interested party or parties? I don't
want a repeat of the events last time, where we had to pull it at the
last
On Tue, Sep 15, 2009 at 10:16 AM, Scott Dial
scott+python-...@scottdial.com wrote:
R. David Murray wrote:
On Tue, 15 Sep 2009 at 14:28, Antoine Pitrou wrote:
Andrew McNamara andrewm at object-craft.com.au writes:
ipaddr.IPv4Network('192.168.1.1/16').network
IPv4Address('192.168.0.0')
Scott Dial scott+python-dev at scottdial.com writes:
gateway = net[1]
I was then confused, because:
print(type(gateway))
class 'ipaddr.IPv4Address'
Which sorta blew my mind.. I fully expected to receive an IPNetwork back
from that operation.
Speaking as a non-network specialist,
Peter Moody wrote:
On Tue, Sep 15, 2009 at 10:16 AM, Scott Dial
scott+python-...@scottdial.com wrote:
In the end, I found the names IPNetwork/IPAddress and their
instantiations confusing. ISTM that IPNetwork is overloaded and plays
two roles of being an IPNetwork and being an
On Tue, Sep 15, 2009 at 12:16 PM, Scott Dial
scott+python-...@scottdial.comscott%2bpython-...@scottdial.com
wrote:
addr = ipaddr.IPAddress(10.1.2.3/255.255.240.0)
...
ipaddr.IPAddressIPValidationError: '98.223.189.24/255.255.240.0' is not
a valid address (hint, it's probably a network)
On Tue, 15 Sep 2009 at 14:16, Scott Dial wrote:
In other words, I don't see why obtaining a host address would *not*
retain the hostmask from the network it was obtained from. I am not
disagreeing with it being an individual address. I am disagreeing that
IPNetwork itself already does represent
101 - 200 of 230 matches
Mail list logo
