Re: [Python-Dev] [Python-checkins] r43041 - python/trunk/Modules/_ctypes/cfield.c

[Martin] > ... > I believe it does: the ctypes maintainer wants to keep the > code identical across releases (AFAICT). Fair enough -- I reverted the checkin. It's going to need #if'ery on the Python version, though, if it wants to match a Python-version-dependent data width with an appropriate fo

Re: [Python-Dev] Still looking for volunteer to run Windows buildbot

[Martin v. Löwis] > So PythonWin needs to be installed on a Windows buildbot slave, right? It must, since that's what my wiki page says ;-): http://wiki.python.org/moin/BuildbotOnWindows ... o Install a matching version of pywin32. ... _

Re: [Python-Dev] open() mode is lax

[Greg Ewing] > I've just noticed that (in 2.3.4) open() seems to accept > just about anything after the first character of the > mode argument: > > Python 2.3.4 (#1, Jun 30 2004, 16:47:37) > [GCC 3.2 20020903 (Red Hat Linux 8.0 3.2-7)] on linux2 > Type "help", "copyright", "credits" or "license" fo

Re: [Python-Dev] Still looking for volunteer to run Windows buildbot

[Trent Mick, on changing test_winsound to expect RuntimeError on a box without a sound card] > Done now (finally). Cool -- thanks! I merged that to the 2.4 branch, and (of course) your buildbot slave passes the tests on that too now. Green is a lovely color :-) _

[Python-Dev] All green!

After backporting a patch from Neal (to make test_timeout less likely to fail on the Mac buildbot slave living at python.org), all 14 columns in http://www.python.org/dev/buildbot/all/ are green. Yippee! Let's keep 'em that way. You can all take the weekend off ;-) I believe it's possible

[Python-Dev] Two buildbot slaves wedged

svn got confused trying to incorporate updates to the email pkg. Slaves sparc solaris10 gcc trunk and x86 gentoo trunk got stuck in their trunk "updating" steps for 7 hours, presumably as a result. I killed those builds, and tried to start new builds on those slaves. There was no effec

Re: [Python-Dev] Long-time shy failure in test_socket_ssl

[Tim Peters] >> ... >> test_socket_ssl >> test test_socket_ssl crashed -- >> exceptions.TypeError: 'NoneType' object is not callable [Neal Norwitz] > For closure, I believe this problem was addressed by revs 42842 and > 42844 to Lib/test/test_importhoo

Re: [Python-Dev] All green!

[Tim, last Friday] > ... all 14 columns in > > http://www.python.org/dev/buildbot/all/ > > are green. Yippee! Let's keep 'em that way. You can all take the > weekend off ;-) But you didn't, and they haven't been all green again since then . With the next 2.4 release candidate imminent, rem

[Python-Dev] segfaults on Mac (was Re: Long-time shy failure in test_socket_ssl))

[Nick Coghlan] > Hrrm, test_thread_state hands an object pointer off to a different thread > without INCREF'ing it first. Could there be a race condition with the > deallocation of arguments at the end of test_thread_state? > > Specifically, that trace looks to me like the spawned thread is trying

Re: [Python-Dev] [Python-checkins] r43126 - in python/trunk: Doc/lib/libsocket.tex Lib/socket.py Lib/test/test_socket.py Misc/NEWS Modules/socketmodule.c

[attribution lost] Looking into the library, I see many accessor functions starting with either get_ or get; however, I don't recall why that could have been relevant for socket objects. [attribution lost] >>> If you think that should be changed to attributes, we should >>> do that.

[Python-Dev] Prevalence of low-level memory abuse?

When Python's small-object memory allocator was introduced, some horrid hacks came with it to map PyMem_{Del, DEL} and PyMem_{Free, FREE} to PyObject_{Free, FREE}. This was to cater to less than a handful of extension modules found at the time that obtained memory for an object via PyObject_{New,

Re: [Python-Dev] Prevalence of low-level memory abuse?

[Tim, on PyMem vs PyObject memory mismatches] > ... Alas, in a release(*) build, Python's test suite segfaulted all over the > place. > > So far I found one smoking gun: in _subprocess.c, ... And Python's front end was chock full o' these, sometimes even getting memory via PyMem and releasing it

Re: [Python-Dev] Prevalence of low-level memory abuse?

