Re: [Python-Dev] Python Library Addition: First-class Procedure Signatures
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
>>> 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, x36650WWW Software Specialist
___
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
Re: [Python-Dev] Python Library Addition: First-class Procedure Signatures
On Thu, 15 Nov 2007, Isaac Morland wrote: > 1. For the "name" attribute of the Parameter object, I think it needs to > be str | tuple(str) | tuple(tuple(str)) | : No, that's still wrong. I think it needs to be T, where T == str | tuple(T). Isaac Morland CSCF Web Guru DC 2554C, x36650WWW Software Specialist ___ 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
[Python-Dev] Summary of Tracker Issues
ACTIVITY SUMMARY (11/08/07 - 11/15/07) Tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 1330 open (+19) / 11604 closed (+26) / 12934 total (+45) Open issues with patches: 425 Average duration of open issues: 687 days. Median duration of open issues: 798 days. Open Issues Breakdown open 1325 (+19) pending 5 ( +0) Issues Created Or Reopened (47) ___ test_import breaks on Linux 11/09/07 http://bugs.python.org/issue1377reopened gvanrossum py3k Garbage collection not working correctly in Python 2.3 11/09/07 CLOSED http://bugs.python.org/issue1405reopened tiran [performance] Too many closed() checkings11/08/07 http://bugs.python.org/issue1407created wojtekwalczak py3k Inconsistence in multiply list 11/08/07 CLOSED http://bugs.python.org/issue1408created beco new keyword-only function parameters interact badly with nested 11/08/07 http://bugs.python.org/issue1409created _doublep py3k BaseHTTPServer cannot accept Unicode data11/08/07 CLOSED http://bugs.python.org/issue1410created isonno A typo in tutorial 11/09/07 CLOSED http://bugs.python.org/issue1411created falsetru test_subprocess fails on SuSE 10 11/09/07 http://bugs.python.org/issue1412created dvadasz int literal methods inaccessible 11/09/07 CLOSED http://bugs.python.org/issue1413created mykhal Fix for refleak tests11/09/07 http://bugs.python.org/issue1414created tiran py3k, patch py3k: pythonw.exe fails because std streams a missing11/10/07 CLOSED http://bugs.python.org/issue1415created tiran py3k @prop.setter decorators 11/10/07 CLOSED http://bugs.python.org/issue1416created gvanrossum patch Weakref not working properly 11/10/07 CLOSED http://bugs.python.org/issue1417created MHOOO Python/hypot.c is never used 11/10/07 CLOSED http://bugs.python.org/issue1418created marketdickinson ssl module version 1.10 causes TypeError when accepting connecti 11/11/07 CLOSED http://bugs.python.org/issue1419created complex Unicode literals in tokenize.py and tests. 11/11/07 CLOSED http://bugs.python.org/issue1420created ron_adam py3k, patch python.org: outdated and false information 11/11/07 CLOSED http://bugs.python.org/issue1421created tiran Writing to an invalid fd doesn't raise an exception 11/11/07 CLOSED http://bugs.python.org/issue1422created tiran py3k wave sunau aifc 16bit errors 11/11/07 http://bugs.python.org/issue1423created jeroen py3k: readline and rlcompleter doesn't list choices 11/11/07
Re: [Python-Dev] Python Library Addition: First-class Procedure Signatures
On Nov 15, 2007 8:42 AM, Isaac Morland <[EMAIL PROTECTED]> wrote: > 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__(...). > Fair enough, but I prefer having a method for it. > 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 > > >>> a((1,2),(3,(4,5))) > 1 2 3 4 5 > >>> You are taking annotations a little too far in terms of typing. =) There are no type checks for the annotations; they are for documentation purposes only. Plus tuple parameters are gone as of Py3K thanks to my prodding to ditch them so I am really not going to worry about them now. =) > > 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. > It is just he numeric order that the arguments are found, period. Keyword-only arguments are given a index position, it just doesn't really mean much other than giving it a numeric position. > 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). The idea has been to add the code to the stdlib and let people try them out first. If they ended up being used often enough then discussion of putting a signature object on every callable could be discussed. > > 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. > I only want to bother supporting one or the other. Doing the reverse is one or two lines of code. > 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. That's because there is no way. =) > 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: > >
Re: [Python-Dev] Python Library Addition: First-class Procedure Signatures
On Nov 14, 2007 1:18 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: > On Nov 14, 2007 10:30 AM, Isaac Morland <[EMAIL PROTECTED]> wrote: > > So I wrote a Signature class. Instances of the class represent all the > > information present between the parentheses of a procedure definition. > > Properties are provided to get the information out, and an expand_args > > method > > can be called to expand arguments into a dictionary. This expand_args > > method > > implements (if I've done it right) the argument conversion part of section > > 5.3.4 of the Python Reference Manual > > (http://docs.python.org/ref/calls.html). > > 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. Every time I read PEP 362, I get lost in the details. When you get around to working on it again, could you add a bunch of examples? That would make it much easier to tell why we want all those objects and attributes. FWIW, Isaac's version of bind() that returns a regular str->object dict is all I've ever needed in my own code. STeVe -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy ___ 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
Re: [Python-Dev] Hello, I'm the other new guy
On Nov 15, 2007 1:17 PM, Thomas Heller <[EMAIL PROTECTED]> wrote: > PS: I smiled when I saw your introductions. Amaury: I also have > 5 children, and Christian: I'm also a 'strange' guy (but not > metal and gothic). I feel left out. I have only one child and I don't qualify as 'strange' by any stretch of the imagination... Sometimes I think I'm the only regular guy working on Python. ;-) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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
Re: [Python-Dev] Hello, I'm the other new guy
Facundo Batista schrieb: > 2007/11/14, Christian Heimes <[EMAIL PROTECTED]>: > >> After Amaury introduced himself I've decided that I *have* to take some >> time to introduce myself, too. It's probably too late to say welcome to both Christian and Amaury, also we have already met in the bug tracker. I'm especially pleased that both of you also care about and work on Windows stuff - much appreciated. Thomas PS: I smiled when I saw your introductions. Amaury: I also have 5 children, and Christian: I'm also a 'strange' guy (but not metal and gothic). ___ 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
Re: [Python-Dev] Hello, I'm the other new guy
> "Guido" == Guido van Rossum <[EMAIL PROTECTED]> writes: Guido> I feel left out. I have only one child and I don't qualify as Guido> 'strange' by any stretch of the imagination... Sometimes I think I'm Guido> the only regular guy working on Python. ;-) Ah well, that explains a lot! :-) Anyone else here think they're normal? 1. You're a programmer 2. You work on Python 3. You're on the dev mailing list (and you read it) Each one of those must be worth at least one unit of standard deviation. Terry ___ 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
Re: [Python-Dev] Hello, I'm the other new guy
Guido van Rossum wrote: > I feel left out. I have only one child and I don't qualify as > 'strange' by any stretch of the imagination... Sometimes I think I'm > the only regular guy working on Python. ;-) Gosh! Your new beard definitely puts you in the strange guys category. I'm astonished that your son isn't afraid of you with all those hairs in your face. ;) Christian ___ 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
Re: [Python-Dev] Hello, I'm the other new guy
On Nov 15, 2007 1:43 PM, Christian Heimes <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > I feel left out. I have only one child and I don't qualify as > > 'strange' by any stretch of the imagination... Sometimes I think I'm > > the only regular guy working on Python. ;-) > > Gosh! Your new beard definitely puts you in the strange guys category. > I'm astonished that your son isn't afraid of you with all those hairs in > your face. ;) It's a matter of starting them to get used to it when they're young. :-) At least I don't rattle when I walk... -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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
[Python-Dev] Last chance for PyCon talk & tutorial proposals!
Thanks to all the proposal authors so far, we have received lots of proposals for PyCon talks & tutorials. But we'd like to have even more. Alas, the proposal submission deadline should have been set after a weekend, not before. So we have decided to extend the proposal submission deadline to Monday, November 19 at midnight (Chicago time). This gives you a *whole extra weekend* to write up your talk and tutorial ideas! If you've been procrastinating, stop! Get started on a proposal instead! See the call for conference talk proposals: http://us.pycon.org/2008/conference/proposals/ Topic ideas: http://wiki.python.org/moin/Talk_Subjects http://wiki.python.org/moin/PyCon2007/Feedback#head-e2dca74d1492e49fae11550e6cbc40fa18a17f40 See the call for tutorial proposals http://us.pycon.org/2008/tutorials/proposals/ Topic ideas from the PyCon 2007 feedback: http://wiki.python.org/moin/PyCon2007/Feedback/TutorialIdeas I hope to see (and hear) you at PyCon 2008! http://us.pycon.org -- David Goodger, PyCon 2008 Chair signature.asc Description: OpenPGP digital signature ___ 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
Re: [Python-Dev] New python developer
On Nov 13, 2007 1:05 PM, Amaury Forgeot d'Arc <[EMAIL PROTECTED]> wrote: > > I can also help on win32 specific development. As an example, I find > that the distutils module don't work very well with the new compilers. > I won't be of much help on Unix, though. We need more help on Windows! Most of us are Unix only, so it will be great to have some help here. There are many windows bugs in the bug tracker if you'd like to take a look there. Welcome and good work so far! It's great seeing some of the memory issues in py3k get addressed. n ___ 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
