Where I do ask for a new feature
dn
PythonList at DancesWithMice.info
Fri Oct 20 16:44:23 EDT 2023
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... at 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
More information about the Python-list
mailing list