> I have mixed feelings. It is great that the batteries are included, but > some batteries are showing their age or not maintained (who maintains > IDLE? - does the calendar module really warrant being in the standard > library? - imaplib is really not useful and IMAPClient which isn't in > the standard library is much better [1]).
I certainly agree that little-used modules should be removed (by means of a proper deprecation procedure). I do think it is fairly important that IDLE remains included (whether or not gpolo takes ownership of it). As for imaplib: I can't comment on the library itself, since I never use it. However, given the number of bug reports that we receive, it seems there is a fairly significant followership of it. > If a library is well maintained then there seems to be little point in > moving it into the standard library as it may actually be harder to > maintain It depends. For quickly evolving libraries, it might be harder to maintain them in the core, as you can't release as quickly as you desire. In other cases, it simplifies maintenance: whenever a systematic API change is added, all standard library modules get typically updated by whoever makes the systematic change. That is more productive than having each individual maintainer to figure out what to change in response. However, I don't think of the maintainer point of view that much: it's rather the end users (i.e. application developers) who I worry about: Should we remove regular expressions from Python, just because the library doing it is unmaintained? > On the other hand there are some standard tools that a significant > portion of the community use (Python Imaging Library and the PyWin32 > extensions for example) that aren't in the standard library. I continue having the same position: if the authors of those respective libraries would like to contribute it to the core (and eventually drop the out-of-core fork), then I would be happy to let them do that. Of course, Guido's cautioning wrt. external libraries that those depend on still applies: if there are strong external dependencies, the library would have to be really important to the community to still include it. > I think other developers have similar mixed feelings, or at least there > are enough people on both sides of the fence that it is very hard to > make changes. Perhaps this is the way it should be. I think so, yes. Decisions will be made on a case-by-case basis, going either direction one time or the other. 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
