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 _______________________________________________ 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
