> 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.
We could remove it, but then what we have wouldn't really be a release candidate anymore, so the release would get delayed. > 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 have a vested interest in releasing Python 3.1, and in sticking to decisions that have been made by other committers. I trust these fellow committers, so I defend their decisions. I personally have no plans for using this library, or any other IP address library (at least not in any application I plan to write soon). At the moment, I'm struggling more with IP address libraries in Perl. > 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. I believe the API appears more quirky to you than it actually is, probably because you don't have understood it fully (but I might be wrong with that, and there might be a different reason). Regards, Martin _______________________________________________ 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
