Does python support multi prototype.

[angel]

Hi

Java and cpp support one function name multi function prototype.
For example:
A:
int func1(String s){}
int func1(int i){}

B:
int func1(String s){}
int func1(String s, int i){}

Does python support it?

Thanx

[Chris Dutton]

Re: Does python support multi prototype.

angel wrote:[color=blue]
> Hi
>
> Java and cpp support one function name multi function prototype.
> For example:
> A:
> int func1(String s){}
> int func1(int i){}
>
> B:
> int func1(String s){}
> int func1(String s, int i){}
>
> Does python support it?[/color]

No, but it doesn't have to. The type of a function's arguments are not
statically limited.

def foo(bar):
print bar

I can call this as easily with one type as with another:

foo(1)
foo("baz")

As for the number of arguments a function takes, it's possible to use
the * operator to slurp extra arguments up into a list.

def foo(bar, *extras):
...

foo(1)
foo("baz")
foo("baz", "hello", "world")

[Matteo Dell'Amico]

Re: Does python support multi prototype.

angel wrote:[color=blue]
> Java and cpp support one function name multi function prototype.[/color]
[...][color=blue]
> Does python support it?[/color]

Not natively, but - if you really need them - there are modules that
make them possible.

Have a look at
http://gnosis.cx/publish/programming...ython_b12.html , and
maybe at
http://codespeak.net/pypy/index.cgi?...ltimethod.html too.

--
Ciao,
Matteo

[Jorgen Grahn]

Re: Does python support multi prototype.

On Wed, 04 Aug 2004 02:17:11 GMT, Chris Dutton <rubyguru@hotma il.com> wrote:[color=blue]
> angel wrote:[color=green]
>> Hi
>>
>> Java and cpp support one function name multi function prototype.[/color][/color]

To be pedantic, C++ is called "C++", not "cpp", and what you seem to refer
to is what C++ calls "overloaded function names" or "overloadin g".

....[color=blue][color=green]
>> Does python support it?[/color]
>
> No, but it doesn't have to. The type of a function's arguments are not
> statically limited.[/color]
....

Yes, but that's not as elegant in cases where the arguments' types has to
trigger very different processing. I can even imagine situations where
foo(S) and a foo(T) do completely different things, and still 'foo' is the
best name for both of them.

I miss overloading in Python from time to time, but I can live without it.
It is, after all, closely tied to a type system which is desirable in C++
and Java, but not in Python.

/Jorgen

--
// Jorgen Grahn <jgrahn@ ''If All Men Were Brothers,
\X/ algonet.se> Would You Let One Marry Your Sister?''

[Peter Hansen]

Re: Does python support multi prototype.

Jorgen Grahn wrote:
[color=blue]
> Yes, but that's not as elegant in cases where the arguments' types has to
> trigger very different processing. I can even imagine situations where
> foo(S) and a foo(T) do completely different things, and still 'foo' is the
> best name for both of them.
>
> I miss overloading in Python from time to time, but I can live without it.
> It is, after all, closely tied to a type system which is desirable in C++
> and Java, but not in Python.[/color]

(untested code, may be minor bugs)

def _foo_S(arg):
# do something with arg, which is an S

def _foo_T(arg):
# do something with arg, which is a T

def _foo_whatever(a rg):
# do something with arg when it's a "whatever"

# ad nauseum...

def foo(arg):
'''generic dispatcher for foo() function'''
try:
func = globals()['_foo_%s' % type(arg).__nam e__]
except KeyError:
raise TypeError('inva lid type for function foo', arg)
else:
func(arg)


If you _really_ miss it from time to time, then it's _really_
easy to add it so that it's available in a fairly elegant fashion
when you do need it.

The above won't handle old-style classes, but adding support
for them would be pretty trivial too. (Just need to check for
the case where the type is "instance" and use arg.__class__
instead of type(arg).)

-Peter

[Chris Dutton]

Re: Does python support multi prototype.

Jorgen Grahn wrote:
[color=blue]
> On Wed, 04 Aug 2004 02:17:11 GMT, Chris Dutton <rubyguru@hotma il.com> wrote:
>[color=green]
>>angel wrote:[color=darkred]
>>>Does python support it?[/color]
>>
>>No, but it doesn't have to. The type of a function's arguments are not
>>statically limited.[/color]
>
> ...
>
> Yes, but that's not as elegant in cases where the arguments' types has to
> trigger very different processing. I can even imagine situations where
> foo(S) and a foo(T) do completely different things, and still 'foo' is the
> best name for both of them.[/color]

So use the existing control flow structures to decide which set of code
to execute at runtime. It's certainly not going to be as efficient as a
compiled language which can make the distinction at compile time, but
it's easily as elegant a way of thinking about the problem.

def foo(bar):
if (isinstance(bar , int)):
...
elif (isinstance(bar , str)):
...
else
...

Now, if only Python had a smart "switch" style construct like Ruby or
Groovy, since "isinstance " hurts my eyes. :-)

