Operator overloading

Discussion in 'Python' started by MartinRinehart@gmail.com, Jan 25, 2008.

  1. Guest

    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 ..."?
    , Jan 25, 2008
    #1
    1. Advertising

  2. 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
    Diez B. Roggisch, Jan 25, 2008
    #2
    1. Advertising

  3. Guest

    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?
    , Jan 25, 2008
    #3
  4. 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
    Diez B. Roggisch, Jan 25, 2008
    #4
  5. Hexamorph Guest

    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.
    Hexamorph, Jan 25, 2008
    #5
  6. Guest

    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.
    , Jan 25, 2008
    #6
  7. Hexamorph Guest

    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.
    Hexamorph, Jan 25, 2008
    #7
  8. MRAB Guest

    On Jan 25, 8:52 pm, Hexamorph <> wrote:
    > 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.
    MRAB, Jan 27, 2008
    #8
  9. Terry Reedy Guest

    | > > 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
    Terry Reedy, Jan 27, 2008
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. John Smith
    Replies:
    2
    Views:
    414
    Ivan Vecerina
    Oct 6, 2004
  2. Replies:
    11
    Views:
    720
    James Kanze
    May 16, 2007
  3. hurcan solter
    Replies:
    3
    Views:
    713
    Cholo Lennon
    Aug 29, 2007
  4. Replies:
    11
    Views:
    545
  5. Replies:
    2
    Views:
    302
Loading...

Share This Page