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 corr
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 mailin
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
>
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, be
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. U
> 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
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 th
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='te
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 afr
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
>> 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.
> 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 (per
> 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
_
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
Pytho
14 matches
Mail list logo
