Mailman 3 December 2002 - Python-Dev

Re: [Python-Dev] make install fails with current Python CVS
by Michael Hudson Dec. 12, 2002

Dec. 12, 2002

"M.-A. Lemburg" <mal(a)lemburg.com> writes: > Martin v. L=F6wis wrote: > >>I've tried to run a "make install" with todays CVS version, but > >>this fails on my Linux box with the following error: [...] > Looking at the output of ./python -vv it appears as if the struct > cannot be loaded (which is imported by codecs.py). Is this an out-of-tree build? I have a feeling you may be being bitten by their current breakage. Weird symptom, though. Cheers, M. -- 59. In English every word can be verbed. Would that it were so in our programming languages. -- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html

2 1

Re: [Python-Dev] make install fails with current Python CVS
by Michael Hudson Dec. 12, 2002

Dec. 12, 2002

"M.-A. Lemburg" <mal(a)lemburg.com> writes: > I've tried to run a "make install" with todays CVS version, but > this fails on my Linux box with the following error: > > Compiling /home/lemburg/projects/Python/Installation/lib/python2.3/test/test_pep263.py ... > Sorry: MemoryError: > > Is that just my setup or reproducable on other machines as well ? I saw that too, but thought it must have been my fault. > The above file looks pretty innocent to me: > > #! -*- coding: koi8-r -*- > assert u"<russian for python>".encode("utf-8") == '\xd0\x9f\xd0\xb8\xd1\x82\xd0\xbe\xd0\xbd' > assert u"\<russian p>".encode("utf-8") == '\\\xd0\x9f' It might well be the only file that actually uses the pep263 stuff to affect the interpretation of a unicode string. That would seem to be the place to start looking -- though it imports & compiles file when run as part of the test suite... Hmm... >>> exec open("../Lib/test/test_pep263.py").read() sigh, that was one easy guess. Cheers, M. -- Every now and then, Google doesn't throw up what I need so I start checking Altavista, Yahoo, etc. In almost every single case, I am brutally reminded why I use Google in the first place. -- John Riddoch, asr

1 0

RE: [Python-Dev] Re: [Python-checkins] python/dist/src/Include co mpile.h,2.38,2.39 parsetok.h,2.19,2.20 pyerrors.h,2.63,2.64 pythonrun.h,2 .55,2.56 symtable.h,2.10,2.11
by Delaney, Timothy Dec. 12, 2002

Dec. 12, 2002

> From: M.-A. Lemburg [mailto:mal@lemburg.com] > > I remember Tim opposing such changes (and Greg Stein insisting > on them ;-). AFAIK, this breaks third party code since some > compilers simply reject casting char* to const char*. I must admit I caused this recent constifying mess ... someone complained on python-list and I told him to submit a bug report (in the hope that it would get rejected because I knew the problems it would cause). I submit myself for a spanking. Tim Delaney

8 11

trace.py in std library?
by Jeremy Hylton Dec. 12, 2002

Dec. 12, 2002

There's a trace.py script sitting in Tools/scripts that works when imported. I used it today to add code coverage to Zope's test runner script. It took about 30 min. (mostly fixing bugs in trace.py) and seems to work pretty well. Why don't we put this script in the std library so it can actually be imported? I can guess at some of the reasons. The code looks very complicated and has been updated piecemeal by many people of the years. The last update has a bunch of comments with Zooko's name on them and a date. They seem like XXX comments. It might be nice to clean it up before putting in the library, but I'd be in favor of having some minimally functional tool in the library regardless. Jeremy

4 4

RE: [Python-Dev] trace.py in std library?
by Delaney, Timothy Dec. 12, 2002

Dec. 12, 2002

