On Thu, Sep 01, 2016 at 10:43:17AM +0300, Joonas Liik wrote:
Not sure if this is a good idea but it might also make some sense to in stead have an operator at the beginning of the line
for example some languages have a chainging operator for method calls:
my_object.m1() ..m2() being equivalent to my_object.m1() my_object.m2()
It could also be possible to have a special swallow-the-preceding-newline operator or something of that effect.
side note: the chainging operator does not work on the return value of the method thus the method no longer has to choose between returning useful info or `this` for chaining convenience.
Not sure if I would appreciate this. Most of the cases where I do chaining method calls, it's the return value that's being chained on. Of course that is logical, because that's what's currently possible. Also, would it be called 'call forking' instead of 'call chaining'...? But also, what does this mean: my_object.value.m1() ..m2() is that my_object.value.m1() my_object.value.m2() or my_object.value.m1() my_object.m2() I do think the syntax you suggest is readable, I just think the semantics is confusing and ambiguous in non-trivial examples. And the extra '.' to signify it is chaining is not really a syntactical necessity I think. What I think might be a neat idea is to do the following: if: - we have an 'unexpected indent', and - the line starts with a '.' then: - interpret the physical line as continuation of the previous line. In any current Python version this is a syntax error. In a new Python version it could be *the* obvious way to do method chaining. inactive_admins = User.objects .filter(is_staff=True) .exclude(last_login__gt=three_weeks_ago) In current versions of Python, you have to add a `\` to the end, in a possible future version of Python, you could leave out the `\`. To be fair, I think this only makes sense for when the next line starts with a `.`. In PEP8 we could add a rule about 'aligning the . with the last dot on the previous line' (or an indent of 4 if the previous line has no dot). Even though I think it would make for a good enhancement to the Python language, I can not currently estimate how much of a change to the Python parser this would need to be. Is it a three-hour straight-forward job, or a three-month bug-prone assignment? Regards, Sjoerd Job