Workarounds for issues with Features column definition and formatting #282
Conversation
Avoids the hack where the shape() property is temporarily redefined, a source of a few crashed I encountered. The new method works by parsing and replacing the standard output of the pretty printer.
The differences between BoundedMaskedColumn and Column were causing hard-to-debug crashes under very specific circumstances.
|
A very relevant conversation about the pretty-printing is here. You can see me dealing with the fact that the default printer omits the middle of a 3-tuple (like our bounded param). Update: I'm pretty queasy about adding string hacks on top of hacks like this. Using structured arrays for the data without anything else will work, but right now any masked value makes |
|
I think this is entirely superseded by the much simpler #283; please have a look at that. Here's my proposal: let's merge
to |
|
Ok, I will review the above three pull requests. I'll post another comment here once I'm done with this, and then we'll pull those into dev. I will then test test some of my edge cases in dev, to see if we still need any extra hacks on top of #283. |
|
I think this has been superseded by #283 and can be closed, yes? |
|
Yes, we have a different approach in the other pull request now. Closing. |
There were a series of strange issues with the Features class in certain edge cases
To solve #274, both the Column and MaskedColumn definitions of Features were set to BoundedMaskedColumn.
The formatting hacks for Features were revised to deal with the above change and with #273 and #266.
The new formatting method, takes the default output of the formatter (using if/else to cover all possible strings created for a 3-tuple), and modifies it through string replacements.
This pull request is independent from #281, so one can go in after the other (at most a simple rebase required).