I often have statements in my code that do the following:
long_descriptive_variable_name = some_function(long_descriptive_variable_name)
which is very clear, but verbose and somewhat redundant at the same time. Is there any way in Python to simplify this statement perhaps by making some_function
act as a "mutating" ("in-place") function?
For example, in Julia one can often do the following:
some_function!(long_descriptive_variable_name)
and this is dispatched to the version of some_function
that writes directly to long_descriptive_variable_name
, effectively updating the variable.
Is there any way to concisely express the same in Python for a generic function some_function
?
What about doing the same with a general object method? i.e. simplifiying
long_variable_name = long_variable_name.method(arg1, arg2)
If the above is not (easily) doable with current versions of Python, are there any PEPs considering this change in the near future?
Mutating methods are ones that change the object after the method has been used. Non-mutating methods do not change the object after the method has been used. The count and index methods are both non-mutating. Count returns the number of occurrences of the argument given but does not change the original string or list.
"Mutate" and "bind"/"rebind" are two mutually exclusive operations. Mutating changes an object, whereas binding changes a name.
Removing members from a list.
What you're asking for can be achieved like so but I certainly wouldn't recommend doing it:
>>> x = 10
>>> def foo(func, string_of_var):
globals()[string_of_var] = func(globals()[string_of_var])
>>> def bar(x):
return x * 2
>>> foo(bar, 'x')
>>> x
20
As far as a PEP for changing it if there is one I doubt it would get approved. Calling a function like this that implicitly changes a value goes against the Zen of Python:
The Zen of Python, by Tim Peters
Beautiful is better than ugly.
Explicit is better than implicit. <==== Relevant line
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules. <==== also probably relevant
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea. <==== And this one for good measure
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
This also would likely entail a fair amount of work without adding much to the language. Python doesn't have a ++
/--
for this reason. It would have been more work to add it when x += 1
achieves the same thing. The same is true here, it would take a non trivial amount of work by several people to save you a few key strokes when calling functions.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With