[Edward Loper] > Could the debug build's macros for PyMem/PyObject_new/free be modified > to check for mismatches? Or would storing information about which > method was used to allocate each pointer be too expensive? Perhaps a > special build could be used to check for mismatches? It's partly po

Re: [Python-Dev] improving quality

[Neal Norwitz] ... > If you really can't figure out any way to test the change, please > describe why in your checkin message. Just make sure it's true. It > would be quite embarrassing to have your whole theory trashed when > Uncle Timmy comes along 5 minutes later and checks in the test you > j

Re: [Python-Dev] [Python-checkins] r43358 - python/trunk/Modules/itertoolsmodule.c

[Thomas Wouters] > ... > The cycle this nested generator creates, which is also involved in the > test_tee > leak, is not cleanable by the cycle-gc, and it looks like it hasn't been > since the yield-expr/coroutine patch was included in the trunk. That could very well be. Adding finalizers to ge

Re: [Python-Dev] [Python-checkins] r43358 - python/trunk/Modules/itertoolsmodule.c

[Thomas Wouters] >> So does that make all cycles involving only objects with finalizers >> impervious to cycle-gc? I guess it'd have to be that way. [again] > Er, I meant to say 'does that make all cycles involving just one object with > a finalizer impervious to cycle-gc'. Both are true, and bot

Re: [Python-Dev] Fwd: [Python-checkins] r43358 - python/trunk/Modules/itertoolsmodule.c

