By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
439,957 Members | 2,038 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 439,957 IT Pros & Developers. It's quick & easy.

operator overloading + - / * = etc...

P: n/a
Can these operators be overloaded?
If so. How?

Oct 7 '06 #1
Share this Question
Share on Google+
33 Replies


P: n/a
SpreadTooThin enlightened us with:
Can these operators be overloaded?
Yes.
If so. How?
Implement __add__, __sub__ etc. in the class that you want to be able
to add, subtract, etc.

Sybren
--
Sybren Stüvel
Stüvel IT - http://www.stuvel.eu/
Oct 7 '06 #2

P: n/a
Can these operators be overloaded?
If so. How?
http://www.python.org/doc/ref/numeric-types.html

HTH,
Daniel
Oct 7 '06 #3

P: n/a
>Can these operators be overloaded?
>
Yes.
With the caveat of the "=" mentioned in the subject-line (being
different from "==")...I haven't found any way to override
assignment in the general case. There might be some oddball way
to do it via property() but AFAIK, this only applies to
properties of objects, not top-level names/variables. I'd love
to know if there's some workaround for this though...

-tkc

Oct 7 '06 #4

P: n/a
Tim Chase wrote:
>>Can these operators be overloaded?

Yes.

With the caveat of the "=" mentioned in the subject-line (being
different from "==")...I haven't found any way to override
assignment in the general case. There might be some oddball way
to do it via property() but AFAIK, this only applies to
properties of objects, not top-level names/variables. I'd love
to know if there's some workaround for this though...
In almost all cases, binding a name cannot be overridden.

There is a possibility to do that with globals, provided you do

exec code in globals_dict

where globals_dict is an instance of a subclass of dict that has a
customized __setitem__.

Georg
Oct 7 '06 #5

P: n/a
Tim Chase enlightened us with:
With the caveat of the "=" mentioned in the subject-line (being
different from "==")...I haven't found any way to override
assignment in the general case.
Why would you want to do that?

Sybren
--
Sybren Stüvel
Stüvel IT - http://www.stuvel.eu/
Oct 7 '06 #6

P: n/a
>With the caveat of the "=" mentioned in the subject-line (being
>different from "==")...I haven't found any way to override
assignment in the general case.

Why would you want to do that?
For the same reason one would use property() to create
getter/setter functions for a particular variable--to intercept
attempts to set a variable. I'm not sure there's an elegant way
to do it other than creating a custom container object with a
getter/setter using property().

My purpose was just to note that the "=" assignment operator is
distinct from the remainder of the operators that you correctly
identified can be overridden with their associated __[operator]__
method.

-tkc


Oct 7 '06 #7

P: n/a
On Sat, 07 Oct 2006 17:21:55 -0500, Tim Chase wrote:
>>With the caveat of the "=" mentioned in the subject-line (being
different from "==")...I haven't found any way to override
assignment in the general case.

Why would you want to do that?

For the same reason one would use property() to create
getter/setter functions for a particular variable--to intercept
attempts to set a variable.
Despite sloppy talk to the contrary (which I think most of us do from time
to time), Python doesn't have variables. It has names and objects. Names
are just labels -- there is no difference in behavior between the *names*
this_is_an_integer and this_is_a_string. (The *objects* they point to are
a different story, naturally.)

Objects do not, and can not, know what names they are bound to, nor can
they tell when the name or names they are bound to changes. Objects just
don't care what names they are bound to -- in fact, many objects aren't
bound to any name at all.

Suppose we bind the name "x" to the object 1, and then rebind the name "x"
to the object []. Which object's hypothetical __assign__ method should get
called? Object 1 or object []? Both of them? In what order? Why should
the empty list care what names it is bound to?
I'm not sure there's an elegant way
to do it other than creating a custom container object with a
getter/setter using property().
You shouldn't be programming C++ in Python, you should rethink how you
are solving the problem.

But having done that, if you still find that the property() idiom makes
sense for names/objects, you can get close if you are willing to write x =
1 as NAMESPACE.x = 1, and then use a custom class or module to implement
the behavior you want.

Here is one module that you might be able to use:

http://aspn.activestate.com/ASPN/Coo...n/Recipe/65207
--
Steven.

Oct 8 '06 #8

P: n/a
Tim Chase wrote:
>>>Can these operators be overloaded?

