Summer of Code is ramping up. Every year the common complaint is that not enough Python core projects get proposed by students, and of course a big reason for that is often the only encouragement we offer prospective students is a link to the PEP index.
The challenge is finding project ideas for them that could reasonably occupy them for the entire Summer and which the results of their work can be demonstrated. They're being paid for specific projects so "Spend the Summer fixing bugs on the tracker" is a no-go, and Google has outlined that Summer of Code is about code, not documentation.
Improve doctest by allowing it to be aware of nested test scopes such that a variable defined at "class-level scope" (i.e. the variable b defined at the class-level doctest """>>> b=Bag("abacab")""") can be used in "method-level scopes" without re-defining it every time for each method's doctest (each method would reset the given variable (if used) to its original state rather than live mutated between equal-level scopes). Would be a great improvement for doctest in my opinion--both in ease-of-use, and reduction of redundant, error-prone ("did you define your test variable the same in each method?") code)--as well as other benefits. Appreciate any consideration... marcos
On Fri, Mar 20, 2009 at 03:18:00PM -0700, average wrote: -> > Summer of Code is ramping up. ?Every year the common complaint is that not -> > enough Python core projects get proposed by students, and of course a big -> > reason for that is often the only encouragement we offer prospective -> > students is a link to the PEP index. -> > -> > The challenge is finding project ideas for them that could reasonably occupy -> > them for the entire Summer and which the results of their work can be -> > demonstrated. ?They're being paid for specific projects so "Spend the Summer -> > fixing bugs on the tracker" is a no-go, and Google has outlined that Summer -> > of Code is about code, not documentation. -> -> Improve doctest by allowing it to be aware of nested test scopes such -> that a variable defined at "class-level scope" (i.e. the variable b -> defined at the class-level doctest """>>> b=Bag("abacab")""") can be -> used in "method-level scopes" without re-defining it every time for -> each method's doctest (each method would reset the given variable (if -> used) to its original state rather than live mutated between -> equal-level scopes). -> -> Would be a great improvement for doctest in my opinion--both in -> ease-of-use, and reduction of redundant, error-prone ("did you define -> your test variable the same in each method?") code)--as well as other -> benefits. -> -> Appreciate any consideration... Hi Marcos, my primary concern here would be that the student would do all this work and then python-dev would reject it for incorporation into core! Plus it's probably not a summer-long project. If, however, you wanted to suggest a general "gather disparate doctest features and integrate them, for consideration for the core" project, I would definitely recommend posting that as a possible project on the Python GSoC site. I know that zope has done some good doctest stuff, for example; the 'testing-in-python' list would be a good place to go for finding out more. Note, you don't have to offer to be the mentor to post it, but it would help ;) cheers, --titus -- C. Titus Brown, ctb@msu.edu
participants (2)
-
average -
C. Titus Brown