[Python-Dev] PEP 3144 review. (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Wed Sep 30 03:07:28 CEST 2009

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

More information about the Python-Dev mailing list