Dear Mous[e],
On 29/11/2022 14.49, Anony Mous wrote:
As it stands now, to create a local scope, you must define a function.
...
Good coding practice is generally accepted to be that variables are
local if at all possible. However, in direct, inline Python code, we're
inherently creating variables with a global scope.
(inline) inherently?
We don't actually need a function for this kind of code; but a local
scope would often be valuable (as we see with lambda.) Moving things off
into a function can create a circumstance where we have to go looking
for the function. When something is a "one-shot" as in global
preparatory code, that's doing more work, and creating more indirection,
than needs actually be done. But global operations have their own
pitfalls, one of which is variable collisions. So Python sort of drives
us to make "one-use" functions where lambdas are insufficient to the
case in order to control locality.
You can end up writing things like...
def PrepOne():
for MyCount in range(0,10):
pass
PrepOne()
...which achieves the locality desired for variable MyCount, but is
clunky. It also clutters the global namespace with prepOne, which has no
good reason to exist.
The larger criticism of the above is the chosen-name (not referring to
PEP-008). The opportunity a function gives, is to name a unit of code.
This is the way people think - often called "chunking". Whereas
'Apprentices' think (perhaps) one line of code at a time, more
experienced pythonista think in larger 'lumps', eg 'need to sum the
first ten (non-negative) digits'.
The actual code to deliver such a sub-objective is the same, either
in-line or as a function. However, deliberating over the choice of name
for the function makes the code easy to read - indeed, coming to it
later, (and assuming some trust in the author), at first it wouldn't be
necessary read the function's code, if the name enabled comprehension.
Test-oriented folk will also point-out that the function/sub-objective
can be tested, even proven, without regard to other aspects of the code,
or the progress of development 'elsewhere'.
...
This is the scoping equivalent of a pair of curly braces in c and c++. I
would like to see it be nestable, as scopes are in c/c++:
Aside: statements seeking justification from other languages invite an
obvious retort, along the lines of 'use [what you think is] the best
tool for the job'.
local: # <== or whatever syntax makes sense
for MyCount in range(0,10):
local:
for YourCount in range(0,MyCount+1)
pass
Please allow appropriate of the word "clunky".
This example features two uses of "local:" which contribute nothing
except to isolate MyCount and YourCount (sic). In addition to this
'noise' in the code, there is an extra level of indentation for each
"local:". (please refer back to 'the early days' and the Python
blocks-by-indentation discussions, and the debates over tabs cf
how-many-spaces, leading to the idea of code marching off-the-page to
the right). Functions (also) enable a tidy form of nesting.
There, MyCount is available in both scopes (the first local: is an
enclosing scope) and YourCount is available only in the second local: scope.
Or, local: could be very strict, and require further syntax to
incorporate a previous scope, something like this:
Can Python be described as a "strict" language? Compared to which other
languages?
...
Perhaps the very flexibility of Python is its power? The attitude of
'we're all adults here' suggests that some ideas are not "good", eg
globals; but if one has sufficient reason (or foolishness), then proceed
- but at your own risk! (see also Python object-attribute addressing
through dotted-notation cf formal getters and setters).
One of the challenges I faced coming to Python - and still notice from
time-to-time, is accepting the informality, the EAFP (cf LBYL) attitude.
However, one lives and learns...
OTOH given that programming has been described as "choosing good names",
I can't remember the last time a naming-collision/scope-issue proved
that I'm not the smartest person in the room...
--
Regards,
=dn
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/I6NEKT334CRES3WF6GUICB3RBLPGF2P6/
Code of Conduct: http://python.org/psf/codeofconduct/
