AttributeError: type object 'PrettyPrinter' has no attribute '_format_dict_items'

[LaurensBosscher]

When running with Python 3.4

web_1        | Traceback (most recent call last):
web_1        |   File "/code/project_name/apps/students/util.py", line 227, in EDEXML_reader
web_1        |     pprint(groups_output)
web_1        |   File "/usr/local/lib/python3.4/site-packages/datatyping/printer.py", line 111, in pprint
web_1        |     with change_pprint_repr():
web_1        |   File "/usr/local/lib/python3.4/contextlib.py", line 59, in __enter__
web_1        |     return next(self.gen)
web_1        |   File "/usr/local/lib/python3.4/site-packages/datatyping/printer.py", line 101, in change_pprint_repr
web_1        |     old_format_dict_items = _pprint.PrettyPrinter._format_dict_items
web_1        | AttributeError: type object 'PrettyPrinter' has no attribute '_format_dict_items'

Looking at https://github.com/python/cpython/blob/3.4/Lib/pprint.py you can see that this was introduced in 3.5: https://github.com/python/cpython/blob/3.5/Lib/pprint.py.

Might be worth mentioning that only Python 3.5 and higher are supported!

[carlbordum]

Thanks for mentioning. I made it throw a runtime error for now. Let me know if this is not desired :)

see: 1ffbe71

[LaurensBosscher]

I would love this in our Python 3.4 project and given that Python 3.4 is end of life in March 2019 (and I don't think redhat is going to upgrade before that :'( ) i'm willing to spend some time to get this working.

How would you feel about including a backport of pprint in this package? It would give all 3.x users the ability to run this project. Downsides of course would be having to maintain the backport and it would probably be a good idea to include 3.4 in the travis test matrix.

If you think this is a good idea I can work on a pull-request.

[carlbordum]

I think it would be very nice to support 3.x. I feel obligated to warn you that it can be very challenging (and frustrating) to make the printer work.

Can I ask why you need it for 3.4? I imagined that it would only be run once for a given endpoint, which you could do with a different version?

[LaurensBosscher]

All our projects run on 3.4 for now, we do local development in Docker containers (besides all the other advantages Docker has, all modern Linux distro's are at least on 3.5 :) ). So in theory upgrading to 3.5 is pretty easy but that would mean rebuilding our containers everytime we need pprint and I would rather avoid that. Running a higher Python version locally than in production is also not something I feel very comfortable with.

I would really love to upgrade to Python 3.6 and I have been advocating for this for a while but that's going to take a while!

I'll try if I can make a pull-request this weekend so I can check how much work it is :)

[carlbordum]

Best of luck! There's certainly good arguments to be made for 3.6. Maybe your team needs speed and a nice async api^^

I still don't understand why you'd need datatyping.printer.pprint in your runtime, though.

[carlbordum]

Note to self (or anyone interested in working on datatyping.printer): refactor so it subclasses instead of monkey patching. Its documented usage and works with multiple threads (which current solution doesnt if you're unlucky).