On Tue, Jun 2, 2009 at 1:47 AM, "Martin v. Löwis" <mar...@v.loewis.de> wrote:
>> If this were a core feature that many developers were anxiously >> awaiting, I could understand the desire to release and iterate. But is >> there really a pressing need for an IP library in the stdlib? > > You should have asked this question a few month ago. Now, release > mechanics make it difficult to remove the library, except if a severe > problem was uncovered - which you haven't been able to demonstrate. This argument makes no sense. The feasibility of removing the library does not depend on the severity of the issues found within it. Either it is hard to remove the library, or it is easy. If it's hard to remove, it doesn't get any easier because I discover a fatal flaw. I've actually provided several examples of where the library fails when used in common scenarios, yet your solution involves incremental hacks that don't fix the underlying problems. You write as if you have a vested interest in releasing the library -- why? > I don't believe that your issue "hosts and nets are represented with the > same class" is severe: it is very well possible to use the IP function > to represent individual hosts (including having a string representation > that doesn't print a netmask). The only possibly-missing feature is > support for rejecting host strings that include a mask on parsing; that > can be added in a backwards-compatible way as an optional parameter to > the IP function (as discussed on the tracker). There are other missing features, but again, my concern is not about missing features: it's about a quirky API that conflates concepts in the problem domain, leading to subtle bugs and breaking the principle of least surprise. Clay _______________________________________________ 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
