On Sun, Sep 27, 2009 at 12:40 PM, James Y Knight <f...@fuhm.net> wrote:
>
> On Sep 27, 2009, at 3:18 PM, Peter Moody wrote:
>
>> administrators) would use it, but it's doable. what you're claiming is
>> that my use case is invalid.
>>
>> that's what I claim is broken.
>
> He's claiming your solution to address your use case is confusing, not that
> the use case is invalid.
this isn't actually true.
Steven D'Aprano wrote:
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?
that pretty flatly states that my use case is invalid.
>> I'm not going to make ipaddr
>> less useful (strictly removing functionality), more bulky and
>> confusing (adding more confusingly named classes and methods) or
>> otherwise break the library in a vain attempt to have it included in
>> the stdlib.
>
> If I understand correctly, the proposal for addressing the issue is to make
> two rather simple changes:
i wish it were this easy.
> 1) if strict=False, mask off the bits described by the netmask when creating
> an IPNetwork, such that the host bits are always 0.
I haven't heard anyone suggest auto-masking bits, but otherwise that
would be strict=True.
> 2) add a single new function:
>
> def parse_net_and_addr(s):
> return (IPNetwork(s), IPAddress(s.split('/')[0]))
I've only heard talk of new classes and new methods, not new
constructor functions. In fact, when I asked for explicit
clarification of what was required, a new constructor function "ala
IPAddress and IPNetwork (so the current classes remain largely the
same and the various constructors enforce certain restrictions)", I
was told, no, a new object AddressWithMask was actually required. I've
no problem with a constructor like this, but this is not what people
have been asking for.
Cheers,
/peter
> James
>
_______________________________________________
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
