Normally, eval(repr(object)) should give the object back, but in SymPy
we break this because a repr value would be very long, and
unfortunately, in Python str(list) calls repr() on the list elements.
We do have the srepr() function if you want a repr value:
In [27]: srepr(x**2 + 1)
Out[27]: Add(Pow(Symbol('x'), Integer(2)), Integer(1))
You can imagine that that would become unwieldy fast, and is
undesirable in almost all situations.
And for whatever reason, debuggers like to call repr().
Note that even though SymPy objects do not follow eval(repr(object))
== object in general, we never really run into problems because of it,
as far as I know. I don't think a whole lot of things actually use
this invariant.
On Wed, Jul 6, 2011 at 6:40 PM, Adam Moore <[email protected]> wrote:
> Well, that was it! I thought that __repr__ should be a statement that
> can executed, but I suppose that's not an absolute rule.
>
> Where are these boolean objects located?
sympy/logic/boolalg.py.
Aaron Meurer
>
> Thanks again!
>
> Adam
>
> On Jul 6, 6:41 pm, Aaron Meurer <[email protected]> wrote:
>> You might need to implement __repr__. In SymPy, __repr__ == __str__,
>> so either one will give the printed form of an expression.
>>
>> By the way, SymPy has boolean objects (Or(), And(), etc.), that you
>> might gain inspiration from, or even just be able to use directly.
>>
>> Aaron Meurer
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Jul 6, 2011 at 5:38 PM, Adam Moore <[email protected]> wrote:
>> > I am stepping through the following code:
>>
>> > from sympy.abc import x, y
>>
>> > e = x + y
>>
>> > print e
>>
>> > So once I've stepped through all the wrappers and get to the
>> > __add__(self, other) implementation, and then step through the cacheit
>> > wrapper, I end up in the
>> > __new__ of AssocOp.
>>
>> > Here, when inspecting the variables in scope, right at the beginning
>> > of the __new__, the 'args' variable is a tuple containing x and y. The
>> > 'Variables' part of the debugger shows this: args = {tuple}(x, y)
>>
>> > When I do a similar thing in my own project, and I get to the __new__
>> > of my class after my version of __add__, which looks as follows (it's
>> > called Or because I'm doing boolean algebra):
>>
>> > def __add__(self, other):
>> > return Or(self, other)
>>
>> > So then, since my Or class inherits from the boolExpr class, the
>> > __new__ of boolExpr is called, similar to how Adds are done in Sympy.
>>
>> > However, when I inspect my 'args' variable, it looks like this: args =
>> > {tuple}(<basic_bool.Symbol object at 0x0000000002D2B358>,
>> > <basic_bool.Symbol object at 0x0000000002D2B630>)
>> > Why is this? I have implemented the __str__ for my Symbol class, so
>> > why does it display this way?
>>
>> > Thanks again for the help!
>>
>> > -Adam
>>
>> > On Jul 5, 5:17 pm, Aaron Meurer <[email protected]> wrote:
>> >> Well, the good news is that SymPy will soon work in Python 3 (we've
>> >> got a Google Summer of Code student working on it). He's making good
>> >> progress with it, so it should be supported by our next release or the
>> >> one after that.
>>
>> >> And you can still do "class MyClass(object)" in Python 3, which is
>> >> identical to "class MyClass:" there. So it's good to get into the
>> >> habit of always typing "(object)" after your class definitions even in
>> >> Python 3, so you won't accidentally create an old-style class in
>> >> Python 2 (because unfortunately, you will still have to use Python 2
>> >> from time to time for a while).
>>
>> >> Aaron Meurer
>>
>> >> On Tue, Jul 5, 2011 at 1:19 PM, Adam Moore <[email protected]> wrote:
>> >> > Thanks, the problem actually was that I was using an old-style class
>> >> > instead of new style. I started learning Python with 3.2, so the issue
>> >> > wasn't there and I didn't know to look out for it. Thanks again for
>> >> > the help!
>>
>> >> > Adam
>>
>> >> > On Jul 4, 6:58 pm, Aaron Meurer <[email protected]> wrote:
>> >> >> I think you mised the part where he said "when I create my own Symbol
>> >> >> class," in other words, he is not using SymPy's Symbol in the second
>> >> >> case but his own.
>>
>> >> >> Aaron Meurer
>>
>> >> >> On Mon, Jul 4, 2011 at 12:42 PM, Mateusz Paprocki <[email protected]>
>> >> >> wrote:
>> >> >> > Hi,
>>
>> >> >> > On 4 July 2011 20:33, Adam Moore <[email protected]> wrote:
>>
>> >> >> >> So when I import x from sympy.abc, and then check its 'type', its
>> >> >> >> type
>> >> >> >> is <class 'sympy.core.symbol.Symbol'>
>>
>> >> >> >> What makes this so? In a project I'm working on, I'm trying to learn
>> >> >> >> some lessons from sympy as to how variables and such are handled,
>> >> >> >> but
>> >> >> >> when I create my own Symbol class and execute
>>
>> >> >> >> x = Symbol('x')
>>
>> >> >> >> and then check the type, its type is <type 'instance'>
>>
>> >> >> >> What is the nature of a Symbol in sympy then if it is not also an
>> >> >> >> instance of a class?
>>
>> >> >> > Can you show a complete code sample? I get the following:
>> >> >> > $ ipython
>> >> >> > In [1]: from sympy import *
>> >> >> > In [2]: x = Symbol('x')
>> >> >> > In [3]: type(x)
>> >> >> > Out[3]: <class 'sympy.core.symbol.Symbol'>
>> >> >> > In [4]: del x
>> >> >> > In [5]: from sympy.abc import x
>> >> >> > In [6]: type(x)
>> >> >> > Out[6]: <class 'sympy.core.symbol.Symbol'>
>> >> >> > The abc module just uses Symbol():
>> >> >> > In [7]: from sympy import abc
>> >> >> > In [8]: abc??
>> >> >> > Type: module
>> >> >> > Base Class: <type 'module'>
>> >> >> > String Form: <module 'sympy.abc' from 'sympy/abc.pyc'>
>> >> >> > Namespace: Interactive
>> >> >> > File: /home/matt/repo/git/sympy/sympy/abc.py
>> >> >> > Source:
>> >> >> > from core import Symbol
>> >> >> > _latin = list('abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ')
>> >> >> > # COSINEQ should not be imported as they clash; gamma, pi and zeta
>> >> >> > clash,
>> >> >> > too
>> >> >> > _greek = 'alpha beta gamma delta epsilon zeta eta theta iota kappa '\
>> >> >> > 'mu nu xi omicron pi rho sigma tau upsilon phi chi psi
>> >> >> > omega'.split(' ')
>> >> >> > for _s in _latin + _greek:
>> >> >> > exec "%s = Symbol('%s')" % (_s, _s)
>> >> >> > del _latin, _greek, _s
>> >> >> > But anyway, in both cases x is an instance of Symbol class.
>>
>> >> >> >> -Adam
>>
>> >> >> >> --
>> >> >> >> 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.
>>
>> >> >> > Mateusz
>>
>> >> >> > --
>> >> >> > 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
>> >> > athttp://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
>> > athttp://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.
>
>
--
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.