Re: [PyGiNaC-users] Python lists of GiNaC objects?

[Jonathan B. <jbr...@ea...>]

On Sat, 2005-09-17 at 23:26 +0200, Richard B. Kreckel wrote:

> > This is because 'l' is actually a Python list, it isn't a GiNaC::exlist
> > (sp?) pretending to be a Python list.  The python list's __str__ method
> > (invoked by the print statement) annoyingly invokes the __repr__ method
> > of its containees rather than __str__.
> 
> Let me try to understand: Is this a feature?

I can only guess that some Python developers think it is a feature.  The
language has a general trend of simplicity and ease of use, but
controversies like this exist.

> >                                        __repr__ isn't defined by
> > PyGiNaC's classes, so you get the default behavior: the address of the
> > wrapping PyObject.
> 
> Why not define it?

Because repr(x) is supposed to return a string that can be used to
re-create x.
"repr(...)
    repr(object) -> string

    Return the canonical string representation of the object.
    For most object types, eval(repr(object)) == object."

So, the correct behavior of, "repr(numeric(1, 2))" would be to return
the string "numeric(1,2)", not "1/2" or "1.0/2.0".  I haven't written
the code that would provide this behavior.

> >                     There are (at least) two workarounds.
> [...]
> 
> Both workarounds appear cumbersome to me.

You can modify the definition of the basic class by inserting the
relevant code in site-packages/ginac/__init__.py and it will apply to
all of your programs.

HTH,
-Jonathan