4 ms·
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()
by prideout 8y ago
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()
- Sileni 8y agoI 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.
- noobermin 8y agoI 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.
- cozzyd 8y agoTo be fair, some of them predate the STL
- _eht 8y agoI have an unchain-on-sight policy, especially for file manipulations.
- prestonh 8y agoWhat 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.
- jacobolus 8y agoIf 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()
- Sileni 8y agoThe 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.