Does Python have the concept of overloaded functions like C++, C# and other languages have.
Since you cant explicitly specify a data type in python , the concept of overloaded functions within python
cannot then work because how will you differentiate between your functions. You mite answer by saying well your one function will deal with what ever values you give it. Yes that is true but i want a specific function to be called based on the data type of the parameters that you give it. This can be solved with overloaded functions.
For the reason you exposed, Python needs, AFAIK, a different name for a function with different parameters. You could put up a makeshift “overloading” with a set of:
if isinstance(parameter, str):
self.DoThis(parameter)
elif isinstance(parameter, (int, float, boolean)):
self.DoThat(parameter)
and so forth…
···
2008/8/1, musa mhlengi musamhlengi@gmail.com:
Does Python have the concept of overloaded functions like C++, C# and other languages have.
Since you cant explicitly specify a data type in python , the concept of overloaded functions within pythoncannot then work because how will you differentiate between your functions. You mite answer by saying well your one function will deal with what ever values you give it. Yes that is true but i want a specific function to be called based on the data type of the parameters that you give it. This can be solved with overloaded functions.
wxpython-users mailing list
I think no need to overload functions like C++, C#, or Java, in Python.
···
On Fri, Aug 1, 2008 at 4:49 PM, musa mhlengi musamhlengi@gmail.com wrote:
Does Python have the concept of overloaded functions like C++, C# and other languages have.
Since you cant explicitly specify a data type in python , the concept of overloaded functions within python
cannot then work because how will you differentiate between your functions. You mite answer by saying well your one function will deal with what ever values you give it. Yes that is true but i want a specific function to be called based on the data type of the parameters that you give it. This can be solved with overloaded functions.
wxpython-users mailing list
I think the must be need. For example
def division(a, b):
return a / b
i now call this function
example 1:
print division(10, 2)
the answered return will be 5
but if i call it using
print division(10.3, 2.7)
answer return will be 3.81481481481
if you creating a payroll system this can be troublesome!!
···
On Fri, Aug 1, 2008 at 11:11 AM, Widen delight.wjk@gmail.com wrote:
I think no need to overload functions like C++, C#, or Java, in Python.
On Fri, Aug 1, 2008 at 4:49 PM, musa mhlengi musamhlengi@gmail.com wrote:
Does Python have the concept of overloaded functions like C++, C# and other languages have.
Since you cant explicitly specify a data type in python , the concept of overloaded functions within python
cannot then work because how will you differentiate between your functions. You mite answer by saying well your one function will deal with what ever values you give it. Yes that is true but i want a specific function to be called based on the data type of the parameters that you give it. This can be solved with overloaded functions.
wxpython-users mailing list
wxpython-users mailing list
Here's a crude way to get overloaded functions using a decorator to do
name mangling (as in C++).
def mangle(*args):
def closure(a):
def call(*args):
y = '_'.join([a.__name__] + [type(i).__name__ for i in
args])
c = globals().get(y)
if c is None:
raise TypeError
else:
return c(*args)
x = '_'.join([a.__name__] + [i.__name__ for i in args])
globals() = a
return call
return closure
Define your functions as:
@mangle(int,int)
def name(a,b):
print 'int/int'
@mangle(float,int)
def name(a,b):
print 'float/int'
name(1,2) --> prints 'int/int'
name(1.0,2) --> prints 'float/int'
name('s') --> raises TypeError
Mark
P.S. Improvements welcome!
···
On Fri, 2008-08-01 at 11:27 +0200, musa mhlengi wrote:
I think the must be need. For example
musa mhlengi wrote:
I think the must be need. For example
def division(a, b):
return a / bi now call this function
example 1:
*print division(10, 2)*
the answered return will be 5
but if i call it using
*print division(10.3, 2.7)*
answer return will be 3.81481481481
if you creating a payroll system this can be troublesome!!
Usually I think the perceived need for overloaded functions in Python comes from trying to apply paradigms from other languages, but Python isn't other languages.
If you want a division that always returns a float, just always return a float. I don't get why you would want to have two separate functions for what you described. You would have to in other languages which is why you might want to apply your natural inclinations to Python. But Python doesn't require unwieldy solutions.
For example:
def devision(x, y):
return 1.0 * x / y
Now you always get a float, as long as you pass in numbers! You would rather solve this two liner with multiple different functions?
- Mike
If you just need to get a floating number as return, why not use:
def devision(x, y):
return float( x / y)
?
···
2008/8/1 Mike Rooney mxr@qvii.com
musa mhlengi wrote:
I think the must be need. For example
def division(a, b):
return a / b
i now call this function
example 1:
print division(10, 2)
the answered return will be 5
but if i call it using
print division(10.3, 2.7)
answer return will be 3.81481481481
if you creating a payroll system this can be troublesome!!
Usually I think the perceived need for overloaded functions in Python comes from trying to apply paradigms from other languages, but Python isn’t other languages.
If you want a division that always returns a float, just always return a float. I don’t get why you would want to have two separate functions for what you described. You would have to in other languages which is why you might want to apply your natural inclinations to Python. But Python doesn’t require unwieldy solutions.
For example:
def devision(x, y):
return 1.0 * x / y
Now you always get a float, as long as you pass in numbers! You would rather solve this two liner with multiple different functions?
- Mike
wxpython-users mailing list
raffaello wrote:
If you just need to get a floating number as return, why not use:
def devision(x, y):
return float( x / y)
This won't work with float(2/3)
USe this instead:
return x/float(y)
Laszlo Nagy wrote:
raffaello wrote:
If you just need to get a floating number as return, why not use:
def devision(x, y):
return float( x / y)This won't work with float(2/3)
USe this instead:
return x/float(y)
Or the functionally identical solution that I already gave that raffaello was replying to
- Mike
Thanks, Lazslo and Mike: I had not realized that float() casts only the result and not the factors. From now on, I’ll plagiarize without mercy your 1.0*.
···
2008/8/1 Mike Rooney mxr@qvii.com
Laszlo Nagy wrote:
raffaello wrote:
If you just need to get a floating number as return, why not use:
def devision(x, y): return float( x / y)
This won’t work with float(2/3)
USe this instead:
return x/float(y)
Or the functionally identical solution that I already gave that raffaello was replying to
- Mike
wxpython-users mailing list
raffaello wrote:
Thanks, Lazslo and Mike: I had not realized that float() casts only the result and not the factors. From now on, I'll plagiarize without mercy your 1.0*.
personally, I prefer:
def devision(x, y):
return float( x ) / float(y)
it's a bit more explicit that you want both arguments to be interpretable as floats, though it makes little real difference.
Note 1: Aside from being more compact, this is much more in the spirit of python's duck typing than using isinstance(), you shouldn't care if the input is a float, you should only care if it can be converted to one.
Note 2: It's been recognized that the distinction between floats and integers with regard to division is not a good fit with a dynamic language like python, so this is really the way to write it:
>>> from __future__ import division
>>> def division(x, y):
... return x/y
...
>>> division(3.0,4.0)
0.75
>>> division(3,4)
0.75
and if you do want integer division:
>>> def intdiv(x,y):
... return x//y
...
>>> intdiv(3,4)
0
>>> intdiv(3.0,4.0)
0.0
-Chris
···
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov
Christopher Barker <Chris.Barker <at> noaa.gov> writes:
personally, I prefer:
def devision(x, y):
return float( x ) / float(y)it's a bit more explicit that you want both arguments to be
interpretable as floats, though it makes little real difference.
Yes, this is arguable, but
timeit.Timer("r = 1.0 * 3 / 4").timeit()
0.878073923341
timeit.Timer("r = float(3) / 4").timeit()
3.77047005402
timeit.Timer("r = float(3) / float(4)").timeit()
5.48410133576
timeit.Timer("r = 3.0 / 4").timeit()
0.894204739931
wxPython impact:
I'm not a guy running after any speed optimization, but knowing this
can help a lot, eg in drawing/plotting jobs where stupid arithmetic
is extensively used. Analogy: DrawXXXLine() functions.
Note the Python 3 behaviour (3.0b2):
3 / 4
0.75
3 // 4
0
Jean-Michel Fauth, Switzerland
I'm thinking of drawoin
···
Note 1: Aside from being more compact, this is much more in the spirit
of python's duck typing than using isinstance(), you shouldn't care if
the input is a float, you should only care if it can be converted to one.Note 2: It's been recognized that the distinction between floats and
integers with regard to division is not a good fit with a dynamic
language like python, so this is really the way to write it:>>> from __future__ import division
>>> def division(x, y):
... return x/y
...
>>> division(3.0,4.0)
0.75>>> division(3,4)
0.75and if you do want integer division:
>>> def intdiv(x,y):
... return x//y
...
>>> intdiv(3,4)
0
>>> intdiv(3.0,4.0)
0.0-Chris
jmf wrote:
timeit.Timer("r = 1.0 * 3 / 4").timeit()
0.878073923341
timeit.Timer("r = float(3) / 4").timeit()
3.77047005402
timeit.Timer("r = float(3) / float(4)").timeit()
5.48410133576
timeit.Timer("r = 3.0 / 4").timeit()
0.894204739931
ahhh -- that's the famous python function calling overhead, I suppose. It's interesting that the extra float multiplication is essentially free in this case. In fact, if you believe those numbers exactly -- the extra multiplication takes negative time
wxPython impact:
I'm not a guy running after any speed optimization, but knowing this
can help a lot, eg in drawing/plotting jobs where stupid arithmetic
is extensively used.
which is why I use numpy. It will swamp any of these differences if you're working with a lot of numbers, and if you're not, then speed probably doesn't matter.
-Chris
···
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov