Consider object-oriented Block

[ajjackson]

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 corresponding out_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 from get_block(**kwargs, out_fmt=str) to str(get_block(**kwargs))
• __bool__ can be implemented so if block behaves as though for an empty string
• __iter__ can be implemented to allow idiomatic list(get_block(**kwargs)) (where necessary: in most cases iterating over block will be sufficient.)
• a strip_outer_lines() method would improve readability elsewhere
• the out_fmt=io.StringIO option is currently unused; it could be dropped in favour of io.StringIO(str(get_block(**kwargs))) or constructed by a method get_block(**kwargs).as_stringio()

[oerc0122]

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.

[ajjackson]

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.

[ajjackson]

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.