On Mon, Mar 28, 2016 at 12:24 PM, Steven D'Aprano <st...@pearwood.info> wrote: >> >> f() # Probably OK >> g() # Probably OK >> f()+g() # Probably not OK > > You don't and can't know what's "probably not" okay unless you know what > type of object both f and g return. > > Don't think about floats and ints and strings. Think of complex objects with > operator overloading. You're probably thinking of `x + y`. Instead, think > of things like: > > graph + node > database + table > > in a procedural style instead of a functional style. With operator > overloading, we have the ability to write domain-specific little languages.
I would still look askance at code that adds two things and drops the result, though. The compiler can't discard it, but if a linter complains, I'd support that. A DSL that requires you to do this is, imo, poorly designed. It'll make every subsequent maintainer wonder if the code is buggy or not. But it's still... > ... not the compiler's job to cast value judgements on what is good or > likely style, it must accept anything legal. If you want something to make > value judgements about style, or get warnings about what looks like legal > code but might be an error, then you should use a linter like PyChecker, > Pylint, Jedi or similar. That's not the compiler's job. Exactly. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
