Comment #5 on issue 2086 by nicolas.pourcelot: SympifyError should be more
explicit
http://code.google.com/p/sympy/issues/detail?id=2086
"When things get pushed in so quickly there's no time for feedback."
From http://code.google.com/p/sympy/wiki/SympyDevelopment:
"We have just two rules:
* All code that goes to SymPy needs to be reviewed by at least one
other developer.
* All the tests need to pass.
[...]
If you want to find more about this kind of attitude, google the
phrase "extreme programming"
I think this really encourage people to join (at least, this was the
decisive argument for me).
At the opposite, I think long discussions on minor patches will discourage
most people to participate.
To speak frankly, if I didn't post some small-and-quickly-accepted patches
before, I would have give up for a long time in issue 1694...
I think that as long as a patch:
- does not broke anything
- provide an improvement
it should be accepted, even if not perfect.
If patching is easy, it's also easy to improve it later.
I think that's this sort of collaborative working rules that makes sympy
development so dynamic. :)
" Is there a reason to show what it eventually got translated to instead of
the original expression? e.g. x***2 vs x^*2?"
I have no access to the original string in parse_expr().
Of course, feel free to add an "original_string" argument in parse_expr()
if you want and to modify other code accordingly.
Personally, I think both behaviors are acceptable. (And in the docstring
test, I deliberately didn't rely on a specific one).
--
You received this message because you are subscribed to the Google Groups
"sympy-patches" group.
To post to this group, send email to sympy-patc...@googlegroups.com.
To unsubscribe from this group, send email to
sympy-patches+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sympy-patches?hl=en.
