Re: [python-control-discuss] __repr__

[Ryan K. <rk...@si...>]

I guess we are already following the scipy.signal.ltisys convention:

In [4]: test = signal.lti([1,2,3],[1,4,5,6,7])

In [5]: test
Out[5]: <scipy.signal.ltisys.lti at 0x1129c5510>

In [6]: test.num
Out[6]: array([ 1.,  2.,  3.])

In [7]: test.den
Out[7]: array([ 1.,  4.,  5.,  6.,  7.])

We are even a step ahead of them in user friendliness:

In [8]: print test
<scipy.signal.ltisys.lti object at 0x1129c5510>


That just doesn't seem user friendly to me.

--
Ryan Krauss, Ph.D.
Associate Professor
Mechanical Engineering
Southern Illinois University Edwardsville


On Tue, Jun 11, 2013 at 9:26 PM, Ryan Krauss <rk...@si...> wrote:

> > __repr__ is ideally for printing a representation that can directly be
> fed back into Python to > re-create the object.
>
> I guess I didn't realize this convention.  Like you said, I don't think it
> is typically followed.  When I want to look at a variable at the IPython
> prompt, I am not used to having to type print in front of it.
>
>
> --
> Ryan Krauss, Ph.D.
> Associate Professor
> Mechanical Engineering
> Southern Illinois University Edwardsville
>
>
> On Tue, Jun 11, 2013 at 2:37 PM, Rene van Paassen <
> ren...@gm...> wrote:
>
>> __str__ is for pretty printing
>> __repr__ is ideally for printing a representation that can directly be
>> fed back into Python to re-create the object. Many objects don't implement
>> that, though, it is basically limited to the standard Python objects.
>>
>>
>> On 10 June 2013 17:53, Ryan Krauss <rk...@si...> wrote:
>>
>>> I probably won't get to this one for a few weeks (I have a conference
>>> and another paper coming up), but I would like to contribute a __repr__
>>> method for TransferFunctions if it would be welcome.  I personally would
>>> prefer that when I type the name of a TransferFunction instance and hit
>>> enter that it pretty print an ascii numerator and denominator and a
>>> horizontal line.  It might be tricky to do it really nicely with exponents,
>>> but this is what happend now:
>>>
>>> In [2]: G = control.TransferFunction(1,[1,2])
>>>
>>> In [3]: G
>>> Out[3]: <control.xferfcn.TransferFunction instance at 0x10e94cf80>
>>>
>>> I then have to ask ro G.num and G.den separately, which I personally
>>> don't like.
>>>
>>> I see that there is a __str__ method which pretty much does what I would
>>> want, so that "print G" gives me an ascii representation.
>>>
>>> Is there any reason not to have __repr__ simply call __str__?  Is there
>>> some historical reason to have one and not the other?
>>>
>>> --
>>> Ryan Krauss, Ph.D.
>>> Associate Professor
>>> Mechanical Engineering
>>> Southern Illinois University Edwardsville
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> How ServiceNow helps IT people transform IT departments:
>>> 1. A cloud service to automate IT design, transition and operations
>>> 2. Dashboards that offer high-level views of enterprise services
>>> 3. A single system of record for all IT processes
>>> http://p.sf.net/sfu/servicenow-d2d-j
>>> _______________________________________________
>>> python-control-discuss mailing list
>>> pyt...@li...
>>> https://lists.sourceforge.net/lists/listinfo/python-control-discuss
>>>
>>>
>>
>>
>> --
>> René van Paassen        | ______o____/_|     Ren...@gm...
>>                        <[___\_\_-----<               t: +31 15 2628685
>>                         |  o'                   mobile: +31 6 39846891
>>
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Windows:
>>
>> Build for Windows Store.
>>
>> http://p.sf.net/sfu/windows-dev2dev
>>
>> _______________________________________________
>> python-control-discuss mailing list
>> pyt...@li...
>> https://lists.sourceforge.net/lists/listinfo/python-control-discuss
>>
>>
>