[Python-Dev] Integrate BeautifulSoup into stdlib?

"Martin v. Löwis" martin at v.loewis.de
Sun Mar 8 15:31:32 CET 2009


> 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


More information about the Python-Dev mailing list