Hacker News Reader

Comment by domrdy | Hacker News Reader

Very nice, Thank you! I'm curious, why did you remove the json property?

just a guess but if .json was implemented as a property and deserialization fails, you would get an AttributeError instead of the error reporting that there was a problem with deserialization. leaving it a method call would allow for the real error to bubble up as normal.

Bingo :)

i pretty much stopped using properties after I got bit by that. :)

Where does this happen? I'm not seeing it: https://gist.github.com/4329831 – the exception seems to come through just fine?

Feels weird. You shouldn't need to catch an exception when accessing an attribute.

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.

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.

The issue is you don't want to raise an exception when returning a property.

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?

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.

it's possible that it was a method all along, just callable as a property? I haven't looked at the source.

Reply on news.ycombinator.com