It's always pretty easy to turn it into "code you control." Just take
whatever the plan value/object is and wrapped it in a class with a
'._value' attribute that holds the original. From there, as as many
properties as you like, each of which had whatever side effects you wish.
That side effect might be mutating '._value', as you like.
On Thu, Jun 27, 2019, 12:20 PM nate lust <natel...@linux.com> wrote:
> That is true when it is code that you control, but if it is the case you
> want to use some specialized metavar in the context of someone else's
> library things are a bit different. This could be something such as using
> something like a debugger tracing through some execution where you want to
> record how the value was changed and where.
>
> On Thu, Jun 27, 2019 at 12:02 PM David Mertz <me...@gnosis.cx> wrote:
>
>> 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 <natel...@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 <me...@gnosis.cx> wrote:
>>>
>>>> On Thu, Jun 27, 2019 at 9:13 AM Steven D'Aprano <st...@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-le...@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
>>>
>>
>
> --
> Nate Lust, PhD.
> Astrophysics Dept.
> Princeton University
>
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/DSKIC76JOUIUUTKBJ46YEBI7O6OCMCVG/
Code of Conduct: http://python.org/psf/codeofconduct/