Yes.


With the caveat of the "=" mentioned in the subject-line (being
different from "==")...I haven't found any way to override
assignment in the general case. There might be some oddball way
to do it via property() but AFAIK, this only applies to
properties of objects, not top-level names/variables. I'd love
to know if there's some workaround for this though...
That's because assignment isn't an operator - that's why (for example)

print x = 33

would be a syntax error. This is a deliberate design decision about
which, history shows, there is little use complaining.

regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://holdenweb.blogspot.com
Recent Ramblings http://del.icio.us/steve.holden

Oct 8 '06 #9

P: n/a

Daniel Nogradi wrote:
Can these operators be overloaded?
If so. How?

http://www.python.org/doc/ref/numeric-types.html

HTH,
Daniel
Thanks everyone.

Oct 8 '06 #10

P: n/a
On 2006-10-08, Steven D'Aprano <st***@REMOVE.THIS.cybersource.com.auwrote:
On Sat, 07 Oct 2006 17:21:55 -0500, Tim Chase wrote:
>>>With the caveat of the "=" mentioned in the subject-line (being
different from "==")...I haven't found any way to override
assignment in the general case.

Why would you want to do that?

For the same reason one would use property() to create
getter/setter functions for a particular variable--to intercept
attempts to set a variable.

Despite sloppy talk to the contrary (which I think most of us do from time
to time), Python doesn't have variables. It has names and objects. Names
are just labels -- there is no difference in behavior between the *names*
this_is_an_integer and this_is_a_string. (The *objects* they point to are
a different story, naturally.)
I honestly don't see why "variable" would be an inappropiate word to use.
AFAIU, python assignment seems to behave much like lisp and smalltalk
and I never heard that those communities found the word "variable"
inappropiate to use. And since the word variable originally comes
from mathematics and IMHO the mathematical semantics are closer
to the lisp/smalltalk/python semantics than the C/algol/pascal/ada
semantics I don't see why "variable" is seen as "sloppy talk"

--
Antoon Pardon
Oct 9 '06 #11

P: n/a
Steven D'Aprano wrote:
On Sat, 07 Oct 2006 17:21:55 -0500, Tim Chase wrote:
>>>With the caveat of the "=" mentioned in the subject-line (being
different from "==")...I haven't found any way to override
assignment in the general case.
Why would you want to do that?
For the same reason one would use property() to create
getter/setter functions for a particular variable--to intercept
attempts to set a variable.
(snip)
Suppose we bind the name "x" to the object 1, and then rebind the name "x"
to the object []. Which object's hypothetical __assign__ method should get
called?
The current namespace object, of course.

--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"
Oct 9 '06 #12

P: n/a
Bruno Desthuilliers wrote:
Steven D'Aprano wrote:
>On Sat, 07 Oct 2006 17:21:55 -0500, Tim Chase wrote:
>>>>With the caveat of the "=" mentioned in the subject-line (being
different from "==")...I haven't found any way to override
assignment in the general case.
Why would you want to do that?
For the same reason one would use property() to create
getter/setter functions for a particular variable--to intercept
attempts to set a variable.
(snip)
>Suppose we bind the name "x" to the object 1, and then rebind the name "x"
to the object []. Which object's hypothetical __assign__ method should get
called?

The current namespace object, of course.
Which is?

Georg
Oct 9 '06 #13

P: n/a

"Bruno Desthuilliers" <on***@xiludom.growrote in message
news:45***********************@news.free.fr...
>
The current namespace object, of course.
Implementing a namespace as a Python object (ie, dict) is completely
optional and implementation dependent. For CPython, the local namespace of
a function is generally *not* done that way.

tjr

Oct 9 '06 #14

P: n/a
On 9 Oct 2006 11:27:40 GMT, Antoon Pardon <ap*****@forel.vub.ac.bewrote:
I honestly don't see why "variable" would be an inappropiate word to use.
AFAIU, python assignment seems to behave much like lisp and smalltalk
and I never heard that those communities found the word "variable"
inappropiate to use. And since the word variable originally comes
from mathematics and IMHO the mathematical semantics are closer
to the lisp/smalltalk/python semantics than the C/algol/pascal/ada
semantics I don't see why "variable" is seen as "sloppy talk"
Um, that's what I usually use anyway... :)

