This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author claymation
Recipients Rhamphoryncus, benjamin.peterson, claymation, ezio.melotti, giampaolo.rodola, gregory.p.smith, gvanrossum, loewis, mattsmart, oubiwann, pitrou, pmoody, pnasrat, r.david.murray, shields
Date 2009-06-01.23:41:17
SpamBayes Score 0.000541231
Marked as misclassified No
Message-id <8657ee3f0906011641n1fb547d0of55ba87e720effee@mail.gmail.com>
In-reply-to <Pine.LNX.4.64.0906011642160.32513@kimball.webabinitio.net>
Content
On Mon, Jun 1, 2009 at 5:02 PM, R. David Murray <report@bugs.python.org> wrote:

>> >>> ipaddr.IPv4('192.168.1.1') == ipaddr.IPv4('192.168.1.1/32')
>> True
>
> As a network engineer I don't see any inherent problem with that equality.
> In fact I make use of that conceptual equality on a regular basis.

For an example of why 192.168.1.1 != 192.168.1.1/32, look no further
than ifconfig:

# ifconfig en0 192.168.1.1/32
# ifconfig en0
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	inet 192.168.1.1 netmask 0xffffffff broadcast 192.168.1.1
        ...

# ifconfig en0 192.168.1.1
# ifconfig en0
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
        ...

Can you provide an example of when 192.168.1.1 does in fact equal
192.168.1.1/32?

> Further, if you were to add a specifically 'address-without-netmask'
> type, the above equality would still be true, because then the above
> would be comparing two addresses-with-netmasks and you would want to
> apply the hostmask to a bare address for convenience.  To get inequality,
> you'd be comparing two different object types...which comparison would
> be False by default.

I don't follow. Assuming hypothetical Address and Network classes, as
accurately models the problem domain, we would have:

False

That seems to me the correct behavior, since an address is in fact not
the same thing as a network.

Clay
History
Date User Action Args
2009-06-01 23:41:20claymationsetrecipients: + claymation, gvanrossum, loewis, gregory.p.smith, Rhamphoryncus, pitrou, giampaolo.rodola, benjamin.peterson, ezio.melotti, mattsmart, shields, pmoody, pnasrat, r.david.murray, oubiwann
2009-06-01 23:41:18claymationlinkissue3959 messages
2009-06-01 23:41:17claymationcreate