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
