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.