Eric, On 2012-06-06, at 1:02 PM, Eric Snow wrote: > On Wed, Jun 6, 2012 at 10:20 AM, Yury Selivanov <yselivanov...@gmail.com> > 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?
Yes, 'Signature.bind' needs 'qualname' for error messages. But it can be stored as a private attribute. I like the idea of 'foo(a)' and 'bar(a)' having the identical signatures, however, I don't think it's possible. I.e. we can't make it that the 'signature(foo) is signature(bar)'. We can implement the __eq__ operator though. For me, the signature of a function is not just a description of its parameters, so it seems practical to store its name too. > FWIW, I think this PEP is great and am ecstatic that someone is > pushing it forward. :) Thanks ;) - Yury _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