-- Theerasak
Oct 10 '06 #15

P: n/a
# st***@holdenweb.com / 2006-10-08 11:44:18 +0100:
That's because assignment isn't an operator - that's why (for example)

print x = 33

would be a syntax error. This is a deliberate design decision about
which, history shows, there is little use complaining.
Just to clarify: not that there's little complaining about
assignment not being an expression, it's useless to complain because
all previous complaints have been shot down on the basis of claims
of reduced safety and readability. People who complain often fail to
see how

x = foo()
while x:
process(x)
x = foo()

is safer than

while x = foo():
process(x)

(duplication hampers code safety) or how some other features present
in the language, e. g. comprehensions, could make it past the
readability check.

Everybody has an opinion; those who put the most work in the project
get to decide what the software looks like.

--
How many Vietnam vets does it take to screw in a light bulb?
You don't know, man. You don't KNOW.
Cause you weren't THERE. http://bash.org/?255991
Oct 10 '06 #16

P: n/a
Roman Neuhauser wrote:
People who complain often fail to see how

x = foo()
while x:
process(x)
x = foo()

is safer than

while x = foo():
process(x)
that's spelled:

for x in foo():
process(x)

in Python, or, if foo() just refuses be turned into a well-behaved Python
citizen:

while 1:
x = foo()
if not x:
break
process(x)

(this is the standard "loop-and-a-half" pydiom, and every python pro-
grammer should be able to identify it as such in a fraction of a second).

or for the perhaps-overly-clever hackers,

for x in iter(lambda: foo() or None, None):
process(x)

it's not like the lack of assignment-as-expression is forcing anyone to
duplicate code in today's Python.

also, in my experience, most assignment-as-expression mistakes are done
in if-statements, not while-statements (if not else because if statements are
a lot more common in most code). the "but it cuts down on duplication"
argument doesn't really apply to if-statements.

</F>

Oct 10 '06 #17

P: n/a
"Fredrik Lundh" <fr*****@pythonware.comwrites:
or for the perhaps-overly-clever hackers,

for x in iter(lambda: foo() or None, None):
process(x)
for x in takewhile(foo() for _ in repeat(None)):
process (x)
Oct 10 '06 #18

P: n/a
"Fredrik Lundh" <fr*****@pythonware.comwrites:
or for the perhaps-overly-clever hackers,

for x in iter(lambda: foo() or None, None):
process(x)
for x in takewhile(bool, (foo() for _ in repeat(None))):
process(x)

Meh, both are ugly.
Oct 10 '06 #19

P: n/a
On 2006-10-10, Paul Rubin <httpwrote:
"Fredrik Lundh" <fr*****@pythonware.comwrites:
>or for the perhaps-overly-clever hackers,

for x in iter(lambda: foo() or None, None):
process(x)

for x in takewhile(foo() for _ in repeat(None)):
process (x)
>>for x in takewhile(foo() for _ in repeat(None)):
.... print x
....
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: takewhile expected 2 arguments, got 1

Oct 10 '06 #20

P: n/a
Antoon Pardon <ap*****@forel.vub.ac.bewrites:
>for x in takewhile(foo() for _ in repeat(None)):
... print x
...
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: takewhile expected 2 arguments, got 1
Yeah, I cancelled and posted a followup

for x in takewhile(bool, foo() for _ in repeat(None)):
print x

but I haven't tested either way.
Oct 10 '06 #21

P: n/a
On 2006-10-10, Paul Rubin <httpwrote:
"Fredrik Lundh" <fr*****@pythonware.comwrites:
>or for the perhaps-overly-clever hackers,

for x in iter(lambda: foo() or None, None):
process(x)

for x in takewhile(bool, (foo() for _ in repeat(None))):
process(x)

Meh, both are ugly.
Sure, but so is IMO the current pythonic idiom.

Suppose one has the following intention in mind:

while x = setup():
if y = pre_process() in ErrorCondition:
break
post_process(y)
else:
NormalTermination()

The pythonic idiom for this case would then be something like:

while 1:
x = setup()
if x:
NormalTermination()
break
y = pre_process(x)
if y in ErrorCondition:
break
post_process(y)

There was some time it seemed PEP: 315 would be implemented so
that this could have been written as:

