REF: pandas/io/formats/format.py
- [ ] closes #xxxx
- [ ] tests added / passed
- [ ] passes `black pandas`
- [ ] passes `git diff upstream/master -u -- "*.py" | flake8 --diff`
- [ ] whatsnew entry

Partially addresses https://github.com/pandas-dev/pandas/issues/36407

Before splitting ``DataFrameFormatter`` into more dedicated classes, I decided to refactor the class itself, to make the outstanding refactoring more manageable.

As suggested by @jreback, I made this refactor small, trying to split big functions into smaller ones and find some better naming.
Yet, rather small changes are done so far, just to keep diffs readable.
Once approved, I will move on to further refactor.

Hello @ivanovmg! Thanks for updating this PR. We checked the lines you've touched for [PEP 8](https://www.python.org/dev/peps/pep-0008) issues, and found:





There are currently no PEP 8 issues detected in this Pull Request. Cheers! :beers: 

##### Comment last updated at 2020-09-19 18:09:57 UTC Thanks @ivanovmg for the PR. General Question.

DataFrameFormatter is not public. Is the validation always necessary or only during \_\_init__? Would _validator_foo() validators (perhaps even in attrs style https://www.attrs.org/en/stable/examples.html#validators) be more appropriate than property setters. > 
> 
> Thanks @ivanovmg for the PR. General Question.
> 
> DataFrameFormatter is not public. Is the validation always necessary or only during __init__? Would _validator_foo() validators (perhaps even in attrs style https://www.attrs.org/en/stable/examples.html#validators) be more appropriate than property setters.

My intention was indeed to extract parameters validation/conversion. It is not only validation. I will need to carefully look through the code to see if there is any assignment to the attributes via the setters defined. Probably these setters are used only once here.

I think that if we potentially derive ``ConsoleFormatter``, ``HTMLFormatter`` and ``LatexFormatter`` from ``DataFrameFormatter``, these properties with setters will be useful, since they will make initialization neat (just self.some_attr = some_attr). On the other hand it may be not very clear that there is a setter hiding behind. I couldn't help but extracting some more methods. I hope the diffs are is still readable. These changes will be helpful for the upcoming polymorphism updates (formatters with and without truncation). Something is wrong with the CI. The environment is not getting built time after time. we already have a cached property decorator

cache_readonly

though only use it if we are actually doing something non trivial  yeah cache_readonly is in cython without a stub file, so using here would undo all the typing benefits since properties would resolve to 'Any' thanks @ivanovmg keep em coming!