Mailman 3 October 2002 - Python-Dev

Re: [Python-Dev] Tests failing in MacPython 2.2.2
by Michael Hudson Oct. 11, 2002

Oct. 11, 2002

barry(a)python.org (Barry A. Warsaw) writes: > >>>>> "MH" == Michael Hudson <mwh(a)python.net> writes: > > >> "JJ" == Jack Jansen <Jack.Jansen(a)oratrix.com> writes: > >> JJ> Aside from the usual suspects I have three tests failing in > >> JJ> MacPython 2.2.2: test_atexit, test_email and test_httplib. > >> Oops, looks like I'm also getting a segfault in test_re. > > MH> This is normal; run "ulimit -s 2048" before running the test > MH> suite. > > Thanks, that works. Would it make sense to add this to the test suite > some how, either by adding a ulimit call to the makefile, or adding > some resource.setrlimit() call to site.py or test_{,s}re.py? There's a patch of sf to do this. It's probably a good idea (I forget to do this fairly often). Or maybe it could be in Modules/main.c:main()... Cheers, M. -- 39. Re graphics: A picture is worth 10K words - but only those to describe the picture. Hardly any sets of 10K words can be adequately described with pictures. -- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html

5 6

Set-next-statement in Python debuggers
by richie＠entrian.com Oct. 11, 2002

Oct. 11, 2002

Hi, First a brief introduction, since this is my first post to python-dev: I'm a professional software engineer, mostly using C/C++ and Python. I use Python a lot for my own projects and some of you will know me from the spambayes project, as the author of pop3proxy.py. I was interested to see Armin's patch [617312] to "allow the C profile and trace functions to alter some fields of the current PyFrameObject". I'm writing a Python debugger, and as Armin says, his patch "could also be used by advanced debuggers to allow the execution point to be modified by the user." A "Set-next-statement" feature is on my list of nice-to-have-but-hard-to-do jobs, and this patch could make it easy. (I know the blockstack presents a problem, but if it's insurmountable I'm happy to ignore that and to only allow skipping to lines in the same block - 90% of my use of the equivalent feature in MSVC is to skip back one line or forward one line.) There's one fly in the ointment - I'm trying to keep my debugger in pure Python, and Armin's patch only applies to C trace functions. If frame.f_lasti were writable by Python trace functions, pure Python debuggers (including pdb) could implement Set-Next-Statement. Here's a small script that demonstrates what I mean, and the one-line patch to frameobject.c that enables it: ----------------------------------------------------------------------- """Demonstration of debugger 'Set-next-statement' feature. Requires Python 2.2.2 with writeable frame.f_lasti. Prints "1, 2, 2, 3".""" import sys, pprint def example(): print 1, print 2, print 3 # Line 9; we skip back to 8 the first time we hit this. class DebuggerHook: def __init__(self): self.done = False # Have we done the Set-next-statement yet? self.lasti = 0 # The frame.f_lasti of the previous line. sys.settrace(self.trace) def trace(self, frame, action, arg): if not self.done and frame.f_lineno == 9: # This is the first time we've hit line 9; skip back to 8. frame.f_lasti = self.lasti self.done = True else: # Store the instruction offset of this line. self.lasti = frame.f_lasti return self.trace debugger = DebuggerHook() example() # Prints "1, 2, 2, 3" ----------------------------------------------------------------------- *** frameobject.c Tue Oct 8 08:16:39 2002 --- frameobject-222b1.c Tue Oct 8 08:16:12 2002 *************** *** 16,20 **** {"f_builtins", T_OBJECT, OFF(f_builtins),RO}, {"f_globals", T_OBJECT, OFF(f_globals), RO}, ! {"f_lasti", T_INT, OFF(f_lasti)}, {"f_lineno", T_INT, OFF(f_lineno), RO}, {"f_restricted",T_INT, OFF(f_restricted),RO}, --- 16,20 ---- {"f_builtins", T_OBJECT, OFF(f_builtins),RO}, {"f_globals", T_OBJECT, OFF(f_globals), RO}, ! {"f_lasti", T_INT, OFF(f_lasti), RO}, {"f_lineno", T_INT, OFF(f_lineno), RO}, {"f_restricted",T_INT, OFF(f_restricted),RO}, ----------------------------------------------------------------------- For completeness, f_lineno should probably be writable as well, but I'm keeping the changes minimal for the purposes of discussion. Is this a reasonable suggestion for 2.3, or is it giving people too much rope? A nasty consequence is that you can write Python code that causes Python to seg-fault, but you have to be doing some fairly advanced stuff for that to happen. I would say that the power of a Set-next-statement feature in pdb and other debuggers is worth the price, but others may disagree...? -- Richie Hindle richie(a)entrian.com

4 9

Re: [Python-checkins] python/dist/src/Lib os.py,1.62,1.63 dospath.py,1.30,NONE
by Michael Hudson Oct. 11, 2002

Oct. 11, 2002

loewis(a)users.sourceforge.net writes: > Update of /cvsroot/python/python/dist/src/Lib > In directory usw-pr-cvs1:/tmp/cvs-serv24338 > > Modified Files: > os.py > Removed Files: > dospath.py > Log Message: > Remove more DOS support. I think you should remove test_dospath & friends, too? Cheers, M.

2 2

Where is this flag coming from?
by Skip Montanaro Oct. 11, 2002

