learning python ...
hw
hw at adminart.net
Mon May 24 02:21:19 EDT 2021
On 5/24/21 12:03 AM, Cameron Simpson wrote:
> On 23May2021 21:02, Stestagg <stestagg at gmail.com> wrote:
>> On Sun, 23 May 2021 at 20:37, hw <hw at adminart.net> wrote:
>>> I don't know about shadowing.
>>
>> Shadowing is effectively saying “within this bit of code, (scope) I’m going
>> to use an already-used name for my own value”
>
> An example might make this clearer:
>
> x = 1 # global variable
>
> def f(a):
> x = a * 2
> return x
>
> Inside the function f() the name 'x" shadows the global "x"; references
> to "x" are to the function's local vairable. Which is very desireable.
If it works that way, I would consider it an entirely different
variable. Is there a way to access the global x from within a function
without transferring it through parameters of the function? Than can
also sometimes be useful.
>> If I have defeated a whole variable type
>>> by naming a variable like a variable type, I would think it is a bad
>>> idea for python to allow this without warning.
>>
>> There are some reasons why allowing this is quite nice. And there’s
>> actually a ton of corner cases to consider when thinking about changing the
>> rules
>
> As Stestagg has mentioned, there are also tools called linters which
> warn you about issues like this. Tools like pyflakes, pylint,
> pycodestyle all inspect your code for a wide variety of potential errors
> and discouraged habits. Not to mention tools like mypy which do type
> validation.
So you're saying one can't really go without those unless you want to
take the risk?
>> Interestingly python 3 made this a little bit better by stopping you from
>> rebinding (shadowing) a number of built ins, such as True and False.
>>
>> In your case, I agree that it is super confusing. One thing to learn to
>> look out for is if you assign to line 9, in <module>
print(type(str))
TypeError: 'int' object is not callablea name, then use that name on a
different
>> context, expecting it to be different, then that’s not likely to work as
>> you expect.
>>
>> It seems like a recipie
>>> for creating chaos.
>
> The runtime lets you do all sorts of things. Linters and type checkers
> exist to help you notice if you're writing such a recipe.
>
> There _are_ times when it is useful to shadow a builtin name. Not being
> able to prevents a useful activity.
>
> A common example in my own code is this:
>
> from cs.upd import Upd, print
>
> which shadows the print() builtin. The Upd class maintains status lines
> such as progress bars and so forth. It provides a print() function which
> withdraws the status lines, runs the builtin print, then restores them,
> allowing normal idiomatic use of print() in scripts making use of the
> status lines.
>
> Similar situations abound.
I'm not saying it shouldn't be allowed to defeat or to re-define stuff,
only that it shouldn't go through quietly.
More information about the Python-list
mailing list