[reportlab-users] Many __repr__() methods are really __str__ methods

[Norman Shelley]

Sorry for the delay. I didn't realize my message had been posted to the group. I
had group messages disabled and I received a message saying someone had to
approve my message and I thought it said I would be notified on approval. I then
got busy ...

Anyway, I don't know how much more detailed I can be about my application other
than this. I create pdf plots from xmgrace, cut the "appropriate" guts out and
place one or more of them them on a reportlab canvas, ... according to some
formatting instructions in an input file.  Each page has some header/footer
text. Some pages may be just text and no plots.

I have another application that reads embedded dictionaries that a user can
build up to describe where pdf files are at, which ones to use and place on
which pages, etc.  Building these dictionaries by hand is VERY tedious. So I
thought, why not just have the application that created the plots and placed
them in a pdf file created a python program showing exactly how it was built.
Then the end user can go in and remove plots, place them on different pages,
etc. Essentially use what an automated program built as a starting point for
more refinement.


Below is an example which just happened to work fine with standard reportlab.
But then I added in the ability to build Tables, paragraphs, etc.   When it came
time to dump a pythonic representation of these reportlab objects is when I
realized that __repr__() methods were not actually dumping python executable
code into my autogenerated python code. So for these I went in and made
__repr__()  "work". Some were easy but some were complicated so I just made them
work for my simple cases.

./lib/styles.py  PropertySet
./platypus/flowables.py  KeepTogether
./platypus/paragraph.py   Paragraph
./platypus/tables.py  Table

Norman


This is a portion of an autogenerated python program.  This example does not
call Spacer, Table, ... but it could if so instructed.

#!/usr/bin/env python2.1
import os
from mot_ddl_wssg.PDFDocument import package_xmgrace_pdf_files
from reportlab.platypus import KeepTogether, Paragraph, Spacer, Table
from reportlab.lib.styles import ParagraphStyle

pdffile = "abc.pdf"
globals = {
  'author': '10076639',
...
}

pages = {
  'mos': {
      'large': {
          'id': {
              'left_side_footer': 'Wafer 1919, 23',
              'pages': [
                  [
                      './Plots/mos:large:ids:1:id_vs_vg.pdf',
                   ],
              ],
              'subtitle': 'Dut: large       Test: id',
            },
...
}


package_xmgrace_pdf_files(pdffile, globals, pages)


>From Andy Robinson  13FEB2003
-----------------------------------------------
> >__str(self) methods.   __repr__(self) methods should output a
> string that Python
> >can interpret and these only output strings which a human can
> interpret and
> >Python crashes on their output with syntax errors.

You are probably right about what we 'should have done'
but we already did it :-)

Are you asking for all classes in our framework
to be perfectly reproducible through a repr-and-eval
round trip?


Can you be more detailed about what you want to do?
I'd contemplate a global change now if (a) there was a good
reason likely to be useful to several people, (b)
it won't break any real world apps. Otherwise it's
a good guideline to have for "ReportLab 2.0" where
we can break old code...

- Andy


In article <3E4AA11A.2E42668D@email.sps.mot.com>, Norman Shelley
<Norman_Shelley-RRDN60@email.sps.mot.com> writes
>I have an application that dumps a description of how it built a pdf file so
>that one can slightly modify that description and rerun the application to get
a
>new pdf file.
>
>I just noticed today that when a reportlab Table instance is used that my
>generated script fails. I looked into it and determined that the def
>__repr__(self) methods for at least the following are really more like def
>__str(self) methods.   __repr__(self) methods should output a string that
Python
>can interpret and these only output strings which a human can interpret and
>Python crashes on their output with syntax errors.
>
>
>./lib/styles.py  PropertySet
>./platypus/flowables.py  KeepTogether
>./platypus/paragraph.py   Paragraph
>./platypus/tables.py  Table