I actually disagree with this - the point of properties (in many languages) is to handle exactly the case of "there may be some transforms on this data, and the

I actually disagree with this - the point of properties (in many languages) is to handle exactly the case of "there may be some transforms on this data, and they depend on internals, but really it is just a data view, it should be accessible like other data." A good example is C#/.NET issues (and somewhat java) where you have .length .Length and .Length() and .Size() and .Count() and so on. It makes changing a data type an exercise in annoyance, and on the one hand there is a decent argument about semantic meaning of the name, on the other hand, tracking each and every subtle use of "I need to know how many things I'm dealing with" in several different ways becomes an exercise in yak shaving. As for the specific of .json - A lot of python web frameworks provide a .json attribute/property to the request structure, so I presume the earlier version of Requests was mirroring that for conceptual continuity.