On Monday, January 23, 2017 at 2:11:53 PM UTC, M.-A. Lemburg wrote: > On 23.01.2017 14:28, Soni L. wrote: > > > > > > On 23/01/17 11:18 AM, M.-A. Lemburg wrote: > >> On 23.01.2017 14:05, Soni L. wrote: > >>> Yeah but the dotequals operator has many other benefits: > >>> > >>> long_name .= __call__ # cast to callable > >>> long_name .= wrapped # unwrap > >>> etc > >>> > >>> And it also looks neat. > >> I don't see this an being a particular intuitive way of writing > >> such rather uncommon constructs. > >> > >> The syntax is not clear (what if you have an expression on the RHS) > >> and it doesn't save you much in writing (if long_name is too long > >> simply rebind it under a shorter name for the purpose of the code > >> block). > > > > It's literally sugar for repeating the name and moving the dot to the > > right. I think it's clearer than most other compound operators in that > > it doesn't affect precedence rules. > > > > `x += y`, for any code `y`, is equivalent to `x = x + (y)`, not `x = x + > > y`. > > > > `x .= y`, for any code `y`, is equivalent to `x = x . y`, not `x = x . > > (y)`. > > Well, then please consider these: > > x .= y + z > x .= y * z > x .= y.z > x .= y.z() > > >> Also note that rebinding different objects to the same name > >> in the same block is often poor style and can easily lead to > >> hard to track bugs. > >> > > > > Rebinding different objects to the same name in rapid succession > > is fine. > > Not in my book :-) > > It may be fine if the object type stays the same or > in those few cases, where you want to accept multiple > different types for a parameter and then coerce these > to a type that you use in the rest of the code block. > > But even in those cases, debugging becomes easier if > you keep the original binding in place (since you then > know where the new values originated). > > This is not good style... > > x = 'abc' > x = len(x) > x = [x, 1] > x = ''.join(str(a) for a in x) > print (x) > > -- > Marc-Andre Lemburg > eGenix.com >
The wrong list methinks :) Kindest regards. Mark Lawrence. -- https://mail.python.org/mailman/listinfo/python-list
