I think that what Chris suggests makes a lot of sense (at the very
least most `if NEW_ASSUMPTIONS` code can be contained within the
`is_*`, with a `warning.raise('do not forget to remove')`).Is there any reason that it wont work? I vaguely remember that Ondrej or Mateusz have pointed out some issues with the idea, but I may be remembering incorrectly. On 10 April 2013 11:13, Chris Smith <[email protected]> wrote: > Another thing that could be done is that the `is_foo` methods could be > transformed one at a time, so where is_positive is in any given place in > sympy, the guts of that function could be written to use the new > assumptions. When all `is_foo` have been changed *then* an overhaul of the > syntax in the code base can be made (changing the call from x.is_foo to > ask(x, foo) -- or whatever). That way there won't be branch-breaking changes > in much of the code -- only in single functions that don't get changed very > much. > > > On Wed, Apr 10, 2013 at 2:51 PM, Tom Bachmann <[email protected]> wrote: >> >> Hi, >> >> I'm working on writing a proposal for my GSOC application regarding the >> new assumptions. I will be sending out a couple of emails with specific >> questions / topics for discussion shortly. They will all assume the >> following general strategy for the removal of old assumptions: >> >> There have been numerous previous attempts at stripping out the old >> assumptions system. They failed for different specific reasons, but I think >> there is an underlying principle: each of these attempts tried to do the >> entire work in one go, resulting in a single, huge, unmaintainable branch. >> This is because the assumptions system is used throughout most sympy >> modules. It is complex and brittle, and even trivial-looking changes to it >> can break lots of client code. >> >> I think we have to accept that this "one-shot" approach has failed. Let me >> nonetheless summarize what I think are its main attractions. It is not >> obvious that the new assumptions system can, in its current form, replace >> the old one. (And this was true more so for the attempts which have been >> longer ago, of course.) The best way of proving that this *is* possible is >> to "just do it", and I think this was the intention behind these branches. >> It is also the case that using the new system sometimes requires non-trivial >> changes to client code, so a gradual phasing-out of the old system seemed >> complicated. >> >> Did I miss any valid reasons for the "one-shot" approach? >> >> >> Starting from this premise ("one-shot will not work"), it seems to me that >> there is only one way out: we need to initiate a transition phase, during >> which both assumptions systems can be used (controlled via e.g. a command >> line flag). I believe this is what Ronan has been advocating (in some form >> or another) for a long time. >> >> By default, the old assumptions system will be in place, and everything >> will work as always. If on the other hand the flag is set, then the new >> system is used. This will break almost all of sympy. The next step is to fix >> these failures, *without breaking the system using old assumptions*. This >> will likely require substantial workarounds, and quite possibly even code of >> the form >> >> if NEW_ASSUMPTIONS: >> do stuff >> else: >> do other stuff. >> >> However the point is that these fixes can now be done in distinct pull >> requests, e.g. module by module. (Or even several PRs for one module, e.g. >> series.) Anyone who wishes to help this effort can check that their PRs do >> not increase the number of failures with the new assumptions system. >> >> Eventually, all the tests will pass with both assumption systems, and both >> will perform comparably. At this point we can (if so desired) delete the old >> system and all the workarounds. >> >> Obviously the devil is in the details, but what are the opinions of the >> community regarding this general strategy? >> >> Thanks, >> Tom >> >> -- >> You received this message because you are subscribed to the Google Groups >> "sympy" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at http://groups.google.com/group/sympy?hl=en-US. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/sympy?hl=en-US. > For more options, visit https://groups.google.com/groups/opt_out. > > -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sympy?hl=en-US. For more options, visit https://groups.google.com/groups/opt_out.
