[issue1328] feature request: force BOM option

James G. sack (jim) added the comment: Later note: kind of weird! On my LE machine, utf16 reads my BE-formatted test data (no BOM) apparently assumng some kind of surrogate format, until it finds an "illegal UTF-16 surrogate". That I fail to understand, especially since it quits upon seeing

[issue1255] Strange Python hangup

Jiri Krivanek added the comment: In the mena time, by intuition, I have resolved my troube exactly the way you recommend. Thanks to you, currently I also know what is he core of the problem. So the issue can be closed... __ Tracker <[EMAIL PROTECTED]>

[issue1328] feature request: force BOM option

James G. sack (jim) added the comment: Feature Request REVISION Upon reflection and more playing around with some test cases, I wish to revise my feature request. I think the utf8 codecs should accept input with or without the "sig". On output, only the utf_8_sig should

[issue1329] Different 3.0a1 exit behavior

Neal Norwitz added the comment: Thanks for testing 3.0. Do you have any idea why they are no longer called? I don't recall any changes related to this area. Can you try to debug further? -- nosy: +nnorwitz __ Tracker <[EMAIL PROTECTED]>

[issue1330] Fix truncate on Windows, this time for real

Christian Heimes added the comment: > While I like fixing the position restore in _fileio.c, I also liked > Amaury's flush() call in _BufferedIOMixin. Perhaps you can keep that > part (while losing the position restore)? Good point. We have to call flush() in _BufferedIOMixin as you said. I che

[issue1331] More fixes for Windows

Guido van Rossum added the comment: Tested on OSX as well. Thanks!! Committed revision 58662. -- assignee: -> gvanrossum keywords: +patch, py3k resolution: -> accepted status: open -> closed __ Tracker <[EMAIL PROTECTED]>

[issue1330] Fix truncate on Windows, this time for real

Guido van Rossum added the comment: While I like fixing the position restore in _fileio.c, I also liked Amaury's flush() call in _BufferedIOMixin. Perhaps you can keep that part (while losing the position restore)? __ Tracker <[EMAIL PROTECTED]>

[issue1322] platform.dist() has unpredictable result under Linux

Christian Heimes added the comment: [EMAIL PROTECTED]:~$ /usr/bin/lsb_release -a LSB Version: core-2.0-noarch:core-3.0-noarch:core-3.1-noarch:core-2.0-ia32:core-3.0-ia32:core-3.1-ia32:cxx-2.0-noarch:cxx-3.0-noarch:cxx-3.1-noarch:cxx-2.0-ia32:cxx-3.0-ia32:cxx-3.1-ia32:graphics-2.0-noarch:graphi

[issue1322] platform.dist() has unpredictable result under Linux

Raghuram Devarakonda added the comment: > Ony my Ubuntu box lsb_release is just a small Python script that parses > /etc/lsb-release. I suggest that your read the LSB standards about the > file and use the information to parse it instead of invoking a program. Can you please check if it supports

[issue1330] Fix truncate on Windows, this time for real

Changes by Guido van Rossum: -- assignee: -> gvanrossum keywords: +patch, py3k __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing l

[issue1322] platform.dist() has unpredictable result under Linux

Christian Heimes added the comment: Ony my Ubuntu box lsb_release is just a small Python script that parses /etc/lsb-release. I suggest that your read the LSB standards about the file and use the information to parse it instead of invoking a program. -- nosy: +tiran

[issue1332] threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi

New submission from Warren DeLano: import threading rlock = threading.RLock() rlock.acquire(0) # always returns False with python-2.5.1.amd64.msi # even though rlock.acquire() # returns True as expected. # All attempts to acquire locks without blocking are foiled! _

[issue1332] threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi

Changes by Warren DeLano: -- components: Windows nosy: delwarl severity: normal status: open title: threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi type: behavior versions: Python 2.5 __ Tracker <[EMAIL PROTECTED]>

[issue1255] Strange Python hangup

Facundo Batista added the comment: The deadlock happens because strptime has an import inside it, and recursive imports are not allowed in different threads. As a general rule and good coding style, don't run your code when the module is imported, but put it in a function like "main" in the seco

