Author oubiwann
Recipients benjamin.peterson, drkjam, exarkun, giampaolo.rodola, gvanrossum, loewis, mattsmart, oubiwann, pmoody, shields
Date 2009-01-03.18:03:21
SpamBayes Score 0.000232385
Marked as misclassified No
Message-id <1231005803.66.0.454539375867.issue3959@psf.upfronthosting.co.za>
In-reply-to
Content
I am a contributor to netaddr, having deprecated my own old and crufty 
IP address library in its favor. JP's comments on the library in this 
ticket are included in the set of reasons that I initially chose it to 
replace my own.

When I first looked at the ipaddr code a month ago, the features I was 
delighted to see in the ipaddr project include address exclusion and 
address collapsing (we'd been discussing these features in netaddr since 
my old project had similar functionality).

Perhaps the following might be a prudent course:
 * determine how small or big a standard library ip address module or 
subpackage should be;
 * have a mutual discussion on the netaddr and ipaddr mail lists to 
determine what would need to be changed in each project in order to 
support inclusion in the standard lib;
 * choose the option that requires the least code changes (simple naming 
convention changes should probably be given less weight than any changes 
to logic).

As for shutting down any project that is chosen, does such an action not 
leave older Python versions out in the cold? Shouldn't the project 
remain open to support Python versions < 2.7, with a highly visible note 
that the code is included in 2.7/3.1+? (I am completely ignorant of 
related Python development policy.)
History
Date User Action Args
2009-01-03 18:03:23oubiwannsetrecipients: + oubiwann, gvanrossum, loewis, exarkun, giampaolo.rodola, benjamin.peterson, mattsmart, shields, pmoody, drkjam
2009-01-03 18:03:23oubiwannsetmessageid: <1231005803.66.0.454539375867.issue3959@psf.upfronthosting.co.za>
2009-01-03 18:03:23oubiwannlinkissue3959 messages
2009-01-03 18:03:21oubiwanncreate