> From: Jeremy Hylton [mailto:jeremy@alum.mit.edu] > > >>>>> "TD" == Timothy Delaney <Delaney> writes: > > TD> But I don't think it's a candidate yet. Among other things, the > TD> tracing functionality is not hooked into each new thread. Not an > TD> issue for my current project (which must run single-threaded due > TD> to being invoked inside something that must run in a single > TD> thread) but it is an issue for a version in the standard > TD> library. > > Maybe you should checkin what you have now. If it's at least as > functional as trace.py, then it's an improvement over what we've got > in the std library now. You/we can improve it as 2.3 development > proceeds. Ooh - believe me - you don't want to see the code as it is now. Yuk! Needs some major cleanup (esp. after the hacking I've done to make it work with Jython). No way I would check something that disgusting in where other people could see it ;) Unfortunately, I'm really busy right now. Maybe I'll get to spend some time on it over my 2-week break coming up. Plus as I said, I need to check with my employer - it has been partially developed on company time, and for a company project. Maybe I can get it into my goals and objectives ;) I should use the sandbox though. Unfortunately, I can't compile 2.3 at home ... MinGW still doesn't work, and I don't have a BSD or Linux box set up (the only available machine is currently serving as my internet gateway until I fix another machine). Tim Delaney

2 1

RE: [Python-Dev] trace.py in std library?
by Delaney, Timothy Dec. 12, 2002

Dec. 12, 2002

> From: barry(a)python.org [mailto:barry@python.org] > > >>>>> "JH" == Jeremy Hylton <jeremy(a)alum.mit.edu> writes: > > JH> trace.py is Skip's tool. > > So I guess that means they're similar. I think it's premature to put it into the std library - not least because I've got a version I've been working on for a while which I'd eventually like to get in there if I can ;) Of course, part of that will rest on my employer ... The major problems I had with trace.py are that it is *slow* and that the data it collects is very incomplete. If we are going to have a standard tracing module, I think it needs to be *fast* and the data it collects needs to be complete, and easily transformable to many types of reports. My main use case is automated code coverage reports. If my unit tests take 30 minutes to run with no coverage tool, but 15 hours to run under a coverage tool, the coverage tool is useless for my nightly builds and automated testing. The one I've been working on is a *lot* faster (though still in pure python), dropping from about 3000% performance overhead to about 50%. It also collects pretty much all the data it can (calls, lines, which lines belong to which classes/functions/methods), resolves modules down to a single, most-qualified instance (for example, if import a and import b.a end up importing the same module, both will be represented in the report as b.a) and various other things. It also determines which source lines are executable (for example, multi-line strings will only have one of the lines as executable). It also *almost* works with Jython (doesn't work out executable lines properly). It *also* allows outputting of tracing lines as they are executed (and damn that slows things down). But I don't think it's a candidate yet. Among other things, the tracing functionality is not hooked into each new thread. Not an issue for my current project (which must run single-threaded due to being invoked inside something that must run in a single thread) but it is an issue for a version in the standard library. Tim Delaney

3 2

Re: [Python-checkins] python/dist/src/Include compile.h,2.38,2.39 parsetok.h,2.19,2.20 pyerrors.h,2.63,2.64 pythonrun.h,2.55,2.56 symtable.h,2.10,2.11
by M.-A. Lemburg Dec. 11, 2002

Dec. 11, 2002

loewis(a)users.sourceforge.net wrote: > Update of /cvsroot/python/python/dist/src/Include > In directory sc8-pr-cvs1:/tmp/cvs-serv15966/Include > > Modified Files: > compile.h parsetok.h pyerrors.h pythonrun.h symtable.h > Log Message: > Constify filenames and scripts. Fixes #651362. I remember Tim opposing such changes (and Greg Stein insisting on them ;-). AFAIK, this breaks third party code since some compilers simply reject casting char* to const char*. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/

6 8

Modules/tclNotify.c
by Martin v. Löwis Dec. 11, 2002

Dec. 11, 2002

Is this file still in use? I stumbled over it while investigating support for threaded Tcl. If it is not used anymore, can it be deleted? Regards, Martin

3 2

Re: [Python-Dev] Re: [Python-checkins] python/dist/src/Lib textwrap.py,1.18,1.19
by Michael Hudson Dec. 11, 2002

Dec. 11, 2002

Just van Rossum <just(a)letterror.com> writes: > I have _no_ idea what's going on here. I do: readline. I wouldn't want to live without readline, but some of the things it does call for the application of thumbscrews. Cheers, M. -- FORD: Just pust the fish in your ear, come on, it's only a little one. ARTHUR: Uuuuuuuuggh! -- The Hitch-Hikers Guide to the Galaxy, Episode 1

4 5

anyone tried to use optparse with something else than sys.argv?
by Erik Heneryd Dec. 10, 2002

Dec. 10, 2002

hi snuck a peek at the newly included optparse module yesterday and it seems option parsing will be a breeze in the future. good work! however, imho, it seems a bit too focused on initial sys.argv parsing. for anything else, you basically have to subclass OptionParser etc to do anything useful. for example, you can supply your own argument list to the parse_args() method, but the autohelp/version/error reporters still use sys.argv[0] as command name (probably not what you want). the way optparse gets the command name (a global function) indicates that you're not supposed to override it? also, even if you tell OptionParser to use your user defined Option class (as explained in the docs: op = OptionParser(option_class=MyOption)), it still adds standard Option instances to handle autohelp/version. per default, the autohelp/version/error handlers call sys.exit(). the docs says that if you want to change this behaviour, simply subclass OptionParser and/or Option and override/extend the corresponding methods. ofcourse, this has no effect, since standard instances are used. also, supressing the actual printing of autohelp/version/error requires subclassing OptionParser and Option (or sys.stdout = StringIO fiddling). so? some minor glitches and (imho) annoyances, whats the deal? well, to me, it's pretty obvious that the design effort on optparse has pretty much been focused strictly on initial sys.argv parsing and while it's extendable, other use cases (embedded consoles etc) seem to have been given little or no real thought. the things i mention is probably easy to fix: * make parse_args() take the whole "sys.argv" list and use the first element as the command name. breaks backward compatibility, i know. why was sys.argv[1:] used in the first place? the getopt legacy? * add parse_args_ex() that raises an exception containing the help/error message instead of SystemExit (SystemExit containing something means something went wrong, don't it?) * (simple bug) dynamically populate the OptionParser using the option_class and not some pre-made Option. * (simple bug) replace all %prog in help texts etc, not just the first occurance. erik

3 2