[Thomas Wouters] ... > not to mention avoiding finalizers on other builtin objects. (None seem to > have > them at the moment, they all do their stuff in tp_dealloc, Right, generators are the only exception now (and there were no exceptions before 2.5). > which I guess doesn't allow objects to r

Re: [Python-Dev] [Python-checkins] r43358 - python/trunk/Modules/itertoolsmodule.c

[Phillip J. Eby] > By that reasoning, binary compatibility won't be an issue anywhere else, > either, since the change was made on the 2.5 alpha trunk, and ISTM that 2.5 > will require recompiling extensions anyway. I don't know how people work on Linux; that's why I brought it up. The binary API

[Python-Dev] Nasty trunk test failures

test_tokenize started failing on all the trunk buildbots immediately after this seemingly unrelated checkin: > Author: armin.rigo > Date: Thu Mar 30 16:04:02 2006 > New Revision: 43458 > > Modified: >python/trunk/Lib/test/test_index.py >python/trunk/Objects/abstract.c >python/trunk/Obj

Re: [Python-Dev] Nasty trunk test failures

[Guido] > tokenize seems to be mishandling this line: > > assert 6 .__index__() == 6 > > Note the space between '6' and '.'. > > I'm guessing that the untokenization of this somehow drops the space; > this seems to be a bug in untokenize() which probably should add a > safety space after na

Re: [Python-Dev] 2.5 trunk built for Windows available?

[Georg Brandl] > for the Bug Day, someone asked me if there is a prebuilt trunk > for Windows available somewhere so that he could participate. > > Martin: I read you've built for a snapshot AMD64, is there one for x86 too? If someone can explain what "prebuilt trunk" means, exactly, maybe I can d

Re: [Python-Dev] alpha problems -- need input

Disabling a test on a platform is usually a bad thing, overall. The purpose of the test suite isn't to get a lot of green buildbot boxes <0.5 wink>, it's to determine whether Python works as expected. If a platform bug causes some test to fail, then that test _should_ fail on that platform -- it

Re: [Python-Dev] [Python-checkins] Python Regression Test Failures all (1)

[Neal Norwitz] """ test_bsddb3 Exception in thread reader 4: Traceback (most recent call last): File "/home/neal/python/trunk/Lib/threading.py", line 473, in __bootstrap self.run() File "/home/neal/python/trunk/Lib/threading.py", line 453, in run self.__target(*self.__args, **self.__kwa

Re: [Python-Dev] reference leaks, __del__, and annotations

[Phillip J. Eby] > ... > As Tim suggested, it'd be better to have the code be generator-specific, at > least for now. That had actually been my original plan, to make it > generator-specific, but I was afraid of breaking encapsulation in the > garbage collector by having it know about generators.

Re: [Python-Dev] [Python-checkins] r43545 - in python/trunk: Doc/lib/libcalendar.tex Lib/calendar.py

> Author: walter.doerwald > Date: Sat Apr 1 22:40:23 2006 > New Revision: 43545 > > Modified: >python/trunk/Doc/lib/libcalendar.tex >python/trunk/Lib/calendar.py > Log: > Make firstweekday a simple attribute instead > of hiding it behind a setter and a getter. Walter, what's the purpose o

Re: [Python-Dev] PY_FORMAT_SIZE_T warnings on OS X

[Brett Cannon] > I think these are all Tim's fault =) : No, they're Anthony's fault :-) He added this clause to pyport.h yesterday: # if SIZEOF_SIZE_T == SIZEOF_INT # define PY_FORMAT_SIZE_T "" and that's obviously triggering on your platform. He added this (at my suggestion) to shut u

Re: [Python-Dev] PY_FORMAT_SIZE_T warnings on OS X

[Brett Cannon] > ... > This is just so ridiculous. Ya think ;-)? > Is there even a way to do this reasonably? Not really in C89. That's why C99 introduced the "z" printf modifier, and approximately a billion ;-) format macros like PY_FORMAT_SIZE_T (since there's almost nothing portably useful

Re: [Python-Dev] Bug Day on Friday, 31st of March

[/F] > so, how did it go? a status report / summary would be nice, I think ? http://wiki.python.org/moin/PythonBugDayStatus has been kept up to date. Note that, e.g., there are still open items in the "Bugs/patches to assess for commit" section, if you want to do more than just read. __

Re: [Python-Dev] [Python-checkins] r43545 - in python/trunk: Doc/lib/libcalendar.tex Lib/calendar.py

[Tim, gripes about ...] >>> Author: walter.doerwald >>> Date: Sat Apr 1 22:40:23 2006 >>> New Revision: 43545 >>> >>> Modified: >>>python/trunk/Doc/lib/libcalendar.tex >>>python/trunk/Lib/calendar.py >>> Log: >>> Make firstweekday a simple attribute instead >>> of hiding it behind a setter

Re: [Python-Dev] Whole bunch of test failures on OSX

[EMAIL PROTECTED] > I'm not sure this is going to be all that helpful. If there's more I can do > to help track down these problems, let me know. Sure: you can do _everything_ to track them down ;-) > Last night I ran > > make test EXTRATESTOPTS='-R :: -uall -r' > > on my Mac laptop after a

Re: [Python-Dev] Whole bunch of test failures on OSX

[Neal Norwitz, on -R testing] > ... > For the latest results, see: > http://docs.python.org/dev/results/make-test-refleak.out > > Several tests fail consistently with -R. These are the most recent > from the link above: test_decimal test_difflib test_logging > test_optparse test_warnings. > > It

Re: [Python-Dev] reference leaks, __del__, and annotations

[Michael Hudson] >> I'm not sure the problem is so much that anyone _wants_ to support >> resurrection in __del__, it's just that it can't be prevented. [Guido] > Well, Java has an answer to that (at least I believe Tim Peters told > me so years ago): it allows

Re: [Python-Dev] posixmodule.c patch- revision 43586

[A.B., Khalid] > According to MSDN, ShellExecute has only six parameters: > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/reference/functions/shellexecute.asp > > But in the posixmodule patch at: > http://mail.python.org/pipermail/python-checkins/2006-April

Re: [Python-Dev] reference leaks, __del__, and annotations

[Guido] >>> but don't we have a whole word of GC-related flags? [Neil S] >> No. [James Y Knight] > Actually there is. Kinda. Currently python's refcounting scheme uses > 4 words per object (gc_next, gc_prev, gc_refs, ob_refcnt), and has > one spare word in the padding of PyGC_Head that's just sit

Re: [Python-Dev] posixmodule.c patch- revision 43586

[Tim] >> While we're at it, looks like all the 2.4 buildbots are failing >> test_email today. [Barry] > Anthony backported the patch that should fix this, so it should be > showing up in 2.4 buildbots soon. ? Anthony's """ Changed by: anthony.baxter Changed at: Mon 03 Apr 2006 16:40:28 Branch:

Re: [Python-Dev] reference leaks, __del__, and annotations

[Phillip J. Eby] > I'm trying to figure out how to implement this now, and running into > a bit of a snag. It's easy enough for gcmodule.c to check if an > object is a generator, but I'm not sure how safe the dynamic check > actually is, since it depends on the generator's state. In > principle,

Re: [Python-Dev] reference leaks, __del__, and annotations

[Michael Hudson] > ... > What happened to the 'get rid of __del__ in py3k' idea? Apart from its initial mention, every now & again someone asks what happened to it :-). ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/list

