5 ms·

I just started using requests and one of the first questions I asked myself was "Hey, why isnt't this a function rather than a property?" . I'm not that seasone

by gardarh 14y ago

I just started using requests and one of the first questions I asked myself was "Hey, why isnt't this a function rather than a property?" . I'm not that seasoned python developer but it feels wrong to me that you have to perform work in order to calculate a property, making it a function feels more explicit about that "there is work being done here". Requests is great by the way, had already written some code to abstract away the urllib/urllib2 mess but this module is so much more complete (of course) and cleaner.

sophacles 14y ago
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.
- kenneth_reitz 14y ago
  The issue is you don't want to raise an exception when returning a property.
- gardarh 14y ago
  I was dead wrong on what the issue was, but the actual explanation does actually hint that that doing error-prone calculation (such as deserialization) to magically calculate a property is not a good idea. I haven't seen the .json property used before but that only shows that I haven't looked into that many frameworks. I'm not sure why java uses .length for arrays and .size() for collections ... but could it be that it was for similar reasons?
domrdy 14y ago
The whole point of the @property decorator is to compute properties. It's no big deal really, I'm just interested in the design decision in this particular case.

by gardarh 14y ago

sophacles 14y ago

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.

kenneth_reitz 14y ago
The issue is you don't want to raise an exception when returning a property.
gardarh 14y ago
I was dead wrong on what the issue was, but the actual explanation does actually hint that that doing error-prone calculation (such as deserialization) to magically calculate a property is not a good idea. I haven't seen the .json property used before but that only shows that I haven't looked into that many frameworks. I'm not sure why java uses .length for arrays and .size() for collections ... but could it be that it was for similar reasons?

domrdy 14y ago

The whole point of the @property decorator is to compute properties. It's no big deal really, I'm just interested in the design decision in this particular case.