Addition of a .= operator

Rob Cliffe rob.cliffe at btinternet.com
Tue May 23 18:06:52 EDT 2023



On 23/05/2023 22:03, Peter J. Holzer wrote:
> On 2023-05-21 20:30:45 +0100, Rob Cliffe via Python-list wrote:
>> On 20/05/2023 18:54, Alex Jando wrote:
>>> So what I'm suggesting is something like this:
>>>
>>> ------------------------------------------------------------
>>> hash = hashlib.sha256(b'word')
>>> hash.=hexdigest()
>>> ------------------------------------------------------------
>>> num = Number.One
>>> num.=value
>>> ------------------------------------------------------------
>> It seems to me that this would encourage bad style.  When you write
>>      num = num.value
>> you are using num with two different meanings (an object and an
>> attribute of it).
> I think that's ok if it's the same thing at a high level.
>
> 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.
>
>          hp
>
>
>
Quite so.  I did imply in my full answer that this kind of thing can be 
appropriate in the right context.  I'm sure I've done it myself.
Your code is a beautiful example of when such "level-crossing" IS 
appropriate; creating a plethora of variables with a short useful life
would be a distraction which HINDERS readability ("Are any of these 
variables used later on?").
(Not to mention the effort of thinking up suitable variable names, and 
the effort of someone reading the code to assimilate them.)
But IMO your code would not really benefit from writing
         user .= strip()
         user .= lower()
and allowing it would have the disadvantage (apart from all the known 
costs of adding a new feature to Python) of encouraging bad style in the 
cases where it IS bad style.
Best wishes
Rob Cliffe


More information about the Python-list mailing list