Updates:
Summary: Add __xor__ magic method to Boolean
Labels: -Type-Defect -PassedReview Type-Enhancement NeedsReview
Comment #11 on issue 1928 by ronan.l...@gmail.com: Add __xor__ magic method
to Boolean
http://code.google.com/p/sympy/issues/detail?id=1928
'1928-reviewed' is
Do all tests (including the code quality) work for you? If so, we need
to improve this.
You said without the first commit. Do you mean without the latest
commit? In any case, all solvers.py tests pass in all commits. The
equal() can be used too make these pass on 32 or 64 bit systems if
ti., 11.05.2010 kl. 02.36 -0700, skrev smichr:
As I already said, it would be much easier if you could create another
branch for review (1766-for-review) which contains only stable changes.
This would help to get it in faster.
The commits before 1766-- are stable. I
In the meanwhile, I've used Øyvind's hint to create branches numbered
as to commit number for all the commits in review and pushed them to
github. In cases where there are additions (like 1725a 1725b 1725c,
those are all in branch 1725).
ff50ca5 1936: Integral and Sum edits
c2a77c6 1919: unify
As we run into problem where a workaround is necessary, it would be
good to have a way to be able to mark the code so that when the
problem is fixed we can update the code.
e.g. in issue 1934 is raised the issue of Function not having a
.is_number property. This means that code that is interested
On 10 Mai, 21:19, Ondrej Certik ond...@certik.cz wrote:
On Mon, May 10, 2010 at 12:08 PM, Christian Muise
christian.mu...@gmail.com wrote:
Yowzas...
- Why the changes from self.new(...) to self.__class__(...)? (it happens
in a number of places)
Good point --- I removed .new(), as it
On 11 Mai, 08:03, smichr smi...@gmail.com wrote:
As we run into problem where a workaround is necessary, it would be
good to have a way to be able to mark the code so that when the
problem is fixed we can update the code.
e.g. in issue 1934 is raised the issue of Function not having a
Another variant would be to use xfailed tests for this.
Vinzent
On 11 Mai, 08:03, smichr smi...@gmail.com wrote:
As we run into problem where a workaround is necessary, it would be
good to have a way to be able to mark the code so that when the
problem is fixed we can update the code.
e.g.
Nice idea.
The problem I see with this is that the code inside that else: block
can't be tested until that feature is fixed, which makes it pointless to
include it.
I think it would be better to always use the workaround (and maybe
document a better approach via comments), and have broken() just
On May 11, 2010, at 4:32 AM, Felix Kaiser wrote:
Nice idea.
The problem I see with this is that the code inside that else: block
can't be tested until that feature is fixed, which makes it pointless to
include it.
I think it would be better to always use the workaround (and maybe
On 05/11/2010 05:42 PM, Aaron S. Meurer wrote:
On May 11, 2010, at 4:32 AM, Felix Kaiser wrote:
Nice idea.
The problem I see with this is that the code inside that else: block
can't be tested until that feature is fixed, which makes it pointless to
include it.
I think it would be
11 matches
Mail list logo
