On 11/29/06, Talin <[EMAIL PROTECTED]> wrote:
Guido van Rossum wrote: > Have you thought much about the issue of different signature? The > regular method table only has functions taking one or more objects and > returning an object. (There are a few flags to indicate variations on > the call args.) The special slots have all sorts of other signatures, > some returning int, some returning void, some taking ints or C > strings, etc. (And changing this would be a huge inefficiency in some > cases.) > > Not using some variant of C (or C99) struct initialization means more > chance for undetected errors since you will necessarily have to cast > everything to a standard type and then the compiler can't type-check > that the function signature matches the slot's needs. Yes, there will be some loss of type safety. I'm not sure what to say about that. (Although, there is one benefit that you will at least be able to declare the "self" argument as its concrete type, rather than as PyObject *.)
I must be missing something, why is this any different than what you can do now? You either define the function with the exact call signature as typed for the struct field, or you define how you want the arguments to be treated and you cast to the call signature that is expected for the struct field. -Brett
_______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
