[ python-Bugs-1470540 ] XMLGenerator creates a mess with UTF-16
Bugs item #1470540, was opened at 2006-04-15 00:07 Message generated for change (Comment added) made by ngrig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470540&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: XML Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Nikolai Grigoriev (ngrig) Assigned to: Nobody/Anonymous (nobody) Summary: XMLGenerator creates a mess with UTF-16 Initial Comment: When output encoding in xml.sax.saxutils.XMLGenerator is set to UTF-16, the result is a terrible mess. Namely: - it does not encode the XML declaration at the very top of the file (leaving it in single-byte Latin); - it leaves closing '>' of each start tag unencoded (that is, always outputs a single byte); - it inserts a spurious byte order mark for each tag, each attribute, each text node, and each processing instruction. A test illustrating the issue is attached. The issue is applicable to both stable (2.4.3) and current (2.5) versions of Python. - Looking in xml/sax/saxutils.py, I see the problem in XMLGenerator._write(): - one-byte strings aren't recoded at all (sic!); - two-byte strings are converted using unicode.encode(); this results in a BOM for each call of _write() on Unicode strings. The issue is easy to fix by using StreamWriter instead of a plain stream as the output sink. I am going to submit a patch shortly. Regards, Nikolai Grigoriev -- >Comment By: Nikolai Grigoriev (ngrig) Date: 2006-04-16 11:42 Message: Logged In: YES user_id=195108 FYI: I posted a patch (#1470548) that fixes the issue. Regards, Nikolai Grigoriev -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470540&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1471243 ] Visual Studio 2005 CRT error handler
Bugs item #1471243, was opened at 2006-04-16 16:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471243&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: ShireII (shireii) Assigned to: Nobody/Anonymous (nobody) Summary: Visual Studio 2005 CRT error handler Initial Comment: Visual Studio 2005 CRT has new default behavior for invalid parameters. When invalid parameter is passed, function calls CrtDbgReport, and after - handler for invalid parameter. Default handler crushes application. Solution - set handler on initialization and restore on uninitization. Sample source code - on attachment. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471243&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1465834 ] bdist_wininst preinstall script support is broken in 2.5a1
Bugs item #1465834, was opened at 2006-04-06 17:40 Message generated for change (Comment added) made by pmoore You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465834&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: Paul Moore (pmoore) Assigned to: Thomas Heller (theller) Summary: bdist_wininst preinstall script support is broken in 2.5a1 Initial Comment: The attached zip file contains a trivial module. Run "run_setup.bat" to create a bdist_wininst installer (you'll need to edit it to make the preinstall script path match where you unzipped the file). The resulting installer fails with an error "Running the pre-installation script failed". -- >Comment By: Paul Moore (pmoore) Date: 2006-04-16 15:18 Message: Logged In: YES user_id=113328 Thomas, As I've just got my own build environment set up with the free MS compiler, I thought I'd show off and build my own copy :-) I can confirm that with the patch, the pywin32 installer also works (the one real-life case of a preinstall script that I know). Also, this patch fixes another funny issue I'd not quite managed to isolate - installers were failing to compile .py files (and conversely, the uninstaller was leaving .pyc files behind). Paul. -- Comment By: Thomas Heller (theller) Date: 2006-04-12 21:12 Message: Logged In: YES user_id=11105 Attached a patch which should fix this issue. Paul, if you want do further tests *now* I can upload a python25.dll, compiled from current SVN + patch, somewhere. Hopefully this will be compatible with a 2.5a1 installation. -- Comment By: Thomas Heller (theller) Date: 2006-04-11 18:19 Message: Logged In: YES user_id=11105 These apis are now macros, they were exported functions in Python 2.4: PyParser_SimpleParseFile PyParser_SimpleParseString PyRun_AnyFile PyRun_AnyFileEx PyRun_AnyFileFlags PyRun_File PyRun_FileEx PyRun_FileFlags PyRun_InteractiveLoop PyRun_InteractiveOne PyRun_SimpleFile PyRun_SimpleFileEx PyRun_SimpleString PyRun_String Py_CompileString All of them, to be safe, should probably exposed as exported functions again. See also this thread on python-dev: http://mail.python.org/pipermail/python-dev/2006-January/059374.html Raising the priority to 7 because this must be fixed before release. -- Comment By: Paul Moore (pmoore) Date: 2006-04-06 21:01 Message: Logged In: YES user_id=113328 Seems to be limited to installers with preinstall scripts, as far as I can tell. The main example is pywin32, which is irritatingly significant :-) (One oddness I couldn't check is that scripts don't seem to get compiled any more - don't know if this is related to the same issue. It's not a big deal either way, though). The fix sounds reasonable. -- Comment By: Thomas Heller (theller) Date: 2006-04-06 19:22 Message: Logged In: YES user_id=11105 bdist_wininst7.1.exe uses runtime dynamic linking to the python dll. Python25.dll doesn't export a PyRun_SimpleString function anymore, it has been replaced by a macro: #define PyRun_SimpleString(s) PyRun_SimpleStringFlags(s, NULL) bdist_wininst *could* be changed to use PyRun_SimpleStringFlags instead, however, installers built with previous versions of Python will then refuse to install pure distributions to Python 2.5. I have not checked if installers that do *not* have a pre-install script will work or not. I suggest to make PyRun_SimpleString an exported function again - this should be cheap. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465834&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1470502 ] Mention coercion removal in Misc/NEWS
Bugs item #1470502, was opened at 2006-04-14 12:24 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470502&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 3000 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Guido van Rossum (gvanrossum) Summary: Mention coercion removal in Misc/NEWS Initial Comment: Neal has been ripping out __coerce__ but Misc/NEWS doesn't mention that. Should be mentioned (along with test_coercion being removed). -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-16 12:20 Message: Logged In: YES user_id=33168 This was done AFAIK. There will be more coercion removals coming as soon as I have time. I'll update NEWS when I do. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470502&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1471407 ] setup.py --help-commands exception
Bugs item #1471407, was opened at 2006-04-16 12:23
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471407&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: James William Pye (jwpye)
Assigned to: Nobody/Anonymous (nobody)
Summary: setup.py --help-commands exception
Initial Comment:
>From a recent trunk build(2.5a1) on FreeBSD 6.1:
[EMAIL PROTECTED]:/src/org/pgfoundry/python/fe/local %
/usr/dev/bin/python ./setup.py --help-commands
Standard commands:
buildbuild everything needed to install
build_py "build" pure Python modules (copy to
build directory)
build_extbuild C/C++ extensions (compile/link
to build directory)
build_clib build C/C++ libraries used by Python
extensions
build_scripts"build" scripts (copy and fixup #! line)
cleanclean up temporary files from
'build' command
install install everything from build directory
install_lib install all Python modules
(extensions and pure Python)
install_headers install C/C++ header files
install_scripts install scripts (Python or otherwise)
install_data install data files
sdistcreate a source distribution
(tarball, zip file, etc.)
Traceback (most recent call last):
File "./setup.py", line 52, in
setup(defaults)
File "./setup.py", line 46, in setup
d = distutils.core.setup(**kw)
File "/usr/dev/lib/python2.5/distutils/core.py", line
137, in setup
ok = dist.parse_command_line()
File "/usr/dev/lib/python2.5/distutils/dist.py", line
455, in parse_command_line
if self.handle_display_options(option_order):
File "/usr/dev/lib/python2.5/distutils/dist.py", line
680, in handle_display_options
self.print_commands()
File "/usr/dev/lib/python2.5/distutils/dist.py", line
758, in print_commands
max_length)
File "/usr/dev/lib/python2.5/distutils/dist.py", line
720, in print_command_list
klass = self.get_command_class(cmd)
File "/usr/dev/lib/python2.5/distutils/dist.py", line
851, in get_command_class
raise DistutilsModuleError("invalid command '%s'" %
command)
distutils.errors.DistutilsModuleError: invalid command
'register'
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471407&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1470353 ] test_ctypes fails on FreeBSD 4.x
Bugs item #1470353, was opened at 2006-04-14 15:11
Message generated for change (Comment added) made by theller
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470353&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Andrew I MacIntyre (aimacintyre)
Assigned to: Thomas Heller (theller)
Summary: test_ctypes fails on FreeBSD 4.x
Initial Comment:
$ ./python Lib/test/regrtest.py test_ctypes
test_ctypes
test test_ctypes failed -- Traceback (most recent call
last):
File
"/home/andymac/dev/python-svn-head/Lib/ctypes/test/test_functions.py",
line 333, in test_struct_return_2H
self.failUnlessEqual((s2h.x, s2h.y), (99*2, 88*3))
AssertionError: (-1004, 2123) != (198, 264)
1 test failed:
test_ctypes
[41158 refs]
This is with a subversion checkout updated to 5am AEST
(Aust) 14Apr06, debug build.
The returned tuple values (s2h.x, s2h.y) appear to vary
from run to run, so it looks like something isn't where
its expected.
This is with a FreeBSD 4.8 i386 system (not
particularly recent), using gcc 2.95.4. A quick and
dirty test (in C) suggests that its not an alignment
issue for the 2 shorts in the S2H struct.
Ideas for trying to debug this further?
--
>Comment By: Thomas Heller (theller)
Date: 2006-04-16 22:19
Message:
Logged In: YES
user_id=11105
I can confirm that both current Python SVN as well as ctypes
CVS pass the testsuite under FreeBSD 6.0.
--
Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2006-04-16 05:03
Message:
Logged In: YES
user_id=250749
In that case, it would be worth confirming whether later
versions of FreeBSD (at least 5.4, better 6.0) are also
affected. I don't know whether there's anyone from
DragonflyBSD active - its a FreeBSD 4.x offshoot.
--
Comment By: Thomas Heller (theller)
Date: 2006-04-15 22:26
Message:
Logged In: YES
user_id=11105
Committed as 45440.
For NetBSD, this change seems not to be required - ctypes
works fine as it is (I'm testing this on the SF compilefarm
host, which has NetBSD 2.0.2).
--
Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2006-04-15 13:18
Message:
Logged In: YES
user_id=250749
Your suggested change does indeed get the test to pass on
this system. Given the history and relationship of
[Free/Net/Open]BSD, I would suggest that for x86 it is very
likely that you will need to add defined(__NetBSD__) clauses
as well.
>From my POV this bug can now be closed.
Thanks, Thomas.
BTW, the actual patch applied was:
--- ffi.c.orig Tue Apr 4 05:26:32 2006
+++ ffi.c Sat Apr 15 21:02:16 2006
@@ -121,7 +121,7 @@
switch (cif->rtype->type)
{
case FFI_TYPE_VOID:
-#if !defined(X86_WIN32) && !defined(__OpenBSD__)
+#if !defined(X86_WIN32) && !defined(__OpenBSD__) &&
!defined(__FreeBSD__)
case FFI_TYPE_STRUCT:
#endif
case FFI_TYPE_SINT64:
@@ -135,7 +135,7 @@
cif->flags = FFI_TYPE_SINT64;
break;
-#if defined(X86_WIN32) || defined(__OpenBSD__)
+#if defined(X86_WIN32) || defined(__OpenBSD__) ||
defined(__FreeBSD__)
case FFI_TYPE_STRUCT:
if (cif->rtype->size == 1)
{
--
Comment By: Thomas Heller (theller)
Date: 2006-04-14 21:09
Message:
Logged In: YES
user_id=11105
Of course I meant FreeBSD instead of NetBSD, sorry.
--
Comment By: Thomas Heller (theller)
Date: 2006-04-14 21:08
Message:
Logged In: YES
user_id=11105
This looks very similar to a problem I recently 'fixed' on
OpenBSD - maybe it is even a bug in libffi. On OpenBSD x86
the problem seemed to be that small structures are passed
like short or int. You could try to fix it by adding the
appropriate definition in
Modules/_ctypes/libffi/src/x86/ffi.c, at lines 124 and lines
138. Maybe changing them to
#if !defined(X86_WIN32) && !defined(__OpenBSD__) &&
!defined(__NetBSD__)
or whatever the magic symbol for Netbsd is.
Unfortunately I do not have access to a netbsd machine myself.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470353&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1471423 ] reload(ctypes) leaks references
Bugs item #1471423, was opened at 2006-04-16 22:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471423&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Thomas Heller (theller) Summary: reload(ctypes) leaks references Initial Comment: Found by Neal Norwitz, reload(ctypes) leaks references: >>> reload(ctypes); gc.collect(); gc.collect(); gc.collect() 128 13 0 [34251 refs] >>> reload(ctypes); gc.collect(); gc.collect(); gc.collect() 128 13 0 [34786 refs] >>> reload(ctypes); gc.collect(); gc.collect(); gc.collect() 128 13 0 [35321 refs] >>> -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471423&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1471427 ] tarfile.py chokes on long names
Bugs item #1471427, was opened at 2006-04-16 22:34
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471427&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexander Schremmer (alexanderweb)
Assigned to: Nobody/Anonymous (nobody)
Summary: tarfile.py chokes on long names
Initial Comment:
The following bug is reproducible on Py 2.4.3 and 2.5.
It was tested on Windows. You need a tarfile with a
long file name that triggers the GNU LONGNAME
extension.
Extracting such a file gives me an IO error because it
tries to create a file with a slash at the end. This is
because
# Some old tar programs represent a directory
as a regular
# file with a trailing slash.
if tarinfo.isreg() and tarinfo.name.endswith("/
"):
tarinfo.type = DIRTYPE
sets the type incorrectly after it was called from the
callback proc which has no possiblity to set the name
of the intermediary tarinfo class because it is
instantiated in the next-method.
So this yields a directory which should be a file which
is obviously wrong. Might be related to commit 41340
"Patch #1338314, Bug #1336623". (At least the code
changed there is causing this bug).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471427&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1471427 ] tarfile.py chokes on long names
Bugs item #1471427, was opened at 2006-04-16 22:34
Message generated for change (Comment added) made by alexanderweb
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471427&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexander Schremmer (alexanderweb)
Assigned to: Nobody/Anonymous (nobody)
Summary: tarfile.py chokes on long names
Initial Comment:
The following bug is reproducible on Py 2.4.3 and 2.5.
It was tested on Windows. You need a tarfile with a
long file name that triggers the GNU LONGNAME
extension.
Extracting such a file gives me an IO error because it
tries to create a file with a slash at the end. This is
because
# Some old tar programs represent a directory
as a regular
# file with a trailing slash.
if tarinfo.isreg() and tarinfo.name.endswith("/
"):
tarinfo.type = DIRTYPE
sets the type incorrectly after it was called from the
callback proc which has no possiblity to set the name
of the intermediary tarinfo class because it is
instantiated in the next-method.
So this yields a directory which should be a file which
is obviously wrong. Might be related to commit 41340
"Patch #1338314, Bug #1336623". (At least the code
changed there is causing this bug).
--
>Comment By: Alexander Schremmer (alexanderweb)
Date: 2006-04-16 22:34
Message:
Logged In: YES
user_id=254738
Hmm, I just want to clarify that tarfile doesn't give the IO
error (it passes silently) but my code that expects a file
instead of a directory ;-)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471427&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
