Will McGugan wrote:
> I'm forced to use C++ and STL at work, and consequently miss the ease
> of use of Python. I was wondering if there was a C++ library that
> implemented the fundamental objects of Python as close as possible,
> perhaps using STL underneath the hood.
Not copying Python but it h
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
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" <[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 separa
"Diez B. Roggisch" <[EMAIL PROTECTED]> wrote:
> google for gnosis utils and multimethods to see a more "oldfashioned"
> implementation.
I now remember to have seen it but it requires a lot of typing to
achieve it and you would call a different function name from the one
you define, reducing the co
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