Oh well, now that I'm looking more closely at the core's structure, 
patching what 
I wanted to initially patch makes less sense. One of the problems is that 
the operators
(AssocOp or LatticeOp) subclass Expr, and that Expr is really meant for 
other things than
logical propositions.

I guess my initial boolean simplify() will be delayed as I'm thinking about 
sympy.core
related issues now.

On Saturday, July 28, 2012 1:07:13 AM UTC-7, Alex wrote:
>
>
> > There are some discrepancies between the two classes, and I'm not 
>> exactly 
>> > sure why. 
>> > 
>> > - AssocOp sympifies arguments in strict mode via _sympify (which is 
>> > anyway just a proxy for sympify(., strict=True) -- is it reasonable to 
>> have 
>> > a separate function 
>> > for doing just this?). Anyway, this is an issue when dealing with 
>> booleans: 
>> > Xor(True, A) breaks as booleans are obviously not converted. LatticeOp 
>> uses 
>> > sympify. 
>>
>> Booleans won't be converted with anything, as we don't have Basic 
>> boolean literal types. 
>>
>
> I'm totally fine with that. I'm just arguing that AssocOp should use 
> simplify instead of _symplify,
> and that _symplify might need to go away.
>  
>
>>
>> > 
>> > - AssocOp: the is_commutative attribute is overridden by the 
>> combination 
>> > __new__()+flatten(). 
>> > Both should probably be rewritten to take commutativity (or not) into 
>> > account, this should be fully backward 
>> > compatible, and provide more functionality for virtually nothing. 
>> > This does not happen in LatticeOp() as _new_args_filter rightfully 
>> assumes 
>> > commutativity and does flatten()'s job. Notice that LatticeOp derives 
>> from 
>> > AssocOp, and provides 
>> > as such its flatten() method. Needs refactoring? 
>>
>
> I think we are on the same ground. I'm just seeing unnecessary 
> code/functionality
> duplication and weird inconsistencies.
>  
>
>>
>> By the way, in case you haven't already started to figure it out, the 
>> class structure here is not set in stone, or in any way claimed to be 
>> the best (this actually goes for most features in SymPy).  If you see 
>> a problem and you think you can do it better, by all means, try it. 
>> Our test suite will give you a good idea of if you're breaking 
>> something or not. 
>>
>
> Alright, let me submit a patch :)
>  
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/sympy/-/myez6wrA8d0J.
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.

Reply via email to