Oct. 11, 2002

On my MacOS 10.2 system an unexpected flag is added to the link line for the bsddb module: gcc -bundle -bundle_loader python.exe \ build/temp.darwin-6.1-Power\ Macintosh-2.3/bsddbmodule.o \ -L/sw/lib -L/sw/lib -L/usr/local/lib -Wl,-R/sw/lib -ldb-4.1 \ -o build/lib.darwin-6.1-Power\ Macintosh-2.3/bsddb.so None of the other extension modules are linked with "-Wl,-R/sw/lib". I don't find "-R" in either setup.py or configure. Any idea where this is coming from and how to get rid of it? Skip

6 27

Re: [Python-Dev] Where is this flag coming from?
by Skip Montanaro Oct. 11, 2002

Oct. 11, 2002

Martin> It seems that Skip chose the blacklist approach (aka the Martin> I-care-only-about-MacOS approach). Skip's approach is probably Martin> overkill, since there will be already -L options for all those Martin> directories. It appears that OS X records the full path of the Martin> library in the binary, so the notion of a runtime path is Martin> irrelevant. I didn't want to return "" because that would require me to filter it out of the argument list elsewhere. "-L" + dir seemed like the most innocuous change. Skip

1 0

PEP239 (Rational Numbers) Reference Implementation and new issues
by python-pep＠ccraig.org Oct. 10, 2002

Oct. 10, 2002

I just uploaded a reference implementation of how rationals might look in Python as patch 617779 [1]. I do have some new issues for discussion that I'd like to get some comments on before I change the PEP. 1) Should future division return rationals rather than floats. I had sort of assumed this would happen, but I just had a discussion with Kirby Urner and couldn't convince him it was a good idea, so I guess it isn't so clear. Arguments for: - you don't lose precision on divides - It provides a really nice way to specify rationals (i.e. 1/3) - It allows you to eventually unify int/long/rationals so that rationals with a denominator of 1 are automagically upcast. Arguments against: - people who have already changed their code to expect floats will have to change it again - rationals are slow 2) Should floats compare equal with rationals only when they are equal, or whenever the are the closest float? (i.e. will .2 compare equal to rational(1, 5)) 3) Should rationals try to hash the same as floats? My leaning on this is that it will be decided by (2). If they compare equal when 'close enough' then they should hash the same, if not then they should only hash the same when both are integral. I would rather not see .5 hash with rational(1, 2) but not .2 with rational(1, 5). [1] http://sourceforge.net/tracker/?func=detail&aid=617779&group_id=5470&atid=3… -- Christopher A. Craig <python-pep(a)ccraig.org> "[Windows NT is] not about 'Where do you want to go today?'; it's more like 'Where am I allowed to go today?'" -- Mike Mitchell, NT Systems Administrator

22 85

Re: [Python-Dev] Non-ASCII characters in test_pep277.py in 2.3
by Michael Hudson Oct. 10, 2002

Oct. 10, 2002

"Neil Hodgson" <nhodgson(a)bigpond.net.au> writes: > Stephen J. Turnbull: > > > No current XEmacs recognizes cookies in the second line. I tried it, > > it broke, I backed it out, had a bad attack of day job, and forgot to > > fix the patch. :-( > > Where did the coding cookie originally come from? It seems to have > arrived in Python from somewhere else, probably Emacs but I couldn't find a > reference in PEP-263.

2 1

Re: [Python-Dev] Where is this flag coming from?
by Michael Hudson Oct. 10, 2002

Oct. 10, 2002

Tim Rice <tim(a)multitalents.net> writes: > Am I out to lunch on the idea that the logic should be in > Lib/distutils/unixccompiler.py where the -R is added? No. The code we have right now is dubious, to say the least. Cheers, M. -- ... so the notion that it is meaningful to pass pointers to memory objects into which any random function may write random values without having a clue where they point, has _not_ been debunked as the sheer idiocy it really is. -- Erik Naggum, comp.lang.lisp

1 0

Re: [Python-checkins] python/dist/src/Lib ntpath.py,1.50,1.51
by Michael Hudson Oct. 10, 2002

Oct. 10, 2002

tim_one(a)users.sourceforge.net writes: > Update of /cvsroot/python/python/dist/src/Lib > In directory usw-pr-cvs1:/tmp/cvs-serv28728/python/Lib > > Modified Files: > ntpath.py > Log Message: > Don't try to access sys.getwindowsversion unless it exists (ntpath is > imported on systems other than Windows, and in particular is imported > by test___all__; the compile farm reported that all Linux tests failed > due to this; isn't anyone in PythonDevLand running CVS on Linux?!). Yes, but I do sleep occasionally... Cheers, M. -- it's not that perl programmers are idiots, it's that the language rewards idiotic behavior in a way that no other language or tool has ever done -- Erik Naggum, comp.lang.lisp

2 1

2.2.2b fails test_minidom on Itanium Linux
by Mats Wichmann Oct. 10, 2002

Oct. 10, 2002

Been tied up since the beta was announced; the 2.2.2 CVS of this morning, which I assume is very close if not identical to the beta, fails with "lines 2-217 of output missing" on the minidom test on Itanium (ia64) Linux. I presume this is due to the test dying or some resource missing so it doesn't get started. No chance to check deeper just now. This was fine just a bit ago when I sent Guido some feedback pre-beta. Mats

1 0