On 21/10/2023 01.32, Thomas Passin via Python-list wrote:
On 10/19/2023 11:16 PM, Bongo Ferno via Python-list wrote:
On Thursday, October 19, 2023 at 11:26:52 PM UTC-3, avi.e...@gmail.com
wrote:
There are many ways to make transient variables that disappear at
some time
and do we need yet another? Yes, you can create one of those ways but
what
is the big deal with deleting a variable when no longer used?
Assigning a variable to something can be anything else than a temporal
alias.
A with statement makes clear that the alias is an alias and is local,
and it automatically clears the variable after the block code is used.
Python clutters the variable space with vars that are needed only on
certain places, and an alias doesn't has a scope.
Convenient alias are short names, and short names are limited in
quantity. If the space is cluttered with short alias, it opens risks
for wrong utilization.
Its like writing a "for i" in a list comprehension and having to worry
if "i" was already used in another place..
If a name is temporarily needed in a certain place and in a certain
scope then reusing the name shouldn't be a problem.
Agree. Surely, the only time we use a name like "i" is in a throw-away
context?
Under many circumstances Python will let us use "_" in place of a
named-identifier - which enables both us and Python to remember its
short-lived value/local-only use.
Using an alias MERELY for the convenience of a shorter-name suggests two
things: 1 lack of a competent editor/IDE, 2 lack of imagination in
choosing names (perhaps one of THE skills of programming!)
Yes, there are other languages which enforce a limited-scope on
data-items created within or as part of a code-structure - and it IS a
handy feature! On the other hand, Python's apposite stance can be useful
too, eg trivial toy-example:
# list_of_stuff = ...
for n, element in list_of_stuff:
if element == target:
break
# now element == target, so "element" is probably not that useful
# but "n" is the index of the target-element, which may be
# (there are other ways to accomplish same)
Please take a look at the ideas behind "Modular Programming". This
encourages the breaking-up of monolithic code and its "cluttered" global
namespace, into potentially-independent code-units. The outlined-problem
is solved by the independent scope of those code-units (in Python:
modules, classes, functions, and "if __name__ == "__main__":".
(to say nothing of the coder's virtues of "re-use", the "Single
Responsibility Principle", "do one thing, and do it well", Law of
Demeter, ...)
Personal comment: my habit is to break specs into many classes and
functions - sometimes more-so than others might prefer. Cannot recall
when last had that hard-to-locate bug of unwittingly re-using a name/alias.
(apologies: not a boast - a recommendation for going modular)
--
Regards,
=dn
--
https://mail.python.org/mailman/listinfo/python-list
