Mailman 3 August 2000 - Python-Dev

Adding insint() function
by Andrew Kuchling Aug. 22, 2000

Aug. 22, 2000

Four modules define insint() functions to insert an integer into a dictionary in order to initialize constants in their module dictionaries: kronos Modules>grep -l insint *.c pcremodule.c shamodule.c socketmodule.c zlibmodule.c kronos Modules> (Hm... I was involved with 3 of them...) Other modules don't use a helper function, but just do PyDict_SetItemString(d, "foo", PyInt_FromLong(...)) directly. This duplication bugs me. Shall I submit a patch to add an API convenience function to do this, and change the modules to use it? Suggested prototype and name: PyDict_InsertInteger( dict *, string, long) --amk

6 9

Adding doc-strings to attributes [with patch]
by M.-A. Lemburg Aug. 22, 2000

Aug. 22, 2000

Here's a patch which roughly implements the proposed attribute doc-string syntax and semantics: class C: " class C doc-string " a = 1 " attribute C.a doc-string " b = 2 " attribute C.b doc-string " The compiler would handle these cases as follows: " class C doc-string " -> C.__doc__ " attribute C.a doc-string " -> C.__doc__a__ " attribute C.b doc-string " -> C.__doc__b__ The name mangling assures that attribute doc-strings a) participate in class inheritence and b) are treated as special attributes (following the __xxx__ convention) Also, the look&feel of this convention is similar to that of the other existing conventions: the doc string follows the definition of the object. The patch is a little rough in the sense that binding the doc-string to the attribute name is done using a helper variable that is not reset by non-expressions during the compile. Shouldn't be too hard to fix though... at least not for one of you compiler wizards ;-) What do you think ? [I will probably have to write a PEP for this...] -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ --- CVS-Python/Python/compile.c Tue Aug 22 10:31:06 2000 +++ Python+Unicode/Python/compile.c Tue Aug 22 19:59:30 2000 @@ -293,10 +293,11 @@ struct compiling { int c_last_addr, c_last_line, c_lnotab_next; #ifdef PRIVATE_NAME_MANGLING char *c_private; /* for private name mangling */ #endif int c_tmpname; /* temporary local name counter */ + char *c_last_name; /* last assigned name */ }; /* Error message including line number */ @@ -435,12 +436,13 @@ com_init(struct compiling *c, char *file c->c_stacklevel = 0; c->c_maxstacklevel = 0; c->c_firstlineno = 0; c->c_last_addr = 0; c->c_last_line = 0; - c-> c_lnotab_next = 0; + c->c_lnotab_next = 0; c->c_tmpname = 0; + c->c_last_name = 0; return 1; fail: com_free(c); return 0; @@ -1866,10 +1868,11 @@ com_assign_name(struct compiling *c, nod { REQ(n, NAME); com_addopname(c, assigning ? STORE_NAME : DELETE_NAME, n); if (assigning) com_pop(c, 1); + c->c_last_name = STR(n); } static void com_assign(struct compiling *c, node *n, int assigning) { @@ -1974,18 +1977,40 @@ com_assign(struct compiling *c, node *n, } } } /* Forward */ static node *get_rawdocstring(node *); +/* Forward */ static PyObject *get_docstring(node *); static void com_expr_stmt(struct compiling *c, node *n) { REQ(n, expr_stmt); /* testlist ('=' testlist)* */ - /* Forget it if we have just a doc string here */ - if (!c->c_interactive && NCH(n) == 1 && get_rawdocstring(n) != NULL) + /* Handle attribute doc-strings here */ + if (!c->c_interactive && NCH(n) == 1) { + node *docnode = get_rawdocstring(n); + if (docnode != NULL) { + if (c->c_last_name) { + PyObject *doc = get_docstring(docnode); + int i = com_addconst(c, doc); + char docname[420]; +#if 0 + printf("found doc-string '%s' for '%s'\n", + PyString_AsString(doc), + c->c_last_name); +#endif + sprintf(docname, "__doc__%.400s__", c->c_last_name); + com_addoparg(c, LOAD_CONST, i); + com_push(c, 1); + com_addopnamestr(c, STORE_NAME, docname); + com_pop(c, 1); + c->c_last_name = NULL; + Py_DECREF(doc); + } return; + } + } com_node(c, CHILD(n, NCH(n)-1)); if (NCH(n) == 1) { if (c->c_interactive) com_addbyte(c, PRINT_EXPR); else

1 0

Re: [Python-checkins] CVS: python/dist/src/PCbuild python20.wse,1.6,1.7
by Thomas Heller Aug. 22, 2000

Aug. 22, 2000

> Update of /cvsroot/python/python/dist/src/PCbuild > In directory slayer.i.sourceforge.net:/tmp/cvs-serv25776 > > Modified Files: > python20.wse > Log Message: > Thomas Heller noticed that the wrong registry entry was written for > the DLL. Replace > %_SYSDEST_%\Python20.dll > with > %_DLLDEST_%\Python20.dll. > Unfortunately, there was a bug in my bug-report. %DLLDEST% would have been correct. Sorry: Currently I don't have time to test the fix. Thomas Heller

3 4

Lockstep iteration - eureka!
by Greg Ewing Aug. 22, 2000

Aug. 22, 2000

I think I've actually found a syntax for lockstep iteration that looks reasonable (or at least not completely unreasonable) and is backward compatible: for (x in a, y in b): ... Not sure what the implications are for the parser yet. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg(a)cosc.canterbury.ac.nz +--------------------------------------+

19 57

Re: [Python-Dev] iterators
by Jack Jansen Aug. 22, 2000

Aug. 22, 2000

> it = something.newiterator() > for x over it: > if time_to_start_second_loop(): break > do_something() > for x over it: > do_something_else() Another, similar, paradigm I find myself often using is something like tmplist = [] for x in origlist: if x.has_some_property(): tmplist.append(x) else do_something() for x in tmplist: do_something_else() I think I'd like it if iterators could do something like it = origlist.iterator() for x in it: if x.has_some_property(): it.pushback() else do_something() for x in it: do_something_else() -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

1 0

Re: [Python-Dev] New anal crusade
by Jack Jansen Aug. 22, 2000

Aug. 22, 2000

> Has anyone tried compiling Python under gcc with > > -Wmissing-prototypes -Wstrict-prototypes I have a similar set of options (actually it's difficult to turn them off if you're checking for prototypes:-) which will make the CodeWarrior compiler for the Mac be strict about prototypes, which complains about external functions being declared without a prototype in scope. I was initially baffled by this: why would it want a prototype if the function declaration is ansi-style anyway? But, it turns out its a really neat warning: usually if you declare an external without a prototype in scope it means that it isn't declared in a .h file, which means that either (a) it shouldn't have been an extern in the first place or (b) you've duplicated the prototype in an external declaration somewhere else which means the prototypes aren't necessarily identical. For Python this option produces warnings for all the init routines, which is to be expected, but also for various other things (I seem to remember there's a couple in the GC code). If anyone is interested I can print them out and send them here. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

1 0

Looking for an "import" expert
by Tim Peters Aug. 22, 2000

Aug. 22, 2000

Fred Drake opened an irritating <wink> bug report (#112436). Cut to the chase: regrtest.py imports test_support. test_support.verbose is 1 after that. regrtest's main() reaches into test_support and stomps on test_support.verbose, usually setting to 0. Now in my build directory, if I run python ..\lib\test\regrtest.py test_getopt the test passes. However, it *shouldn't* (and the crux of Fred's bug report is that it does fail when he runs regrtest in an old & deprecated way). What happens is that test_getopt.py has this near the top: from test.test_support import verbose and this is causing *another* copy of the test_support module to get loaded, and *its* verbose attr is 1. So when we run test_getopt "normally" via regrtest, it incorrectly believes that verbose is 1, and the "expected result" file (which I generated via regrtest -g) is in fact verbose-mode output. If I change the import at the top of test_getopt.py to from test import test_support from test_support import verbose then test_getopt.py sees the 0 it's supposed to see. The story is exactly the same, btw, if I run regrtest while *in* the test directory (so this has nothing to do with that I usually run regrtest from my build directory). Now what *Fred* does is equivalent to getting into a Python shell and typing >>> from test import regrtest >>> regrtest.main() and in *that* case (the original) test_getopt sees the 0 it's supposed to see. I confess I lost track how fancy Python imports work a long time ago. Can anyone make sense of these symptoms? Why is a 2nd version of test_support getting loaded, and why only sometimes?

3 3

configure.in, C++ and Linux
by Mark Hammond Aug. 22, 2000

Aug. 22, 2000

I'm pretty new to all of this, so please bear with me. I create a Setup.in that references some .cpp or .cxx files. When I create the Makefile, the command line generated for building these C++ sources is similar to: $(CCC) $(CCSHARE) ... However, CCC is never set anywhere.... Looking at configure.in, there appears to be support for setting this CCC variable. However, it was commented out in revision 1.113 - a checkin by Guido, December 1999, with the comment: """ Patch by Geoff Furnish to make compiling with C++ more gentle. (The configure script is regenerated, not from his patch.) """ Digging a little deeper, I find that config/Makefile.pre.in and config/makesetup both have references to CCC that account for the references in my Makefile. Unfortunately, my knowledge doesnt yet stretch to knowing exactly where these files come from :-) Surely all of this isn't correct. Can anyone tell me what is going on, or what I am doing wrong? Thanks, Mark.

2 2

regression test question
by Fred L. Drake, Jr. Aug. 21, 2000

Aug. 21, 2000

I'm working on bringing the parser module up to date and introducing a regression test for it. (And if the grammar stops changing, it may actually get finished!) I'm having a bit of a problem, though: the test passes when run as a script, but not when run via the regression test framework. The problem is *not* with the output file. I'm getting an exception from the module which is not expected, and is only raised when it runs using the regression framework. Has anyone else encountered a similar problem? I've checked to make sure the right version or parsermodule.so and test_parser.py are being picked up. Thanks! -Fred -- Fred L. Drake, Jr. <fdrake at beopen.com> BeOpen PythonLabs Team Member

2 2

Doc-strings for class attributes ?!
by M.-A. Lemburg Aug. 21, 2000

Aug. 21, 2000

Lately I was busy extracting documentation from a large Python application. Everything worked just fine building on existing doc-strings and the nice Python reflection features, but I came across one thing to which I didn't find a suitable Python-style solution: inline documentation for class attributes. We already have doc-strings for modules, classes, functions and methods, but there is no support for documenting class attributes in a way that: 1. is local to the attribute definition itself 2. doesn't affect the attribute object in any way (e.g. by adding wrappers of some sort) 3. behaves well under class inheritence 4. is available online After some thinking and experimenting with different ways of achieving the above I came up with the following solution which looks very Pythonesque to me: class C: " class C doc-string " a = 1 " attribute C.a doc-string " b = 2 " attribute C.b doc-string " The compiler would handle these cases as follows: " class C doc-string " -> C.__doc__ " attribute C.a doc-string " -> C.__doc__a__ " attribute C.b doc-string " -> C.__doc__b__ All of the above is perfectly valid Python syntax. Support should be easy to add to the byte code compiler. The name mangling assures that attribute doc-strings a) participate in class inheritence and b) are treated as special attributes (following the __xxx__ convention) Also, the look&feel of this convention is similar to that of the other existing conventions: the doc string follows the definition of the object. What do you think about this idea ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

2 1