Re: [Python-Dev] Preserving the blamelist
Tim Peters wrote: > Since we're spread across time zones, I think 24 hours is a good > minimum. Ok, done. > If something is set to 12 hours now, doesn't look like it's > working: when I wrote my msg, it showed (as I said) about 5 hours of > history. Right now it shows only about 3 hrs, from Sat 15 Apr 2006 > 21:47:13 GMT to now (about 00:50:00 GMT Sunday). This is under > Firefox on Windows, so nobody can blame it on an IE bug :-) There is another limit on the height of the waterfall: at most 200 "timestamps". I have now doubled that as well. Regards, Martin ___ 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-checkins] r45321 - in python/trunk: Lib/test/test_traceback.py Lib/traceback.py Misc/NEWS
On Sat, 15 Apr 2006, Tim Peters wrote: [...] >> Hmm, will 2.5's doctest work under Python 2.4? I guess that's not >> guaranteed, since I don't see any comment in doctest.py implying it needs >> to be compatible with old Pythons. > > doctest compatibility with 2.4 is neither a goal nor a non-goal for > 2.5. I'm not sure why it's being asked, since the incompatible change > projected for 2.5 is in how the trackback module spells some exception > names; and doctest (every version of doctest) gets its idea of the > name of an exception from the traceback module. Ah, yes. (Does the channelling service extend to divining the questions that posters on python-dev *should* have asked? No?) OK, I suppose I should have asked "will 2.5's module traceback work with Python 2.4?". I guess the answer is something resembling "no", but of course (?) the question I'm really interested in is "how, without too much effort or ugliness, can people run their doctests on both 2.4 and 2.5"? I guess if I care sufficiently, I should just go ahead and back-port to 2.4 and post it somewhere for the public good. John ___ 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-checkins] r45321 - in python/trunk: Lib/test/test_traceback.py Lib/traceback.py Misc/NEWS
On 4/16/06, John J Lee <[EMAIL PROTECTED]> wrote: > OK, I suppose I should have asked "will 2.5's module traceback work with > Python 2.4?". I guess the answer is something resembling "no", but of > course (?) the question I'm really interested in is "how, without too much > effort or ugliness, can people run their doctests on both 2.4 and 2.5"? I think there was an example earlier - you could change your doctest to not rely on the exact exception by catching it: >>> try: ... 1/0 ... except ZeroDivisionError: ... print "Divide by zero!" ... Divide by zero! >>> Whether that counts as "too much effort or ugliness", I'm not sure. Personally, my instinct is that having the whole traceback in a doctest is at least as ugly. Paul. ___ 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-checkins] r45321 - in python/trunk: Lib/test/test_traceback.py Lib/traceback.py Misc/NEWS
On 4/16/06, Paul Moore <[EMAIL PROTECTED]> wrote: > Personally, my instinct is that having the whole traceback in a > doctest is at least as ugly. Well, it depends on what you use doctest for. If you use it to write unit tests, the try/except solution is fine, and perhaps preferable. If you use it as *documentation*, where doctest is used to ensure that the documentation is accurate, showing a (short) traceback seems to be the logical thing to do. In a sample session where you want to show that a certain exception is raised for a certain combination of erroneous arguments (for example), showing the traceback is much more natural than putting a try/except around the erroneous call. So one person's ugly is another person's pretty. -- --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] [Python-checkins] r45321 - in python/trunk: Lib/test/test_traceback.py Lib/traceback.py Misc/NEWS
On Sun, 16 Apr 2006, Guido van Rossum wrote:
> On 4/16/06, Paul Moore <[EMAIL PROTECTED]> wrote:
>> Personally, my instinct is that having the whole traceback in a
>> doctest is at least as ugly.
You don't need the whole traceback -- e.g.:
"""
If a URL is supplied, it must have an authority (host:port) component.
According to RFC 3986, having an authority component means the URL must
have two slashes after the scheme:
>>> _parse_proxy('file:/ftp.example.com/')
Traceback (most recent call last):
ValueError: proxy URL with no authority: 'file:/ftp.example.com/'
"""
I think the try: ... except FooException: print 'FooException occurred'
style is uglier and less natural than that, but I guess it's not a big
deal.
> Well, it depends on what you use doctest for. If you use it to write
> unit tests, the try/except solution is fine, and perhaps preferable.
[...]
Preferable because depending less on irrelevant details? I had thought
that, apart from the issue with module traceback, IGNORE_EXCEPTION_DETAIL
made that a non-issue in most cases, but perhaps I missed something
(again).
John
___
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] refleaks & test_tcl & threads
On my box, the latest batch of refleak fixes seems to have fixed all but one of the leaky tests. test_threading_local still leaks, but it leaks rather consistently now (which is new.) I'm not able to make the other ones leak with any combination of '-u' or removing .pyc's beforehand or running longer or shorter. I hope it's not just my box :-) test_threading_local is not entirely consistent, but it looks a lot more reliable on my box than on Neal's automated mails:test_threading_localbeginning 11 repetitions12345678901... test_threading_local leaked [34, 34, 34, 34, 34, 26, 26, 22, 34] referencesOne remaining issue with refleakhunting on my machine is that test_tcl can't stand being run twice. Even without -R, this makes Python hang while waiting for a mutex in the second run through test_tcl: ...trunk $ ./python -E -tt Lib/test/regrtest test_tcl test_tclAttaching gdb to the hung process shows this unenlightening trace:#0 0x2b7d6629514b in __lll_mutex_lock_wait () from /lib/libpthread.so.0 #1 0x2b7d6639a280 in completed.4801 () from /lib/libpthread.so.0#2 0x0004 in ?? ()#3 0x2b7d66291dca in pthread_mutex_lock () from /lib/libpthread.so.0#4 0x in ?? () The process has one other thread, which is stuck here:#0 0x2b7d667f14d6 in __select_nocancel () from /lib/libc.so.6#1 0x2b7d67512d8c in Tcl_WaitForEvent () from /usr/lib/libtcl8.4.so.0#2 0x2b7d66290b1c in start_thread () from /lib/libpthread.so.0 #3 0x2b7d667f8962 in clone () from /lib/libc.so.6#4 0x in ?? ()It smells like test_tcl or Tkinter is doing something wrong with regards to threads. I can reproduce this on a few machines, but all of them run newish linux kernels with newish glibc's and newish tcl/tk. At least in kernel/libc land, various thread related things changed of late. I don't have access to other machines with tcl/tk right now, but I wonder if anyone can reproduce this in different situations. -- Thomas Wouters <[EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ 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] refleaks & test_tcl & threads
On 4/16/06, Thomas Wouters <[EMAIL PROTECTED]> wrote: test_threading_local is not entirely consistent, but it looks a lot more reliable on my box than on Neal's automated mails:test_threading_localbeginning 11 repetitions12345678901 ... test_threading_local leaked [34, 34, 34, 34, 34, 26, 26, 22, 34] referencesThis is caused by _threading_local.local's __del__ method, or rather the fact that it's part of a closure enclosing threading.enumerate . Fixing the inner __del__ to call enumerate (which is 'threading.enumerate') directly, rather than through the cellvar 'threading_enumerate', makes the leak go away. The fact that the leakage is inconsistent is actually easily explained: the 'local' instances are stored on the 'currentThread' object indexed by 'key', and keys sometimes get reused (since they're basically id(self)), so sometimes an old reference is overwritten. It doesn't quite explain why using the cellvar causes the cycle, nor does it explain why gc.garbage remains empty. I guess some Thread objects linger in threading's _active or _limbo dicts, but I have no idea why having a cellvar in the cycle matters; they seem to be participating in GC just fine, and I cannot reproduce the leak with a simpler test. And on top of that, I'm not sure *why* _threading_local.local is doing the song and dance to get a cellvar. If the global 'enumerate' (which is threading.enumerate) disappears, it will be because Python is cleaning up. Even if we had a need to clean up the local dict at that time (which I don't believe we do), using a cellvar doesn't guarantee anything more than using a global name. Chances are very good that the 'threading' module has also been cleared, meaning that while we still have a reference to threading.enumerate, it cannot use the three globals it uses (_active, _limbo, _active_limbo_lock.) All in all, I think matters improve significantly if it just deals with the NameError it'll get at cleanup (which it already does.) -- Thomas Wouters <[EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ 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] PEP 359: The "make" Statement
On 4/15/06, Greg Ewing <[EMAIL PROTECTED]> wrote: > Steven Bethard wrote: > > >make : > > > > I don't like the position of the name being defined. > It should be straight after the opening keyword, as > with 'def' and 'class'. I see where you're coming from, but the current ordering exists so that ``class`` and ``make type`` are basically equivalent (for new-style classes). I'm trying not to break too far from the class statement. The next update of the PEP will try to make this more clear. That said, I think that the order of expressions is only a minor concern, at least until people have agreed that the make-statement concept is a good one. Until then, I'd rather defer pure syntax issues. STeVe -- Grammar am for people who can't think for myself. --- 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] need info for externally maintained modules PEP
On 4/8/06, Brett Cannon <[EMAIL PROTECTED]> wrote: > OK, I am going to write the PEP I proposed a week or so ago, listing > all modules and packages within the stdlib that are maintained > externally so we have a central place to go for contact info or where > to report bugs on issues. This should only apply to modules that want > bugs reported outside of the Python tracker and have a separate dev > track. People who just use the Python repository as their mainline > version can just be left out. > Basically, from all the replies I have gotten has said that package that were/are externally maintained either considers Python HEAD as the current version or watches checkins and the bug tracker and thus the PEP is really not needed. So unless some package steps forward and says that they prefer external reporting of bugs and patches, I will consider this PEP idea dead and just modify HEAD without worrying about it. -Brett ___ 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] need info for externally maintained modules PEP
Brett Cannon wrote: > Basically, from all the replies I have gotten has said that package > that were/are externally maintained either considers Python HEAD as > the current version or watches checkins and the bug tracker and thus > the PEP is really not needed. So unless some package steps forward > and says that they prefer external reporting of bugs and patches, I > will consider this PEP idea dead and just modify HEAD without worrying > about it. Not sure whether Fredrik Lundh has responded, but I believe he once said that he would prefer if ElementTree isn't directly modified, but that instead patches are filed on the SF tracker and assigned to him. Regards, Martin ___ 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] need info for externally maintained modules PEP
On 4/16/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Brett Cannon wrote: > > Basically, from all the replies I have gotten has said that package > > that were/are externally maintained either considers Python HEAD as > > the current version or watches checkins and the bug tracker and thus > > the PEP is really not needed. So unless some package steps forward > > and says that they prefer external reporting of bugs and patches, I > > will consider this PEP idea dead and just modify HEAD without worrying > > about it. > > Not sure whether Fredrik Lundh has responded, but I believe he once > said that he would prefer if ElementTree isn't directly modified, but > that instead patches are filed on the SF tracker and assigned to him. > Nope, Fredrik never responded. I am cc:ing him directly to see if he has a preference along with Gerhard to see if he has one as well for pysqlite. -Brett ___ 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] Py_Finalize does not release all memory, not even closely
[Tim] >> Because new-style classes create cycles that Py_Finalize() doesn't >> clean up, it may make analysis easier to stick a PyGC_Collect() call >> (or two! repeat until it returns 0) inside the loop now. [Martin] > I'm shy to do this: the comment in Py_Finalize suggests that things > will break if there is a "late" garbage collection. Putting a collection call inside an initialize/finalize loop isn't doing it late, it's doing it early. If we can't collect cyclic trash after Py_Initialize(), that would be a showstopper for apps embedding Python "in a loop"! There's either nothing to fear here, or Python has a very bad bug. Are you thinking of this comment?: /* Collect final garbage. This disposes of cycles created by * new-style class definitions, for example. * XXX This is disabled because it caused too many problems. If * XXX a __del__ or weakref callback triggers here, Python code has * XXX a hard time running, because even the sys module has been * XXX cleared out (sys.stdout is gone, sys.excepthook is gone, etc). * XXX One symptom is a sequence of information-free messages * XXX coming from threads (if a __del__ or callback is invoked, * XXX other threads can execute too, and any exception they encounter * XXX triggers a comedy of errors as subsystem after subsystem * XXX fails to find what it *expects* to find in sys to help report * XXX the exception and consequent unexpected failures). I've also * XXX seen segfaults then, after adding print statements to the * XXX Python code getting called. */ I wrote that, and think it's pretty clear: after PyImport_Cleanup(), so little of the interpreter still exists that _any_ problem while running Python code has a way of turning into a fatal problem. For example, internal error mechanisms that fetch things from the sys module (like excepthook or stdout) are usually (always?) careful to check whether the fetched things are NULL, but wander into lala-land when Py_None comes back (as it does after PyImport_Cleanup() "Nones-out" everything in sys). But call Py_Initialize() again, and everything (including the sys module) should become usable again. ... >>> This totals to 360, which is for some reason higher than the numbers >>> I get when counting the objects on the global list of objects. >> How much higher? > Well, I counted an increase of 156 objects on the "all objects" > list, and an increase of 360 according to the COUNT_ALLOCS numbers. > The first number was without COUNT_ALLOCS being defined, though. > > Anyway, thanks for your comments. I'll try to look at this from > time to time, maybe I can resolve some of the leaks. Could you check in the code you're using? It would be useful to share this, and improve it over time. Of course it's easy to write a C program that calls Py_Initialize() and Py_Finalize() in a loop, but it gets real tedious real fast to add analysis code sufficient to truly help track down leaks. I'd be happiest to contribute future hints in the form of working C code :-) Heck, if we got the leaks down to 0 on second and subsequent calls, we could even make a standard test out of it to ensure it stays that way. ___ 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] windows buildbot failures
The windows buildbot slaves (cygwin too) are still having problems with the DLL being in use when we start compiling so the compile fails. clean.bat is not called afterwards based on the buildbot log. I don't know if clean fixes the problem. If it does, would this patch fix the problem: Index: Tools/buildbot/build.bat === --- Tools/buildbot/build.bat(revision 45475) +++ Tools/buildbot/build.bat(working copy) @@ -1,4 +1,5 @@ @rem Used by the buildbot "compile" step. +cmd /c Tools\buildbot\clean.bat cmd /c Tools\buildbot\external.bat call "%VS71COMNTOOLS%vsvars32.bat" devenv.com /useenv /build Debug PCbuild\pcbuild.sln If the patch won't fix the problem, is there something else we can do to ensure the python DLL is no longer used regardless of whether the previous test passed or not? If we can get the process handle, can we can subprocess.TerminateProcess()? 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
[Python-Dev] 2.5 post-alpha1 broken on mac-intel machines
Back from vacation, just did an svn up and make, and...: ... gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes Parser/acceler.o Parser/grammar1.o Parser/listnode.o Parser/node.o Parser/parser.o Parser/parsetok.o Parser/bitset.o Parser/metagrammar.o Parser/ firstsets.o Parser/grammar.o Parser/pgen.o Objects/obmalloc.o Python/ mysnprintf.o Parser/tokenizer_pgen.o Parser/printgrammar.o Parser/ pgenmain.o -ldl -o Parser/pgen /usr/bin/ld: warning Parser/printgrammar.o cputype (18, architecture ppc) does not match cputype (7) for specified -arch flag: i386 (file not loaded) /usr/bin/ld: Undefined symbols: __Py_printgrammar __Py_printnonterminals collect2: ld returned 1 exit status make: *** [Parser/pgen] Error 1 No idea where that deuced "architecture ppc" comes from, since this Mac (a Macbook Pro) has an intel CPU -- I assume some configuration file erroneously posits that Macs "must" have PPC processors (which has been false for many months and was not posited in alpha-1, which compiled fine here). Too tired to look more into this (having just driven back from a week's vacation in the Grand Canyon), but I will next week if I have to...:-( Alex ___ 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] windows buildbot failures
[Neal Norwitz] > The windows buildbot slaves (cygwin too) are still having problems > with the DLL being in use when we start compiling so the compile > fails. clean.bat is not called afterwards based on the buildbot log. > I don't know if clean fixes the problem. If it does, would this patch > fix the problem: > > Index: Tools/buildbot/build.bat > === > --- Tools/buildbot/build.bat(revision 45475) > +++ Tools/buildbot/build.bat(working copy) > @@ -1,4 +1,5 @@ > @rem Used by the buildbot "compile" step. > +cmd /c Tools\buildbot\clean.bat > cmd /c Tools\buildbot\external.bat > call "%VS71COMNTOOLS%vsvars32.bat" > devenv.com /useenv /build Debug PCbuild\pcbuild.sln I doubt that will solve it, but you can check it in to give it a try (and revert the checkin if it doesn't help). > If the patch won't fix the problem, is there something else we can do > to ensure the python DLL is no longer used regardless of whether the > previous test passed or not? If we can get the process handle, can we > can subprocess.TerminateProcess()? I don't know. Typically (but not always, and in IME), we get into this like so: 1. The buildbot slave terminates the test run "early" for some reason. Maybe because the slave lost its connection to the master, or maybe because too much time has elapsed since the buildbot saw any output from the test process. 2. The buildbot code tries to kill the process itself. It appears (to judge from the buildbot messges) that this never works on Windows. 3. For reasons that are still unknown, python_d.exe keeps running, and forever. So long as the DLL is in use, Windows will not allow it to be deleted or renamed, so all subsequent attempts to compile fail. Now I'm not really sure _which_ process #2's "the process" may be. If it's the python_d.exe process, then I conclude that the programmatic way the buildbot uses to try to kill python_d.exe doesn't work in this situation. I never have any trouble killing it "by hand" using Task Manager, and that's all I know for sure. ___ 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
