Hacker News Reader

Comment by prideout | Hacker News Reader

Yes, I'm happy with this design decision. The only bummer is that it doesn't allow daisy-chaining, as in:

    img = img.resize(...).blur(....).hflip()

View on HN

I always regret writing those lines when I come back to them anyway. Any time I try to refactor them I throw something out of order or drop a function.

That said, I don't claim to be a clever man.

I didn't want to reply to not sound too opinionated (ironically) but I agree. Chains feel cool when you write them down but don't always scale and lead to mistakes as Sileni points out.

BTW, as an addition to my original comment, a good example of reinventing types are the litany of C++ libraries that do NOT use the STL but reinvent half of it.

To be fair, some of them predate the STL

What is the alternative besides chaining, devise a new variable name for every operation? I understand that daisy chaining can be error prone, but the alternative is so difficult to maintain in long chains.

If the object is modified in place (as it seems to be in this case), then the “pythonic” approach is:

   img = ...
   img.resize(...)
   img.blur(....)
   img.hflip()

The other commenter pointed out the "inplace" version, but in the event I can't get away with that (or don't want to for some reason), I tend to throw in some numbering scheme on my original variable, and at the end replace the original variable or move to a "result_object" sort of name.

I think this is an edge case that is always going to feel inelegant, so whatever makes it easiest to load into my head wins out.

I have an unchain-on-sight policy, especially for file manipulations.

Reply on news.ycombinator.com