.
The rest of the list-returning methods all return iterators now too.
There should only be a few minor outstanding issues to to work out.
Cheers,
peter
--
Peter Moody Google 1.650.253.7306
Security Engineer pgp:0xC3410038
___
Python-Dev m
that?
> --
> --Guido van Rossum (python.org/~guido)
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/pmo
On Mon, Mar 12, 2012 at 9:15 AM, Peter Moody wrote:
>>> - iterable APIs should consistently produce iterators (leaving users
>>> free to wrap list() around the calls if they want the concrete
>>> realisation)
I might've missed earlier discussion somewhere, but ca
On Wed, Feb 29, 2012 at 9:13 PM, Peter Moody wrote:
> Just checking in:
>
> On Mon, Feb 20, 2012 at 5:48 PM, Nick Coghlan wrote:
>> At the very least:
>> - the IP Interface API needs to move to a point where it more clearly
>> *is* an IP Address and *has* an associa
.com/p/ipaddress-py/source/detail?r=10dd6a68139fb99116219865afcd1c183777e8cc
(the date is munged b/c I rebased to my original commit before submitting).
--
Peter Moody Google 1.650.253.7306
Security Engineer pgp:0xC3410038
___
Python-Dev mailing list
Python-Dev@python
ieve the authorship of ipaddr either decided that they were
>> not going to compromise their module or lost interest.
>>
>> See Nick Coghlan's summary:
>>
>> http://mail.python.org/pipermail//python-ideas/2011-August/011305.html
>
> Peter Moody actually addressed
[[email protected]]
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]
>>
[[email protected]]
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
in it, as I managed to completely misunderstand what you
> absolutely require), when AFAICT the only "line in the sand" is being
> drawn around the semantics of "net1 == net2".
>
> Peter Moody writes:
>
> > I don't actually see a disconnect. it seems analo
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
[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
>>
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
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 c
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 on
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:
>> >
>> >> adminis
On Sun, Sep 27, 2009 at 12:40 PM, James Y Knight 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 br
On Sun, Sep 27, 2009 at 11:17 AM, Antoine Pitrou wrote:
> Peter Moody hda3.com> writes:
>>
>> > (or would you argue that Address objects should have an optional
> distinguishing
>> > port number, for "convenience" reasons?)
>>
>> I'm
On Sun, Sep 27, 2009 at 10:22 AM, Antoine Pitrou wrote:
> Peter Moody 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
On Sun, Sep 27, 2009 at 10:30 AM, Steven D'Aprano 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
>>
On Sun, Sep 27, 2009 at 4:23 AM, Antoine Pitrou wrote:
> Peter Moody 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
>> usabilit
On Sat, Sep 26, 2009 at 11:08 PM, Nick Coghlan 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.
>
On Sat, Sep 26, 2009 at 6:34 AM, Barry Scott 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?
>>
>
On Sat, Sep 26, 2009 at 10:38 PM, Nick Coghlan wrote:
> Peter Moody wrote:
>> I again invite interested parties to continue this discussion on
>> [email protected]. we're pushing 250 messages on PEP
>> 3144 at this point; well beyond what most folks would
I again invite interested parties to continue this discussion on
[email protected]. 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:
>
ne
On Sat, Sep 26, 2009 at 4:27 PM, Daniel Stutzbach
wrote:
> On Sat, Sep 26, 2009 at 4:57 PM, DrKJam wrote:
>>
>> 2009/9/26 Daniel Stutzbach
>>>
>>> On Sat, Sep 26, 2009 at 2:07 PM, DrKJam wrote:
The current version of the PEP and reference implementation do not
mention or deal wit
On Thu, Sep 17, 2009 at 11:10 AM, Daniel Fetchinson
wrote:
>> 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.
>
> Downloadin
On Thu, Sep 17, 2009 at 6:17 PM, Andrew McNamara
wrote:
>>off to patch the pep and implement some of the non controversial changes.
>
> It might be a good idea to add some use-cases to the PEP.
There are several use-cases in the PEP already.
The problem is, for every use-case where one can show
On Thu, Sep 17, 2009 at 3:27 PM, Greg Ewing 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
On Thu, Sep 17, 2009 at 10:50 AM, David Moss wrote:
> On 17 Sep 2009, at 15:40, Peter Moody wrote:
>
>> On Thu, Sep 17, 2009 at 7:26 AM, DrKJam wrote:
>>>
>>> Please can we have the following RFCs added to the references section
>>> that
>>&g
On Thu, Sep 17, 2009 at 10:32 AM, R. David Murray wrote:
> On Thu, 17 Sep 2009 at 09:16, Peter Moody wrote:
>>
>> I mentioned before that IPy's insistence on receiving masked out
>> networks was one of the main reasons I wrote ipaddr to begin with.
>> Having ipadd
On Thu, Sep 17, 2009 at 9:26 AM, Antoine Pitrou wrote:
> Peter Moody hda3.com> writes:
>>
>> Again, the same error-catching functionality can be obtained through
>> an option to the constructor. network and broadcast attributes can be
>> renamed to .\1_address
On Thu, Sep 17, 2009 at 5:32 AM, Nick Coghlan wrote:
> Eric Smith wrote:
>> Antoine Pitrou wrote:
>>> As it is, -1 from me. Either we only keep two concepts (Address and
>>> Network), or if we introduce a third one (AddressWithMask,
>>> whatever) for added practicality; but we shouldn't blur the
On Thu, Sep 17, 2009 at 6:25 AM, Eric Smith 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 = my_n
On Thu, Sep 17, 2009 at 7:32 AM, Antoine Pitrou 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
On Thu, Sep 17, 2009 at 7:26 AM, DrKJam 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 IPv4 Addresses
On Wed, Sep 16, 2009 at 8:36 PM, Peter Moody wrote:
> On Wed, Sep 16, 2009 at 8:21 PM, Andrew McNamara
> 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 di
On Wed, Sep 16, 2009 at 8:21 PM, Andrew McNamara
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 are singletons).
>>>
>>> Personally, I thi
On Wed, Sep 16, 2009 at 7:48 PM, Greg Ewing 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
On Wed, Sep 16, 2009 at 6:32 PM, Andrew McNamara
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 of the current netw
On Wed, Sep 16, 2009 at 5:30 PM, Andrew McNamara
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 for me, than
On Wed, Sep 16, 2009 at 1:35 PM, Antoine Pitrou 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
On Tue, Sep 15, 2009 at 5:33 PM, Antoine Pitrou wrote:
> Antoine Pitrou pitrou.net> writes:
>>
>> I don't see any valid reason for entering a network as "192.168.1.1/24"
>> rather
>> than the canonical "192.168.1.0/24". The former might indicate a typing error
>> or
>> a mental slip, so let's be
On Tue, Sep 15, 2009 at 6:02 PM, Eric Smith wrote:
> Antoine Pitrou wrote:
>>
>> Peter Moody hda3.com> writes:
>>>>>>>
>>>>>>> However, I do not think
>>>>>>> that the proposed API should accept, eg,
>>>
On Tue, Sep 15, 2009 at 4:34 PM, Scott Dial
wrote:
> R. David Murray wrote:
>> On Tue, 15 Sep 2009 at 21:58, Antoine Pitrou wrote:
>>> Le mardi 15 septembre 2009 à 15:48 -0400, R. David Murray a écrit :
However, I do not think
that the proposed API should accept, eg, IPv4Network('192.168
On Tue, Sep 15, 2009 at 1:34 PM, Daniel Fetchinson
wrote:
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
On Tue, Sep 15, 2009 at 11:49 AM, Stephen J. Turnbull
wrote:
> Antoine Pitrou writes:
>
> > Speaking as a non-network specialist, it actually looks logical to
> > me to be given an address if I iterate over a network (the same way
> > that, if I iterate on a list, I get individual elements, not
On Tue, Sep 15, 2009 at 11:33 AM, Jake McGuire wrote:
> On Tue, Sep 15, 2009 at 10:36 AM, Peter Moody wrote:
>>
>> On Tue, Sep 15, 2009 at 10:16 AM, Jake McGuire wrote:
>> > On Mon, Sep 14, 2009 at 9:54 AM, Guido van Rossum
>> > wrote:
>> >>
>
On Tue, Sep 15, 2009 at 10:16 AM, Scott Dial
wrote:
> R. David Murray wrote:
>> On Tue, 15 Sep 2009 at 14:28, Antoine Pitrou wrote:
>>> Andrew McNamara object-craft.com.au> writes:
>>> ipaddr.IPv4Network('192.168.1.1/16').network
IPv4Address('192.168.0.0')
>>>
>>> Er, does t
On Tue, Sep 15, 2009 at 10:16 AM, Jake McGuire wrote:
> On Mon, Sep 14, 2009 at 9:54 AM, Guido van Rossum 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 be
On Mon, Sep 14, 2009 at 7:11 PM, Andrew McNamara
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 octets are assumed to
Folks, Guido,
I believe PEP 3144 is ready for your review. When you get a chance,
can you take a look/make a pronouncement?
Cheers,
/peter
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Howdy,
So I've made most of the suggested changes here and put up a release
of ipaddr. Do folks here consider this pep is final (enough) for
submission or is there more work to be done?
Cheers,
/peter
On Thu, Aug 27, 2009 at 6:52 AM, Peter Moody wrote:
> Howdy folks,
>
> the refe
On Fri, Aug 28, 2009 at 2:31 AM, Nick Coghlan wrote:
> Peter Moody wrote:
>> If there are any more suggestions on the PEP or the code, please let me know.
>
> I noticed the new paragraphs on the IPv4 vs IPv6 types not being
> comparable - is there a canonical ordering for m
On Thu, Aug 27, 2009 at 10:37 AM, Peter Moody wrote:
> On Thu, Aug 27, 2009 at 10:24 AM, David Moss wrote:
>> Peter,
>>
>> I would like to apologise if I have caused you any offense.
>
> Thanks. Accepted.
>
>> Please can we
>> put the animosity behind us
On Thu, Aug 27, 2009 at 10:24 AM, David Moss wrote:
> Peter,
>
> I would like to apologise if I have caused you any offense.
Thanks. Accepted.
> Please can we
> put the animosity behind us and stick to pulling together the best IP
> library possible as part of this PEP?
pep-3144 should hopefully
On Wed, Aug 26, 2009 at 4:48 PM, DrKJam wrote:
> I've started a very basic (work in progress) entry on the netaddr wiki to
> track various aspects of this discussion that might not be in a format
> suitable for publishing to the list or are too lengthy. It will also allow
> my ascii art diagrams to
ritance and the benefits from that design
choice. hopefully that should go live soon.
If there are any more suggestions on the PEP or the code, please let me know.
Cheers,
/peter
On Tue, Aug 18, 2009 at 1:00 PM, Peter Moody wrote:
> Howdy folks,
>
> I have a first draft of a PEP for
On Fri, Aug 21, 2009 at 4:00 AM, Oleg Broytmann wrote:
> http://ipaddr-py.googlecode.com/svn/branches/2.0.x/ipaddr.py
>
>> _compat_has_real_bytes = bytes != str
>
> Wouldn't it be nicer "bytes is not str"?
it is. fixing this.
Cheers,
/peter
> Oleg.
> --
> Oleg Broytmann http
On Mon, Aug 24, 2009 at 3:24 PM, DrKJam wrote:
> Good evening fellow Pythonistas,
>
> Considering a PEP is now available I'd like to join this discussion and
> raise several points with regard to both the PEP and the ipaddr reference
> implementation put forward with it.
Hi David,
is this what pa
On Fri, Aug 21, 2009 at 4:41 PM, Nick Coghlan wrote:
> Peter Moody wrote:
>> On Thu, Aug 20, 2009 at 10:15 PM, Case Vanhorsen wrote:
>>> I was surprised that IP('172.16.1.1') returned
>>> IPv4Address('172.16.1.1/32') instead of IPv4Address('1
On Thu, Aug 20, 2009 at 10:15 PM, Case Vanhorsen wrote:
>>On Thu, Aug 20, 2009 at 2:00 PM, Peter Moody wrote:
>> The pep has been updated with the excellent suggestions thus far.
>>
>> Are there any more?
>
> Thanks for writing the PEP.
>
> I tried a few of the
The pep has been updated with the excellent suggestions thus far.
Are there any more?
Cheers,
/peter
On Tue, Aug 18, 2009 at 1:00 PM, Peter Moody wrote:
> Howdy folks,
>
> I have a first draft of a PEP for including an IP address manipulation
> library in the python stdlib. It seem
On Thu, Aug 20, 2009 at 6:46 AM, Jeroen Ruigrok van der
Werven wrote:
> -On [20090818 22:15], Peter Moody ([email protected]) wrote:
>>I have a first draft of a PEP for including an IP address manipulation
>>library in the python stdlib. It seems like there are a lot of really
>>
On Wed, Aug 19, 2009 at 9:07 PM, Eric Smith wrote:
> Fred Drake wrote:
>>
>> On Aug 19, 2009, at 6:01 PM, Peter Moody wrote:
>>>
>>> just to double check, it's fine for IPNetwork to remain hashable if
>>> set_prefix() actually returned a new object
On Wed, Aug 19, 2009 at 2:44 PM, Nick Coghlan wrote:
> Peter Moody wrote:
>> you can't set them directly, if that's what you mean.
>>
>>>>> import ipaddr
>>>>> o = ipaddr.IPv4Network('1.1.1.0/24')
>>>>>
On Wed, Aug 19, 2009 at 9:21 AM, R. David Murray wrote:
> On Wed, 19 Aug 2009 at 08:19, Peter Moody wrote:
>>
>> On Wed, Aug 19, 2009 at 6:47 AM, Tino Wildenhain
>> wrote:
>>>>
>>>> Le Tue, 18 Aug 2009 13:00:06 -0700, Peter Moody a écrit :
>>>
On Wed, Aug 19, 2009 at 8:39 AM, Eric Smith wrote:
> Peter Moody wrote:
>>
>> On Wed, Aug 19, 2009 at 3:20 AM, Antoine Pitrou
>> wrote:
>>>
>>> Le Tue, 18 Aug 2009 13:00:06 -0700, Peter Moody a écrit :
>>>>
>>>> Howdy folks,
>
On Wed, Aug 19, 2009 at 3:20 AM, Antoine Pitrou wrote:
> Le Tue, 18 Aug 2009 13:00:06 -0700, Peter Moody a écrit :
>> Howdy folks,
>>
>> I have a first draft of a PEP for including an IP address manipulation
>> library in the python stdlib. It seems like there are a l
On Wed, Aug 19, 2009 at 6:47 AM, Tino Wildenhain wrote:
> Antoine Pitrou wrote:
>>
>> Le Tue, 18 Aug 2009 13:00:06 -0700, Peter Moody a écrit :
>>>
>>> Howdy folks,
>>>
>>> I have a first draft of a PEP for including an IP address manipulation
&g
On Tue, Aug 18, 2009 at 1:34 PM, Oleg Broytmann wrote:
>> http://ipaddr-py.googlecode.com/svn/branches/2.0.x/ipaddr.py :
>
>> def IP(address, host=False, version=None):
>> """Take an IP string/int and return an object of the correct type.
>>
>> Args:
>> ip_str: ...
>
> The arg is
Howdy folks,
I have a first draft of a PEP for including an IP address manipulation
library in the python stdlib. It seems like there are a lot of really
smart folks with some, ahem, strong ideas about what an IP address
module should and shouldn't be so I wanted to solicit your input on
this pep.
>> How about a merger?
>
> I think that's a brilliant idea. David and Peter, logistics aside,
> what do you think of (or how to you feel about) this suggestion?
the devil, as they say, is in the details :). I'd be interested to
know what form this merger would take. WRT v4/v6 manipulation, it
see
72 matches
Mail list logo
