[issue3187] os.listdir can return byte strings

STINNER Victor <[EMAIL PROTECTED]> added the comment: Would it possible to close this issue since os.listdir() is fixed and many other related functions (posix, posixpath, ntpath, macpath, etc.) are also fixed? I propose to open new issues for new bugs since this issue becomes a litt

[issue4061] summing two numbers-strange answer

STINNER Victor <[EMAIL PROTECTED]> added the comment: Use Decimal to get an exact result: >>> from decimal import Decimal >>> print Decimal('2.3') + Decimal('6.3') 8.6 -- nosy: +haypo ___ Python tracker

[issue3187] os.listdir can return byte strings

STINNER Victor <[EMAIL PROTECTED]> added the comment: Le Tuesday 07 October 2008 01:13:22 Martin v. Löwis, vous avez écrit : > IIUC, these fixes are still not complete: they lack documentation > changes. (...) Of course, it would have been better if the original patches > alread

[issue3574] compile() cannot decode Latin-1 source encodings

STINNER Victor <[EMAIL PROTECTED]> added the comment: test_sys failure is fixed by the issue #2384. -- dependencies: +[Py3k] line number is wrong after encoding declaration ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.pytho

[issue4035] Support bytes for os.exec*()

STINNER Victor <[EMAIL PROTECTED]> added the comment: The patch is incomplete. It allows bytes for the arguments but not for the environment variables: posix_execve() in Modules/posixmodule.c uses: PyArg_Parse(key "s", &k) PyA

[issue3975] PyTraceBack_Print() doesn't respect # coding: xxx header

STINNER Victor <[EMAIL PROTECTED]> added the comment: Le Tuesday 07 October 2008 15:06:01 Amaury Forgeot d'Arc, vous avez écrit : > - The two calls to open() are missing the O_BINARY flag, necessary on > Windows to avoid newline translation. This may be important for some &

[issue3975] PyTraceBack_Print() doesn't respect # coding: xxx header

Changes by STINNER Victor <[EMAIL PROTECTED]>: Added file: http://bugs.python.org/file11732/traceback_unicode-3.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.pytho

[issue4004] missing newline in "Could not convert argument %s to string" error message

STINNER Victor <[EMAIL PROTECTED]> added the comment: @amaury.forgeotdarc: Done for "out of memory". @loewis: Oops, it's an error. I removed the YY. So here is a new patch. Added file: http://bugs.python.org/file11728/argv_error_newline-2.patch _

[issue3975] PyTraceBack_Print() doesn't respect # coding: xxx header

STINNER Victor <[EMAIL PROTECTED]> added the comment: Thanks for your remarks amaury. I improved my patch: - PyMem_FREE(found_encoding) is called just after PyFile_FromFd() - Create static subfunction _Py_FindSourceFile(): find a file in sys.path - Consider that sys.path contain

[issue2384] [Py3k] line number is wrong after encoding declaration

STINNER Victor <[EMAIL PROTECTED]> added the comment: @amaury: Ok, I added your long comment in tokenizer.c. You're also right about the strange code in the test. I reused ocean-city's test. "sys.exc_info()[2].tb_lineno" raises an additional (useless) error. So I

[issue2384] [Py3k] line number is wrong after encoding declaration

Changes by STINNER Victor <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file11625/tokenizer-coding-2.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.pytho

[issue2384] [Py3k] line number is wrong after encoding declaration

Changes by STINNER Victor <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file11717/tokenizer-coding-3.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.pytho

[issue2384] [Py3k] line number is wrong after encoding declaration

Changes by STINNER Victor <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file11609/test_traceback-gbk.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.pytho

[issue2384] [Py3k] line number is wrong after encoding declaration

Changes by STINNER Victor <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file11737/traceback_unicode-4.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.pytho

[issue2384] [Py3k] line number is wrong after encoding declaration

Changes by STINNER Victor <[EMAIL PROTECTED]>: Added file: http://bugs.python.org/file11738/tokenizer-coding-4.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.pytho

[issue3975] PyTraceBack_Print() doesn't respect # coding: xxx header