def foo(bar)
case bar
when Integer
...
when String
...
else
...
end
end

[Jorgen Grahn]

Re: Does python support multi prototype.

On Wed, 04 Aug 2004 10:20:53 -0400, Peter Hansen <peter@engcorp. com> wrote:[color=blue]
> Jorgen Grahn wrote:[/color]
....[color=blue][color=green]
>> I miss overloading in Python from time to time, but I can live without it.
>> It is, after all, closely tied to a type system which is desirable in C++
>> and Java, but not in Python.[/color]
>
> (untested code, may be minor bugs)[/color]
....[color=blue]
>
> If you _really_ miss it from time to time, then it's _really_
> easy to add it so that it's available in a fairly elegant fashion
> when you do need it.[/color]

Well, I don't _really_ miss overloading that much. Not enough to try to
squeeze it into Python when I know it's an idiom that doesn't really fit.

Your code was kind of elegant, but kind of misses the point with
overloading, I think. At least, it's not anything I'd want to do in most
situations where overloading would have been nifty in C++. IMHO.

/Jorgen

--
// Jorgen Grahn <jgrahn@ ''If All Men Were Brothers,
\X/ algonet.se> Would You Let One Marry Your Sister?''

[Peter Hansen]

Re: Does python support multi prototype.

Jorgen Grahn wrote:
[color=blue]
> Your code was kind of elegant, but kind of misses the point with
> overloading, I think. At least, it's not anything I'd want to do in most
> situations where overloading would have been nifty in C++. IMHO.[/color]

Okay, fair enough. Would you be able to describe any situation
in which you have found overloading to be useful in C++. (Note,
not merely nifty, but useful?) In my experience, most of the
cases where I used it in C++ were actually cases of poor design
and should have been done differently, in hindsight.

-Peter

[Jorgen Grahn]

Re: Does python support multi prototype.

On Wed, 04 Aug 2004 23:08:28 -0400, Peter Hansen <peter@engcorp. com> wrote:[color=blue]
> Jorgen Grahn wrote:
>[color=green]
>> Your code was kind of elegant, but kind of misses the point with
>> overloading, I think. At least, it's not anything I'd want to do in most
>> situations where overloading would have been nifty in C++. IMHO.[/color]
>
> Okay, fair enough. Would you be able to describe any situation
> in which you have found overloading to be useful in C++. (Note,
> not merely nifty, but useful?)[/color]

Well, it's needed for output streams to work -- the << operators which push
objects onto streams cannot be member functions - and they better have the
same "names".

I also suspect it's vital to generic programming using templates and such ...

Also when you want common functions that operate on objects without being
members -- the thing Python solves by translating len(x) to x.__len__() etc.
[color=blue]
> In my experience, most of the
> cases where I used it in C++ were actually cases of poor design
> and should have been done differently, in hindsight.[/color]

If we are talking member functions, you may have something there ...
On the other hand, I don't see embedding a type name in the method name as a
better alternative, ever.

I wrote a small Python helper class yesterday, for reasons too complicated
to explain here. I called it "Cluster", and it was really just a set of
(x,y) points which I expected to be roughly clustered around some point.
I needed to find the distance between (the center of) a Cluster and a point,
but also between two Clusters.

Had that been C++, I would have been tempted to add two methods:
double Cluster::distan ce(const Cluster&) const;
double Cluster::distan ce(const Point&) const;
but for some reason (asymmetry?) that feels like the easy and slightly wrong
way out.

Anyway, this was Python so I didn't have to think much about that ;-)

/Jorgen

--
// Jorgen Grahn <jgrahn@ ''If All Men Were Brothers,
\X/ algonet.se> Would You Let One Marry Your Sister?''

[xtian]

Re: Does python support multi prototype.

Matteo Dell'Amico <della@toglimi. linux.it> wrote in message news:<w54Qc.296 47$OH4.805468@t wister1.libero. it>...[color=blue]
> angel wrote:[color=green]
> > Java and cpp support one function name multi function prototype.[/color]
> [...][color=green]
> > Does python support it?[/color]
>
> Not natively, but - if you really need them - there are modules that
> make them possible.
>
> Have a look at
> http://gnosis.cx/publish/programming...ython_b12.html , and
> maybe at
> http://codespeak.net/pypy/index.cgi?...ltimethod.html too.[/color]

One thing to note is that these Lisp-ish multimethods are more
powerful than Java- or C#-style method overloading, because the method
dispatch is done at runtime using the actual types of the arguments.
In Java and C# overload selection is done at compile time, so if
you've got, frex:

public class Thing {
public void DoSomething(Int eger val) {
...
}

public void DoSomething(Str ing val) {
...
}

public void DoSomething(Obj ect val) {
...
}
}


[and then]

Object o = "fish";
Thing t = new Thing();
t.DoSomething(o );

.... you'll always get the object version of DoSomething called,
because the declared type of o is Object.

Which always annoyed me.

xtian