On Wed, Jun 6, 2012 at 10:20 AM, Yury Selivanov <[email protected]> wrote: > On 2012年06月06日, at 11:38 AM, Steven D'Aprano wrote: >> Functions already record their name (twice!), and it is simple enough to >> query func.__name__. What reason is there for recording it a third time, in >> the Signature object? > > Signature object holds function's information and presents it in a > convenient manner. It makes sense to store the function's name, > together with the information about its parameters and return > annotation. > >> Besides, I don't consider the name of the function part of the function's >> signature. Functions can have multiple names, or no name at all, and the >> calling signature remains the same. > > It always have _one_ name it was defined with, unless it's > a lambda function. > >> Even if we limit the discussion to distinct functions (rather than a single >> function with multiple names), I consider spam(x, y, z) ham(x, y, z) and >> eggs(x, y, z) to have the same signature. Otherwise, it makes it difficult >> to talk about one function having the same signature as another function, >> unless they also have the same name. Which would be unfortunate. > > I see the point ;) Let's see what other devs think.
I'm with Steven on this one. What's the benefit to storing the name or qualname on the signature object? That ties the signature object to a specific function. If you access the signature object by f.__signature__ then you already have f and its name. If you get it by calling signature(f), then you also have f and the name. If you are passing signature objects for some reason and there's a use case for which the name/qualname matters, wouldn't it be better to pass the functions around anyway? What about when you create a signature object on its own and you don't care about the name or qualname...why should it need them? Does Signature.bind() need them? FWIW, I think this PEP is great and am ecstatic that someone is pushing it forward. :) -eric _______________________________________________ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com