[issue1331] More fixes for Windows

New submission from Christian Heimes: The patch fixes some of the problems on Windows. It doesn't introduce addition problems on Linux. -- components: Library (Lib) files: py3k_misc_win.patch messages: 56770 nosy: gvanrossum, nnorwitz, tiran severity: normal status: open title: More fixe

[issue1330] Fix truncate on Windows, this time for real

Changes by Christian Heimes: -- nosy: +gvanrossum, nnorwitz __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe: h

[issue1330] Fix truncate on Windows, this time for real

New submission from Christian Heimes: The patch fixes for real what "Patch # 1323 by Amaury Forgeot d'Arc" claims to have fixed. I reverted his patch to io.py and implemented the fix in the Windows specific part of truncate in _fileio.c. It fixes two tests for raw io on Windows. -- compo

[issue1302] Fixes for profile/cprofile

Christian Heimes added the comment: Alexandre Vassalotti wrote: > It the address of lower[18] to be exact. (l < &lower[(sizeof lower) - > 2]) is simply tricky notation to check the bound of the array. > Personally, I used like to subtract pointer, ((lower - l + 1) < (sizeof > lower)) to get the b

[issue1302] Fixes for profile/cprofile

Alexandre Vassalotti added the comment: > Personally, I used like to subtract pointer, ((lower - l + 1) < > (sizeof lower)) to get the bound. Doh. I got it backward. It's (l - lower + 1), not (lower - l + 1). > But now, I find Guido's trick more cute (and less error-prone). At least, I got th

[issue1302] Fixes for profile/cprofile

Alexandre Vassalotti added the comment: > I still don't understand why you are using (sizeof lower) - 2 It is simply to avoid duplicating the constant (a.k.a. the Don't Repeat Yourself (DRY) rule). > and what &lower[(sizeof lower) - 2] returns. Is it the memory address > of lower[17]? It the

[issue1302] Fixes for profile/cprofile

Christian Heimes added the comment: Guido van Rossum wrote: > Guido van Rossum added the comment: > > Committed revision 58659. > > I'm sorry I confused you; I was fine with the version that has char > lower[N] but I wanted you to not repeat N-1 later in the code. See what > I checked in. :-)

[issue1302] Fixes for profile/cprofile

Guido van Rossum added the comment: Committed revision 58659. I'm sorry I confused you; I was fine with the version that has char lower[N] but I wanted you to not repeat N-1 later in the code. See what I checked in. :-) -- resolution: -> accepted status: open -> closed ___

[issue1323] py3k: file.truncate() changes the file position

Guido van Rossum added the comment: Looks fine to me. Committed revision 58658. -- nosy: +gvanrossum resolution: -> accepted status: open -> closed __ Tracker <[EMAIL PROTECTED]> __ _

[issue1318] Remove os.tmpnam() and os.tempnam()

Guido van Rossum added the comment: Committed revision 58657. Thanks! -- resolution: -> accepted status: open -> closed __ Tracker <[EMAIL PROTECTED]> __

[issue1329] Different 3.0a1 exit behavior

New submission from Jean Brouwers: Python 3.0a1 on Linux and MacOS X 10.4.10 exits differently than Python 2.4 and 2.5. With previous Python binaries the destructor** function of any pre- loaded shared library is called prior to exit. With Python 3.0a1 it is not, neither when exiting Python f

[issue1318] Remove os.tmpnam() and os.tempnam()

Changes by Christian Heimes: Added file: http://bugs.python.org/file8612/py3k_remove_os_tmp.patch __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list

[issue1318] Remove os.tmpnam() and os.tempnam()

Guido van Rossum added the comment: 2007/10/25, Christian Heimes <[EMAIL PROTECTED]>: > I can do that for you. But I still believe that os.tmpfile() works > different than tempfile.mkstemp(). The former returns a file descriptor > of a file w/o directory entry and the later a file in tempfile.tem

[issue1328] feature request: force BOM option

