[Python-Dev] Google Summer of Code/core Python projects - RFC

["Martin v. Löwis"]

Tarek Ziadé wrote:
>> -> I'm also skeptical that this is a good SoC project in the first place.
> 
> What is a good SoC project from your point of view ?

As a core project - tricky. Implement some long-standing complex feature
request, or fix a pile of outstanding bug reports for a module (like
the IDLE proposal). I liked the outcome of last year's "memory
profiling" project: the student added sys.getsizeof (with much of
mentoring on my side), and created a profiling library and application
that wasn't added to the core. The latter part is a biased outcome
(as I originally hoped to get something that becomes part of the
standard library - but gave up on this quickly as way too much design
went into that library); the useful core contribution (getsizeof) took
considerable amount of learning, and still had a few tricky design
issues to resolve.

In short, there must be a realistic chance that the code gets actually
used. Chances for a from-scratch library to be used are nearly zero, so
from-scratch libraries are not good projects.

In case you wonder why I give it nearly zero chance: I keep telling
long-term contributors that libraries have to be field-tested before
being considered for inclusion, and sometimes, even field-testing is
not enough (think setuptools). If SoC students get to short-cut the
process, that would send a wrong message to contributors and users.

> Part of the work will consist of working on a PEP-like document, and on
> building APIs for various keychains and see if we can have an unified one.
> I doubt the PEP-like document can be written before writing prototypes APIs
> for various keychains has been done.

That's certainly true. That's why I think it is a much larger project:
- write different wrappers
- come up with a unifying API
- field-test it for actual applications
- write a PEP

This could easily take a few years to get right (unless the actual
authors of the various keychain implementations get together, define
a common C API, which then a Python module just needs to wrap).

> At the end of the summer, if we come up with a nice unified API, I'd
> like to include
> it to Distutils for the "register" command, and maybe write a PEP to have it
> as part of the standard library because it makes sense to have this kind
> of feature imho.

I completely agree that this is a useful functionality to have, and I
also agree it *eventually* belongs into the standard library.

I just don't like the idea of bypassing the proper process by making
it part of distutils. This model (I need it, so I add it) made both
distutils and setuptools so unmaintainable.

Regards,
Martin