[Biopython-dev] [Bug 2711] GenomeDiagram.py: write() and write_to_string() are inefficient and don't check inputs

[bugzilla-daemon at portal.open-bio.org]

http://bugzilla.open-bio.org/show_bug.cgi?id=2711





------- Comment #14 from bsouthey at gmail.com  2008-12-23 05:18 EST -------
(In reply to comment #12)
> (In reply to comment #9)
> > (In reply to comment #3)
> > > As an aside, I'd like write_to_string() to support a DPI argument like
> > > write() does.
> > 
> > The way I originally intended write_to_string() to be used - sending graphics
> > to a browser - the DPI has no influence at all.  DPI is only of any importance
> > for printing graphics ...
> 
> OK, so its less useful than I had expected.  Rending bitmaps to strings so they
> can be inserted into a database as blobs is one potential use-case.  Also for a
> web-service where you expect the user to save and print the naked image
> (unusual, and probably software dependent on how the DPI is treated).
> 

Surely it is important because a user can write to a string and then save the
string to a file rather than using write() a second time. 

What do these options do?
bg, configPIL, showBoundary

> > In that case, I think that an appropriate merging of the write() and
> > write_to_string() methods could be:
> > 
> > def write(self, filename=None, output=default_output, dpi=default_dpi,
> > encoding=default_encoding):
> > 
> > encoding could then be either 'binary' (default), or 'string' - which would
> > emulate write_to_string()'s function.
> > 
> > Where handle is not None, the resulting output would be sent to the passed
> > handle - which could potentially include sys.stdout.  Where handle is None,
> > the method could return the encoded image directly, as write_to_string()
> > does, now.
> > 
> > Other than the obvious problem with ReportLab's drawToFile requiring a
> > filename, rather than a handle - does this seem like a reasonable plan to
> > others?
> 
> On the plus side, this would be backwards compatible (and we could deprecate
> the draw_to_string function).
> 
> However, I'm not so keen on this style personally - the return value is
> radically different depending on the arguments (nothing, or a string of data).
> 
> If we were designing this from scratch, I would have suggested one write
> function which wrote to a handle - which would let you then write to a file or
> a string (using StringIO).  On the other hand, this is perhaps a little low
> level.  We're had similar discussions regarding Bio.SeqIO in the past.
> 

I agree and I am not very concerned about backwards compatibility since this is
a very new function to Biopython. I think that is what is almost what
write_to_string() does and python functions are very big. But this is not my
code so please do as you want here.

Bruce


-- 
Configure bugmail: http://bugzilla.open-bio.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.