Obviously many kinds of errors are possible in existing Python. My quick sample made one by passing 'data' rather than my intended 'datum'.

As you mention, maybe 'process_the()' will return the wrong kind of object some or all of the time. Mostly I would expect subsequent code to throw a ValueError or similar when trying to deal with that bad object, and the traceback would be fairly straightforward to diagnose.

But allowing purported binding to instead perform mutation of the same object previously bound introduces a new category of errors, and ones that are generally more difficult to anticipate and debug.

Moreover, this new magic is entirely needless. Properties already 100% cover the plausible need. It's really no harder to write 'f.new = mod_value()' than it is to write 'f = mod_value()' with magic behind the scenes.

On Thu, Jun 27, 2019, 11:25 AM nate lust <natelust@linux.com> wrote:

I think in this case, it would depend on what the metavar is designed to do. If f was a metavar that took in a value, had side effects, and then presented the variable back on load (that would be the __getself__ part of the proposal) I also included built ins for working with this type of variable, such as iscloaked('f') which would let you know if this is a metavar. There is a builtin called setcloaked(name, value) that will always trigger the existing python assignemnt, regardless of the type of variable. This is similar to the escape hatch of object.__setattr__ for classes.

I would argue that you are calling process_the() because you have looked up its function and found that it does what you want it to do. The process of seeing its result would be the same. It is currently possible that a function called process_the would return an array (what you need to call munge_result) 99% of the time, but have a random clause to return a string, which would result in an exception thrown in your code. The same is possible with my proposal, if a library author wrote something that was hard to consume, it would be hard to consume. There are utilities available to gaurd against unexpected code currently (isinstance), and I am proposing the same.

On Thu, Jun 27, 2019 at 9:58 AM David Mertz <mertz@gnosis.cx> wrote:
On Thu, Jun 27, 2019 at 9:13 AM Steven D'Aprano <steve@pearwood.info> wrote:
The only risk here is if your refactoring does something silly, such as
reusing a variable which overrides assignment:

How would you propose to write this code without reusing a variable?

def frobnicate(data):
stuff = []
for datum in data:
f = process_the(data)
g = munge_result(f)
stuff.append(g)
return stuff

Under the proposal, we have no guarantee that each iteration through the loop will give us a new `f` to work with. Maybe yes, maybe no. Without looking at the source code in `process_the()` we have no way of knowing whether `f` is being bound to a new object each time or some completely different arbitrary action.

--
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons. Intellectual property is
to the 21st century what the slave trade was to the 16th.
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/5IQOHCTV5F4KYHTWSYHYCF6PERZKOJ3S/
Code of Conduct: http://python.org/psf/codeofconduct/

--
Nate Lust, PhD.
Astrophysics Dept.
Princeton University