Closed ajjackson closed 1 month ago
Very true, this would also tie in well with exploiting the FileWrapper
features of line-nos and detailed error reporting from file. Could require a deep bit of restructuring though.
That could potentially be done quite non-destructively: just maintain the str
and iter
interfaces to main information while adding methods to access the deeper stuff.
Ah, on closer inspection I see that that StringIO is the default and so used quite a lot. But it is generally used as an iterator over lines, so the proposed interface would drop into the functions expecting TextIO and Mostly Just Work.
Currently if I read/write code operating on a block, I have to check back and see whether the block is a list or a StringIO to understand what indexing/methods are allowed.
I don't like to recommend creating new classes where a Python built-in will do fine...
but looking at this return section of
get_block
(and the correspondingout_fmt
parameter)https://github.com/oerc0122/castep_outputs/blob/0512ad1edeed551de96caff831f1f79d5e3020d2/castep_outputs/utilities/castep_res.py#L47-L55
there is a strong code smell that this function should be consistently returning a Block object which provides the features or conversion to these other classes.
Specifically:
__str__
can be implemented to Do The Right Thing and receiving code modified fromget_block(**kwargs, out_fmt=str)
tostr(get_block(**kwargs))
__bool__
can be implemented soif block
behaves as though for an empty string__iter__
can be implemented to allow idiomaticlist(get_block(**kwargs))
(where necessary: in most cases iterating overblock
will be sufficient.)strip_outer_lines()
method would improve readability elsewhereout_fmt=io.StringIO
option is currently unused; it could be dropped in favour ofio.StringIO(str(get_block(**kwargs)))
or constructed by a methodget_block(**kwargs).as_stringio()