OT: Addition of a .= operator

[dn]

On 24/05/2023 10.21, Rob Cliffe via Python-list wrote:
> 
>> This sort of code might be better as a single expression. For example:
>>
>> user = (
>>      request.GET["user"]
>>      .decode("utf-8")
>>      .strip()
>>      .lower()
>> )
>> user = orm.user.get(name=user)
>>
>>
> LOL.  And I thought I was the one with a (self-confessed) tendency to 
> write too slick, dense, smart-alec code. 😁
> Indeed, I was itching to shorten it (starting with the low-hanging 
> fruit: user = user.strip().lower() ).
> Seriously though: this kind of condensation can come unstuck when any of 
> the steps need to be made more complicated.
...

> Peter's actual code feels more Pythonic to me.  (It's even 2 lines 
> shorter! 😎)

On 24/05/2023 09.03, Peter J. Holzer wrote:
 > I sometimes have a chain of transformations (e.g. first decode it, then
 > strip extra spaces, then normalize spelling, then look it up in a
 > database and replace it with the record, ...). Technically, of course
 > all these intermediate objects are different, and I could make that
 > explicit by using different variable names:
 >
 >      user_param = request.GET["user"]
 >      user_decoded = str(user_param, encoding="utf-8")
 >      user_stripped = user_decoded.strip()
 >      user_normalized = user_stripped.lower()
 >      user_object = orm.user.get(name=user_normalized)
 >
 > But I find it easier to read if I just reuse the same variable name:
 >
 >      user = request.GET["user"]
 >      user = str(user, encoding="utf-8")
 >      user = user.strip()
 >      user = user.lower()
 >      user = orm.user.get(name=user)
 >
 > Each instance only has a livetime of a single line (or maybe two or
 > three lines if I have to combine variables), so there's little risk of
 > confusion, and reusing the variable name makes it very clear that all
 > those intermediate results are gone and won't be used again.


Once again/recently/another trainee came with a question about input() 
because he expected an number (cf input() providing a string). In this 
case, and to drive-home the point, preferred training illustration is:

     quantity_input = input( "How many would you like? " )
     quantity = float( quantity_input )

Many others, and I dare so all those who suffer from the aforementioned 
"itch", want to condense this into a single line.

However, (continuing @Peter's theme) such confuses things when something 
goes wrong - was the error in the input() or in the float()?
- particularly for 'beginners'
- and yes, we can expand the above discussion to talk about 
error-handling, and repetition until satisfactory data is input by the 
user or (?frustration leads to) EOD...

Accordingly, I'd start by favoring @Peter's "explicit" approach. However 
(as mentioned), we end-up with a bunch of names (storage-space) which 
are essentially unused - and many lint-er types will deplore such 
single-use [like it's s-u plastic].

Thus, advice becomes somewhat the opposite(!) of function parameter 
handling - there, I'm happy with one or two positional-parameters, but 
by three-or-more, this over-taxed brain starts begging/itching for 
named-parameters instead.

Now, the "easier" approach appeals. Indeed, if something goes wrong (per 
input()/float(), above), at least one has the assistance of a 
line-number (where error was noted). Further, using the PyCharm 
Debugger/pdb makes locating the design-error/coder's mistaken 
assumption, a snap.

A debatable-point is how much we should consider more junior-level 
programmers. IMHO more common functions such as strip() and lower() can 
be combined without much loss of readability or comprehension (apart 
from 'function-chaining' adding complication). Whereas, the other three 
lines are more likely to challenge - and/or become a source of concern 
if mods are requested...

However, some disagreement - which comes back to why the "_input" suffix 
(above) acts as an aide-memoire: When "user" is first used (hah!), it is 
the result of an http request. It is then transmogrified, until at the 
end where it is a query-result/object. Yes, however contrived and 
deliberately drawn-out the example, there is still a difference between 
the value which the code first produces (request/input) and that which 
eventually settles-out (orm/float).

Accordingly (perhaps), "user_request" or "user_requested" and "user" or 
"user_record" (according to the way 'that' ORM operates). Perhaps more 
psychology rather than coding?

-- 
Regards,
=dn