[Python-Dev] PEP 3144 review, and the inclusion process

[Andrew McNamara]

>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 to the stdlib, especially if the stdlib is in
>such flux that I'll get to do this again in 18 months.

The point is that, having brought it to us, we all now have an interest
in the outcome. Whatever goes into the standard library is going to be
something that we have to live with for a long time, and now is our best
chance to shape the result.

I understand your concern over introducing more classes, however I still
feel my suggested functional decomposition is worth that cost because
I consider the behaviour of my suggested classes to be more intuitive.
I should mention that I am not a computer scientist, and none of this is
motivated by a desire for theoretical purity - just practical experience.

One of my concerns now is that if a code block receives an IPv4Network
instance, it does not know whether this represents a host address
with mask, or a network address. In some contexts, this distinction is
critical, and confounding them can result in delayed error reporting or
erroneous behaviour. Your addition of a strict flag does not completely
address this concern as it assumes the instantiation and use occur in
proximity, which is often not the case in large projects.

I suspect you are also mistaken in thinking my proposed changes make
the module less useful for you - maybe you can describe the problem as
you see it?


As a reminder to people who have come late to this thread, I proposed three
classes per protocol:

    IPv?Address
        A single address

    IPv?AddressWithMask
        A single address with implied IPv?Network

    IPv?Network
        A container-like network address (with strict mask parsing)

Further:

 * Comparisons between classes should be disallowed. 

 * The IPv?AddressWithMask class would have a .address and .mask attributes
   containing IPv?Addresses, and a .network attribute for the containing
   network (as specified by the mask, and lazily constructed).

 * The IPv?Network class would have similar .address and .mask attributes.

In cases where you want to allow lax specification of network addresses,
this would be spelt:

    IPv?AddressWithMask(some_address).network

At first glance, this seems somewhat round-about, however it makes explicit
the potential loss of bits.

-- 
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/