[Python-Dev] PEP 3144 review.

[Nick Coghlan]

Guido van Rossum wrote:
> On Tue, Sep 29, 2009 at 2:05 PM, Terry Reedy <tjreedy at 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 users to have few choices of data types, since
> they usually make the wrong choice (Ever tried to figure out whether
> to use an ArrayList or a LinkedList in Java?)
> 
> So if there are two different but similar classes to represent a
> network, distinguished only by whether they retain the denormalized
> input address or not, users have a 50% chance of picking the wrong
> one, while if there is only one class, there is a 100% chance of
> picking the right one. (There is still the IPAddress class, but the
> differences between IPAddress and IPNetwork are much  clearer.)

Note that Terry was just talking about the documentation there. That is,
he was suggesting that the documentation first describe the "normal"
IPNetwork methods which are unaffected by the .ip attribute and then, in
a separate section, describe the methods that are specific to
"denormalised" networks where "net.ip != net.network". Such an
arrangement makes sense to me.

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 write code using 'net.ip' that should have
used 'net.network' instead. Such code will then work correctly most of
the time (i.e. when only given normalised IPNetwork objects) but will
fail when given a denormalised one.

I believe that discomfort could be eliminated best by changing the name
of the ".ip" attribute to ".host_ip" to make it clear that it is
referring to the IP address of the host that was used to derive the
network definition rather than referring to the network ID itself.
Shortening ".network" to ".net_ip" would also help (this latter change
would also eliminate the mental disconnect caused by an attribute called
.network returning an IPAddress instance).

Those two naming suggestions are far less fundamental than fixing the
definition of the IPNetwork equivalent classes though - and it sounds
like Peter is happy with the proposed change on that front.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------