[Python-Dev] os.defpath for Windows
Hi, just saw that os.defpath for Windows is defined as Lib/ntpath.py:30:defpath = '.;C:\\bin' Most Windows machines I saw has no c:\bin directory. Any reason why it was defined this way ? Thanks, Yinon ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.6.1 documentation not available for download
> I've made documentation for 2.6.1 now. It's at > http://www.python.org/ftp/python/doc/2.6.1 In previous releases (back to 1.2), these files had version numbers in them. It would be good if those could be added for the more recent documentation sets as well. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] extremely slow exit for program having huge (45G) dict (python 2.5.2)
> It is likely that PyMalloc would be better with a way to disable the > free()ing of empty arenas, or move to an arrangement where (like the > various type free-lists in 2.6+) explicit action can force pruning of > empty arenas - there are other usage patterns than yours which would > benefit (performance wise) from not freeing arenas automatically. Before such a mechanism is added, I'd like to establish for a fact that this is an actual problem. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Can't have unbuffered text I/O in Python 3.0?
>> It appears that this bug was already reported: >> http://bugs.python.org/issue4705 >> >> Any chance that it gets in the next 3.0.x bugfix release? >> >> Just as a note, if I do: sys.stdout._line_buffering = True, it also >> works, but doesn't seem right as it's accessing an internal attribute. >> >> Note 2: the solution that said to pass 'wb' does not work, because I >> need the output as text and not binary or text becomes garbled when >> it's not ascii. >> > > Can't you decode the bytes after you receive them? > Well, in short, no (long answer is that I probably could if I spent a long time doing my own console instead of relying on what's already done and working in Eclipse for all the current available languages it supports, but that just doesn't seem right). Also, it's seems easily solvable (enabling line buffering for the python streams when -u is passed) in the Python side... My current workaround is doing that on a custom site-initialization when a Python 3 interpreter is found, but I find that this is not the right way for doing it, and it really feels like a Python bug. -- Fabio ___ Python-Dev mailing list Python-Dev@python.org 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 3.0.1
Barry Warsaw wrote: > Thanks. I've bumped that to release blocker for now. If there are any > other 'high' bugs that you want considered for 3.0.1, please make the > release blockers too, for now. I think wsgiref package needs to be fixed. For now it's totally broken. I've already found 4 issues about that: http://bugs.python.org/issue3348 http://bugs.python.org/issue3401 http://bugs.python.org/issue3795 http://bugs.python.org/issue4522 What needs to be fixed: 1. Headers handling in wsgiref.simple_server. Not so hard actually - in a few places headers expected as a list object instead of a dict. 2. wsgiref.handlers should support bytes instead of str. I think WSGI applications must return bytes as a result but we can allow Unicode strings in start_response() because the resulting encoding for headers is known and strings can be safely encoded. So the fix won't be so hard too - few asserts needs to be fixed and headers output needs to be directed through auxiliary encoding method. 3. Tests 4. Documentation examples. I can create the patch before December 24th if needed. -- Dmitry Vasiliev http://hlabs.spb.ru ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.6.1 documentation not available for download
On Sun, Dec 21, 2008 at 3:46 AM, "Martin v. Löwis" wrote: > In previous releases (back to 1.2), these files had version > numbers in them. It would be good if those could be added for > the more recent documentation sets as well. I agree that adding version numbers would be nice, but I'm also afraid of breaking people's automatic downloads of the documentation. Perhaps add symlinks? -- Cheers, Benjamin Peterson "There's nothing quite as beautiful as an oboe... except a chicken stuck in a vacuum cleaner." ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] python 2.5.3 segmentation fault with gcc 4.1.2
hi all, i'm trying to build python 2.5.3 on centos5.2 x86_64 (base gcc is 4.1.2) output of env, configure, make -j and make test at http://users.ugent.be/~stdweird/python-gcc-seg.tar.gz this all seems ok (at least to me ;) but the following code gives a segfault instead of an IOerror fname='test123' f=open(fname,'w') f.read() (test123 doesn't exists. it is a reduced problem from a scipy unittest). with system python (2.4.3) i get: IOError: [Errno 9] Bad file descriptor any hints what might cause this (or how i can figure it out). i have a coredump, but have no clue what to look for. many thanks, stijn -- The system will shutdown in 5 minutes. ___ Python-Dev mailing list Python-Dev@python.org 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 2.5.3 segmentation fault with gcc 4.1.2
Stijn> any hints what might cause this (or how i can figure it out). i Stijn> have a coredump, but have no clue what to look for. I can reproduce it on my Mac. The croak happens while it is attempting to raise the exception about a bad file descriptor. Unfortunately, in PyErr_Restore the call to PyThreadState_GET() returns NULL which means that _PyThreadState_Current is NULL. I see no differences between pystate.[ch] in the 2.5 and 2.6 branches. There must be something different about the way PyThreadState_Swap or PyThreadState_DeleteCurrent are used. Those are the only two routines which appear to set it. Did this not happen with 2.5.2? -- Skip Montanaro - s...@pobox.com - http://smontanaro.dyndns.org/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.6.1 documentation not available for download
> I agree that adding version numbers would be nice, but I'm also afraid > of breaking people's automatic downloads of the documentation. Perhaps > add symlinks? For the releases that have been made, yes (or, actually, hard links would work as well). For the releases yet to come, it would be good if the release process created version-numbered files. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org 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 2.5.3 segmentation fault with gcc 4.1.2
s...@pobox.com schrieb: > Stijn> any hints what might cause this (or how i can figure it out). i > Stijn> have a coredump, but have no clue what to look for. > > I can reproduce it on my Mac. The croak happens while it is attempting to > raise the exception about a bad file descriptor. Unfortunately, in > PyErr_Restore the call to PyThreadState_GET() returns NULL which means that > _PyThreadState_Current is NULL. I see no differences between pystate.[ch] > in the 2.5 and 2.6 branches. There must be something different about the > way PyThreadState_Swap or PyThreadState_DeleteCurrent are used. Those are > the only two routines which appear to set it. > > Did this not happen with 2.5.2? Wild guess: the bug might be related to http://bugs.python.org/issue1683. From the top of my head it's the only major change in the thread state code that I can recall. Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] extremely slow exit for program having huge (45G) dict (python 2.5.2)
On Sat, Dec 20, 2008 at 6:09 PM, Mike Coleman wrote: > On Sat, Dec 20, 2008 at 5:40 PM, Alexandre Vassalotti >> Have you seen any significant difference in the exit time when the >> cyclic GC is disabled or enabled? > > Unfortunately, with GC enabled, the application is too slow to be > useful, because of the greatly increased time for dict creation. I > suppose it's theoretically possible that with this increased time, the > long time for exit will look less bad by comparison, but I'd be > surprised if it makes any difference at all. I'm confident that there > are no loops in this dict, and nothing for cyclic gc to collect. Try putting an explicit gc.collect() at the end, with the usual timestamps before and after. After that try deleting your dict, then calling gc.collect(), with timestamps throughout. -- Adam Olsen, aka Rhamphoryncus ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.6.1 documentation not available for download
On Sun, Dec 21, 2008 at 11:57 AM, "Martin v. Löwis" wrote: >> I agree that adding version numbers would be nice, but I'm also afraid >> of breaking people's automatic downloads of the documentation. Perhaps >> add symlinks? > > For the releases that have been made, yes (or, actually, hard links > would work as well). For the releases yet to come, it would be good > if the release process created version-numbered files. Ok. I will add hardlinks for past releases and modify the Doc/Makefile to add version numbers. -- Regards, Benjamin Peterson ___ Python-Dev mailing list Python-Dev@python.org 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 2.5.3 segmentation fault with gcc 4.1.2
s...@pobox.com wrote: > Did this not happen with 2.5.2? I have 2.5.1 and 2.5.2 and it produces an IOError, just as it should. So this was indeed introduced by 2.5.3. -Scott -- Scott Dial sc...@scottdial.com scod...@cs.indiana.edu ___ Python-Dev mailing list Python-Dev@python.org 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 2.5.3 segmentation fault with gcc 4.1.2
Stijn De Weirdt wrote: > but the following code gives a segfault instead of an IOerror > fname='test123' > f=open(fname,'w') > f.read() I've tracked this down to r67740: """ Issue #1706039: Support continued reading from a file even after EOF was hit. """ Looking at the diff, I question the correctness of this patch. I believe the actual issue is the Py_UniversalNewlineFread() was changed to make calls to PyErr_SetFromErrno(), but then these calls occur within an ALLOW_THREADS block. I was going to try to make a new patch, but the test case that was added for it succeeded *before* the patch was applied (I reverted fileobject.c to r67739) on many platforms. I don't have access to a platform which exhibits the problem described in the tracker. Reading people's assessment, I *think* the correct patch is merely to add a call to clearerr() just before calling fread() in each function (to clear the EOF flag before performing the fread()). I don't really understand what the point of all the other changes are in the diff. I can't test my assessment because it seems the only platform discussed that had a problem was OS X (and I don't have one of those). -Scott -- Scott Dial sc...@scottdial.com scod...@cs.indiana.edu ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
