No warning after redefining Python built-in since friendly 0.7.9

[mardukbp]

Before version 0.7.9 when a Python built-in was redefined friendly issued a warning. This is specially useful for beginners, who actually do things like

print = 3

In case the warning now has to be manually activated, I believe that it would be a good idea to revert to making it default behavior. Because disabling safety measures should be a conscious decision.

[aroberge]

I've removed these warnings from the console for the following reason:

• For 3 years, these warnings included a link inviting feedback (originally open in November 2020 https://github.com/aroberge/friendly/issues/112 and since moved to https://github.com/friendly-traceback/friendly-traceback/issues/7) and I never received a single comment about them.
• They were only available in the friendly console, and not in other environments in which friendly could be used.
• They duplicated the warnings that were now given in all environments (see example below) if a redefined built-in was used as part of the code that produced an exception, and which are now part of friendly_traceback. See example below. These new warnings are available in all environments (e.g. jupyter notebooks, iPython console, etc.) in which friendly can be used, and not only in the console.
• To prevent the same warning from being shown each time a new statement was executed, the code had to be quite convoluted, much more so than the new warnings which are only given when an exception is raised.

friendly-traceback: 0.7.35
friendly: 0.7.15
Python: 3.10.6
Type 'Friendly' for help on special functions/methods.

[1]: len = 1

[2]: a = len + b

Traceback (most recent call last):
  Code block [2], line 1
    a = len + b
NameError: name 'b' is not defined

[3]: where()

Exception raised on line 1 of code block [2].

     > 1| a = len + b

Friendly warning: you have redefined the python builtin len.

[aroberge]

It might be useful to re-introduce these warnings, but make them available in other environments on demand via an explicit call; perhaps something like check_unsafe(). By default, check_unsafe() would then be called each time some code is executed in the console. check_unsafe() could take an optional argument, check_unsafe(name) which would see if name is a module that has been imported, and examine whether or not some "unsafe" reassignment took place.

[mardukbp]

I see. Thank you for the thorough explanation. I noticed that the warning is not part of the output of explain(). I thought that explain() prints the concatenation of friendly_tb(), what(), why() and where().

Checking for shadowed variables from the modules imported by default and also from modules imported by the user would be nice. Instead of calling the function check_unsafe I propose calling it check_shadowed_names. I think that unsafe is usually used in the context of FFI, which involves passing pointers and manual memory management.

[aroberge]

Friendly warnings are shown when using explain().

I'm thinking of adding more checks than simply shadowing names. I might use the name check or check_code.

[mardukbp]

Now I see the warning. I was probably using an older version of friendly-traceback.