New submission from James G. sack (jim): The behavior of codecs utf_16_[bl]e is to omit the BOM. In a testing environment (and perhaps elsewhere), a forced BOM is useful. I'm requesting an optional argument something like force_BOM=False I guess it would require such an option in multiple func

[issue1318] Remove os.tmpnam() and os.tempnam()

Christian Heimes added the comment: Guido van Rossum wrote: > Christian can you revise your patch to also remove os.tmpfile per > Martin's request? Make sure unit tests and docs are fixed too. I can do that for you. But I still believe that os.tmpfile() works different than tempfile.mkstemp().

[issue1286] fileinput, StringIO, and cStringIO do not support the with protocol

Guido van Rossum added the comment: 2007/10/25, Yitz Gale <[EMAIL PROTECTED]>: > I was actually bitten badly by this issue with > StringIO. I added fileinput only as an afterthought. > > In an xml.sax app, I needed seek() support for a > codec-wrapped file handle, so I over-wrapped it with > Stri

[issue1322] platform.dist() has unpredictable result under Linux

Changes by Guido van Rossum: -- nosy: -gvanrossum __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe: http://mai

[issue1318] Remove os.tmpnam() and os.tempnam()

Guido van Rossum added the comment: Christian can you revise your patch to also remove os.tmpfile per Martin's request? Make sure unit tests and docs are fixed too. __ Tracker <[EMAIL PROTECTED]>

[issue1159051] Handle corrupted gzip files with unexpected EOF

Wummel added the comment: Here is a new test script that works with simple strings and no file objects. It reproduces the error by cutting off the last two bytes of the GZIP data. The resulting struct error is due to the read() methods missing a check that the requested amount of data is actuall

[issue1292] libffi needs an update to support mips64, arm and armeabi on linux

Thomas Heller added the comment: I'm unsure how to proceed with this. Replacing the copy of libffi in the ctypes sources - I'm very afraid to do that. It has it's own configure system, written by someone else. Then it has several changes from various people for Python, which would be overwritte

[issue1324] r58034 breaks building _ctypes with the upstream libffi.

Thomas Heller added the comment: Maybe I should give up the idea to define the ffi_type_... types myself. Committed as rev 58655. Thanks. -- resolution: -> accepted status: open -> closed __ Tracker <[EMAIL PROTECTED]>

[issue1252] IDLE - patch Delegator to support callables

Tal Einat added the comment: I understand your argument, but am not convinced. I'll try to explain how I see this and how I came to this view. I wished to wrap a specific method (or function) instead of wrapping the father object with a Delegator and implementing a single method. But I needed m

[issue1318] Remove os.tmpnam() and os.tempnam()

Martin v. Löwis added the comment: > os.tmpfile() is the only method that has no duplicate in tempfile. Why do you say that? tempfile.mkstemp() does essentially the same as os.tmpfile(). > The promise of tempfile.mkstemp is also bogus for every OS except > Windows. IIRC only Windows supports O_

[issue1322] platform.dist() has unpredictable result under Linux

Raghuram Devarakonda added the comment: On 10/25/07, Yann Cointepas <[EMAIL PROTECTED]> wrote: > I can easily do the patch to ignore symlinks and /etc/lsb-release but I am > not sure of the appropriate way to look for lsb_update command, is > distutils.spawn.find_executable( 'lsb_release' ) ok ?

[issue1322] platform.dist() has unpredictable result under Linux

Yann Cointepas added the comment: I can easily do the patch to ignore symlinks and /etc/lsb-release but I am not sure of the appropriate way to look for lsb_update command, is distutils.spawn.find_executable( 'lsb_release' ) ok ? If you need the patch earlier than begining of next week, you shoul

[issue1322] platform.dist() has unpredictable result under Linux

Raghuram Devarakonda added the comment: I think it is safe to ignore lsb-release. In fact, there seems to be a command "lsb_release" that gives information about distribution. On my SuSE box, this is what I get: marvin:~# lsb_release -i Distributor ID: SUSE LINUX marvin:~# lsb_release -d Descrip

[issue1700463] VC6 build patch for trunk

