So are you suggesting that S(list) shouldn't work then (or else return a Tuple
or whatever)? As for the difference between coercion and conversion, aren't
they normally the same in Python anyway? For example, int(3), int(3.0), and
int('3') all return 3.
Aaron Meurer
On Dec 7, 2010, at 5:24 PM, Ronan Lamy wrote:
> Le lundi 06 décembre 2010 à 13:05 -0800, Ondrej Certik a écrit :
>> On Mon, Dec 6, 2010 at 11:29 AM, smichr <[email protected]> wrote:
>>>> The similarity between "simpify" and "simplify" is misleading.
>>>
>>> Yes, that would be...but it's SYMpify not SIMpify. But yes, they are
>>> close. I (as has been pointed out) almost exclusively use S() and so
>>> it's not a problem. Would there be any reason not to delete sympify
>>> from the namespace and just provide S() as the standard conversion
>>> call name?
>>
>> It seems like a good plan if everybody agrees. I believe S is some
>> other global object, so it should be renamed and S should be a
>> function. sympify() should return a deprecated warning for some time,
>> before we remove it.
>
> I don't really have an opinion on the naming issue, but it seems
> relevant to mention an insight I've had while trying to implement
> generic functions and to refactor sympify() as such a generic function
> (see http://github.com/rlamy/sympy/tree/generic ).
>
> So, the idea is that sympify(), as currently implemented, mixes two
> distinct concepts: coercion and conversion. The difference between the
> two can be hard to grasp but it corresponds quite well to the difference
> between the internal-use function _sympify() and plain sympify().
>
> Coercion is the transformation of an object that is already conceptually
> a sympy object into an actual sympy object, for example the
> transformation of a Python int into a sympy Integer. End users are only
> meant to use it implicitly, usually by using binary operators. For
> instance, in the expression 'Integer(1)/3', the int instance '3' is
> coerced to 'Integer(3)'.
>
> Conversion, on the other hand, is an explicit request to take any object
> and return a sympy object. For instance, in 'S("1/3")', the string "1/3"
> is converted to 'Rational(1, 3)'.
>
> If we want a consistent and easily explainable system, I think that the
> two concepts should be clearly separated and that the result of both
> should only ever be a sympy object (i.e. an instance of Basic).
>
> --
> 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.
>
--
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.