Re: [Python-Dev] reference leaks, __del__, and annotations

[Michael Hudson] >>> And if we want to have a version of __del__ that can't reference >>> 'self', we have it already: weakrefs with callbacks. [Greg Ewing] >> Does that actually work at the moment? Last I heard, >> there was some issue with gc and weakref callbacks >> as well. Has that been resolv

Re: [Python-Dev] current 2.5 status

[Neal Norwitz] > ... > The following systems are green: > ... > x86 Windows 2k & XP (though there were some problems due to previous runs) There are no problems on one of the XP slaves. test_sqlite never ran on Win2K, although it's unlikely it will fail there (given that test_sqlite has run succe

Re: [Python-Dev] current 2.5 status

Trent, FYI, on my box the invariable cause for LINK : fatal error LNK1104: cannot open file './python25_d.dll' in a failed buildbot Windows compile step is that some previous run left behind a python_d.exe process that won't go away. I don't know why it won't go away on its own, or how it ge

Re: [Python-Dev] reference leaks, __del__, and annotations

[Tim Peters] >> A problem is that the variant semantics also seem pretty arbitrary ;-), >> and there's a dearth of compelling use cases to guide a decision. [Greg Ewing] |> At the time I think I suggested that it would be > reasonable if weakref callbacks were guaranteed to

Re: [Python-Dev] reference leaks, __del__, and annotations

[Greg Ewing] > That's really what I'm asking -- what *does* a > generator finaliser need to reference? Or does > it depend on what the generator's code does? A generator finalizer can execute arbitrary Python code. Note that even if that was limited (which it isn't -- there are no limitations) to

Re: [Python-Dev] reference leaks, __del__, and annotations

[various people debating how to steal a bit from an existing PyObject member] Let's stop this. It's a "bike shed" argument: even if we had 1000 spare bits, it wouldn't do any good. Having a bit to record whether an object has been finalized doesn't solve any problem that's been raised recently

Re: [Python-Dev] 2.5a1 Performance

FYI, on my WinXP box, there appears to be about a 1% pystone difference: best seen for 2.4.3: 48118.9 best seen for trunk: 47629.8 While tiny, the difference "looked real", as many runs on 2.4.3 broke 48000 but none did on the trunk. Note that pystone uses wall-clock time on Windows (with sub-

[Python-Dev] Who understands _ssl.c on Windows?

An "impossible problem" showed up on Bug Day, which got more impossible the more I looked at it: http://www.python.org/sf/1462352 See that for details. The short course is that socketmodule.c and _ssl.c disagree about the offset at which the sock_timeout member of a PySocketSockOb

Re: [Python-Dev] Who understands _ssl.c on Windows?

So Martin fixed _ssl.c on Windows (thanks! what a subtle pit that turned out to be), and I restored the test_timeout() test in test_socket_ssl. That test was introduced on Bug Day, but: a) First got fiddled to exclude Windows, because the _ssl.c bug made it impossible for the test to pass on W

Re: [Python-Dev] segfault (double free?) when '''-string crosses line

[Guido] > On Linux, In HEAD 2.5, but only with the non-debug version, I get a > segfault when I do this: > > >>> ''' > ... ''' > > It seems to occur for any triple-quoted string crossing a line > boundary. A bit of the stack trace: > > #0 0x40030087 in pthread_mutex_lock () from /lib/i686/libpthre

Re: [Python-Dev] segfault (double free?) when '''-string crosses line

[Neal Norwitz] > http://python.org/sf/1467512 fixes the problem for me on linux. It > converts all the PyMem_* APIs to PyObject_* APIs. Assigned to Guido > until he changes that. :-) Thanks! I didn't take that route, instead not changing anything I didn't take the time to understand first. For

Re: [Python-Dev] pdb segfaults in 2.5 trunk?

[Phillip J. Eby] > ... > #0 0x401bbaa4 in _int_free () from /lib/libc.so.6 > #1 0x401baa3c in free () from /lib/libc.so.6 > #2 0x080a253e in builtin_raw_input (self=0x0, args=0x4050862c) at > Python/bltinmodule.c:1759 > > It appears the problem is an object/mem mismatch: both PyOS_Readline in >