Changes by STINNER Victor <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file11612/traceback_unicode.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.pytho

[issue3975] PyTraceBack_Print() doesn't respect # coding: xxx header

Changes by STINNER Victor <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file11633/traceback_unicode-2.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.pytho

[issue3975] PyTraceBack_Print() doesn't respect # coding: xxx header

Changes by STINNER Victor <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file11732/traceback_unicode-3.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.pytho

[issue4035] Support bytes for os.exec*()

STINNER Victor <[EMAIL PROTECTED]> added the comment: Improved patch: - support bytes in the env dictionary using the file system default encoding - support bytes for program arguments but only on a POSIX system Document is not updated yet. Added file: http://bugs.python.org/fil

[issue4035] Support bytes for os.exec*()

Changes by STINNER Victor <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file11695/os_exec_bytes.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.pytho

[issue4036] Support bytes for subprocess.Popen()

Changes by STINNER Victor <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file11696/os_exec_bytes.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.pytho

[issue4036] Support bytes for subprocess.Popen()

STINNER Victor <[EMAIL PROTECTED]> added the comment: Oops, I attached the wrong patch :-/ -- dependencies: +Support bytes for os.exec*() Added file: http://bugs.python.org/file11742/subprocess-bytes.patch ___ Python tracker <[EMAIL PROTECTE

[issue3975] PyTraceBack_Print() doesn't respect # coding: xxx header

STINNER Victor <[EMAIL PROTECTED]> added the comment: > More fun will arise when my Windows terminal (encoding=cp1252) > will try to display Chinese characters. Let's pretend this is > yet another issue. I tried the patch using a script with unicode characters (character

[issue3975] PyTraceBack_Print() doesn't respect # coding: xxx header

Changes by STINNER Victor <[EMAIL PROTECTED]>: Added file: http://bugs.python.org/file11748/traceback_unicode-5.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.pytho

[issue3975] PyTraceBack_Print() doesn't respect # coding: xxx header

Changes by STINNER Victor <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file11747/traceback_unicode-5.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.pytho

[issue3975] PyTraceBack_Print() doesn't respect # coding: xxx header

Changes by STINNER Victor <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file11736/traceback_unicode-4.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.pytho

[issue3975] PyTraceBack_Print() doesn't respect # coding: xxx header

