On Wed, 30 Sep 2009 at 13:11, Guido van Rossum wrote:
On Wed, Sep 30, 2009 at 4:33 AM, Mark Dickinson <dicki...@gmail.com> wrote:
On Wed, Sep 30, 2009 at 12:06 PM, Nick Coghlan <ncogh...@gmail.com> wrote:
Mark Dickinson wrote:
Okay, so maybe this is an abuse of IPv4Network. ?But I'd (mis?)understood
that the retention of the .ip attribute was precisely a convenience to allow
this sort of use. ?If not, then what's it for? ?I've read the PEP and almost
all of this thread, but I can't help feeling I'm still missing something. ?If
someone could point out the obvious to me I'd be grateful.
You're not missing anything that I'm aware of - unlike the use case for
accepting a denormalised network definition in the IPNetwork constructor
(which has been made quite clear in the list discussion, even if it is
still a bit vague in the PEP), the use case for *retaining* the host
information on the network object hasn't been well articulated at all.
The closest anyone has come to describing a use case is an indirect
comment via Guido that leaving out the attribute would involve real code
having to find somewhere else to stash the original address details
(e.g. by passing around an IPAddres/IPNetwork tuple rather than just an
IPNetwork object).
Ah, thanks---I'd missed that bit. ?So the .ip attribute is mainly for
backwards compatibility with existing uses/users of ipaddr. ?I guess
that makes sense, then. ?In particular, if it's suggested that new code
shouldn't make use of the .ip attribute, then the list/dict membership
problems described above can't arise.
I don't know -- this is (from what Peter told me) a common use case so
he (and presumably others) would from time to time have to write
extra code to keep track of that IP address in a new app. Since this
is just one extra attribute on an IPNetwork object I don't think that
adding extra classes which only differ from the IPvXNetwork classes in
having this one extra attribute is worthy.
I don't believe anyone ever suggested adding a class that differed from
IPvXNetwork by the presence or absence of an 'ip' attribute. The two
approaches(*) suggested were:
1) do not add another class, just pass around (IPvXAddress,
IPVXNetwork) tuples when the address needs to be retained (or write
your own tailored trivial class, like I did in my example).
2) add a class that differs from IPvXAddress by having a 'network'
attribute that points (possibly lazily) to an IPvXNetwork object,
and perhaps 'netmask' and 'hostmask' attributes.
Especially after my experience with writing a real example program, I
prefer (1).
--David
(*) For completeness there was also a third approach: add a 'network'
attribute to IPvXAddress that would be None if there were no associated
netmask. Conceptual problems with this were raised which I won't
summarize; IMO it would only be slightly better than IPvXNetwork having an
'.ip' attribute._______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
