I would suggest thinking carefully about ramifications as well as any benefits
of adding some or .=operator.
It sounds substantially different than the whole slew of +=, *= and so on
types of operators. The goal some would say of those is to either allow the
interpreter optimize by not evaluating twice as in x = x + 1 or python
extensions of the dunder type like __iadd__() that allow you to control what
exactly is done and which sometimes make a += b do things a bit different than
a= a+b.
So what would a __i_invoke_method__() function look like? It seems you want the
command to sort of replace
Object = Object.method(args)
But for any method whatsoever.
But Python objects can have methods all over the place as they may be
subclasses that inherit methods, or may implement an abstract method or use
multiple inheritance. All that searching happens in the current way, so if
Object.method(args))
Works as expected, would your new method be just syntactic sugar, or would it
look for a dunder method that may have no idea initially what you want?
Just curious.
Is there an alternative way you could get the functionality without using the
same way that is used for a very different circumstance?
-----Original Message-----
From: Python-list <python-list-bounces+avi.e.gross=gmail....@python.org> On
Behalf Of 2qdxy4rzwzuui...@potatochowder.com
Sent: Saturday, May 20, 2023 2:49 PM
To: python-list@python.org
Subject: Re: Addition of a .= operator
On 2023-05-21 at 06:11:02 +1200,
dn via Python-list <python-list@python.org> wrote:
> On 21/05/2023 05.54, Alex Jando wrote:
> > I have many times had situations where I had a variable of a certain type,
> > all I cared about it was one of it's methods.
> >
> > For example:
> >
> > ------------------------------------------------------------
> > import hashlib
> > hash = hashlib.sha256(b'word')
> > hash = hash.hexdigest()
> > ------------------------------------------------------------
> > import enum
> > class Number(enum.Enum):
> > One: int = 1
> > Two: int = 2
> > Three: int = 3
> > num = Number.One
> > num = num.value
> > ------------------------------------------------------------
> >
> > Now to be fair, in the two situations above, I could just access the method
> > right as I declare the object, however, sometimes when passing values into
> > functions, it's a lot messier to do that.
Can you give an example, preferably one from an actual program, that
shows the mess? Is it More Messier™ than the difference between the
following examples?
# example 1
hash = hashlib.sha256(b'word')
f(hash.hexdigest()) # call f with hash's hexdigest
# example 2
hash = hashlib.sha256(b'word')
hash = hash.hexdigest() # extract hash's hexdigest
f(hash) # call f with hash's hexdigest
Can you also show what your code would look like with a .= operator?
> > So what I'm suggesting is something like this:
> >
> > ------------------------------------------------------------
> > import hashlib
> > hash = hashlib.sha256(b'word')
> > hash.=hexdigest()
> > ------------------------------------------------------------
> > import enum
> > class Number(enum.Enum):
> > One: int = 1
> > Two: int = 2
> > Three: int = 3
> > num = Number.One
> > num.=value
> > ------------------------------------------------------------
>
> A custom-class wrapper?
> Even, a decorator-able function?
--
https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
