[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.python

Operator overloading

Martin Rinehart

1/25/2008 6:14:00 PM

If it were my choice, the plus sign would do this:

def itemadd( i1, i2 ):
if ( type(i1) == str ) or ( type(i2) == str ):
return str(i1) + str(i2)
else:
return i1 + i2

I'd like to redefine it so it works my way but operator overloading
seems strictly confined to classes I create. Is there a way? Or do I
just have to grump, "Even a kludge like Perl ..."?
8 Answers

Diez B. Roggisch

1/25/2008 6:33:00 PM

0

MartinRinehart@gmail.com schrieb:
> If it were my choice, the plus sign would do this:
>
> def itemadd( i1, i2 ):
> if ( type(i1) == str ) or ( type(i2) == str ):
> return str(i1) + str(i2)
> else:
> return i1 + i2
>
> I'd like to redefine it so it works my way but operator overloading
> seems strictly confined to classes I create. Is there a way? Or do I
> just have to grump, "Even a kludge like Perl ..."?
>

No, there is no way. You would change general interpreter behavior if
you could set arbitrary operators for predefined types.

Start grumping...

Diez

Martin Rinehart

1/25/2008 6:59:00 PM

0



Diez B. Roggisch wrote:
> No, there is no way. You would change general interpreter behavior if
> you could set arbitrary operators for predefined types.
>
> Start grumping...

Thank you, Diez.

If I ever design a language, please remind me that complete, easy,
well-documented access to the working of the internals (and the
ability to change same) would be very, uh, what's the right word?
Pythonic?

Diez B. Roggisch

1/25/2008 7:17:00 PM

0

MartinRinehart@gmail.com schrieb:
>
> Diez B. Roggisch wrote:
>> No, there is no way. You would change general interpreter behavior if
>> you could set arbitrary operators for predefined types.
>>
>> Start grumping...
>
> Thank you, Diez.
>
> If I ever design a language, please remind me that complete, easy,
> well-documented access to the working of the internals (and the
> ability to change same) would be very, uh, what's the right word?
> Pythonic?

As you say - it's a question of design & thus taste. Python has chosen
to _not_ allow to change (all) inner workings of itself in favor of not
introducing subtle bugs that arise from somebody (accidentially or not)
altering behavior of builtins that might effect code he'd never intended
to touch.

But you _can_ create subclasses of these builtins and adapt their
behavior. I for once like it that way. If you don't - to bad for you. It
won't change, so either you live with it, or start working on your
lex/yacc skillz and create your own language. Or switch to Ruby, which
allow for what you desire (AFAIK, not entirely sure though)

Diez

Hexamorph

1/25/2008 7:25:00 PM

0

MartinRinehart@gmail.com wrote:
>
> Diez B. Roggisch wrote:
>> No, there is no way. You would change general interpreter behavior if
>> you could set arbitrary operators for predefined types.
>>
>> Start grumping...
>
> Thank you, Diez.
>
> If I ever design a language, please remind me that complete, easy,
> well-documented access to the working of the internals (and the
> ability to change same) would be very, uh, what's the right word?
> Pythonic?


You mean you want the ability to change for example the + operator
for ints to something like calculating the cosine instead of doing
addition?

That will break the whole system in general as other parts of the
language (or modules, libraries and programs) rely on a certain
inner behaviour.

There are some languages in which you can do this (Lisp/Scheme for
example) but messing with the internals is almost never done for
good reasons.

Martin Rinehart

1/25/2008 8:27:00 PM

0



Hexamorph wrote:
> You mean you want the ability to change for example the + operator
> for ints to something like calculating the cosine instead of doing
> addition?

Sure. Cosines are a monadic operation and the monadic '+' is a NOP, so
why shouldn't I define +45 to return cosine of 45, (presuming I needed
lots of cosines). I'd even let you define your own operators. Lots of
programmers really liked '++' and '--', for examples.

Hexamorph

1/25/2008 8:52:00 PM

0

MartinRinehart@gmail.com wrote:
>
> Hexamorph wrote:
>> You mean you want the ability to change for example the + operator
>> for ints to something like calculating the cosine instead of doing
>> addition?
>
> Sure. Cosines are a monadic operation and the monadic '+' is a NOP, so
> why shouldn't I define +45 to return cosine of 45, (presuming I needed
> lots of cosines). I'd even let you define your own operators. Lots of
> programmers really liked '++' and '--', for examples.

Well, OK, the cosine example was badly chosen (it would still be
very wired in terms of common syntax and semantics), but I think you
got my point. Changing internal behaviour mostly causes more trouble
as it's worth.

In the end, you probably can access the parser to do this.

MRAB

1/27/2008 12:58:00 AM

0

On Jan 25, 8:52 pm, Hexamorph <hexamo...@gmx.net> wrote:
> MartinRineh...@gmail.com wrote:
>
> > Hexamorph wrote:
> >> You mean you want the ability to change for example the + operator
> >> for ints to something like calculating the cosine instead of doing
> >> addition?
>
> > Sure. Cosines are a monadic operation and the monadic '+' is a NOP, so
> > why shouldn't I define +45 to return cosine of 45, (presuming I needed
> > lots of cosines). I'd even let you define your own operators. Lots of
> > programmers really liked '++' and '--', for examples.
>
> Well, OK, the cosine example was badly chosen (it would still be
> very wired in terms of common syntax and semantics), but I think you
> got my point. Changing internal behaviour mostly causes more trouble
> as it's worth.
>
> In the end, you probably can access the parser to do this.

You'd probably want the change to be limited to a certain scope so
that, for example, it doesn't affect imported modules.

Terry Reedy

1/27/2008 3:35:00 AM

0


| > > Sure. Cosines are a monadic operation and the monadic '+' is a NOP,
so
| > > why shouldn't I define +45 to return cosine of 45, (presuming I
needed
| > > lots of cosines). I'd even let you define your own operators. Lots of
| > > programmers really liked '++' and '--', for examples.

One cannot change builtin types. One can subclass most of them and
override most if not all the special methods.

import math as m
class trigint(int):
def __pos__(self):
return m.cos(m.pi*self/180.0)

print +trigint(45)
>>>
0.707106781187

Of course, for this case,
def cosi(degrees): return m.pi*degrees/180.0
would probably be more sensible.

There is and is no prospect of being able to add operators.

Terry Jan Reedy