PEP czar for PEP 3144?

classic Classic list List threaded Threaded
39 messages Options
12
Reply | Threaded
Open this post in threaded view
|

PEP czar for PEP 3144?

Nick Coghlan
Does anyone object to me naming myself PEP czar for PEP 3144?

I've collated the objections to the original proposal on a few
different occasions throughout the (long!) PEP review process, and as
noted in the Background section, the latest version of the PEP [1] has
addressed the key concerns that were raised:

- the "strict" flag for Network objects is gone (instead, the
validation differences between IP Network and IP Interface definitions
are handled as different classes with otherwise similar interfaces)
- the factory function naming scheme follows PEP 8
- some properties have been given new names that make it clearer what
kind of object they produce
- the module itself has been given a new name (ipaddress) to avoid
clashing with the existing ipaddr module on PyPI

There's also basic-but-usable module documentation available
(http://code.google.com/p/ipaddr-py/wiki/Using3144).

So, unless there are any new objections, I'd like to:
- approve ipaddress for inclusion in Python 3.3
- grant Peter Moody push access as the module maintainer
- create a tracker issue to cover incorporating the new module into
the standard library, documentation and test suite

(There are still a few places in both the PEP and the preliminary
documentation that say "ipaddr" instead of "ipaddress", but those can
be cleaned up as the module gets integrated).

I don't personally think the module API needs the provisional
disclaimer as the core functionality has been tested for years in
ipaddr and the API changes in ipaddress are just cosmetic ones either
for PEP 8 conformance, or to make the API map more cleanly to the
underlying networking concepts. However, I'd be willing to include
that proviso if anyone else has lingering concerns.

Regards,
Nick.

[1] http://www.python.org/dev/peps/pep-3144/

--
Nick Coghlan   |   [hidden email]   |   Brisbane, Australia
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP czar for PEP 3144?

Antoine Pitrou
On Mon, 20 Feb 2012 23:23:13 +1000
Nick Coghlan <[hidden email]> wrote:
> Does anyone object to me naming myself PEP czar for PEP 3144?

“Tsar is a title used to designate certain European Slavic monarchs or
supreme rulers.”

Is this our official word?

> There's also basic-but-usable module documentation available
> (http://code.google.com/p/ipaddr-py/wiki/Using3144).

Mmmh, some comments:
- a network can be "in" another network? Sounds strange. Compare with
  sets, which can be ordered, but not contained one within another.
  The idea of an address or network being "in" an interface sounds even
  stranger.
- iterhosts()? Why not simply hosts()?
- “A TypeError exception is raised if you try to compare objects of
  different versions or different types.”: I hope equality still works?

Regards

Antoine.


_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP czar for PEP 3144?

Nick Coghlan
On Mon, Feb 20, 2012 at 11:55 PM, Antoine Pitrou <[hidden email]> wrote:
> On Mon, 20 Feb 2012 23:23:13 +1000
> Nick Coghlan <[hidden email]> wrote:
>> Does anyone object to me naming myself PEP czar for PEP 3144?
>
> “Tsar is a title used to designate certain European Slavic monarchs or
> supreme rulers.”
>
> Is this our official word?

PEP czar/tsar and BDFOP (Benevolent Dictator for One PEP) are the two
names I've seen for the role. I don't have a strong preference either
way (just a mild preference for 'czar').

>> There's also basic-but-usable module documentation available
>> (http://code.google.com/p/ipaddr-py/wiki/Using3144).
>
> Mmmh, some comments:
> - a network can be "in" another network? Sounds strange. Compare with
>  sets, which can be ordered, but not contained one within another.
>  The idea of an address or network being "in" an interface sounds even
>  stranger.

Ah, I'd missed that one. Yes, I think this a holdover from the main
ipaddr module which plays fast and loose with type correctness by
implicitly converting between networks and addresses in all sorts of
places. It doesn't have Network and Interface as separate types
(calling them both "Networks") and it appears the current incarnation
of the Interface API still retains a few too many Network-specific
behaviours.

I agree the "container" behaviour should be reserved for the actual
Network API, with Interface objects behaving more like Addresses in
that respect.

I also agree Network subset and superset checks should follow a
set-style API rather than overloading the containment checks.

There are actually a few other behaviours (like compare_networks()
that should probably be moved to the Network objects, and accessed via
the "network" property for Interface objects.

> - iterhosts()? Why not simply hosts()?

And I missed that one, too. Perhaps that provisional marker wouldn't
be such a bad idea after all...

One requirement for integration would be fleshing out the standard
library version of the documentation to include a full public API
reference for the module and public classes, which will also help
highlight any lingering naming problems, as well as areas where APIs
that currently return realised lists should probably be returning
iterators instead (there's currently iter_subnets() and subnet(),
which should just be a single subnets() iterator).

> - “A TypeError exception is raised if you try to compare objects of
>  different versions or different types.”: I hope equality still works?

It looks like it's supposed to (and does for Address objects), but
there's currently a bug in the _BaseInterface.__eq__ impl that makes
it return None instead of False (the method impl *should* be returning
NotImplemented, just as _BaseAddress does, with the interpreter than
reporting False if both sides return NotImplemented).

There's currently an implicit promotion of Address objects to
Interface objects, such that "network_or_interface == address" is the
same as "network_or_interface.ip == address".

So yes, with the appropriate boundaries between the different types of
objects still being a little blurred, I think a "provisional" marker
is definitely warranted. Some of the APIs that are currently available
directly on Interface objects should really be accessed via their
.network property instead.

Cheers,
Nick.

--
Nick Coghlan   |   [hidden email]   |   Brisbane, Australia
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP czar for PEP 3144?

Dirkjan Ochtman
In reply to this post by Nick Coghlan
On Mon, Feb 20, 2012 at 14:23, Nick Coghlan <[hidden email]> wrote:
> I don't personally think the module API needs the provisional
> disclaimer as the core functionality has been tested for years in
> ipaddr and the API changes in ipaddress are just cosmetic ones either
> for PEP 8 conformance, or to make the API map more cleanly to the
> underlying networking concepts. However, I'd be willing to include
> that proviso if anyone else has lingering concerns.

Should it be net.ipaddress instead of just ipaddress?

Somewhat nested is better than fully flat.

Cheers,

Dirkjan
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP czar for PEP 3144?

Antoine Pitrou
On Mon, 20 Feb 2012 16:20:15 +0100
Dirkjan Ochtman <[hidden email]> wrote:

> On Mon, Feb 20, 2012 at 14:23, Nick Coghlan <[hidden email]> wrote:
> > I don't personally think the module API needs the provisional
> > disclaimer as the core functionality has been tested for years in
> > ipaddr and the API changes in ipaddress are just cosmetic ones either
> > for PEP 8 conformance, or to make the API map more cleanly to the
> > underlying networking concepts. However, I'd be willing to include
> > that proviso if anyone else has lingering concerns.
>
> Should it be net.ipaddress instead of just ipaddress?
>
> Somewhat nested is better than fully flat.

IMHO, nesting without a good, consistent, systematic categorization
leads to very unpleasant results (e.g. "from urllib.request import
urlopen").

Historically, our stdlib has been flat and I think it should stay so,
short of redoing the whole hierarchy.

(note this has nothing to do with the possible implementation of
modules as packages, such as unittest or importlib)

Regards

Antoine.


_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP czar for PEP 3144?

"Martin v. Löwis"
In reply to this post by Antoine Pitrou
>> Does anyone object to me naming myself PEP czar for PEP 3144?
>
> “Tsar is a title used to designate certain European Slavic monarchs or
> supreme rulers.”
>
> Is this our official word?

"supreme ruler" sounds good to me. I could go for "inquisitor" instead
of "czar" as well...

Regards,
Martin




_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP czar for PEP 3144?

Senthil Kumaran-7
On Tue, Feb 21, 2012 at 12:07 AM,  <[hidden email]> wrote:
> "supreme ruler" sounds good to me. I could go for "inquisitor" instead
> of "czar" as well...

But that would be bad for developers from Spain as nobody would expect
a spanish inquisition.

:-)

--
Senthil
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP czar for PEP 3144?

Mark Lawrence
On 20/02/2012 16:28, Senthil Kumaran wrote:
> On Tue, Feb 21, 2012 at 12:07 AM,<[hidden email]>  wrote:
>> "supreme ruler" sounds good to me. I could go for "inquisitor" instead
>> of "czar" as well...
>
> But that would be bad for developers from Spain as nobody would expect
> a spanish inquisition.
>
> :-)
>

How about Big Brother then?  As anyone worked in room 101?

--
Cheers.

Mark Lawrence.

_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP czar for PEP 3144?

Andrew Svetlov
I like 'PEP czar'

On Mon, Feb 20, 2012 at 6:50 PM, Mark Lawrence <[hidden email]> wrote:

> On 20/02/2012 16:28, Senthil Kumaran wrote:
>>
>> On Tue, Feb 21, 2012 at 12:07 AM,<[hidden email]>  wrote:
>>>
>>> "supreme ruler" sounds good to me. I could go for "inquisitor" instead
>>> of "czar" as well...
>>
>>
>> But that would be bad for developers from Spain as nobody would expect
>> a spanish inquisition.
>>
>> :-)
>>
>
> How about Big Brother then?  As anyone worked in room 101?
>
> --
> Cheers.
>
> Mark Lawrence.
>
>
> _______________________________________________
> Python-Dev mailing list
> [hidden email]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/andrew.svetlov%40gmail.com
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP czar for PEP 3144?

Dirkjan Ochtman
In reply to this post by Antoine Pitrou
On Mon, Feb 20, 2012 at 16:27, Antoine Pitrou <[hidden email]> wrote:

>> Should it be net.ipaddress instead of just ipaddress?
>>
>> Somewhat nested is better than fully flat.
>
> IMHO, nesting without a good, consistent, systematic categorization
> leads to very unpleasant results (e.g. "from urllib.request import
> urlopen").
>
> Historically, our stdlib has been flat and I think it should stay so,
> short of redoing the whole hierarchy.
>
> (note this has nothing to do with the possible implementation of
> modules as packages, such as unittest or importlib)

I thought Python 3 already came with a net package, but apparently
that plan has long been discarded. So I retract my suggestion.

Cheers,

Dirkjan
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP czar for PEP 3144?

Matt Joiner
In reply to this post by Antoine Pitrou
On Mon, Feb 20, 2012 at 11:27 PM, Antoine Pitrou <[hidden email]> wrote:
> IMHO, nesting without a good, consistent, systematic categorization
> leads to very unpleasant results (e.g. "from urllib.request import
> urlopen").
>
> Historically, our stdlib has been flat and I think it should stay so,
> short of redoing the whole hierarchy.

I concur. Arbitrary nesting should be avoided.
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP czar for PEP 3144?

Terry Reedy
In reply to this post by Nick Coghlan
On 2/20/2012 8:23 AM, Nick Coghlan wrote:
> Does anyone object to me naming myself PEP czar for PEP 3144?

I think it great that you volunteer to be the PEP czar and hope Guido
appoints you -- especially after your response to Antoine. Since this is
a Python 3 module, let us start off with a modern Python 3 interface.
That includes returning iterators instead of lists unless there is a
really good reason.

I can see how an outside developer could have difficulty getting
integrated into our collective PEP process ;-).

--
Terry Jan Reedy

_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP czar for PEP 3144?

Guido van Rossum
Approved. Nick is PEP czar for PEP 3144. Thanks Nick!

On Mon, Feb 20, 2012 at 11:13 AM, Terry Reedy <[hidden email]> wrote:

> On 2/20/2012 8:23 AM, Nick Coghlan wrote:
>>
>> Does anyone object to me naming myself PEP czar for PEP 3144?
>
>
> I think it great that you volunteer to be the PEP czar and hope Guido
> appoints you -- especially after your response to Antoine. Since this is a
> Python 3 module, let us start off with a modern Python 3 interface. That
> includes returning iterators instead of lists unless there is a really good
> reason.
>
> I can see how an outside developer could have difficulty getting integrated
> into our collective PEP process ;-).
>
> --
> Terry Jan Reedy
>
>
> _______________________________________________
> Python-Dev mailing list
> [hidden email]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/guido%40python.org



--
--Guido van Rossum (python.org/~guido)
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP czar for PEP 3144?

Steven D'Aprano-8
In reply to this post by Nick Coghlan
Nick Coghlan wrote:

> On Mon, Feb 20, 2012 at 11:55 PM, Antoine Pitrou <[hidden email]> wrote:
>> On Mon, 20 Feb 2012 23:23:13 +1000
>> Nick Coghlan <[hidden email]> wrote:
>>> Does anyone object to me naming myself PEP czar for PEP 3144?
>> “Tsar is a title used to designate certain European Slavic monarchs or
>> supreme rulers.”
>>
>> Is this our official word?
>
> PEP czar/tsar and BDFOP (Benevolent Dictator for One PEP) are the two
> names I've seen for the role. I don't have a strong preference either
> way (just a mild preference for 'czar').

Also, "Czar" is commonly used in US politics as an informal term for the top
official responsible for an area. "Drug Czar" is only the most familiar:

http://en.wikipedia.org/wiki/List_of_U.S._executive_branch_%27czars%27



--
Steven
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP czar for PEP 3144?

Stephen J. Turnbull
Steven D'Aprano writes:

 > Also, "Czar" is commonly used in US politics as an informal term for the top
 > official responsible for an area.

I think here the most important connotation is that in US parlance a
"czar" does not report to a committee, and with the exception of a
case where Sybil is appointed czar, cannot bikeshed.  Decisions get
made (what a concept!)
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP czar for PEP 3144?

Nick Coghlan
In reply to this post by Guido van Rossum
On Tue, Feb 21, 2012 at 7:09 AM, Guido van Rossum <[hidden email]> wrote:
> Approved. Nick is PEP czar for PEP 3144. Thanks Nick!

In that case the addition of the "ipaddress" module is approved for
3.3, with a provisional caveat on the API details. I'm doing it that
way because I think those remaining details can be better flushed out
by the integration process (in particular, populating full module API
reference documentation) than they could by another round of updates
on the PEP and the ipaddr 3144 branch.

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 associated IP Network (rather than
being the other way around)
- IP Network needs to behave more like an ordered set of sequential IP
Addresses (without sometimes behaving like an Address in its own
right)
- iterable APIs should consistently produce iterators (leaving users
free to wrap list() around the calls if they want the concrete
realisation)

Initial maintainers will be me (for the semantically cleaner
incarnation of the module API) and Peter (for the IPv4 and IPv6
correctness heavy lifting and ensuring any API updates only change the
spelling of particular operations, such as adding a ".network." to
some current operations on Interface objects, rather than reducing
overall module functionality).

This approach means we will still gain the key benefits of using the
PyPI-tested ipaddr as a base (i.e. correct IP address parsing and
generation, full coverage of the same set of supported operations)
while exposing a simpler semantic model for new users that first
encounter these concepts through the standard library module
documentation:

- IP Address as the core abstraction
- IP Network as a container for IP Addresses
- IP Interface as an IP Address with an associated IP Network

Cheers,
Nick.

--
Nick Coghlan   |   [hidden email]   |   Brisbane, Australia
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP czar for PEP 3144?

Guido van Rossum
In reply to this post by Stephen J. Turnbull
On Mon, Feb 20, 2012 at 4:53 PM, Stephen J. Turnbull <[hidden email]> wrote:
> Steven D'Aprano writes:
>
>  > Also, "Czar" is commonly used in US politics as an informal term for the top
>  > official responsible for an area.
>
> I think here the most important connotation is that in US parlance a
> "czar" does not report to a committee, and with the exception of a
> case where Sybil is appointed czar, cannot bikeshed.  Decisions get
> made (what a concept!)

I'm curious how old that usage is. I first encountered it around '88
when I interned for a summer at DEC SRC (long since subsumed into HP
Labs); the person in charge of deciding a particular aspect of their
software or organization was called a czar, e.g. the documentation
czar.

--
--Guido van Rossum (python.org/~guido)
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP czar for PEP 3144?

Terry Reedy
On 2/20/2012 11:52 PM, Guido van Rossum wrote:

> On Mon, Feb 20, 2012 at 4:53 PM, Stephen J. Turnbull<[hidden email]>  wrote:
>> Steven D'Aprano writes:
>>
>>   >  Also, "Czar" is commonly used in US politics as an informal term for the top
>>   >  official responsible for an area.
>>
>> I think here the most important connotation is that in US parlance a
>> "czar" does not report to a committee, and with the exception of a
>> case where Sybil is appointed czar, cannot bikeshed.  Decisions get
>> made (what a concept!)
>
> I'm curious how old that usage is. I first encountered it around '88
> when I interned for a summer at DEC SRC (long since subsumed into HP
> Labs); the person in charge of deciding a particular aspect of their
> software or organization was called a czar, e.g. the documentation
> czar.

In US politics, the first I remember was the Drug Czar about that time.
It really came into currently during Clinton's admin.

--
Terry Jan Reedy

_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP czar for PEP 3144?

Robert Kern-2
In reply to this post by Guido van Rossum
On 2/21/12 4:52 AM, Guido van Rossum wrote:

> On Mon, Feb 20, 2012 at 4:53 PM, Stephen J. Turnbull<[hidden email]>  wrote:
>> Steven D'Aprano writes:
>>
>>   >  Also, "Czar" is commonly used in US politics as an informal term for the top
>>   >  official responsible for an area.
>>
>> I think here the most important connotation is that in US parlance a
>> "czar" does not report to a committee, and with the exception of a
>> case where Sybil is appointed czar, cannot bikeshed.  Decisions get
>> made (what a concept!)
>
> I'm curious how old that usage is. I first encountered it around '88
> when I interned for a summer at DEC SRC (long since subsumed into HP
> Labs); the person in charge of deciding a particular aspect of their
> software or organization was called a czar, e.g. the documentation
> czar.

 From the Wikipedia article Steven cited:

"""
The earliest known use of the term for a U.S. government official was in the
administration of Franklin Roosevelt (1933–1945), during which eleven unique
positions (or twelve if one were to count "Economic Czar" and "Economic Czar of
World War II" as separate) were so described. The term was revived, mostly by
the press, to describe officials in the Nixon and Ford administrations and
continues today.
"""

http://en.wikipedia.org/wiki/List_of_U.S._executive_branch_%27czars%27

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco

_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP czar for PEP 3144?

Peter Moody-3
In reply to this post by Nick Coghlan
Just checking in:

On Mon, Feb 20, 2012 at 5:48 PM, Nick Coghlan <[hidden email]> 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 associated IP Network (rather than
> being the other way around)

This is done [1]. There's cleanup that needs to happen here, but the
interface classes are now subclasses of the respective address
classes.

Now I need to apply some consistency and then move on to the remaining
issues points:

> - IP Network needs to behave more like an ordered set of sequential IP
> Addresses (without sometimes behaving like an Address in its own
> right)
> - iterable APIs should consistently produce iterators (leaving users
> free to wrap list() around the calls if they want the concrete
> realisation)

Cheers,
peter

[1] http://code.google.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
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
12