[Python-Dev] PEP 3144 review.
peter at hda3.com
Sun Sep 27 19:53:27 CEST 2009
On Sun, Sep 27, 2009 at 10:30 AM, Steven D'Aprano <steve at pearwood.info> wrote:
> On Mon, 28 Sep 2009 02:47:27 am Peter Moody wrote:
>> > There was a proposal to have a separate parse_address_and_mask
>> > method which would return a (Address, Network) tuple, I still don't
>> > know why you don't seem to consider it seriously, rather than
>> > trying to make the Network class a kind of all-in-one type
>> > conflating different concepts.
>> The reason (aside from the name) that I'm not going to include this
>> in ipaddr is that it would require the user to deal with two objects
>> when one would suffice. It's similar to getting two return values
>> from float().
>> integer, fraction = float('1.25')
>> crazy, right?
> Not if you want a separate integer and fraction object. There are plenty
> of use-cases for such things, and the math module includes a function,
> modf(), that does precisely that..
>> Finally, to Stephen's point about seeing the other side of the
>> argument, I wrote this offlist a week ago:
>> I *understand* what you're saying, I *understand* that
>> 192.168.1.1/24 isn't a network,
> But you still want to treat it as one.
> Could you explain what benefit there is for allowing the user to create
> network objects that don't represent networks? Is there a use-case
> where these networks-that-aren't-networks are something other than a
> typo? Under what circumstances would I want to specify a network as
> 192.168.1.1/24 instead of 192.168.1.0/24?
this is pretty ridiculous. if in the last two months you haven't seen
a single use case, then you haven't been paying attention.
> Steven D'Aprano
> Python-Dev mailing list
> Python-Dev at python.org
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-dev%40hda3.com
More information about the Python-Dev