Re: [Python-Dev] pdb segfaults in 2.5 trunk?

[Guido] > Shouldn't it at least match call_readline() in Modules/readline.c, > which uses PyMem_Malloc()? I'm not sure what "it" means there, but, like I said, it's messy regardless. That's why we ended up with a large number of mismatches to begin with: there are many allocation and free'ing si

Re: [Python-Dev] Who understands _ssl.c on Windows?

[Trent] > C:\trentm\src\python\python\PCbuild>python_d > Python 2.5a1 (trunk, Apr 10 2006, 14:48:00) [MSC v.1310 32 bit (Intel)] > on win32 > Type "help", "copyright", "credits" or "license" for more information. > >>> import socket > [25133 refs] > >>> s = socket.socket()

Re: [Python-Dev] Who understands _ssl.c on Windows?

[Neal Norwitz] > Maybe we should clean before we configure/compile? That would leave > the last build in tact until the next run. It doesn't matter much to me -- I do all changes and checkins from a non-buildbot checkout. The one thing I like about the current scheme is that when I run my daily

Re: [Python-Dev] pdb segfaults in 2.5 trunk?

[Greg Ewing] > However, if they're not exclusively for objects, > having "Object" in the name would seem to be > highly confusing, perhaps dangerously so. (Person > A writes PyObject_Alloc(some_chars), Person B > writing the code to free it thinks "What??? > That can't be right!" and uses PyMem_Fre

Re: [Python-Dev] Py_Finalize does not release all memory, not even closely

[Martin v. Löwis] > Several places in the documentation claim that Py_Finalize will > release all memory: > > http://docs.python.org/api/embedding.html > > says that literally, It's wrong ;-). > and > > http://docs.python.org/api/initialization.html#l2h-778 > > suggests it is a bug when memory is

Re: [Python-Dev] pdb segfaults in 2.5 trunk?

[Delaney, Timothy (Tim)] > Definitely seems to me that it would be worthwhile in debug mode adding > a field specifying which memory allocator was used, and checking for > mismatches in the deallocators. > > I know this has been suggested before, but with number of mismatches > being found now it s

[Python-Dev] Preserving the blamelist

All the trunk buildbots started failing about 5 hours ago, in test_parser. There have been enough checkins since then that the boundary between passing and failing is about to scroll off forever. So, here's the blamelist before it vanishes: """ 1. Changed by: thomas.wouters Chang

Re: [Python-Dev] Preserving the blamelist

[Neal Norwitz] > ... > I'm concerned about the negative ref leak in test_contextlib. I > wonder if this was a result of PJE's fix for generators? I don't know, but if you do while 1: test_contextlib.test_main() gc.collect() under a debug build it eventually (> 500 iterations) crashes wi

Re: [Python-Dev] Preserving the blamelist

[Neal] >> ... >> I'm concerned about the negative ref leak in test_contextlib. I >> wonder if this was a result of PJE's fix for generators? [Tim] > I don't know, but if you do > > while 1: > test_contextlib.test_main() > gc.collect() > > under a debug build it eventually (> 500 iteration

Re: [Python-Dev] Preserving the blamelist

[Tim ] >> I'd whine about not checking buildbot health after a code change, >> except that it's much more tempting to point out that Thomas couldn't >> have run the test suite successfully on his own box in this case :-) [Thomas] > Not with -uall, yes. Without -uall it ran fine (by chance, I admit

Re: [Python-Dev] Preserving the blamelist

