I think I already agreed with much of your point. That is indeed the
problem. You are allowed to do some possibly non-standard things. A static
evaluation/replacement may show the wrong function being called and a
dynamic one may still mess up as there are many ways to do indirection.

I mention this partially because of a recent discussion on another computer
where the question was why they got an error message that the object being
given a function was not a data.frame or something compatible. What was
being passed was a data structure meant to hold some simulation of an EXCEL
spreadsheet. Not quite the same. But they insisted it had to be a data.frame
because they called functionA() and it is documented to return a data.frame.


It turned out that they had loaded lots of packages (modules but not) and
had not paid attention when they got a message that one function called
functionA was now being covered by another with the same name. Each such
package loaded often gets a new namespace/environment and when searching for
a function by name, the new package was ahead of the older package, hence
the warning.

So one solution was to change his code in one of several ways, but more
generally to call any functions that may be hidden this way in a fully
qualified manner as in packageA::functionA(...) do you do not accidentally
get package::functionA(...)

Now note this is not so much a bug as a feature in that language and It is
quite common to sort of redefine a function name to do what you want.

But if you have developed your own package and want to guarantee the user
does not undo your work in specific cases, you should also call some things
as explicitly within your own namespace.

Back to Python, it is a tad too flexible in some places and my point was
that it would be interesting, along the lines of a linter, to have some
tools that help explain what the program might be doing a tad more
explicitly. But as an interpreted language, so much can happen at runtime
that this may not be very effective or accurate. The language is full of
places where slipping in another object means you over-rode the meaning of
+= for instance.

-----Original Message-----
From: Python-list <python-list-bounces+avigross=verizon....@python.org> On
Behalf Of Richard Damon
Sent: Tuesday, September 7, 2021 10:09 PM
To: python-list@python.org
Subject: Re: on writing a while loop for rolling two dice

On 9/7/21 3:51 PM, Avi Gross via Python-list wrote:
> and similarly changes any function imported directly to also be fully 
> qualified.

One danger with this is that it can actual change the behavior of the
program. Maybe more likely with global objects than functions, but still an
issue.

Remember, "from module import fun" will bind the name fun in this modules
namespace to the current definiton of the object fun in the other modules
name space. If after that point, something rebinds the name in the other
module, the module that did the from import won't see that change, but if
the reference is changed to module.fun, it will.

Since that rebinding might even be some third module doing a 'monkey patch',
detecting if it is safe is basically impossible.

Admittedly, if this is an issue, the sensitivity to timing makes the
difference something very fussy to exactly the order you do things, the
cases where the difference is intended is likely fairly small.

--
Richard Damon

--
https://mail.python.org/mailman/listinfo/python-list

-- 
https://mail.python.org/mailman/listinfo/python-list

Reply via email to