Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Operator overloading

Reply
Thread Tools

Operator overloading

 
 
MartinRinehart@gmail.com
Guest
Posts: n/a
 
      01-25-2008
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 ..."?

 
Reply With Quote
 
 
 
 
Diez B. Roggisch
Guest
Posts: n/a
 
      01-25-2008
http://www.velocityreviews.com/forums/(E-Mail Removed) 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
 
Reply With Quote
 
 
 
 
MartinRinehart@gmail.com
Guest
Posts: n/a
 
      01-25-2008


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?
 
Reply With Quote
 
Diez B. Roggisch
Guest
Posts: n/a
 
      01-25-2008
(E-Mail Removed) 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
 
Reply With Quote
 
Hexamorph
Guest
Posts: n/a
 
      01-25-2008
(E-Mail Removed) 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.
 
Reply With Quote
 
MartinRinehart@gmail.com
Guest
Posts: n/a
 
      01-25-2008


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.

 
Reply With Quote
 
Hexamorph
Guest
Posts: n/a
 
      01-25-2008
(E-Mail Removed) 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.

 
Reply With Quote
 
MRAB
Guest
Posts: n/a
 
      01-27-2008
On Jan 25, 8:52 pm, Hexamorph <(E-Mail Removed)> wrote:
> (E-Mail Removed) 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.
 
Reply With Quote
 
Terry Reedy
Guest
Posts: n/a
 
      01-27-2008

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



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
overloading operator->*() and operator->() gob00st@googlemail.com C++ 2 02-21-2009 04:26 AM
overloading operator->*() and operator->() gob00st@googlemail.com C++ 11 02-20-2009 08:52 PM
user defined conversion operator or operator overloading? hurcan solter C++ 3 08-29-2007 07:39 PM
Why is overloading operator. (member operator) forbidden? dascandy@gmail.com C++ 11 05-16-2007 07:54 PM
Operator overloading on "default" operator John Smith C++ 2 10-06-2004 10:22 AM



Advertisments