[Tim] >> Phillip, when eyeballing gen_dealloc(), I didn't understand two things: >> >> 1. Why doesn't >> >> if (gen->gi_frame->f_stacktop!=NULL) { >> >>check first to be sure that gen->gi_frame != Py_None? [Phillip] > Apparently, it's because I'm an idiot, and because nobody else reali

Re: [Python-Dev] [Python-checkins] r45321 - in python/trunk: Lib/test/test_traceback.py Lib/traceback.py Misc/NEWS

[georg.brandl] > Author: georg.brandl > Date: Wed Apr 12 23:14:09 2006 > New Revision: 45321 > > Modified: >python/trunk/Lib/test/test_traceback.py >python/trunk/Lib/traceback.py >python/trunk/Misc/NEWS > Log: > Patch #860326: traceback.format_exception_only() now prepends the > excepti

Re: [Python-Dev] Request for review

[Georg Brandl] > Hm. This broke a few doctests. I can fix them, but I wonder if > doctest should accept a bare exception name if the exception > is defined in the current module. No. > Or should it ignore the module name altogether? No. doctest strives to be magic-free WYSIWYG. If someone _int

Re: [Python-Dev] [Python-checkins] r45321 - in python/trunk: Lib/test/test_traceback.py Lib/traceback.py Misc/NEWS

[Tim] >> ... >> Fine by me if we change the failing tests on the trunk to pass (noting >> that should have been done before checking in). [Phillip] > It's not fine by me if the reason for the failure is that doctests trapping > specific exceptions no longer work with the patch.> > If that's the ca

Re: [Python-Dev] TODO Wiki (was: Preserving the blamelist)

[A.M. Kuchling] >> Do we need a list of CPython cleanup projects? >> (Compare to the Linux kernel janitors: >> .) [Neal Norwitz] > +1. Could add a page to the wiki and link to it from the dev faq. Not the same thing, but I just added: http://wiki.pytho

[Python-Dev] Exceptions doctest Re: Request for review

[Tim] >> ... >> doctest strives to be magic-free WYSIWYG. If someone _intends_ >> the module name to be optional in a doctest, they should explicitly >> use doctest's ELLIPSIS option. [Nick Coghlan] > There's already a little bit of magic in the way doctest handles exceptions. I > always use doct

Re: [Python-Dev] [Python-checkins] r45321 - in python/trunk: Lib/test/test_traceback.py Lib/traceback.py Misc/NEWS

[Georg Brandl] > Well, it's tempting to let the buildbots run the tests for you > Honestly, I didn't realize that doctest relies on traceback. Running > the test suite takes over half an hour on this box, so I decided to > take a chance. Nobody ever expects that a checkin will break tests, so mer

Re: [Python-Dev] Is test_sundry really expected to succeed on Windows?

[Paul Moore] > I've just managed to get Python built using the free MS compiler and > tools (yay! full instructions to follow somewhere - probably the wiki > and maybe as a patch to PCBuild\readme.txt) > > There's one thing that puzzled me - test_sundry is marked as an > "unexpected skip". As it im

Re: [Python-Dev] Is test_sundry really expected to succeed on Windows?

[Paul Moore] >> Sorry, it's a trunk checkout, but I'm currently working on a machine >> without svn access, so my checkout is from last night (before your >> checkin). So that's the issue. >> >> Apologies - I should have checked the svn logs first. [Martin v. Löwis] > I find this kind of mistake (

Re: [Python-Dev] [Python-checkins] r45334 - python/trunk/Lib/test/leakers/test_gen1.py python/trunk/Lib/test/leakers/test_generator_cycle.py python/trunk/Lib/test/leakers/test_tee.py

[neal.norwitz] >> Author: neal.norwitz >> Date: Thu Apr 13 06:35:36 2006 >> New Revision: 45334 >> >> Added: >>python/trunk/Lib/test/leakers/test_gen1.py (contents, props changed) >> Removed: >>python/trunk/Lib/test/leakers/test_generator_cycle.py >>python/trunk/Lib/test/leakers/test_

Re: [Python-Dev] Procedure for sandbox branches in SVN?

[Phillip J. Eby] > I'd like to create a branch for maintaining the setuptools 0.6 line through > its beta and final release, while new work proceeds on the trunk for > integration with Python 2.5 and beginning the 0.7 line. Is there any > special procedure I should follow, or can I just make a 'se

Re: [Python-Dev] Procedure for sandbox branches in SVN?

[Martin v. Löwis] > That's all true. Of course, removing the branch won't free up > any disk space - it will just remove the branch from the view > (IOW, it is also easy to bring it back if it was removed mistakenly). Right! I'm implicitly addressing a different issue, namely that two reasons for

[Python-Dev] Debugging opportunity :-)

When "possible finalizers" were added to generators, the implementation at first said that all generators need finalizing. As a result, some old tests in test_generators.py started leaking cyclic trash. As a result of that, someone(s) added a number of explicit "close" gimmicks to those tests, to

Re: [Python-Dev] Debugging opportunity :-)

