On Wed, 14 Nov 2007, Brett Cannon wrote: > As Collin already pointed out, it sounds like you want PEP 362 to get > into the stdlib. I have not made a big push to try to get my existing > implementation into Python 2.6/3.0, but I plan to at some point.
Yes, it had not occurred to me to check the existing PEPs for my PEP before proposing it. Now that I've read it I have a couple of comments, but it is close to what I'm looking for. >> I've put the code below, but I wonder if the real solution is just to create >> an >> interface to already-existing capability? It occurs to me that the >> implementation is likely to be in the interpreter itself and not written in >> Python. > > I don't see why a Python implementation is bad. If you make this > information lazy then it is not such a big deal to have it take a > little bit longer than if it was implemented in C. I don't have any problem with a Python implementation. In particular, I'm not concerned in this case about the performance. Rather what I actually wanted was a way to just bind arguments and then get the resulting dictionary (what would usually become locals()). I realized that I could create a Signature object with a binding method, but that I would just be duplicating part of the Python interpreter. I haven't studied the Python interpreter so I don't know if it is feasible to re-use that (presumably highly optimized for actually calling procedures, not just binding arguments) code or if it makes more sense to simply re-implement it. >> One possible improvement (and I'm not sure it's better, so I'm just putting >> it >> out there): perhaps expand_args should be renamed to __call__. Then >> essentially >> a Signature object would be a procedure whose body is just "return locals >> ()". > > __call__ is already used a method name for objects that can be called. Yes, that is why I used that name. The idea is that a Signature object be callable, have itself as signature, and return the dictionary of locals resulting from the procedure call argument binding process. You can also think of (my idea of) Signature objects as providing a simple way to create lots of special-case dictionary constructors. More (semi-)formally, if the body of a procedure p is "return locals ()", then p(...) is the same as p.__signature__(...). A couple of comments about PEP-362: 1. For the "name" attribute of the Parameter object, I think it needs to be str | tuple(str) | tuple(tuple(str)) | ....: >>> def a ((b,c),(d,(e,f))): ... print b,c,d,e,f ... >>> a <function a at 0x7899b0> >>> a((1,2),(3,(4,5))) 1 2 3 4 5 >>> 2. For "position" of keyword-only parameters, are they allowed to conflict with each other, or does each parameter get a unique value? +1 on not using -1 as a special value. Python is not COBOL. 3. (My apologies if any of these have already been discussed) Under "Implementation", could __signature__ just be a property of callable objects? Not saying anything about implementation, but just being able to say "formataddr.__signature__" feels nicely minimal (to me). 4. Signature.bind - for what I'm doing, I definitely want what would become locals() in a procedure call, i.e. keys in the resulting dictionary are strings. But I can see the other behaviour being useful in other circumstances so maybe there should be bind and bindp, or (see above) __call__ and bind, or something else. 5. var_args... default to None. +10 from me on this one - this is *exactly* what None is, as far as I can tell. I'm new enough that this should probably count for at most +0.1 though. 6. The PEP doesn't say anything about building Signature objects from scratch, and the code does not reassure me. I would like to be able to build a Signature from a sequence of strings for positional parameter names, for example, and provide default values for some parameters. My solution started off: class Signature (object): def __init__ (self, argnames, excessargs=None, excesskeys=None, defaults=None): self.__argnames = tuple (argnames) self.__excessargs = excessargs self.__excesskeys = excesskeys if defaults is None: defaults = {} self.__defaults = dict (defaults) [....] Thanks for the responses. I hope the above is at least in part not a re-hash of old discussions. Isaac Morland CSCF Web Guru DC 2554C, x36650 WWW Software Specialist _______________________________________________ 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