do:
x = setup()
while x:
y = pre_process(x)
if y in ErrorCondition:
break
post_process(y)
else:
NormalTermination()
Which IMO would have been clearer. Alas PEP 315 is deffered so
it will be probably a long time before this will be implemented.
Oct 10 '06 #22

P: n/a
Antoon Pardon <ap*****@forel.vub.ac.bewrites:
Suppose one has the following intention in mind:

while x = setup():
if y = pre_process() in ErrorCondition:
break
post_process(y)
else:
NormalTermination()
Maybe we need a new itertools function:

def forever(func, *args, **kw):
while True:
yield func(*args, **kw)

then you'd write:

for x in takewhile(bool, forever(setup)):
if y = pre_process() in ErrorCondition:
break
post_process(y)
else:
NormalTermination()

It might be preferable to write pre_process to raise an exception if
there's an error condition. Then the whole thing becomes:

try:
for x in takewhile(bool, forever(setup)):
post_process(pre_process())
NormalTermination()
except PreprocessError:
pass
Oct 10 '06 #23

P: n/a
>>>>Steven D'Aprano <st***@REMOVE.THIS.cybersource.com.au(SD) wrote:
>SDDespite sloppy talk to the contrary (which I think most of us do from time
SDto time), Python doesn't have variables. It has names and objects. Names
SDare just labels -- there is no difference in behavior between the *names*
SDthis_is_an_integer and this_is_a_string. (The *objects* they point to are
SDa different story, naturally.)
The official Python documentation (language reference manual) talks a lot
about variables. So it seems silly to say that Python doesn't have
variables.
--
Piet van Oostrum <pi**@cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C4]
Private email: pi**@vanoostrum.org
Oct 10 '06 #24

P: n/a
Piet van Oostrum <pi**@cs.uu.nlwrites:
The official Python documentation (language reference manual) talks a lot
about variables. So it seems silly to say that Python doesn't have
variables.
The symbols on the left side of = signs are called variables even in
Haskell, where they don't "vary" (you can't change the value of a
variable once you have set it).
Oct 10 '06 #25

P: n/a
Piet van Oostrum wrote:
The official Python documentation (language reference manual) talks a lot
about variables. So it seems silly to say that Python doesn't have
variables.
the language reference mostly uses the term "variables" when discussing
local variables and instance variables, and is (usually) careful to talk
about "names" when talking about binding behaviour.

for example, the description of the assignment statement:

http://www.python.org/doc/2.4.3/ref/assignment.html

only uses "variable" twice, in a note that discussing a given code
example. the more formal parts of that page consistently use the term
"name".

it's often a good idea to be a bit careful when discussing detailed
behaviour, especially in contexts where the audience may associate
variables with "small areas of memory".

(it's also important to realize that the language reference is a hodge-
podge of incremental revisions with no grand plan behind it; it was a
bit more consistent when Guido wrote the first version.)

</F>

Oct 10 '06 #26

P: n/a
Paul Rubin wrote:
The symbols on the left side of = signs are called variables even in
Haskell, where they don't "vary" (you can't change the value of a
variable once you have set it).
at the language specification level, the things to the left side of =
signs are called "targets" in Python. if they are plain identifiers,
they're called "names".

</F>

Oct 10 '06 #27

P: n/a
Paul Rubin wrote:
The symbols on the left side of = signs are called variables even in
Haskell, where they don't "vary" (you can't change the value of a
variable once you have set it).
FWIW, that's the original, mathematical meaning of the word 'variable'.
They _do_ vary, but only when you call the function with different
arguments (which happens frequently in Haskell, which uses recursion in
place of loops).
Oct 11 '06 #28

P: n/a
Georg Brandl wrote:
Bruno Desthuilliers wrote:
>Steven D'Aprano wrote:
>>On Sat, 07 Oct 2006 17:21:55 -0500, Tim Chase wrote:

>With the caveat of the "=" mentioned in the subject-line (being
>different from "==")...I haven't found any way to override
>assignment in the general case.
Why would you want to do that?
For the same reason one would use property() to create getter/setter
functions for a particular variable--to intercept attempts to set a
variable.
(snip)
>>Suppose we bind the name "x" to the object 1, and then rebind the
name "x"
to the object []. Which object's hypothetical __assign__ method
should get
called?

The current namespace object, of course.

Which is?
Depends on the context... Can be actually the module (global) namespace,
a function local namespace or a class namespace.
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"
Oct 12 '06 #29

