I haven't been following this whole thread, but it sounds like you want
something like PJE's RuleDispatch package.
There's a Developer Works article about it, put up very recently:
http://www-128.ibm.com/developerworks/linux/library/l-cppeak2/?ca=dgr-
lnxw02aScalingPEAK
PJE (IIRC) based it of
Pierre Barbier de Reuille <[EMAIL PROTECTED]> wrote:
> Now suppose you have two classes A and B, B subclassing A.
> If you define :
>
> @method(A)
> def myfct(f):
> do_something_with_f
>
> Then, you want it to work with any object of type B ... but with either
> Guido's or this implementation, it
On Sun, 25 Sep 2005 09:30:30 +0100, Catalin Marinas <[EMAIL PROTECTED]> wrote:
>Hi,
>
>Sorry if this was previously discussed but it's something I miss in
>Python. I get around this using isinstance() but it would be cleaner
>to have separate functions with the same name but different argument
>ty
In article <[EMAIL PROTECTED]>,
Catalin Marinas <[EMAIL PROTECTED]> wrote:
...
> Of course, duck-typing is simple to use but the parametric
> polymorphism is useful when the types are unrelated. Let's say you
> want to implement a colour-print function which should suppo
Tom Anderson <[EMAIL PROTECTED]> wrote:
> Is there any reason you have to stringify the type signature? Types
> are hashable, so a tuple of types is hashable, so you can just use
> that as a key. Replace "methods[f.func_name][str(types)] = f" with
> "methods[f.func_name][types] = f" and "type_str =
Kay Schluehr a écrit :
> Catalin Marinas wrote:
>
>>Hi,
>>
>>Sorry if this was previously discussed but it's something I miss in
>>Python. I get around this using isinstance() but it would be cleaner
>>to have separate functions with the same name but different argument
>>types. I think the idea g
"Kay Schluehr" <[EMAIL PROTECTED]> wrote:
> Catalin Marinas wrote:
>> Hi,
>>
>> Sorry if this was previously discussed but it's something I miss in
>> Python. I get around this using isinstance() but it would be cleaner
>> to have separate functions with the same name but different argument
>> type
Catalin Marinas wrote:
> Hi,
>
> Sorry if this was previously discussed but it's something I miss in
> Python. I get around this using isinstance() but it would be cleaner
> to have separate functions with the same name but different argument
> types. I think the idea gets quite close to the Lisp/
On Sun, 25 Sep 2005, Catalin Marinas wrote:
> Sorry if this was previously discussed but it's something I miss in
> Python. I get around this using isinstance() but it would be cleaner to
> have separate functions with the same name but different argument types.
> I think the idea gets quite cl
Catalin Marinas wrote:
> Sorry if this was previously discussed but it's something I miss in
> Python. I get around this using isinstance() but it would be cleaner
> to have separate functions with the same name but different argument
> types. I think the idea gets quite close to the Lisp/CLOS
> im
c/Body/mac_defmethod.html. Actually, the
defmehod macro is the base for implementing object polymorphism.
> I _rarely_ need such functionality. Ususally duck-typing suits me
> well.
Of course, duck-typing is simple to use but the parametric
polymorphism is useful when the types are unrelated.
Catalin Marinas wrote:
> Hi,
>
> Sorry if this was previously discussed but it's something I miss in
> Python. I get around this using isinstance() but it would be cleaner
> to have separate functions with the same name but different argument
> types. I think the idea gets quite close to the Lisp/
Hi,
Sorry if this was previously discussed but it's something I miss in
Python. I get around this using isinstance() but it would be cleaner
to have separate functions with the same name but different argument
types. I think the idea gets quite close to the Lisp/CLOS
implementation of methods.
Be
13 matches
Mail list logo
