Overloading methods in C API
Afanasiy
Martin v. Löwis
> How is it expected I create overloaded methods/functions in the C API?
This is not possible. Overloading of methods is not supported in Python.
Regards,
Martin
Afanasiy
wrote:
>Afanasiy <abeli...@hotmail.com> writes:
>
>> How is it expected I create overloaded methods/functions in the C API?
>
>This is not possible. Overloading of methods is not supported in Python.
As a matter of principle?
Gerhard Häring
Not as a matter of principle. The language just doesn't support it
having multiple methods with the same name in the same class.
Of course you can subclass a class and override a method.
You can, however, have functions with a variable number of arguments.
At the C API, the function you'll need to implement this is
PyArg_ParseTupleAndKeywords.
Gerhard
--
Favourite database: http://www.postgresql.org/
Favourite programming language: http://www.python.org/
Combine the two: http://pypgsql.sf.net/
Embedded database for Python: http://pysqlite.sf.net/
Martin v. Löwis
> So you have to implement it yourself by checking the types of the arguments
> and calling the right overload, by which time you really need to be using an
> automatic bindings generator to do it for you.
>
> http://www.riverbankcomputing.co.uk/sip/ is my favorite. :)
That, of course, assumes that you really can perform the right
dispatching. For example, when dispatching from Python to C++, there
might be tricky issues, such as how to relate the many C++ integer
types to the two Python integer types. Some languages (e.g. C++) even
allow to define functions with a potentially unbounded number of
overloaded definitions (i.e. templates).
Regards,
Martin
Phil Thompson
So you have to implement it yourself by checking the types of the arguments
and calling the right overload, by which time you really need to be using an
automatic bindings generator to do it for you.
http://www.riverbankcomputing.co.uk/sip/ is my favorite. :)
Phil
Afanasiy
wrote:
>Afanasiy <abeli...@hotmail.com> writes:
>
>> How is it expected I create overloaded methods/functions in the C API?
>
>This is not possible. Overloading of methods is not supported in Python.
Is method/function overloading common in Python modules?
Is it looked down upon?
Steve Holden
Steve Holden
Well, it isn't like anybody said "We'll leave out method and function
overloading, and that will fix those *@#$! [language of your choice]
devotees". More that it simply isn't a part of the language design.
Python's signature-based polymorphism doesn't allow for multiple signatures
to be associated with the same method or function. Consequently if you want
to perform different functionsa ccording to the arguments provided, you have
to do the decoding yourself as a part of the logic of your method/function.
Personally I think this is good, and fits well with Python's general
"explicit is better than implicit" philosophy (though where that leaves
properties is another question, currently being discussed on a thread not
far from here).
Of course, many of Python's operators are tied to methods "under the hood",
so you can get operator overloading in the same way for many operators.
regards
--
Steve Holden http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/pwp/
Bring your musical instrument to PyCon! http://www.python.org/pycon/
Grant Edwards
No. It's isn't supported. The language does not allow it. Therefore, it
is not common.
> Is it looked down upon?
It is not allowed by the language design. I suppose that's a pretty good
indication that it's "looked down upon."
--
Grant Edwards grante Yow! Yow! I forgot my
at PAIL!!
visi.com
Tim Peters
> Is method/function overloading common in Python modules?
No. As Martin said, it's not *supported* in Python.
> Is it looked down upon?
It's more that it can't be spelled: there are no type declarations in
Python. You can write a function
def f(x):
that accepts any type of argument, but there's no way to say, via
declaration, that it only accepts a *particular* type of argument. So if
you want f(int) to do one thing and f(float) another, runtime code in the
body of f has to branch on type(x). People have also invented elaborate
registration schemes for more-or-less automating this kind of thing, but
it's unnatural in Python and such packages are rarely used. They don't get
away from runtime branching on type, they just hide it under additional
layers of obscurity <0.9 wink>.
The only kind of overloading naturally supported in Python is
single-dispatch OO-style (a single method name can be implemented in a
different way by each class that chooses to support a method of that name):
the meaning of x.meth() is whatever type(x) says "meth" means.
Robert Amesz
>> Is method/function overloading common in Python modules?
>
> No. It's isn't supported. The language does not allow it.
> Therefore, it is not common.
It's not that the language doesn't allow it, it's just that dynamic
typing makes it impossible to decide beforehand what methods/functions
would be called.
>> Is it looked down upon?
>
> It is not allowed by the language design. I suppose that's a
> pretty good indication that it's "looked down upon."
No, it's not "looked down upon". Take, for example, the % operator for
strings: it allows things like:
"Single value: %d" % 43
or:
"Multiple values: %s %d" % ("one", 2)
or even:
"Using a dict: %(first)s %(second)d" % {"first": "one", "second": 2}
That's a pretty overloaded function, if you ask me, and it's part of
core Python. It's just that in Python you have to do this manually. Ah,
well, "explicit is better than implicit", to coin a phrase.
Robert Amesz
Grant Edwards
> Grant Edwards wrote:
>
>>> Is method/function overloading common in Python modules?
>>
>> No. It's isn't supported. The language does not allow it.
>> Therefore, it is not common.
>
> It's not that the language doesn't allow it, it's just that dynamic
> typing makes it impossible to decide beforehand what methods/functions
> would be called.
The language doesn't allow one to declare the types of function/method
parameters. Therefore function/method overloading is not possible. In my
mind, that can be summarized as "the language doesn't allow it."
>>> Is it looked down upon?
>>
>> It is not allowed by the language design. I suppose that's a
>> pretty good indication that it's "looked down upon."
>
> No, it's not "looked down upon". Take, for example, the % operator for
> strings: it allows things like:
That's operator overloading, which I think of as different than
function/method overloading.
>
> "Single value: %d" % 43
>
> or:
>
> "Multiple values: %s %d" % ("one", 2)
>
> or even:
>
> "Using a dict: %(first)s %(second)d" % {"first": "one", "second": 2}
>
> That's a pretty overloaded function, if you ask me, and it's part of
> core Python. It's just that in Python you have to do this manually. Ah,
> well, "explicit is better than implicit", to coin a phrase.
For whatever historical reasons, operator overloading and function/method
overloading are usually considered as two separate language features. C and
python have the former but not the latter. C++ has both.
--
Grant Edwards grante Yow! A shapely CATHOLIC
at SCHOOLGIRL is FIDGETING
visi.com inside my costume...
James Kew
> In article <Xns9307CD59...@amesz.demon.nl>, Robert Amesz
> wrote:
>> No, it's not "looked down upon". Take, for example, the % operator
>> for strings: it allows things like:
>
> That's operator overloading, which I think of as different than
> function/method overloading.
Yes and no. Operator overloading allows you to provide your own definitions
for operators. Method overloading allows you to provide multiple versions of
a method for different argument types.
Operator overloading is directly supported in Python. Method overloading
isn't, but Robert's examples -- using the % operator on string with integer,
sequence, and directory arguments -- illustrates how Python methods can
simulate it by being liberal in what they accept.
> For whatever historical reasons, operator overloading and
> function/method overloading are usually considered as two separate
> language features. C and python have the former but not the latter.
*cough* C has neither.
--
James Kew
jame...@btinternet.com
Carl Banks
> In article <Xns9307CD59...@amesz.demon.nl>, Robert Amesz wrote:
>> Grant Edwards wrote:
>>
>>>> Is method/function overloading common in Python modules?
>>>
>>> No. It's isn't supported. The language does not allow it.
>>> Therefore, it is not common.
>>
>> It's not that the language doesn't allow it, it's just that dynamic
>> typing makes it impossible to decide beforehand what methods/functions
>> would be called.
>
> The language doesn't allow one to declare the types of function/method
> parameters. Therefore function/method overloading is not possible. In my
> mind, that can be summarized as "the language doesn't allow it."
His point is that you can write a function that dispatches on type
manually, like this:
def fn(x):
if type(x) == type(1):
...
elif type(x) == type([]):
...
I would call that an overloaded function, even if it isn't technically
an Overloaded Function (tm).
--
CARL BANKS
Grant Edwards
>> For whatever historical reasons, operator overloading and
>> function/method overloading are usually considered as two separate
>> language features. C and python have the former but not the latter.
>
> *cough* C has neither.
Nonsense. The operators + - * / do different things depending on the types
of their operands. That's operator overloading.
--
Grant Edwards grante Yow! I feel... JUGULAR...
at
visi.com
Grant Edwards
>> The language doesn't allow one to declare the types of function/method
>> parameters. Therefore function/method overloading is not possible. In my
>> mind, that can be summarized as "the language doesn't allow it."
>
> His point is that you can write a function that dispatches on type
> manually, like this:
>
> def fn(x):
> if type(x) == type(1):
> ...
> elif type(x) == type([]):
> ...
>
> I would call that an overloaded function, even if it isn't technically
> an Overloaded Function (tm).
Fair enough, but I only call it "overloading" when the dispatching is hidden
and automagical.
--
Grant Edwards grante Yow! Where does it go when
at you flush?
visi.com
Grzegorz Adam Hankiewicz
> >> function/method overloading are usually considered as two
> >> separate language features. C and python have the former but
> >> not the latter.
> >
> > *cough* C has neither.
>
> Nonsense. The operators + - * / do different things depending on
> the types of their operands. That's operator overloading.
Maybe you are refering to C's usually warningless type coercion in
mathematical operations? Or you know of a way to add two strings
and have them concatenated? Please ellaborate.
Erik Max Francis
> > Nonsense. The operators + - * / do different things depending on
> > the types of their operands. That's operator overloading.
>
> Maybe you are refering to C's usually warningless type coercion in
> mathematical operations? Or you know of a way to add two strings
> and have them concatenated? Please ellaborate.
Well, for one thing, + can do both numeric and pointer arithmetic. Very
different things. - also means unary negation (+ also has a unary form
but it is a no-op), and as well as being useful for both pointer
arithmetic _and_ computing the difference between two pointers (a
variant of pointer arithmetic where both operands are compatible
pointers). * is also used for dereferencing pointers. And do so on.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ Mona Lisa / Come to discover / I am your daughter
\__/ Lamya
7 Sisters Productions / http://www.7sisters.com/
Web design for the future.
Grant Edwards
Those operators don't happen to work on strings. That's neither here nor
there.
The "+" operator can mean several things:
integer addition
pointer addition
floating point addition
unary postive
The "-" can mean several different "subtraction" operations (integer, fp,
pointer) and can also be unary negation.
The "*" operator does two different multiplaction operations (integer, fp)
as well as de-referenecing pointers.
Back when I studied language design, that was called "operator overloading".
Perhaps the definition has changed since then -- it was 15 years ago.
--
Grant Edwards grante Yow! HAIR TONICS, please!!
at
visi.com
Afanasiy
Like others, I was caught by "C [has] the former"... and I will just
say... I meant overloading that developers could define themselves.
Otherwise, I have a tough time thinking of a language
that doesn't have operator "overloading"...
Grzegorz Adam Hankiewicz
> The "+" operator can mean several things:
>
> integer addition
> pointer addition
> floating point addition
> unary postive
> Back when I studied language design, that was called "operator
> overloading".
>
> Perhaps the definition has changed since then -- it was 15
> years ago.
Aah... thanks for your (and Eric's) answer. I understand your point
of view now. So basic things, and never had thought of them! You
are right in the "15 years ago" sentence, nowadays teachers are so
worried about carefully explaining C++'s class operator overloading
as a feature that they forget about the basics.
James Kew
>
> The "+" operator can mean several things:
>
> integer addition
> pointer addition
> floating point addition
Add, add, add. All addition. The details may vary slightly (pointer
arithmetic, for example) but the basic semantics are the same.
> unary postive
That's a different operator -- it's unary, not binary. The fact that it's
represented by the same character in source code is a matter of syntax, not
of operator overloading.
--
James Kew
jame...@btinternet.com
jsaul
> In article <b0cdjh$nsnhe$1...@ID-71831.news.dfncis.de>, James Kew wrote:
>
> >> For whatever historical reasons, operator overloading and
> >> function/method overloading are usually considered as two separate
> >> language features. C and python have the former but not the latter.
> >
> > *cough* C has neither.
>
> Nonsense. The operators + - * / do different things depending on the types
> of their operands. That's operator overloading.
Can you overload, say, the '*' operator to support multiplication
of matrices or complex numbers in C as you can in both Python and
C++? Obviously you can't. But you still call it 'operator
overloading'?
Cheers, jsaul
--
Palo pa'que aprenda que aquí sí hay honor!
[Rubén Blades]
Grant Edwards
You're correct: C doesn't have programmer controlled operator
overloading.
--
Grant Edwards grante Yow! One FISHWICH coming
at up!!
visi.com
Grant Edwards
> Grant Edwards wrote:
>>
>> The "+" operator can mean several things:
>>
>> integer addition
>> pointer addition
>> floating point addition
>
> Add, add, add. All addition. The details may vary slightly (pointer
> arithmetic, for example) but the basic semantics are the same.
If you think integer addition and FP addition "vary slightly", you've
obviously never had to do FP in SW.
--
Grant Edwards grante Yow! Clear the
at laundromat!! This
visi.com whirl-o-matic just had a
nuclear meltdown!!
Grant Edwards
Yes. It's neither programmer-controlled not extensible, but C has
overloaded operators.
--
Grant Edwards grante Yow! BARBARA STANWYCK
at makes me nervous!!
visi.com
Mike Meyer
BCPL, maybe. The only type it had was integer. You could dereference
them, but adding one and dereferencing got the next integer, with no
overlap. It did have binary and unary operators that shared
spelling.constants. See <URL:
http://cm.bell-labs.com/cm/cs/who/dmr/bcpl.html >.
<mike
--
Mike Meyer <m...@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Martin v. Löwis
> > The "+" operator can mean several things:
> >
> > integer addition
> > pointer addition
> > floating point addition
>
> Add, add, add. All addition. The details may vary slightly (pointer
> arithmetic, for example) but the basic semantics are the same.
So then no language has operator overloading: "+" means always "to
add". How precisely addition acts on the internal representation
certainly varies, but this is apparently a detail that you consider
irrelevant.
I can assure you that the C compiler takes very different actions and
emits very different code depending on the types of the arguments -
just like for the user-extensible overloading in C++.
> > unary postive
>
> That's a different operator -- it's unary, not binary.
Typically, people consider the number of arguments as a minor detail
when they talk about method overloading: f.foo(3) and
f.foo("Hello","world") are considered overloaded methods in C++ and
Java even though the number of arguments varies. For the same reason,
unary and binary + should be considered overloaded operators.
> The fact that it's represented by the same character in source code
> is a matter of syntax, not of operator overloading.
It appears that this is a matter of terminology. My definition is "an
operator is overloaded if the same operator has different effects
depending on the number and types of its arguments". It appears that
this terminology is shared by a number of people in this group.
My guess is that people who had formal training in a single language
will associate any term with the definition that this term had for
this language. People who have been exposed to more languages tend to
accept generalizations as useful, too.
Regards,
Martin
Martin v. Löwis
> > On 18 Jan 2003 19:56:24 GMT, Grant Edwards <gra...@visi.com> wrote:
> > Otherwise, I have a tough time thinking of a language
> > that doesn't have operator "overloading"...
>
> BCPL, maybe. The only type it had was integer.
By the same line of argument: Tcl (atleast earlier versions). It had
only a single type (string), so you can't do overloading on the type.
Furthermore, Tcl does not have operators (only commands), so there
can't be any operator overloading :-)
Of course, the expr command would support both strings that represent
floats and strings that represent integers, but it is unclear whether
this isn't just promotion instead of overloading - the result would be
a string, in any case.
Regards,
Martin
Jp Calderone
Many ML variants lack it to some extent. In O'Caml, for example, + only
works on integers. For arbitrary integers (Nums), +/ is the addition
operator (likewise for */, //, %/, etc).
Jp
--
12:00am up 34 days, 9:48, 3 users, load average: 0.23, 0.25, 0.22
Donn Cave
...
| It appears that this is a matter of terminology. My definition is "an
| operator is overloaded if the same operator has different effects
| depending on the number and types of its arguments". It appears that
| this terminology is shared by a number of people in this group.
|
| My guess is that people who had formal training in a single language
| will associate any term with the definition that this term had for
| this language. People who have been exposed to more languages tend to
| accept generalizations as useful, too.
Maybe it would help to consider why we're asking. If the goal is to
arrive at an explanation that resolves some potential confusions about
how Python might work, I propose that "overloading" is a term we're
better off without.
Isn't it reasonably true that operators in Python are a notational
convenience for the same method dispatch that's conceptually used
anywhere else? "a + b" is "a.__add__(b)". It has different effects
depending on number and type of its arguments, but not really - if
b is 9 or "hi" or [] makes no difference, the same function will be
called notwithstanding.
The complications - a.__add__ may not exist, b.__radd__ may be called
then, pages of code inside Python may be devoted to sorting out the
possibilities - are just footnotes. Tim Peter's explanation of why
Python doesn't have overloading applies just the same to operators -
lacking type declarations, there's still no way to spell it.
Donn Cave, do...@drizzle.com
James Kew
> unary and binary + should be considered overloaded operators.
Python thinks they're distinct: __pos__ and __add__.
However,
> My guess is that people who had formal training in a single language
> will associate any term with the definition that this term had for
> this language.
You're right: my C-with-a-smattering-of-C++ background is showing and I was
interpreting "operator overloading" as "overloadable by the programmer". A
tip of the hat to you and Grant for demonstrating to me how it can have
wider meaning.
--
James Kew
jame...@btinternet.com
Martin v. Löwis
> Maybe it would help to consider why we're asking. If the goal is to
> arrive at an explanation that resolves some potential confusions about
> how Python might work, I propose that "overloading" is a term we're
> better off without.
That might well be. I'm still not certain what the OP was asking.
> Isn't it reasonably true that operators in Python are a notational
> convenience for the same method dispatch that's conceptually used
> anywhere else?
Not really. Some operators can't be represented in method calls,
e.g. "and" and "or", as they short-circuit evaluation of the
arguments.
> "a + b" is "a.__add__(b)".
Not really.
>>> 3+4.0
7.0
>>> (3).__add__(4.0)
NotImplemented
The binary + may invoke all of the following: __add__, __radd__,
__coerce__. So these methods should be considered as helpers in
providing the meaning of the operator.
> The complications - a.__add__ may not exist, b.__radd__ may be called
> then, pages of code inside Python may be devoted to sorting out the
> possibilities - are just footnotes. Tim Peter's explanation of why
> Python doesn't have overloading applies just the same to operators -
> lacking type declarations, there's still no way to spell it.
If you take overloading to mean "different behaviour depending on the
type of the arguments", then I do think there is a way to spell
it. It's just that the spelling doesn't involve the name of the
operator, but definitions of these helper methods.
Regards,
Martin