P: n/a
Terry Reedy wrote:
"Bruno Desthuilliers" <on***@xiludom.growrote in message
news:45***********************@news.free.fr...
>The current namespace object, of course.

Implementing a namespace as a Python object (ie, dict) is completely
optional and implementation dependent. For CPython, the local namespace of
a function is generally *not* done that way.
I know this, and that's not the point here. The op's question seemed to
imply that the hypothetical __assign__ method should belong to the rhs
object, which is obviously not the case - it must of course belongs to
the lhs 'object'.
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"
Oct 12 '06 #30

P: n/a

"Bruno Desthuilliers" <on***@xiludom.growrote in message
news:45**********************@news.free.fr...
Terry Reedy wrote:
>"Bruno Desthuilliers" <on***@xiludom.growrote in message
news:45***********************@news.free.fr...
>>The current namespace object, of course.

Implementing a namespace as a Python object (ie, dict) is completely
optional and implementation dependent. For CPython, the local namespace
of
a function is generally *not* done that way.

I know this, and that's not the point here. The op's question seemed to
imply that the hypothetical __assign__ method should belong to the rhs
object, which is obviously not the case - it must of course belongs to
the lhs 'object'.
And my point is that in general there is no lhs object for the method to
belong to.


Oct 12 '06 #31

P: n/a
Terry Reedy wrote:
Implementing a namespace as a Python object (ie, dict) is
completely optional and implementation dependent. For CPython, the
local namespace of a function is generally *not* done that way.
Sure, but this is all just theoretical talk anyway, right? I would
like to see more control over the name-binding operation, and exposing
the namespace as an object sounds like an interesting way to do this.

--
--OKB (not okblacke)
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is
no path, and leave a trail."
--author unknown
Oct 12 '06 #32

P: n/a
>>>>Fredrik Lundh <fr*****@pythonware.com(FL) wrote:
>FLPiet van Oostrum wrote:
>>The official Python documentation (language reference manual) talks a lot
about variables. So it seems silly to say that Python doesn't have
variables.
>FLthe language reference mostly uses the term "variables" when discussing
FLlocal variables and instance variables, and is (usually) careful to talk
FLabout "names" when talking about binding behaviour.
Mostly yes, but not exclusively. E.g.
If a name is bound in a block, it is a local variable of that block. If a
name is bound at the module level, it is a global variable. (The
variables of the module code block are local and global.) If a variable
is used in a code block but not defined there, it is a free variable.

There are also other uses of variable for things at the module level. And
the word `variable(s)' occurs 80 times in the language reference manual.
>FLfor example, the description of the assignment statement:
>FL http://www.python.org/doc/2.4.3/ref/assignment.html
>FLonly uses "variable" twice, in a note that discussing a given code
FLexample. the more formal parts of that page consistently use the term
FL"name".
>FLit's often a good idea to be a bit careful when discussing detailed
FLbehaviour, especially in contexts where the audience may associate
FLvariables with "small areas of memory".
It is interesting that the word 'variable' is nowhere defined in the
manual. What one imagines with the word `variable' depends on one's
programming background, I guess, and that could certainly give a wrong
impression.
--
Piet van Oostrum <pi**@cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C4]
Private email: pi**@vanoostrum.org
Oct 13 '06 #33

P: n/a
Terry Reedy wrote:
"Bruno Desthuilliers" <on***@xiludom.growrote in message
news:45**********************@news.free.fr...
>Terry Reedy wrote:
>>"Bruno Desthuilliers" <on***@xiludom.growrote in message
news:45***********************@news.free.fr...
The current namespace object, of course.
Implementing a namespace as a Python object (ie, dict) is completely
optional and implementation dependent. For CPython, the local namespace
of
a function is generally *not* done that way.
I know this, and that's not the point here. The op's question seemed to
imply that the hypothetical __assign__ method should belong to the rhs
object, which is obviously not the case - it must of course belongs to
the lhs 'object'.

And my point is that in general there is no lhs object for the method to
belong to.
<nitpicking>
Mmm... Of course, there's always something that's being used as a
namespace. But yes, this something may not be directly accessible as a
Python object.
</nitpicking>.

--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"
Oct 13 '06 #34

This discussion thread is closed

Replies have been disabled for this discussion.