I think that suggestion is great in many circumstances. In larger PORO (or components), I find that using an attr_reader or attr_accessor can break the readability of the code. Simply because an instance variable, at a glance will be something that you know is coming from an external source from the perspective of the object. But any local variables are likely a private method or something similar.
In the past, I've created a flask app which has the endpoints I needed and would respond with a JSON payload. This gets a bit tricker if you want things to be architected properly where you don't wait for the server to give the full response. So, I think the proper route would be to have your Rails app make an API request to the Python App Web Interface that you create. It queues a background job with Celery and gives an OK response back to the Rails application. You can then create an ingress endpoint on the Rails application side that the Celery working will call once its background job is completed. This saves from having a long running request holding up a thread.