[Phillip J. Eby] > Even with the close() gimmicks still in place? If so, it sounds like the > safest thing for a2 might be to claim that generators always need > finalizing. :( LOL! Been there many times before: Python's gc really does work, but it's as unforgivingly delicate as any dance you'

Re: [Python-Dev] [Python-checkins] r45321 - in python/trunk: Lib/test/test_traceback.py Lib/traceback.py Misc/NEWS

[John J Lee] >> Assuming this is fixed in 2.5 final, is there some way to write doctests that >> work on both 2.4 and 2.5? If not, should something like >> doctest.IGNORE_EXCEPTION_DETAIL be added -- say >> IGNORE_EXCEPTION_MODULE? [also John] > Sorry, please ignore the post of mine I'm replying

Re: [Python-Dev] [Python-checkins] r45321 - in python/trunk: Lib/test/test_traceback.py Lib/traceback.py Misc/NEWS

[John J Lee] ... > You mentioned use of '...' / ELLIPSIS, IIRC, so I assumed that would work > -- but it seems not, from your latest post (that I'm replying to here). Different context -- answering why IGNORE_EXCEPTION_DETAIL exists given that ELLIPSIS can do everything it does (provided you don't

Re: [Python-Dev] Py_Finalize does not release all memory, not even closely

[Martin] > Running Py_Initialize/Py_Finalize once leaves 2150 objects behind (on > Linux). The second run adds 180 additional objects; each subsequent > run appears to add 156 more. One thing I notice is that they're all > 0 :-) I believe that, at one time, the second and subsequent numbers were

Re: [Python-Dev] Preserving the blamelist

[Tim] >> All the trunk buildbots started failing about 5 hours ago, in >> test_parser. There have been enough checkins since then that the >> boundary between passing and failing is about to scroll off forever. [Martin] > It's not lost, though; it's just not displayed anymore. It would be > possi

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 bre

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 > f

Re: [Python-Dev] windows buildbot failures

[Tim] >> ... >> 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. [Martin] > It's actually not too surprising th

Re: [Python-Dev] refleaks & test_tcl & threads

[Thomas Wouters] >> 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_local >> beginning 11 repetitions >> 12345678901 >> ... >> test_threading_local leaked [34, 34, 34, 34, 34, 26, 26, 22, 34]

Re: [Python-Dev] Returning -1 from function with unsigned long type

[EMAIL PROTECTED] > I'm fiddling with the "compile Python w/ C++" stuff and came across a number > of places where a function is defined as returning unsigned long or unsigned > long long but returns -1. For example, see PyInt_AsUnsignedLongMask. > What's the correct fix for that, return ~0 (assu

Re: [Python-Dev] Gentoo failures - it's blaming me...

[EMAIL PROTECTED] > I'm on the blame list for the current gentoo buildbot failures. I promise I > ran "make test" before checking anything in. I don't see where the changes > I checked in would have caused the reported test failures, but I'm > investigating. If anyone has any suggestions, let me

Re: [Python-Dev] refleaks & test_tcl & threads

[Thomas Wouters] > ... > One 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_tcl >

Re: [Python-Dev] 2.5a1 Performance

[M.-A. Lemburg] > I could contribute pybench to the Tools/ directory if that > makes a difference: +1. It's frequently used and nice work. Besides, then we could easily fiddle the tests to make Python look better ;-) ___ Python-Dev mailing list Python-

Re: [Python-Dev] Google Summer of Code proposal: improvement of long int and adding new types/modules.

> than already used, and transparently improve efficiency of multiplying >> and printing/reading big integers. [Guido van Rossum] > That would be a good project, if someone is available to mentor it. > (Tim Peters?) Generally speaking, I think longobject.c is already at the limit

Re: [Python-Dev] [Python-checkins] Python Regression Test Failures refleak (1)

[19 Apr 2006, Neal Norwitz] > test_cmd_line leaked [0, 17, -17] references > test_filecmp leaked [0, 13, 0] references > test_threading_local leaked [-93, 0, 0] references > test_urllib2 leaked [-121, 88, 99] references Thanks to Thomas digging into test_threading_local, I checked in what appeare

Re: [Python-Dev] windows buildbot failures

[Andrew MacIntyre] > I doubt it has anything to do with this issue, but I just thought I'd > mention something strange I've encountered on Windows XP Pro (SP2) at > work. > > If Python terminates due to an uncaught exception, with stdout & stderr > redirected externally (ie within the batch file th

Re: [Python-Dev] windows buildbot failures

[Martin] > I see a similar phenomenon (sp?) Yup! The plural is phenomena. > on XP SP2: test_mailbox fails to > me, with permission denied in some (random) test. I believe this > is due to Tortoise SVN: test_mailbox creates a few directories, > then Tortoise detects them (thanks to file change no

Re: [Python-Dev] Reducing memory overhead for dictionaries by removing me_hash

[Kirat Singh] > Hi, this is my first python dev post, so please forgive me if this topic has > already been discussed. It's hard to find one that hasn't -- but it's even harder to find the old discussions ;-) > It seemed to me that removing me_hash from a dict entry would save 2/3 of > the space

Re: [Python-Dev] Proposed addition to threading module - released

[Guido] > Actually, what Nick describes is *exactly* how one should write code > using a condition variable: > > LOCK > while nothing to do: > UNLOCK > wait for the condition variable (or sleep, or whatever) > LOCK > # here we have something to do with the lock held > remo

Re: [Python-Dev] PY_FORMAT_SIZE_T warnings on OS X

[Brett Cannon] >> I created patch 1474907 with a fix for it. Checks if %zd works for >> size_t and if so sets PY_FORMAT_SIZE_T to "z", otherwise just doesn't >> set the macro def. >> >> Assigned to Martin to make sure I didn't foul it up, but pretty much >> anyone could probably double-check it.

Re: [Python-Dev] [Python-checkins] r45721 - python/trunk/Lib/test/test_with.py

>> Author: tim.peters >> Date: Wed Apr 26 03:15:53 2006 >> New Revision: 45721 >> >> Modified: >>python/trunk/Lib/test/test_with.py >> Log: >> Rev 45706 renamed stuff in contextlib.py, but didn't rename >> uses of it in test_with.py. As a result, test_with has been skipped >> (due to failing i

Re: [Python-Dev] [Python-checkins] Python Regression Test Failures refleak (1)

[Neal Norwitz] > ... > I have disabled the leak warning for: > > LEAKY_TESTS="test_(cmd_line|ctypes|filecmp|socket|threadedtempfile|threading|urllib2) > > This is an attempt to reduce the spam. Would people rather me reduce > this list so we can try to find the problems? The test runs 2 times > p

Re: [Python-Dev] binary trees. Review obmalloc.c

[Vladimir 'Yu' Stepanov] >> * To adapt allocation of blocks of memory with other alignment. Now >> alignment is rigidly set on 8 bytes. As a variant, it is possible to >> use alignment on 4 bytes. And this value can be set at start of the >> interpreter through arguments/variable environments/etc.

Re: [Python-Dev] 2.5 open issues

[Georg Brandl] >> As I posted here previously, I contacted the owner, and he said that he >> didn't care about specifying a license. I guess that means that we can >> pick one ;) [Martin v. Löwis] > Can you please ask whether he would be willing to fill out a contrib > form (http://www.python.org/

Re: [Python-Dev] Float formatting and #

[Georg Brandl] > ... > Reviewing the printf man page, this is okay since for %f, the precision is the > number of digits after the decimal point while for %g, it is the number of > significant digits. Still, that should be documented in the Python manual. Well, there are a lot of little details in

Re: [Python-Dev] introducing the experimental pyref wiki

[A.M. Kuchling] > ... > (Or are the two goals -- completeness and readability -- > incompossible, unable to be met at the same time by one document?) No, but it's not easy, and it's not necessarily succinct. For an existence proof, see Guy Steele's "Common Lisp the Language". I don't think it's

Re: [Python-Dev] New methods for weakref.Weak*Dictionary types

[Fred L. Drake, Jr.] > I'd like to commit this for Python 2.5: > > http://www.python.org/sf/1479988 > > The WeakKeyDictionary and WeakValueDictionary don't > provide any API to get just the weakrefs out, instead > of the usual mapping API. This can be desirable when > you want to get a list of ever

Re: [Python-Dev] Assigning "Group" on SF tracker?

[John J Lee] > When opening patches on the SF tracker for bugs that affect Python 2.5, > but may be candidates for backporting (to 2.4 ATM), should I leave "Group" > as "None", or set it to "Python 2.5" to indicate it affects 2.5? > > If it's known to be a candidate for backporting, should I set it

<    3   4   5   6   7   8   9   10   11   >