I'm thrilled to see the extended call syntax patches go in! One less wart in the language! Jeremy ZitBlaster Hylton and Greg Noxzema Ewing! --david
I'm thrilled to see the extended call syntax patches go in! One less wart in the language!
but did he compile before checking in? ..\Python\compile.c(1225) : error C2065: 'CALL_FUNCTION_STAR' : undeclared identifier (compile.c and opcode.h both mention this identifier, but nobody defines it... should it be CALL_FUNCTION_VAR, perhaps?) </F>
On Wed, 29 Mar 2000, Fredrik Lundh wrote:
You beat me to it. I read David's message and got so excited i just had to try it right away. So i updated my CVS tree, did "make", and got the same error: make[1]: Entering directory `/home/ping/dev/python/dist/src/Python' gcc -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c compile.c -o compile.o compile.c: In function `com_call_function': compile.c:1225: `CALL_FUNCTION_STAR' undeclared (first use in this function) compile.c:1225: (Each undeclared identifier is reported only once compile.c:1225: for each function it appears in.) make[1]: *** [compile.o] Error 1
But CALL_FUNCTION_STAR is mentioned in the comments... #define CALL_FUNCTION 131 /* #args + (#kwargs<<8) */ #define MAKE_FUNCTION 132 /* #defaults */ #define BUILD_SLICE 133 /* Number of items */ /* The next 3 opcodes must be contiguous and satisfy (CALL_FUNCTION_STAR - CALL_FUNCTION) & 3 == 1 */ #define CALL_FUNCTION_VAR 140 /* #args + (#kwargs<<8) */ #define CALL_FUNCTION_KW 141 /* #args + (#kwargs<<8) */ #define CALL_FUNCTION_VAR_KW 142 /* #args + (#kwargs<<8) */ The condition (CALL_FUNCTION_STAR - CALL_FUNCTION) & 3 == 1 doesn't make much sense, though... -- ?!ng
"FL" == Fredrik Lundh <effbot@telia.com> writes:
I'm thrilled to see the extended call syntax patches go in! One less wart in the language!
FL> but did he compile before checking in? Indeed, but not often enough :-). FL> ..\Python\compile.c(1225) : error C2065: 'CALL_FUNCTION_STAR' : FL> undeclared identifier FL> (compile.c and opcode.h both mention this identifier, but nobody FL> defines it... should it be CALL_FUNCTION_VAR, perhaps?) This was a last minute change of names. I had previously compiled under the old names. The Makefile doesn't describe the dependency between opcode.h and compile.c. And the compile.o file I had worked, because the only change was to the name of a macro. It's too bad the Makefile doesn't have all the dependencies. It seems that it's necessary to do a make clean before checking in a change that affects many files. Jeremy
On Tue, 28 Mar 2000, Jeremy Hylton wrote:
I updated again and rebuilt. >>> def sum(*args): ... s = 0 ... for x in args: s = s + x ... return s ... >>> sum(2,3,4) 9 >>> sum(*[2,3,4]) 9 >>> x = (2,3,4) >>> sum(*x) 9 >>> def func(a, b, c): ... print a, b, c ... >>> func(**{'a':2, 'b':1, 'c':6}) 2 1 6 >>> func(**{'c':8, 'a':1, 'b':9}) 1 9 8 >>> *cool*. So does this completely obviate the need for "apply", then? apply(x, y, z) <==> x(*y, **z) -- ?!ng
I think so (except for backwards compatibility). The 1.6 docs for apply should point this out! --Guido van Rossum (home page: http://www.python.org/~guido/)
"DA" == David Ascher <DavidA@ActiveState.com> writes:
DA> But most importantly, IMO: DA> class SubClass(Class): DA> def __init__(self, a, *args, **kw): DA> self.a = a DA> Class.__init__(self, *args, **kw) DA> Much neater. This version of method overloading was what I liked most about Greg's patch. Note that I also prefer: class SubClass(Class): super_init = Class.__init__ def __init__(self, a, *args, **kw): self.a = a self.super_init(*args, **kw) I've been happy to have all the overridden methods explicitly labelled at the top of a class lately. It is much easier to change the class hierarchy later. Jeremy
Changing the definition of class Nums to class Nums: def __getitem__(self, i): if 0 <= i < 10: return i raise IndexError def __len__(self): return 10 I.e. adding the __len__() method avoids the SystemError. Either the *arg call should not depend on the sequence being lenght-able, or it should error check that the length calculation doesn't return -1 or raise an exception. Looking at PySequence_Length() though, it seems that m->sq_length(s) can return -1 without setting a type_error. So the fix is either to include a check for return -1 in PySequence_Length() when calling sq_length, or instance_length() should set a TypeError when it has no __len__() method and returns -1. I gotta run so I can't follow this through -- I'm sure I'll see the right solution from someone in tomorrow mornings email :) -Barry
"KY" == Ka-Ping Yee <ping@lfw.org> writes:
| It should be noted that "apply" has the same problem, with a | different counterintuitive error message: >> n = Nums() apply(sum, n) | Traceback (innermost last): | File "<stdin>", line 1, in ? | AttributeError: __len__ The patch I just posted fixes this too. The error message ain't great, but at least it's consistent with the direct call. -Barry -------------------- snip snip -------------------- Traceback (innermost last): File "/tmp/doit.py", line 15, in ? print apply(sum, n) TypeError: len() of unsized object
"BAW" == Barry A Warsaw <bwarsaw@cnri.reston.va.us> writes:
BAW> Uh oh. Fresh CVS update and make clean, make: >>> sum(*n) | Traceback (innermost last): | File "<stdin>", line 1, in ? | SystemError: bad argument to internal function Here's a proposed patch that will cause a TypeError to be raised instead. -Barry -------------------- snip snip -------------------- Index: abstract.c =================================================================== RCS file: /projects/cvsroot/python/dist/src/Objects/abstract.c,v retrieving revision 2.33 diff -c -r2.33 abstract.c *** abstract.c 2000/03/10 22:55:18 2.33 --- abstract.c 2000/03/29 05:36:21 *************** *** 860,866 **** PyObject *s; { PySequenceMethods *m; ! if (s == NULL) { null_error(); return -1; --- 860,867 ---- PyObject *s; { PySequenceMethods *m; ! int size = -1; ! if (s == NULL) { null_error(); return -1; *************** *** 868,877 **** m = s->ob_type->tp_as_sequence; if (m && m->sq_length) ! return m->sq_length(s); ! type_error("len() of unsized object"); ! return -1; } PyObject * --- 869,879 ---- m = s->ob_type->tp_as_sequence; if (m && m->sq_length) ! size = m->sq_length(s); ! if (size < 0) ! type_error("len() of unsized object"); ! return size; } PyObject * Index: ceval.c =================================================================== RCS file: /projects/cvsroot/python/dist/src/Python/ceval.c,v retrieving revision 2.169 diff -c -r2.169 ceval.c *** ceval.c 2000/03/28 23:49:16 2.169 --- ceval.c 2000/03/29 05:39:00 *************** *** 1636,1641 **** --- 1636,1649 ---- break; } nstar = PySequence_Length(stararg); + if (nstar < 0) { + if (!PyErr_Occurred) + PyErr_SetString( + PyExc_TypeError, + "len() of unsized object"); + x = NULL; + break; + } } if (nk > 0) { if (kwdict == NULL) {
On Tue, 28 Mar 2000, David Ascher wrote:
I'm thrilled to see the extended call syntax patches go in! One less wart in the language!
Me too! Even the lisps i used to know (albeit ancient, according to eric) couldn't get it as tidy as this. (Silly me, now i'm imagining we're going to see operator assignments just around the bend. "Give them a tasty morsel, they ask for your dinner..."-) Ken klm@digicool.com
I'm thrilled to see the extended call syntax patches go in! One less wart in the language!
but did he compile before checking in? ..\Python\compile.c(1225) : error C2065: 'CALL_FUNCTION_STAR' : undeclared identifier (compile.c and opcode.h both mention this identifier, but nobody defines it... should it be CALL_FUNCTION_VAR, perhaps?) </F>
On Wed, 29 Mar 2000, Fredrik Lundh wrote:
You beat me to it. I read David's message and got so excited i just had to try it right away. So i updated my CVS tree, did "make", and got the same error: make[1]: Entering directory `/home/ping/dev/python/dist/src/Python' gcc -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c compile.c -o compile.o compile.c: In function `com_call_function': compile.c:1225: `CALL_FUNCTION_STAR' undeclared (first use in this function) compile.c:1225: (Each undeclared identifier is reported only once compile.c:1225: for each function it appears in.) make[1]: *** [compile.o] Error 1
But CALL_FUNCTION_STAR is mentioned in the comments... #define CALL_FUNCTION 131 /* #args + (#kwargs<<8) */ #define MAKE_FUNCTION 132 /* #defaults */ #define BUILD_SLICE 133 /* Number of items */ /* The next 3 opcodes must be contiguous and satisfy (CALL_FUNCTION_STAR - CALL_FUNCTION) & 3 == 1 */ #define CALL_FUNCTION_VAR 140 /* #args + (#kwargs<<8) */ #define CALL_FUNCTION_KW 141 /* #args + (#kwargs<<8) */ #define CALL_FUNCTION_VAR_KW 142 /* #args + (#kwargs<<8) */ The condition (CALL_FUNCTION_STAR - CALL_FUNCTION) & 3 == 1 doesn't make much sense, though... -- ?!ng
"FL" == Fredrik Lundh <effbot@telia.com> writes:
I'm thrilled to see the extended call syntax patches go in! One less wart in the language!
FL> but did he compile before checking in? Indeed, but not often enough :-). FL> ..\Python\compile.c(1225) : error C2065: 'CALL_FUNCTION_STAR' : FL> undeclared identifier FL> (compile.c and opcode.h both mention this identifier, but nobody FL> defines it... should it be CALL_FUNCTION_VAR, perhaps?) This was a last minute change of names. I had previously compiled under the old names. The Makefile doesn't describe the dependency between opcode.h and compile.c. And the compile.o file I had worked, because the only change was to the name of a macro. It's too bad the Makefile doesn't have all the dependencies. It seems that it's necessary to do a make clean before checking in a change that affects many files. Jeremy
On Tue, 28 Mar 2000, Jeremy Hylton wrote:
I updated again and rebuilt. >>> def sum(*args): ... s = 0 ... for x in args: s = s + x ... return s ... >>> sum(2,3,4) 9 >>> sum(*[2,3,4]) 9 >>> x = (2,3,4) >>> sum(*x) 9 >>> def func(a, b, c): ... print a, b, c ... >>> func(**{'a':2, 'b':1, 'c':6}) 2 1 6 >>> func(**{'c':8, 'a':1, 'b':9}) 1 9 8 >>> *cool*. So does this completely obviate the need for "apply", then? apply(x, y, z) <==> x(*y, **z) -- ?!ng
I think so (except for backwards compatibility). The 1.6 docs for apply should point this out! --Guido van Rossum (home page: http://www.python.org/~guido/)
"DA" == David Ascher <DavidA@ActiveState.com> writes:
DA> But most importantly, IMO: DA> class SubClass(Class): DA> def __init__(self, a, *args, **kw): DA> self.a = a DA> Class.__init__(self, *args, **kw) DA> Much neater. This version of method overloading was what I liked most about Greg's patch. Note that I also prefer: class SubClass(Class): super_init = Class.__init__ def __init__(self, a, *args, **kw): self.a = a self.super_init(*args, **kw) I've been happy to have all the overridden methods explicitly labelled at the top of a class lately. It is much easier to change the class hierarchy later. Jeremy
Changing the definition of class Nums to class Nums: def __getitem__(self, i): if 0 <= i < 10: return i raise IndexError def __len__(self): return 10 I.e. adding the __len__() method avoids the SystemError. Either the *arg call should not depend on the sequence being lenght-able, or it should error check that the length calculation doesn't return -1 or raise an exception. Looking at PySequence_Length() though, it seems that m->sq_length(s) can return -1 without setting a type_error. So the fix is either to include a check for return -1 in PySequence_Length() when calling sq_length, or instance_length() should set a TypeError when it has no __len__() method and returns -1. I gotta run so I can't follow this through -- I'm sure I'll see the right solution from someone in tomorrow mornings email :) -Barry
"KY" == Ka-Ping Yee <ping@lfw.org> writes:
| It should be noted that "apply" has the same problem, with a | different counterintuitive error message: >> n = Nums() apply(sum, n) | Traceback (innermost last): | File "<stdin>", line 1, in ? | AttributeError: __len__ The patch I just posted fixes this too. The error message ain't great, but at least it's consistent with the direct call. -Barry -------------------- snip snip -------------------- Traceback (innermost last): File "/tmp/doit.py", line 15, in ? print apply(sum, n) TypeError: len() of unsized object
"BAW" == Barry A Warsaw <bwarsaw@cnri.reston.va.us> writes:
BAW> Uh oh. Fresh CVS update and make clean, make: >>> sum(*n) | Traceback (innermost last): | File "<stdin>", line 1, in ? | SystemError: bad argument to internal function Here's a proposed patch that will cause a TypeError to be raised instead. -Barry -------------------- snip snip -------------------- Index: abstract.c =================================================================== RCS file: /projects/cvsroot/python/dist/src/Objects/abstract.c,v retrieving revision 2.33 diff -c -r2.33 abstract.c *** abstract.c 2000/03/10 22:55:18 2.33 --- abstract.c 2000/03/29 05:36:21 *************** *** 860,866 **** PyObject *s; { PySequenceMethods *m; ! if (s == NULL) { null_error(); return -1; --- 860,867 ---- PyObject *s; { PySequenceMethods *m; ! int size = -1; ! if (s == NULL) { null_error(); return -1; *************** *** 868,877 **** m = s->ob_type->tp_as_sequence; if (m && m->sq_length) ! return m->sq_length(s); ! type_error("len() of unsized object"); ! return -1; } PyObject * --- 869,879 ---- m = s->ob_type->tp_as_sequence; if (m && m->sq_length) ! size = m->sq_length(s); ! if (size < 0) ! type_error("len() of unsized object"); ! return size; } PyObject * Index: ceval.c =================================================================== RCS file: /projects/cvsroot/python/dist/src/Python/ceval.c,v retrieving revision 2.169 diff -c -r2.169 ceval.c *** ceval.c 2000/03/28 23:49:16 2.169 --- ceval.c 2000/03/29 05:39:00 *************** *** 1636,1641 **** --- 1636,1649 ---- break; } nstar = PySequence_Length(stararg); + if (nstar < 0) { + if (!PyErr_Occurred) + PyErr_SetString( + PyExc_TypeError, + "len() of unsized object"); + x = NULL; + break; + } } if (nk > 0) { if (kwdict == NULL) {
On Tue, 28 Mar 2000, David Ascher wrote:
I'm thrilled to see the extended call syntax patches go in! One less wart in the language!
Me too! Even the lisps i used to know (albeit ancient, according to eric) couldn't get it as tidy as this. (Silly me, now i'm imagining we're going to see operator assignments just around the bend. "Give them a tasty morsel, they ask for your dinner..."-) Ken klm@digicool.com
participants (8)
-
Barry A. Warsaw -
bwarsaw＠cnri.reston.va.us
-
David Ascher -
Fredrik Lundh -
Guido van Rossum -
Jeremy Hylton -
Ka-Ping Yee -
Ken Manheimer