On Fri, Mar 30, 2012 at 3:07 AM, Sergiu Ivanov <[email protected]> wrote: > On Fri, Mar 30, 2012 at 4:59 AM, Ronan Lamy <[email protected]> wrote: >> >> This looks like it'll be a solid proposal. In particular, you do a good >> job of summarising the feasibility of your project, its evaluation >> criteria and the benefits it would bring. However, some points >> (particularly the section "Infrastructure setup") could be made more >> concrete if you wrote some doctest-ish pseudocode. Bonus points if the >> code actually works. > > Thank you for your feedback! > > I will throw down some pseudo-code in a couple of days. > >>> As a way to better structure the code, I propose a (partial) >> transition to object-oriented design. >> >> Yay! +10. > > Cool :-) > >>> I suggest defining a very basic class Operation which will initially >> contain one method with two arguments, which will perform the operation >> itself. >> >> I suspect that having to use the object in order to perform the >> operation would be cumbersome, so it might be more fruitful to consider >> Operation as a description of the operation, instead of as the operation >> itself. > > This is exactly the point of Operation: it will eventually store the > information about the operation *and* will be able to actually perform > the operation on two elements. The problem is that implementing a > full fledged Operation is beyond the scope of my project, so I am only > going to set up a very basic form of it. Eventually, when someone > (maybe myself even, but later) gets to work on base classes for > abstract algebraic structures, it will be possible to easily migrate > the existing Groebner code base to the proper structures. > >>> I will start by defining the function nextPoint() >> >> "nextPoint" isn't PEP8-compliant. It should be "next_point". > > Oh, sorry, habits :-( Fixed. > >>> July 9 - July 15: start merging the changes upstream; start working on >> the documentation; >> >> That's rather late. Any pull request with more than ~10 commits is >> painful to review. A pull request at that stage is likely to contain a >> few dozen commits, so you'd be lucky if it got merged before the end of >> August. You should endeavour to send pull requests as soon as you have a >> consistent and well-tested piece of functionality. > > I actually had this thought while writing the proposal, but wasn't > sure about it. For me, pushing things upstream in small chunks feels > much more comfortable; it's good news that the developers are also > comfortable with strategy. > > Fixed the proposal by removing explicit statements about merging in > the timeline and adding a proposition about pushing things in small > chunks after the timeline. > > Sergiu
I've written another mail to this list about this. We need to really focus on merging things early and often this summer. Aaron Meurer -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