STINNER Victor <[EMAIL PROTECTED]> added the comment: @amaury: Oops, yes, I introduced a refleak in the version 4 with the PyUnicode_Check(). Instead of just moved Py_(X)RECREF(lineobj);, I could not not resist to refactor the code to remove one more indentation level (I pre

[issue3975] PyTraceBack_Print() doesn't respect # coding: xxx header

STINNER Victor <[EMAIL PROTECTED]> added the comment: My patch for #2384 contains a testcase which require #3975 and #2384 to be fixed (you have to apply both patches to test it). ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.pytho

[issue3574] compile() cannot decode Latin-1 source encodings

STINNER Victor <[EMAIL PROTECTED]> added the comment: Amaury applied my both patches for issues #2384 and #3975. So all tests now pass with python trunk + alt_latin_1.diff. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.pytho

[issue4097] Traceback doesn't run back all the way

STINNER Victor <[EMAIL PROTECTED]> added the comment: Can you write an example to reproduce your traceback? You don't give enough informations to see what is the type of your variable, which modules are used, etc. -- nosy: +haypo ___ Pyt

[issue3724] math.log(x, 10) gives different result than math.log10(x)

STINNER Victor <[EMAIL PROTECTED]> added the comment: About large integers which can not be converted to float (too big!): it would be nice if math.log2() and/or math.log10() works which such numbers. But it would better if you know if the functions used the FPU or not (only integers)

[issue3799] Byte/string inconsistencies between different dbm modules

STINNER Victor <[EMAIL PROTECTED]> added the comment: For information, Python3 trunk fails on: test.support.TestFailed: Traceback (most recent call last): File "Lib/test/test_dbm.py", line 157, in test_keys self.assert_('xxx' not in self.d) TypeError: gdbm

[issue4114] struct returns incorrect 4 byte float

STINNER Victor <[EMAIL PROTECTED]> added the comment: Why do you use float (32 bits) instead of double (64 bits)? Your example use: double (python) -> float (C) -> double (python) If you convert 64 bits float to 32 bits, for sure you will loose some digits. It's not a bug

[issue6352] Compiler warning in unicodeobject.c

STINNER Victor added the comment: r76197 fixed the warning (Nov 10 2009, 2 months ago). -- nosy: +haypo resolution: -> fixed status: open -> closed ___ Python tracker <http://bugs.python.org/

[issue5115] Extend subprocess.kill to be able to kill process groups

STINNER Victor added the comment: > I suspect that on Windows, TerminateJobObject won't work > with a handle returned by CreateProcess. TerminateJobObject works with CreateJobObject and AssignProcessToJobObject. The following code (from your patch) should call AssignProcessToJob

[issue7739] time.strftime may hung while trying to open /etc/localtime but does not release GIL

STINNER Victor added the comment: > It appears that the stall happens due to time.strftime call, which internally > opens > a file ('/etc/localtime') In the GNU libc, strftime() calls tzset() and tzset() uses a lock to be thread safe. Yes, releasing the GIL before calli

[issue7720] Errors in tests and C implementation of raw FileIO

STINNER Victor added the comment: IOTest.test_destructor() is already fixed in Python trunk (future 2.7) by r73394 (Issue #6215: backport the 3.1 io lib). I don't think that it would be possible to backport the 3.1 io lib in Python 2.6. Would it possible to backport only the io

[issue7708] test_xmlrpc fails with non-ascii path

STINNER Victor added the comment: SimpleXMLRPCRequestHandler.do_POST() writes the traceback in the HTTP header "X-traceback". But an HTTP header value is ASCII only, whereas a traceback can contain any character (eg. an non-ASCII character from a directory name for this issue). A

[issue7739] time.strftime may hung while trying to open /etc/localtime but does not release GIL

Changes by STINNER Victor : Removed file: http://bugs.python.org/file15954/unnamed ___ Python tracker <http://bugs.python.org/issue7739> ___ ___ Python-bugs-list mailin

[issue7739] time.strftime may hung while trying to open /etc/localtime but does not release GIL

STINNER Victor added the comment: Here you have a patch releasing the GIL for the call to strftime(). -- keywords: +patch Added file: http://bugs.python.org/file15959/time_strftime_gil.patch ___ Python tracker <http://bugs.python.org/issue7

[issue7739] time.strftime may hung while trying to open /etc/localtime but does not release GIL

STINNER Victor added the comment: time_tzset() might also release the GIL, but: - i hope that multithreaded programs don't call regulary tzset() in different threads - time_tzset() calls tzset() and inittimezone() - inittimezone() modify the time module attributes and may call

[issue7727] xmlrpc library returns string which contain null ( \x00 )

STINNER Victor added the comment: Marshaller.dump_string() encodes a byte string in ... using the escape() function. A byte string can be encoded in base64 using It's described in the XML-RPC specification, but I don't know if all XML-RPC implementations do understand this

[issue7727] xmlrpc library returns string which contain null ( \x00 )

STINNER Victor added the comment: Here is an example of patch using the following test: all(32 <= ord(byte) <= 127 for byte in value) I don't know how much slower is the patch, but at least it doesn't raise an "ExpatError: not well-formed (invalid token): ...&q

[issue7668] test_httpservers fails with non-ascii path

STINNER Victor added the comment: CGIHTTPServerTestCase creates .py files with sys.executable in a shebang: - cgi_file1 = """\ #!%s ...""" with open(self.file1_path, 'w') as file1: file1.write(cgi_file1 % sys.executable) - The shebang hav

[issue7667] test_doctest fails with non-ascii path

STINNER Victor added the comment: There are 2 different issues: * doctest.DocTestRunner.report_failure() raise an unicode error if the source line type is unicode: _failure_header() should convert the line to bytes using ASCII with backslashreplace error handler (as sys.stderr

[issue4221] inconsistent exception from int is confusing

STINNER Victor added the comment: See also issue #7710. -- nosy: +haypo ___ Python tracker <http://bugs.python.org/issue4221> ___ ___ Python-bugs-list mailin

[issue5905] strptime fails in non-UTF locale

STINNER Victor added the comment: I'm unable to reproduce the error. I tried locales fr_FR.iso88591 and fr_fr.iso885...@euro (fr...@euro), but the example works correctly. Should the terminal use the specified locale? My terminal uses fr_FR.utF8 locale. Should set_locale() be called b

[issue7544] Fatal error on thread creation in low memory condition

STINNER Victor added the comment: Sum up of my patch: * it pass all test_thread*.py tests (tested with in pydebug mode) * it preallocates the thread state in the parent thread to be able to raise an error with PyErr_NoMemory() instead of Py_FatalError() * PyThreadState_Prealloc() doesn&#

[issue7267] format method: c presentation type broken

STINNER Victor added the comment: See also issue #7649. -- nosy: +haypo ___ Python tracker <http://bugs.python.org/issue7267> ___ ___ Python-bugs-list mailin

[issue7649] "u'%c' % char" broken for chars in range '\x80'-'\xFF'

STINNER Victor added the comment: @Ezio: Your patch leaks a reference: PyUnicode_FromString(...) is not destroyed (Py_DECREF) on success. -- ___ Python tracker <http://bugs.python.org/issue7

[issue7564] test_ioctl may fail when run in background

STINNER Victor added the comment: test_ioctl() gets the process group ID of the foreground process group on /dev/tty. If Python is in foreground, it's equal to the process group ID (os.getpgrp()) or to the session ID (os.getsid(0)). If Python is in background, yes, the test

[issue7267] format method: c presentation type broken

STINNER Victor added the comment: ('%c' % 255) == chr(255) == '\xff' '%c' % 256 raise an "OverflowError: unsigned byte integer is greater than maximum" and chr(256) raise a "ValueError: chr() arg not in range(256)". I prefer the second error

[issue7801] xmlrpc.client binary object examples needs to use binary mode

STINNER Victor added the comment: Fixed in trunk by r77836 (r77837) and py3k by r77838 (r77839), thanks. -- nosy: +haypo ___ Python tracker <http://bugs.python.org/issue7

[issue7801] xmlrpc.client binary object examples needs to use binary mode

Changes by STINNER Victor : -- resolution: -> fixed status: open -> closed ___ Python tracker <http://bugs.python.org/issue7801> ___ ___ Python-bugs-list

[issue7801] xmlrpc.client binary object examples needs to use binary mode

STINNER Victor added the comment: Note: The python3 example closed the file after the return instruction :-( I fixed that by using the with syntax, as does Python trunk example. -- ___ Python tracker <http://bugs.python.org/issue7

[issue7173] Cython compiler run crashes CPython 3.1.1 and 3.2

STINNER Victor added the comment: I'm unable to reproduce the crash. Can someone write a shorter code reproducing the issue? I downloaded Cython tip and applied the patch attached to this issue. I tried py3k, py3k compiled in pydebug mode, python 3.1 branch: none crashed. Should I

[issue3194] Demo/loop.c passing "char *" instead of "wchar_t *"

STINNER Victor added the comment: loop demo is still broken in py3k: * try to link to libpython3.0 (wrong python version) * there is still the argv[0] type issue -- nosy: +haypo ___ Python tracker <http://bugs.python.org/issue3

[issue4340] xmlrpc.client - default 'SlowParser' not defined

STINNER Victor added the comment: I'm unable to reproduce the bug on py3k nor python3.1. Reopen the issue if the bug reappears. -- nosy: +haypo resolution: -> invalid status: open -> closed ___ Python tracker <http://bugs.python

[issue6409] 2to3 generates malformed diffs

STINNER Victor added the comment: I'm able to reproduce the bug. The problem is that "-j 4" option creates 4 working processes, and they are all writing to stdout at the same time. Main process: main() => refactor() => refactor_file() sends tasks to child proce

[issue7165] xmlrpc.server assumes sys.stdout will have a buffer attribute

STINNER Victor added the comment: antoine's patch (fixing this issue) is commited. Can we close this issue? -- nosy: +haypo ___ Python tracker <http://bugs.python.org/i

[issue7708] test_xmlrpc fails with non-ascii path

STINNER Victor added the comment: This issue is a duplicate of #7606. -- ___ Python tracker <http://bugs.python.org/issue7708> ___ ___ Python-bugs-list mailin

[issue7606] test_xmlrpc fails with non-ascii path

STINNER Victor added the comment: #7608 was a duplicate issue. Copy of my message (msg98091): - SimpleXMLRPCRequestHandler.do_POST() writes the traceback in the HTTP header "X-traceback". But an HTTP header value is ASCII only, whereas a traceback can contain any character (

[issue7708] test_xmlrpc fails with non-ascii path

Changes by STINNER Victor : -- resolution: -> duplicate status: open -> closed ___ Python tracker <http://bugs.python.org/issue7708> ___ ___ Python-bugs-

[issue7606] test_xmlrpc fails with non-ascii path

STINNER Victor added the comment: pitrou> If it's only about transmitting the string representation of the pitrou> traceback, perhaps we can simply use "replace" or "ignore" as the error pitrou> handler? Both replace and ignore loose information. My pat

[issue7818] Improve set().test_c_api(): don't expect a set("abc"), modify the content

New submission from STINNER Victor : test_c_api() method of a set() (only defined in pydebug mode) suppose that the set content is "abc". It causes assertion error if the method is called in a set different than set("abc"). My patch modifies the set content at the b

[issue7818] Improve set().test_c_api(): don't expect a set("abc"), modify the content

Changes by STINNER Victor : -- components: +Interpreter Core type: -> crash versions: +Python 2.7, Python 3.2 ___ Python tracker <http://bugs.python.org/iss

[issue7819] sys.call_tracing(): check arguments type

New submission from STINNER Victor : Ensure that "args" argument is a tuple. Fix the following crash: $ python -c "import sys; sys.call_tracing(open, u'a')" SystemError: ../Python/getargs.c:1413: bad argument to internal function -- comp

[issue7820] parser: restores all bytes in the right order if check_bom() fails

New submission from STINNER Victor : My patch fixes check_bom() to restore all bytes in the right order if there is no BOM to leave the stream unchanged and to fix an assertion error in buf_ungetc() (raised in pydebug mode). The current code only unget one byte (0xFF), even if two or three

[issue7820] parser: restores all bytes in the right order if check_bom() fails

Changes by STINNER Victor : Added file: http://bugs.python.org/file16068/parser_restore_bom-2.patch ___ Python tracker <http://bugs.python.org/issue7820> ___ ___ Pytho

[issue7820] parser: restores all bytes in the right order if check_bom() fails

Changes by STINNER Victor : Removed file: http://bugs.python.org/file16067/parser_restore_bom.patch ___ Python tracker <http://bugs.python.org/issue7820> ___ ___ Pytho

[issue7820] parser: restores all bytes in the right order if check_bom() fails

STINNER Victor added the comment: > Are there test cases for this? Here you have. -- ___ Python tracker <http://bugs.python.org/issue7820> ___ ___ Python-

[issue7819] sys.call_tracing(): check arguments type

STINNER Victor added the comment: Before someone is asking, i wrote a new version of my patch using an unit test. The patch also test sys.call_tracing() with valid arguments. -- Added file: http://bugs.python.org/file16069/sys_call_tracing-2.patch

[issue7818] Improve set().test_c_api(): don't expect a set("abc"), modify the content

STINNER Victor added the comment: > The method was supposed to be for internal use only I found this bug by fuzzing. > it may be worthwhile to build-out the test to accept many different possible > inputs (...) Yeah, but I just want to avoid an assert

[issue7820] parser: restores all bytes in the right order if check_bom() fails

STINNER Victor added the comment: > I think the test should be in test_pep263. Right! I always hesitate when adding a new test. -- Added file: http://bugs.python.org/file16072/parser_restore_bom-3.patch ___ Python tracker <http://bugs.pyth

[issue7820] parser: restores all bytes in the right order if check_bom() fails

Changes by STINNER Victor : Removed file: http://bugs.python.org/file16068/parser_restore_bom-2.patch ___ Python tracker <http://bugs.python.org/issue7820> ___ ___ Pytho

[issue7819] sys.call_tracing(): check arguments type

STINNER Victor added the comment: > This very fix was already done in py3k with issue3661. Oh! My patch is *very* close to this one. I just choosed 10 instead of 2 in the unit test :-) (and I added a test to check a valid argument, py3k doesn't check it). > Patch is OK, please a

[issue7819] sys.call_tracing(): check arguments type

Changes by STINNER Victor : -- resolution: -> fixed stage: commit review -> committed/rejected ___ Python tracker <http://bugs.python.org/issue7819> ___ ___

[issue7825] test_threadsignals leaks references

New submission from STINNER Victor : test_threadsignals leaks references. I'm unable to understand where. Maybe somewhere around Py_AddPendingCall()? - $ ./python Lib/test/regrtest.py -R 3:2: test_threadsignals test_threadsignals beginning 5 repetitions 12345 . test_threadsi

[issue7544] Fatal error on thread creation in low memory condition

STINNER Victor added the comment: > PyThreadState_Prealloc and PyThreadState_Init should (...) be prefixed with > an underscore (...) done > _PyThreadState_New should be static (...) so something like "new_threadstate" done > the last change ("Py_Initialize

[issue7544] Fatal error on thread creation in low memory condition

Changes by STINNER Victor : Removed file: http://bugs.python.org/file15888/thread_prealloc_pystate-3.patch ___ Python tracker <http://bugs.python.org/issue7544> ___ ___

[issue7478] _sqlite3 doesn't catch PyDict_SetItem error

STINNER Victor added the comment: ghaering> I will soon push updates to the version in Python core. What do you mean by "soon"? -- ___ Python tracker <http://bugs.pyth

[issue3058] Let SimpleXMLRPCServer pass client_address to called functions.

STINNER Victor added the comment: client_address is not interresting, but I prefer the handler object (SimpleXMLRPCRequestHandler instance). The handler contains more information: * handler.address_string() gives the FQDN * handler.connection.getpeername() gives the client address

[issue3058] Let SimpleXMLRPCServer pass client_address to called functions.

STINNER Victor added the comment: Oops, I mean "client_address is interresting, but ..." -- ___ Python tracker <http://bugs.python.org/issue3058> ___ ___

[issue3058] Let SimpleXMLRPCServer pass client_address to called functions.

STINNER Victor added the comment: Oops oops oops, samwyse wrote exactly the same idea than me in the first comment! -- ___ Python tracker <http://bugs.python.org/issue3

[issue7649] "u'%c' % char" broken for chars in range '\x80'-'\xFF'

STINNER Victor added the comment: Commited: r78392 (r78394). -- resolution: -> fixed status: open -> closed ___ Python tracker <http://bugs.python.org/

[issue7449] A number tests "crash" if python is compiled --without-threads

STINNER Victor added the comment: Comments about nothreads.patch. There are unrelated changes: Lib/test/test_xmlrpc.py: -p = xmlrpclib.ServerProxy(URL, transport=t) +p = xmlrpclib.ServerProxy('http:', transport=t) Lib/test/test_macostools.py (working copy) -

[issue8034] logging: Improve error handing in RotatingFileHandler.doRollover()

New submission from STINNER Victor : My server is running as root and is writing logs into /var/log/nucentral.log. I tried to run it under a different user ("nucentral"), and I changed /var/log/nucentral.log file permissions. I'm using: MAX_LOG_FILESIZE = 5 * 1024 * 1024

[issue8034] logging: Improve error handing in RotatingFileHandler.doRollover()

STINNER Victor added the comment: I forgot something: to avoid trying to file rotation at each log message, the rotation should be disabled at the first error. For RotatingFileHandler, it can be something like: try: ... except: self.maxBytes=0 raise For TimedRotatingFileHandler, a

[issue2973] _ssl compiler warnings

STINNER Victor added the comment: I commited grooverdan's patch: r78596 (trunk), r78597 (2.6), r78598 (py3k), 78599 (3.1). The API was changed in... 2004, 6 years ago! I hope that everybody upgraded to the new OpenSSL version since that. Anyway, the warning should be fixed, and P

[issue2973] _ssl compiler warnings

Changes by STINNER Victor : -- resolution: -> fixed status: open -> closed ___ Python tracker <http://bugs.python.org/issue2973> ___ ___ Python-bugs-list

[issue7820] parser: restores all bytes in the right order if check_bom() fails

STINNER Victor added the comment: Commited: r78603 (trunk), r78608 (py3k), r78609 (3.1). Delay the fix in 2.6 after the release of 2.6.5. This issue is far from being critical, I don't want to introduce a regression after an RC :-) -- ___ P

[issue3299] Direct calls to PyObject_Del/PyObject_DEL are broken for --with-pydebug

STINNER Victor added the comment: thread fix commited: r78610 (trunk), r78611 (py3k), r78612 (3.1). Delay the backport to 2.6 after the 2.6.5 release. -- ___ Python tracker <http://bugs.python.org/issue3

[issue7449] A number tests "crash" if python is compiled --without-threads

STINNER Victor added the comment: > In the test_xmlrpc.py case I changed the value from URL to 'http:' because > the code that sets URL to a valid url relies on threading. When threading > is disabled, URL is set to None and the test will fail. I would prefer somethin

[issue2973] _ssl compiler warnings

STINNER Victor added the comment: barry> Because we're in release candidate mode, barry> I reverted the change to the release26-maint branch. Yeah, sorry. I realized that after backporting the fix to 2.6. barry> Please do re-apply after 2.6.5 final is released though! Ok.

[issue4036] Support bytes for subprocess.Popen()

STINNER Victor added the comment: os.exec*() now accept bytes thanks to the PEP 383: see issue #4035. I updated my patch: it now includes tests \o/ It works on Linux. Can someone test it on Windows and/or Mac OS X? -- resolution: -> fixed status: open -> closed Added file

[issue7494] _lsprof (cProfile): Profiler.clear() keeps references to detroyed nodes

STINNER Victor added the comment: Sorry, but I'm unable to write a reliable unit test. You have to trust me: the patch fixes the issue and the issue does exist :-) Fixed by r78641 (trunk), r78642 (py3k), r78643 (3.1). Leave this issue open until the fix can be backported to 2.6 (after

[issue4036] Support bytes for subprocess.Popen()

STINNER Victor added the comment: Oops, I realized that the second test is just useless. The argument is str, not bytes. I wanted to test Popen(bytes, shell=True). What is the right encoding to convert a string to bytes for the file system

[issue1054943] Python may contain NFC/NFKC bug per Unicode PRI #29

STINNER Victor added the comment: Commited: r78646 (trunk), r78647 (py3k), r78648 (3.1). Leave the issue open to remember me that I have to backport to 2.6 (after the 2.6.5 release). -- ___ Python tracker <http://bugs.python.org/issue1054

[issue8063] Call _PyGILState_Init() earlier in Py_InitializeEx()

New submission from STINNER Victor : _PyGILState_Init() initialize autoInterpreterState variable. This variable have to be set before the first call to PyGILState_Ensure(). The problem is that _PyGILState_Init() is called late: at the end of Py_InitializeEx(). It's called after ini

[issue8063] Call _PyGILState_Init() earlier in Py_InitializeEx()

STINNER Victor added the comment: haypo> I already hitted this bug some weeks ago when I was working haypo> on the thread state preallocation when creating a new thread: haypo> #7544. According to msg97715: it was indirectly the same issue, call _PyObject_Dump() while the G

<    35   36   37   38   39   40   41   42   43   44   >