operator overloading + - / * = etc...

[SpreadTooThin]

Can these operators be overloaded?
If so. How?

[Sybren Stuvel]

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/

[Daniel Nogradi]

Can these operators be overloaded?

If so. How?

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

HTH,
Daniel

[Tim Chase]

>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

[Georg Brandl]

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

[Sybren Stuvel]

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/

[Tim Chase]

>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

[Steven D'Aprano]

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.

[Steve Holden]

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 [phone] [phone]
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://holdenweb.blogspot.com
Recent Ramblings http://del.icio.us/steve.holden

[SpreadTooThin]

Daniel Nogradi wrote:

Can these operators be overloaded?
If so. How?

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

HTH,
Daniel

Thanks everyone.

[Antoon Pardon]

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

[Bruno Desthuilliers]

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('@')])"

[Georg Brandl]

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

[Terry Reedy]

"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

[Theerasak Photha]

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

[Roman Neuhauser]

# 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

[Fredrik Lundh]

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>

[Paul Rubin]

"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)

[Paul Rubin]

"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.

[Antoon Pardon]

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

[Paul Rubin]

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.

[Antoon Pardon]

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.

[Paul Rubin]

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

[Piet van Oostrum]

>>>>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

[Paul Rubin]

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).

[Fredrik Lundh]

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>

[Fredrik Lundh]

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>

[Leif K-Brooks]

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).

[Bruno Desthuilliers]

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('@')])"

[Bruno Desthuilliers]

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('@')])"

[Terry Reedy]

"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.

[OKB (not okblacke)]

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

[Piet van Oostrum]

>>>>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

[Bruno Desthuilliers]

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('@')])"