Operator overloading

[MartinRinehart]

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

 

[Diez B. Roggisch]

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

 

[MartinRinehart]

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]

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]

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.

 

[MartinRinehart]

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]

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]

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]

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