OT: Addition of a .= operator

[avi.e.gross at gmail.com]

It may be a matter of taste and policies, Dave.

I am talking about whether to write your code so it looks good to you, and
dealing with issues like error messages only when needed, or whether to
first do all kinds of things to catch errors or make it easier if they pop
up.

Python can be written fairly compactly and elegantly when trying out an
algorithm. But if you pepper it with print statements all over the place
showing the current values of variables and return codes (perhaps commented
out or hiding in an IF statement set to False) then you have a version
harder to read even if it can potentially be very useful. If your code is
constantly specifying what types variables must be or testing constraints,
it may well compile but for some users all that gets in the way of seeing
the big picture. 

In this case, we are discussing issues like how to spread code onto multiple
lines and opinions differ. In languages that do not use indentation as
having special meaning, I often like to stretch out and use lots of lines
for something like a function call with umpteen arguments and especially one
containing nested similar dense function calls. A good text editor can be
helpful in lining up the code so things at the same indentation level have
meaning as do things at other levels.

I will say that the try/catch type idioms that surround every piece of code,
often nested, can make code unreadable.

Similarly, some languages make it easy to do chaining in ways that use
multiple lines.

Since python is (justifiably) picky about indentation, I use such features
less and more cautiously and sometimes need to carefully do things like add
parentheses around a region to avoid inadvertent misunderstandings. 

When I do my work for myself and am not expecting serious errors I tend to
write the main program first and only then enhance it as needed. If working
with a group and established standards, of course, we follow whatever
methods are needed, and especially if a large part of the effort is to test
thoroughly against requirements.



-----Original Message-----
From: Python-list <python-list-bounces+avi.e.gross=gmail.com at python.org> On
Behalf Of dn via Python-list
Sent: Wednesday, May 24, 2023 1:19 AM
To: python-list at python.org
Subject: Re: OT: Addition of a .= operator

On 24/05/2023 12.27, Chris Angelico wrote:
> On Wed, 24 May 2023 at 10:12, dn via Python-list <python-list at python.org>
wrote:
>> 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...
> 
> A fair consideration! Fortunately, Python has you covered.
> 
> $ cat asin.py
> import math
> 
> print(
>      math.asin(
>          float(
>              input("Enter a small number: ")
>          )
>      )
> )
> $ python3 asin.py
> Enter a small number: 1
> 1.5707963267948966
> $ python3 asin.py
> Enter a small number: 4
> Traceback (most recent call last):
>    File "/home/rosuav/tmp/asin.py", line 4, in <module>
>      math.asin(
> ValueError: math domain error
> $ python3 asin.py
> Enter a small number: spam
> Traceback (most recent call last):
>    File "/home/rosuav/tmp/asin.py", line 5, in <module>
>      float(
> ValueError: could not convert string to float: 'spam'
> 
> Note that the line numbers correctly show the true cause of the
> problem, despite both of them being ValueErrors. So if you have to
> debug this sort of thing, make sure the key parts are on separate
> lines (even if they're all one expression, as in this example), and
> then the tracebacks should tell you what you need to know.


Yes, an excellent example to show newcomers to make use of 'the 
information *provided*' - take a deep breath and read through it all, 
picking-out the important information...


However, returning to "condense this into a single line", the 
frequently-seen coding is (in my experience, at least):

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

which would not produce the helpful distinction between 
line-numbers/function-calls which the above (better-formatted) code does!


Summarising (albeit IMHO):

- if relatively trivial/likely to be well-known: collect the calls into 
a chain, eg

     user = user.strip().lower()

- otherwise use separate lines in order to benefit from the stack-trace

- (still saying) use separate assignments, rather than chaining more 
complex/lesser-known combinations

- ensure that the 'final' identifier is meaningful (and perhaps the 
first, and/or even an 'intermediate' if pertinent or kept for re-use later)

- perhaps re-use a single identifier-name as a temp-variable, if can 
reasonably 'get away with it'
(and not confuse simple minds, like yours-truly)


-- 
Regards,
=dn
-- 
https://mail.python.org/mailman/listinfo/python-list