[Python-Dev] Google Summer of Code/core Python projects (original) (raw)

"Martin v. Löwis" martin at v.loewis.de
Sun Apr 12 00:36:39 CEST 2009

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:

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

More information about the Python-Dev mailing list