Hirokazu Yamamoto added the comment: I updated patch. To avoid conflict and , WIN32_LEAN_AND_MEAN is needed. Added file: http://bugs.python.org/file8608/vc6-trunk-ver2.patch _ Tracker <[EMAIL PROTECTED]>

[issue1287] os.environ.pop doesn't work

Raghuram Devarakonda added the comment: After reading the change, I think one more small change may be required. Index: Lib/os.py === --- Lib/os.py (revision 58654) +++ Lib/os.py (working copy) @@ -452,7 +452,7 @@

[issue805194] Inappropriate error received using socket timeout

Jean-Paul Calderone added the comment: The APR comment is indeed correct, so this is probably a Python bug. -- nosy: +exarkun Tracker <[EMAIL PROTECTED]> __

[issue1326] "internal" zipimport.zipimporter feature untested

Changes by Jean-Paul Calderone: -- nosy: +fijal __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.p

[issue1325] zipimport.zipimporter.archive undocumented and untested

Changes by Jean-Paul Calderone: -- nosy: +fijal __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.p

[issue1301] Bad assertion in _tkinter.c

Facundo Batista added the comment: Really do not understand that assert. It says: assert(size < size * sizeof(Tcl_UniChar)); For that to be true, considering size to be positive, the result of sizeof needs to be greater than 0. If you modify it, and also accepts it to be 0, and considering

[issue1326] "internal" zipimport.zipimporter feature untested

New submission from Jean-Paul Calderone: It's possible to construct a zipimporter with a "path" which points first to a zip file and then continues to refer to a file within that zip file. For example, /foo/bar.zip/baz where /foo/bar.zip is not a directory, but a zip file, and baz is a fil

[issue1325] zipimport.zipimporter.archive undocumented and untested

New submission from Jean-Paul Calderone: zipimporter instances have a read-only "archive" attribute, but there is no documentation referring to it, nor any test coverage for its existence. It's quite useful to know what a zipimporter is pointed at (for debugging and other introspection). It'd b

[issue1286] fileinput, StringIO, and cStringIO do not support the with protocol

Yitz Gale added the comment: I was actually bitten badly by this issue with StringIO. I added fileinput only as an afterthought. In an xml.sax app, I needed seek() support for a codec-wrapped file handle, so I over-wrapped it with StringIO. The result was that I had to refactor code all over the

[issue1302] Fixes for profile/cprofile

Christian Heimes added the comment: Why should I use (sizeof(lower)-1)? Do you mean PyMem_Malloc(strlen(encoding) + 1)? Changes since last patch: * added #include "bytes_methods.h" in unicodeobject.c * fix all is* to use the macros from bytes_methods.h * use malloc/free the lower version instead

[issue1318] Remove os.tmpnam() and os.tempnam() [patch]

Christian Heimes added the comment: os.tmpfile() is the only method that has no duplicate in tempfile. I chose to keep it for this very reason. But you made good point, too. What do you think about renaming tmpfile to _tmpfile and make it available from the tempfile module as tempfile.tmpfile()?

[issue1324] r58034 breaks building _ctypes with the upstream libffi.

Changes by Matthias Klose: -- keywords: +patch __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.py

[issue1324] r58034 breaks building _ctypes with the upstream libffi.

Matthias Klose added the comment: Index: Modules/_ctypes/cfield.c === --- Modules/_ctypes/cfield.c(revision 58651) +++ Modules/_ctypes/cfield.c(working copy) @@ -1753,6 +1753,9 @@ ffi_type ffi_type_float = { sizeof(float),

[issue1324] r58034 breaks building _ctypes with the upstream libffi.

Changes by Matthias Klose: -- type: -> compile error __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe: http://

[issue1324] r58034 breaks building _ctypes with the upstream libffi.

New submission from Matthias Klose: This breaks building _ctypes with the upstream libffi. r58034 | thomas.heller | 2007-09-07 08:32:17 +0200 (Fr, 07 Sep 2007) | 1 line Add a 'c_longdouble' type to the ctypes module. gcc -pthread -fPIC -fno-strict-aliasing -g -Wall -Wstrict-prototypes -I/usr/