[issue10811] sqlite segfault with generators
New submission from Erick Tryzelaar erick.tryzel...@gmail.com: I found that the sqlite3 function executemany module crashes when passed in a generator that it iself is executing a query. It looks like this confuses the statement cache, and causes it to get cleared inappropriately in this case. I've attached a file that exhibits the problem, which results in this stack trace: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0028 pysqlite_statement_mark_dirty (self=0x0) at /Users/Shared/erickt/Projects/py3k/Modules/_sqlite/statement.c:367 367 self-in_use = 1; (gdb) bt #0 pysqlite_statement_mark_dirty (self=0x0) at /Users/Shared/erickt/Projects/py3k/Modules/_sqlite/statement.c:367 #1 0x00010067e125 in _pysqlite_query_execute (self=0x100568880, multiple=1, args=value temporarily unavailable, due to optimizations) at /Users/Shared/erickt/Projects/py3k/Modules/_sqlite/cursor.c:625 #2 0x0001000af6a2 in PyEval_EvalFrameEx (f=0x1003579f0, throwflag=value temporarily unavailable, due to optimizations) at Python/ceval.c:3874 #3 0x0001000b000a in PyEval_EvalCodeEx (_co=0x1004977a0, globals=value temporarily unavailable, due to optimizations, locals=value temporarily unavailable, due to optimizations, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:3310 #4 0x0001000b031f in PyEval_EvalCode (co=value temporarily unavailable, due to optimizations, globals=value temporarily unavailable, due to optimizations, locals=value temporarily unavailable, due to optimizations) at Python/ceval.c:760 #5 0x0001000d71eb in run_mod [inlined] () at /Users/Shared/erickt/Projects/py3k/Python/pythonrun.c:1759 #6 0x0001000d71eb in PyRun_FileExFlags (fp=0x7fff703f6f40, filename=0x1005c9190 /Users/erickt/sqlite-crash.py, start=value temporarily unavailable, due to optimizations, globals=0x100325220, locals=0x100325220, closeit=1, flags=0x7fff5fbfef90) at Python/pythonrun.c:1716 #7 0x0001000d74b9 in PyRun_SimpleFileExFlags (fp=0x7fff703f6f40, filename=0x1005c9190 /Users/erickt/sqlite-crash.py, closeit=1, flags=0x7fff5fbfef90) at Python/pythonrun.c:1241 #8 0x0001000ebe13 in Py_Main (argc=4832928, argv=value temporarily unavailable, due to optimizations) at Modules/main.c:297 #9 0x00010abf in main (argc=2, argv=0x7fff5fbff090) at ./Modules/python.c:59 -- components: Library (Lib) files: sqlite-crash.py messages: 125148 nosy: Erick.Tryzelaar priority: normal severity: normal status: open title: sqlite segfault with generators type: crash versions: Python 3.2 Added file: http://bugs.python.org/file20238/sqlite-crash.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10811 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6651] Py3k's posixpath.relpath not compatible with ntpath.relpath
New submission from Erick Tryzelaar idade...@users.sourceforge.net: It looks like Python 3.x's relpath isn't compatible between posixpath and ntpath. In posixpath.relpath, the start keyword defaults to None, but ntpath.relpath, the start keyword defaults to curdir. Interestingly enough, 2.6 and 2.7 have a different implementation of posixpath.relpath, where it explicitly sets the start to equal curdir, just like ntpath does. -- components: Library (Lib) messages: 91327 nosy: erickt severity: normal status: open title: Py3k's posixpath.relpath not compatible with ntpath.relpath type: performance versions: Python 3.0, Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6651 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6154] Python 3.1 rc1 will not build on OS X 10.5.7
Erick Tryzelaar idade...@users.sourceforge.net added the comment: Benjamin, I just applied that patch but I still got the same error: /usr/bin/libtool -o Python.framework/Versions/3.1/Python -dynamic libpython3.1.a \ -lSystem -lSystemStubs -arch_only i386 - install_name /opt/local/Library/Frameworks/Python.framework/Versions/3.1/Python - compatibility_version 3.1 -current_version 3.1 -framework CoreFoundation;\ fi Undefined symbols: _libintl_textdomain, referenced from: _PyIntl_textdomain in libpython3.1.a(_localemodule.o) _libintl_dgettext, referenced from: _PyIntl_dgettext in libpython3.1.a(_localemodule.o) _libintl_dcgettext, referenced from: _PyIntl_dcgettext in libpython3.1.a(_localemodule.o) _libintl_bindtextdomain, referenced from: _PyIntl_bindtextdomain in libpython3.1.a(_localemodule.o) _libintl_gettext, referenced from: _PyIntl_gettext in libpython3.1.a(_localemodule.o) ld: symbol(s) not found /usr/bin/libtool: internal link edit command failed -- nosy: +erickt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6154 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5451] patch to make io.StringIO consistent with open with respect to newlines
New submission from Erick Tryzelaar idade...@users.sourceforge.net:
I noticed that io.StringIO is inconsistent with open on how newlines are
handled. The default approach open uses is universal newlines:
with open('foo', 'w') as f:
... f.write('hello hi\r\nla la\r\n')
...
17
open('foo').readlines()
['hello hi\n', 'la la\n']
io.StringIO, however, defaults to just treating \n as newlines:
io.StringIO('hello hi\r\nla la \r\n').readlines()
['hello hi\r\n', 'la la \r\n']
The attached patch changes this so that if the newline keyword isn't
specified, then StringIO will act just like open with respect to
keywords. It will then produce this:
io.StringIO('hello hi\r\nla la \r\n').readlines()
['hello hi\n', 'la la \n']
--
components: Library (Lib)
files: 0001-Make-StringIO-consistent-with-open-wrt-newlines.patch
keywords: patch
message_count: 1.0
messages: 83341
nosy: erickt
nosy_count: 1.0
severity: normal
status: open
title: patch to make io.StringIO consistent with open with respect to newlines
type: behavior
versions: Python 3.1
Added file:
http://bugs.python.org/file13276/0001-Make-StringIO-consistent-with-open-wrt-newlines.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5451
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5451] patch to make io.StringIO consistent with open with respect to newlines
Erick Tryzelaar idade...@users.sourceforge.net added the comment: Thanks Benjamin. Could the documentation for StringIO be updated then? The docs for io.StringIO [1] says that io.TextIOWrapper implements the constructor, but TextIOWrapper defaults newline to None [2], and there's nothing that states that io.StringIO changes the default to newline='\n'. [1]: http://docs.python.org/3.0/library/io.html#io.StringIO [2]: http://docs.python.org/3.0/library/io.html#io.TextIOWrapper -- message_count: 2.0 - 3.0 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5451 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5452] Documentation for io.StringIO has wrong info for arguments
New submission from Erick Tryzelaar idade...@users.sourceforge.net: (this is redirecting from http://bugs.python.org/issue5451). The documentation for io.StringIO is incorrect on the arguments. First off, it doesn't actually accept the encoding and errors arguments. Second, it's not stated that the default newline argument is \n, as opposed to it's parent class TextIOWrapper, which defaults to None. -- assignee: georg.brandl components: Documentation message_count: 1.0 messages: 83345 nosy: erickt, georg.brandl nosy_count: 2.0 severity: normal status: open title: Documentation for io.StringIO has wrong info for arguments type: behavior versions: Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5452 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5451] patch to make io.StringIO consistent with open with respect to newlines
Erick Tryzelaar idade...@users.sourceforge.net added the comment: Moving this to a documentation bug here: http://bugs.python.org/issue5452 -- message_count: 3.0 - 4.0 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5451 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5456] io.StringIO's universal newlines support is broken in 3.0.1
New submission from Erick Tryzelaar idade...@users.sourceforge.net:
Python version 3.0.1's io.StringIO has a bug when trying to use
universal newlines on the mac. It's fixed in 3.1a1 though. Here's the
exception:
io.StringIO('hello there\r\nlela\r\n', newline=None).readlines()
Traceback (most recent call last):
File stdin, line 1, in module
File
/opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3
.0/io.py, line 536, in readlines
return list(self)
File
/opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3
.0/io.py, line 523, in __next__
line = self.readline()
File
/opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3
.0/io.py, line 2110, in readline
more_line = self.read(self._CHUNK_SIZE)
File
/opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3
.0/io.py, line 2007, in read
res = self._decode_newlines(self._read(n), True)
File
/opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3
.0/io.py, line 1953, in _decode_newlines
return output
UnboundLocalError: local variable 'output' referenced before assignment
The broken code is this:
if self._readtranslate:
if crlf:
output = input.replace(\r\n, \n)
if cr:
output = input.replace(\r, \n)
else:
output = input
It appears to fix the problem if we do this:
output = input
if self._readtranslate:
if crlf:
output = output.replace(\r\n, \n)
if cr:
output = output.replace(\r, \n)
--
components: Library (Lib)
message_count: 1.0
messages: 83352
nosy: erickt
nosy_count: 1.0
severity: normal
status: open
title: io.StringIO's universal newlines support is broken in 3.0.1
type: behavior
versions: Python 3.0
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5456
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4375] inspect.getsource doesn't work with PYTHONPATH and source compiled from a different dir
Erick Tryzelaar idade...@users.sourceforge.net added the comment: I just checked, and the latest svn version of python has fixed this. Could someone close this bug for me? ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4375 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5115] Extend subprocess.kill to be able to kill process groups
New submission from Erick Tryzelaar idade...@users.sourceforge.net: It would be really handy to add a way to portably kill process groups of a process spawned with subprocess.Popen. My project starts a process, which then starts other long running processes. Because of this process tree, there's no way for me to portably kill all of those processes. Would it be possible to extend subprocess with these features? I did find someone who's already implemented this [1], and it's working well in my project. There was some discussion about adding this, but it seems no one actually committed a patch to implement it. Anyway, I've attached a patch against python3.0's svn branch that implements this. I don't have access to windows, so I'm not able to make sure that the TerminateJobObject is correct, and works. [1]: http://benjamin.smedbergs.us/blog/2006-12-11/killableprocesspy/ [2]: http://mail.python.org/pipermail/python-list/2008-April/487588.html -- components: Library (Lib) files: killpg.patch keywords: patch messages: 80850 nosy: erickt severity: normal status: open title: Extend subprocess.kill to be able to kill process groups type: feature request versions: Python 3.0 Added file: http://bugs.python.org/file12899/killpg.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5115 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4904] Typo for PickingError in pickle.py
New submission from Erick Tryzelaar idade...@users.sourceforge.net: Noticed that in the release version of python 3.0 and the latest svn that on line 835 the exception UnpickingError is raised instead of UnpicklingError. -- components: Library (Lib) messages: 79531 nosy: erickt severity: normal status: open title: Typo for PickingError in pickle.py type: behavior versions: Python 3.0 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4904 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4727] pickle/copyreg doesn't support keyword only arguments in __new__
New submission from Erick Tryzelaar idade...@users.sourceforge.net: According to both of these bugs: http://bugs.python.org/issue1398 http://bugs.python.org/issue4331 pickle can't pickle functools.partial objects. It looks the underlying reason is that objects that pickle can't handle objects with __new__ and keyword only arguments. To support this, would this require a new pickle protocol and a __getnewfullargs__ that returns a tuple and dict? -- components: Library (Lib) messages: 78222 nosy: erickt severity: normal status: open title: pickle/copyreg doesn't support keyword only arguments in __new__ type: feature request versions: Python 2.7, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4727 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4573] zsh-style subpattern matching for fnmatch/glob
New submission from Erick Tryzelaar [EMAIL PROTECTED]:
As I mentioned on python-ideas, I my project needs to extend fnmatch to
support zsh-style globbing, where you can use brackets to designate
subexpressions. Say you had a directory structure like this:
foo/
foo.ext1
foo.ext2
bar/
foo.ext1
foo.ext2
The subexpressions will let you do patterns like this:
glob.glob('foo/foo.{ext1,ext2}')
['foo/foo.ext1', 'foo/foo.ext2']
glob.glob('foo/foo.ext{1,2}')
['foo/foo.ext1', 'foo/foo.ext2']
glob.glob('{foo,bar}')
['bar', 'foo']
glob.glob('{foo,bar}/foo*')
['bar/foo.ext1', 'bar/foo.ext2', 'foo/foo.ext1', 'foo/foo.ext2']
glob.glob('{foo,bar}/foo.{ext*}')
['bar/foo.ext1', 'bar/foo.ext2', 'foo/foo.ext1', 'foo/foo.ext2']
glob.glob('{f?o,b?r}/foo.{ext*}')
['bar/foo.ext1', 'bar/foo.ext2', 'foo/foo.ext1', 'foo/foo.ext2']
Would this be interesting to anyone else? It would unfortunately break
fnmatch since it currently treats {} as ordinary characters. It'd be
easy to work around that by adding a flag or using a different function
name though. Anyway, here's the patch against the head of py3k.
--
components: Library (Lib)
files: zsh-fnmatch.diff
keywords: patch
messages: 77216
nosy: erickt
severity: normal
status: open
title: zsh-style subpattern matching for fnmatch/glob
type: feature request
versions: Python 3.0
Added file: http://bugs.python.org/file12259/zsh-fnmatch.diff
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4573
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4375] inspect.getsource doesn't work with PYTHONPATH and source compiled from a different dir
New submission from Erick Tryzelaar [EMAIL PROTECTED]:
I'm running into a similar problem as Jean-Paul in:
http://bugs.python.org/issue4223
But the patch in it doesn't work for me. My issue is also with files
compiled already with python3.0, but then being accessed from a
different location using PYTHONPATH. Here's a full example of the
problem:
mkdir dir1
mkdir dir1/foo
mkdir dir2
echo 'def f(): pass' dir1/foo/__init__.py
cd dir1
python3.0 -c import foo
cd ../dir2
python3.0 -c import inspect, sys; sys.path.append('../dir1'); import
foo; print(inspect.getsource(foo.f))
Which errors out with:
Traceback (most recent call last):
File string, line 1, in module
File
/opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3
.0/inspect.py, line 691, in getsource
lines, lnum = getsourcelines(object)
File
/opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3
.0/inspect.py, line 680, in getsourcelines
lines, lnum = findsource(object)
File
/opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3
.0/inspect.py, line 528, in findsource
raise IOError('could not get source code')
IOError: could not get source code
If I instrument inspect, it looks like what's happening is that
linecache is being passed f.__code__.co_filename. However with the
sys.path manipulation, that filename is baked into the .pyc file as
foo/__init__.py. This confuses linecache which can't find the file.
Here's one suggestion of a fix.
--- /tmp/inspect.py 2008-11-21 01:34:56.0 -0800
+++ /opt/local/lib/python3.0/inspect.py 2008-11-21 01:35:28.0 -
0800
@@ -518,6 +518,7 @@
is raised if the source code cannot be retrieved.
file = getsourcefile(object) or getfile(object)
module = getmodule(object, file)
+file = getsourcefile(module) or getfile(file)
if module:
lines = linecache.getlines(file, module.__dict__)
else:
It looks like in most situations the module has an accurate __file__
that's updated from PYTHONPATH. I'm not sure if this works in every
situation, but this, along with the other patch, work together to get
the source printing working.
--
components: Library (Lib)
messages: 76170
nosy: erickt
severity: normal
status: open
title: inspect.getsource doesn't work with PYTHONPATH and source compiled from
a different dir
type: behavior
versions: Python 3.0
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4375
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4321] unintended syntax error with decorators, parenthesis, and dots?
New submission from Erick Tryzelaar [EMAIL PROTECTED]: I believe I found an unintentional syntax error with a combination of decorators, parenthesis, and dots. Here's a demonstration: class C: def prop(self, function): return property(function) class F: @C().prop def foo(self): return 5 Which errors out with: File foo.py, line 6 @C().prop ^ SyntaxError: invalid syntax I can't imagine why this would be desired, since these equivalent forms work: class D: def foo(self): return 5 foo = C().prop(foo) class E: c = C() @c.prop def foo(self): return 5 -- components: Interpreter Core messages: 75850 nosy: erickt severity: normal status: open title: unintended syntax error with decorators, parenthesis, and dots? type: compile error versions: Python 2.5.3, Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4321 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4322] function with modified __name__ uses original name when there's an arg error
New submission from Erick Tryzelaar [EMAIL PROTECTED]: I ran into a case where I modified the __name__ attribute of a function and then didn't specify the right number of arguments, and I got a TypeError that used the original function name, as demonstrated here: def foo(): pass ... foo.__name__ = 'bar' foo(1) Traceback (most recent call last): File stdin, line 1, in module TypeError: foo() takes no arguments (1 given) I would have expected it to say TypeError: bar() I'm guessing that the interpreter isn't using the __name__ attribute in this case. -- components: Library (Lib) messages: 75853 nosy: erickt severity: normal status: open title: function with modified __name__ uses original name when there's an arg error type: behavior versions: Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4322 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4012] Minor errors in multiprocessing docs
Erick Tryzelaar [EMAIL PROTECTED] added the comment: fyi, the multiprocessing docs also refer to applyAync, but the function was renamed to apply_async. This is also in the python 3.0 docs. -- nosy: +erickt versions: +Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4012 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4170] segfault with defaultdict and pickle
New submission from Erick Tryzelaar [EMAIL PROTECTED]: It seems like there's a bug with defaultdict. This is segfaulting with the latest python 3.0 svn checkout: import collections, pickle d=collections.defaultdict(int) d[1] pickle.dumps(d) It errors out with: Assertion failed: (PyIter_Check(iter)), function PyIter_Next, file Objects/abstract.c, line 2751. zsh: abort /tmp/python/bin/python3.0 foo.py -- components: Library (Lib) messages: 75073 nosy: erickt severity: normal status: open title: segfault with defaultdict and pickle type: crash versions: Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4170 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3976] pprint._safe_repr is not general enough in one instance
New submission from Erick Tryzelaar [EMAIL PROTECTED]:
I've run into a case where pprint isn't able to print out a particular
data structure, and have distilled it down to a simple example:
import pprint
class A:
pass
pprint.pprint({A(): 1, A(): 2})
Which throws this exception:
Traceback (most recent call last):
File
/opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3
.0/pprint.py, line 272, in _safe_repr
items = sorted(items)
TypeError: unorderable types: A() A()
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File foo.py, line 6, in module
pprint.pprint({A(): 1, A(): 2})
File
/opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3
.0/pprint.py, line 55, in pprint
printer.pprint(object)
File
/opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3
.0/pprint.py, line 106, in pprint
self._format(object, self._stream, 0, 0, {}, 0)
File
/opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3
.0/pprint.py, line 129, in _format
rep = self._repr(object, context, level - 1)
File
/opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3
.0/pprint.py, line 216, in _repr
self._depth, level)
File
/opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3
.0/pprint.py, line 228, in format
return _safe_repr(object, context, maxlevels, level)
File
/opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3
.0/pprint.py, line 277, in _safe_repr
items = sorted(items, key=sortkey)
TypeError: unorderable types: A() A()
This is happening because of this block of code:
try:
items = sorted(items)
except TypeError:
def sortkey(item):
key, value = item
return str(type(key)), key, value
items = sorted(items, key=sortkey)
The exception block is trying to sort the items again, but in this
instance, it's still not orderable. Could we get _safe_repr to at least
give up on sorting at this point? Or, we could try just falling back to
sorting according to the class name, with:
try:
items = sorted(items)
except TypeError:
def sortkey(item):
key, value = item
return str(type(key)), key, value
try:
items = sorted(items, key=sortkey)
except TypeError:
def sortkey(item):
key, value = item
return str(type(key))
That would at least give some ordering to the output. Unfortunately, in
this case it's a shame that we don't have the cmp function any more,
because then we could just fall back to giving up on the ordering for
just certain unorderable keys, but still have sorted output for
orderable keys. I thought maybe we could test if the key and value have
__lt__, but it looks like all classes now have that function, even if
the user didn't implement it. In the long run though, I suppose the case
where you have mixed types in a dict there's no sensible ordering
anyway.
--
components: Library (Lib)
messages: 73858
nosy: erickt
severity: normal
status: open
title: pprint._safe_repr is not general enough in one instance
versions: Python 3.0
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3976
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3976] pprint._safe_repr is not general enough in one instance
Erick Tryzelaar [EMAIL PROTECTED] added the comment:
fyi, I found another case where pprint needs a safe sort, this is
when you have a list that contains a dictionary. Anyway, Here's a
simple patch that creates a _safe_sorted function that implements the
fallback:
--- /opt/local/lib/python3.0/pprint.py 2008-09-26 09:35:21.0 -0700
+++ /tmp/pprint.py 2008-09-26 09:35:13.0 -0700
@@ -145,7 +145,7 @@
if length:
context[objid] = 1
indent = indent + self._indent_per_level
-items = sorted(object.items())
+items = _safe_sorted(object.items())
key, ent = items[0]
rep = self._repr(key, context, level)
write(rep)
@@ -267,14 +267,7 @@
append = components.append
level += 1
saferepr = _safe_repr
-items = object.items()
-try:
-items = sorted(items)
-except TypeError:
-def sortkey(item):
-key, value = item
-return str(type(key)), key, value
-items = sorted(items, key=sortkey)
+items = _safe_sorted(object.items())
for k, v in items:
krepr, kreadable, krecur = saferepr(k, context, maxlevels, level)
vrepr, vreadable, vrecur = saferepr(v, context, maxlevels, level)
@@ -321,6 +314,20 @@
rep = repr(object)
return rep, (rep and not rep.startswith('')), False
+def _safe_sorted(items):
+try:
+return sorted(items)
+except TypeError:
+def sortkey(item):
+key, value = item
+return str(type(key)), key, value
+try:
+return sorted(items, key=sortkey)
+except TypeError:
+def sortkey(item):
+key, value = item
+return str(type(key))
+return sorted(items, key=sortkey)
def _recursion(object):
return (Recursion on %s with id=%s
One other thing to note is that I'm also aware that the yaml project
also has this problem, and they've got their own safe_sorted
function. It might be worthwhile formalizing this in a public function
in the api somewhere.
--
nosy: +idadesub
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3976
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3290] python-config --cflags includes irrelevant flags
Erick Tryzelaar [EMAIL PROTECTED] added the comment: fyi, on the mac with gcc-4.2, distutils is erroring out because of the - Wno-long-double it is getting from python-config --cflags, as it's no longer accepted as an argument. Fortunately this can be worked around by doing CC=gcc-4.0 python setup.py. -- nosy: +erickt ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3290 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3715] hashlib's docstring throws exception in pydoc
New submission from Erick Tryzelaar [EMAIL PROTECTED]: Hello, I noticed that doing pydoc3.0 hashlib was throwing this exception: Traceback (most recent call last): File /opt/local/bin/pydoc3.0, line 5, in module pydoc.cli() File /opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3 .0/pydoc.py, line 2237, in cli help.help(arg) File /opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3 .0/pydoc.py, line 1714, in help elif request: doc(request, 'Help on %s:') File /opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3 .0/pydoc.py, line 1504, in doc pager(render_doc(thing, title, forceload)) File /opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3 .0/pydoc.py, line 1319, in pager pager(text) File /opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3 .0/pydoc.py, line 1339, in lambda return lambda text: pipepager(text, 'less') File /opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3 .0/pydoc.py, line 1360, in pipepager pipe.write(text) File /opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3 .0/io.py, line 1486, in write b = encoder.encode(s) File /opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3 .0/encodings/mac_roman.py, line 19, in encode return codecs.charmap_encode(input,self.errors,encoding_table)[0] This problem is coming from this block of text: import hashlib m = hashlib.md5() m.update(bNobody inspects) m.update(b the spammish repetition) m.digest() b'\xbbd\x9c\x83\xdd\x1e\xa5\xc9\xd9\xde\xc9\xa1\x8d\xf0\xff\xe9' Specifically, the last line. It seems that pydoc is interpreting the last line as a unicode string, and then when it tries to print it out on my mac it errors out. -- components: Library (Lib) messages: 72099 nosy: erickt severity: normal status: open title: hashlib's docstring throws exception in pydoc type: crash versions: Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3715 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3717] Py_InitModule* is still referenced in docs
New submission from Erick Tryzelaar [EMAIL PROTECTED]: The docs still reference Py_InitModule*, which was removed in r64107. Also, Demo/embed/demo.c still use Py_InitModule, and thus doesn't compile. -- assignee: georg.brandl components: Documentation messages: 72111 nosy: erickt, georg.brandl severity: normal status: open title: Py_InitModule* is still referenced in docs versions: Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3717 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3717] Py_InitModule* is still referenced in docs
Erick Tryzelaar [EMAIL PROTECTED] added the comment:
On Thu, Aug 28, 2008 at 1:48 PM, Erick Tryzelaar [EMAIL PROTECTED] wrote:
New submission from Erick Tryzelaar [EMAIL PROTECTED]:
The docs still reference Py_InitModule*, which was removed in r64107.
Also, Demo/embed/demo.c still use Py_InitModule, and thus doesn't
compile.
Here's a patch to get demo.c working, though it's acting a little
strange. Printing out sys.argv results in japanese characters for some
reason.
Index: Demo/embed/demo.c
===
--- Demo/embed/demo.c (revision 66055)
+++ Demo/embed/demo.c (working copy)
@@ -2,9 +2,9 @@
#include Python.h
-void initxyzzy(void); /* Forward */
+PyObject* PyInit_xyzzy(void); /* Forward */
-main(int argc, char **argv)
+main(int argc, wchar_t **argv)
{
/* Pass argv[0] to the Python interpreter */
Py_SetProgramName(argv[0]);
@@ -13,7 +13,7 @@
Py_Initialize();
/* Add a static module */
- initxyzzy();
+ PyInit_xyzzy();
/* Define sys.argv. It is up to the application if you
want this; you can also let it undefined (since the Python
@@ -26,10 +26,10 @@
/* Execute some Python statements (in module __main__) */
PyRun_SimpleString(import sys\n);
- PyRun_SimpleString(print sys.builtin_module_names\n);
- PyRun_SimpleString(print sys.modules.keys()\n);
- PyRun_SimpleString(print sys.executable\n);
- PyRun_SimpleString(print sys.argv\n);
+ PyRun_SimpleString(print(sys.builtin_module_names)\n);
+ PyRun_SimpleString(print(sys.modules.keys())\n);
+ PyRun_SimpleString(print(sys.executable)\n);
+ PyRun_SimpleString(print(sys.argv)\n);
/* Note that you can call any public function of the Python
interpreter here, e.g. call_object(). */
@@ -57,9 +57,22 @@
{NULL, NULL} /* sentinel */
};
-void
-initxyzzy(void)
+static struct PyModuleDef xyzzymodule = {
+ {}, /* m_base */
+ xyzzy, /* m_name */
+ 0, /* m_doc */
+ 0, /* m_size */
+ xyzzy_methods, /* m_methods */
+ 0, /* m_reload */
+ 0, /* m_traverse */
+ 0, /* m_clear */
+ 0, /* m_free */
+};
+
+PyObject*
+PyInit_xyzzy(void)
{
- PyImport_AddModule(xyzzy);
- Py_InitModule(xyzzy, xyzzy_methods);
+ PyObject* res = PyModule_Create(xyzzymodule);
+ if (!res) return NULL;
+ return res;
}
With loop.c, there are issues with char*/wchar_t* and I'm not sure
what the right approach is. Finally, importexc.c is segfaulting with:
#0 0x0005b2f3 in PyDict_SetItem (op=0x0, key=0x44bed0,
value=0x17d460) at Objects/dictobject.c:712
#1 0x0005ee02 in PyDict_SetItemString (v=0x0, key=0x16e860
last_type, item=0x17d460) at Objects/dictobject.c:2090
#2 0x0012c23a in PySys_SetObject (name=0x16e860 last_type,
v=0x17d460) at Python/sysmodule.c:67
#3 0x00122c99 in PyErr_PrintEx (set_sys_last_vars=1) at Python/pythonrun.c:1254
#4 0x001228bc in PyErr_Print () at Python/pythonrun.c:1150
#5 0x001223a1 in PyRun_SimpleStringFlags (command=0x157b80 import
sys, flags=0x0) at Python/pythonrun.c:1075
#6 0x243b in main () at importexc.c:13
--
nosy: +idadesub
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3717
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3564] making partial functions comparable
New submission from Erick Tryzelaar [EMAIL PROTECTED]: functools.partial functions are not comparable, in both python 2.5 and 3.0: def foo(): pass functools.partial(foo) == functools.partial(foo) False It can be worked around by comparing the func, args, and keywords, but this means that if a partial function is stored in some structure, such as: def foo(): pass f1=functools.partial(foo) f2=functools.partial(foo) (1,'a',f1) == (1,'a',f2) False Which complicates things when I'm comparing things in a function that works with generic data structures. Would it be possible to extend partial to support comparisons? -- components: Library (Lib) messages: 71200 nosy: erickt severity: normal status: open title: making partial functions comparable type: feature request versions: Python 2.5, Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3564 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3514] pickle segfault with infinite loop in __getattr__
New submission from Erick Tryzelaar [EMAIL PROTECTED]:
I found a segfault in pickle.load when you overload __getattr__ and
create yourself a infinite loop in the latest svn checkout of python 3:
import pickle
class Foo:
def __getattr__(self, key):
self.foo
with open('foo.db', 'wb') as f:
foo = Foo()
pickle.dump(foo, f)
with open('foo.db', 'rb') as f:
pickle.load(f)
This results in this stack trace on my mac:
Reason: KERN_PROTECTION_FAILURE at address: 0x000c
0xdc6b in PyObject_Call (func=0x0, arg=0x44cd58, kw=0x0) at
Objects/abstract.c:2174
2174if ((call = func-ob_type-tp_call) != NULL) {
(gdb) bt
#0 0xdc6b in PyObject_Call (func=0x0, arg=0x44cd58, kw=0x0) at
Objects/abstract.c:2174
#1 0x004c1b4d in unpickler_call (self=0x4a6240, func=0x0, arg=0x4b66c8)
at /Users/Shared/erickt/Projects/py3k.svn/Modules/_pickle.c:413
#2 0x004cac9a in load_build (self=0x4a6240) at
/Users/Shared/erickt/Projects/py3k.svn/Modules/_pickle.c:3844
#3 0x004cbb4f in load (self=0x4a6240) at
/Users/Shared/erickt/Projects/py3k.svn/Modules/_pickle.c:4047
#4 0x004cbe71 in Unpickler_load (self=0x4a6240) at
/Users/Shared/erickt/Projects/py3k.svn/Modules/_pickle.c:4119
#5 0x000f2fef in call_function (pp_stack=0xbfffea84, oparg=0) at
Python/ceval.c:3387
#6 0x000edfdb in PyEval_EvalFrameEx (f=0x326cd8, throwflag=0) at
Python/ceval.c:2205
#7 0x000f157e in PyEval_EvalCodeEx (co=0x4a9628, globals=0x487f50,
locals=0x0, args=0x32593c, argcount=1, kws=0x325940, kwcount=0,
defs=0x0, defcount=0, kwdefs=0x4b6428, closure=0x0) at
Python/ceval.c:2840
#8 0x000f39e5 in fast_function (func=0x4b4ab8, pp_stack=0xbfffee54,
n=1, na=1, nk=0) at Python/ceval.c:3501
#9 0x000f35cf in call_function (pp_stack=0xbfffee54, oparg=1) at
Python/ceval.c:3424
#10 0x000edfdb in PyEval_EvalFrameEx (f=0x3257f8, throwflag=0) at
Python/ceval.c:2205
#11 0x000f157e in PyEval_EvalCodeEx (co=0x444c28, globals=0x255818,
locals=0x255818, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0,
defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:2840
#12 0x000e564f in PyEval_EvalCode (co=0x444c28, globals=0x255818,
locals=0x255818) at Python/ceval.c:519
#13 0x00122a96 in run_mod (mod=0x872c80, filename=0xb228 foo.py,
globals=0x255818, locals=0x255818, flags=0xb628, arena=0x322020) at
Python/pythonrun.c:1553
#14 0x00122884 in PyRun_FileExFlags (fp=0xa00dcde0, filename=0xb228
foo.py, start=257, globals=0x255818, locals=0x255818, closeit=1,
flags=0xb628) at Python/pythonrun.c:1510
#15 0x00120e39 in PyRun_SimpleFileExFlags (fp=0xa00dcde0,
filename=0xb228 foo.py, closeit=1, flags=0xb628) at
Python/pythonrun.c:1048
#16 0x001202f9 in PyRun_AnyFileExFlags (fp=0xa00dcde0,
filename=0xb228 foo.py, closeit=1, flags=0xb628) at
Python/pythonrun.c:845
#17 0x00134d1c in Py_Main (argc=2, argv=0x227028) at Modules/main.c:592
#18 0x2574 in main (argc=2, argv=0xb748) at python.c:57
It seems that this isn't just for infinite loops. If you replace the
class with this:
class Foo:
def __init__(self):
self.foo = {}
def __getattr__(self, key):
self.foo[5]
It still errors out. So I'm guessing pickle is just not handling
exceptions properly.
--
components: Library (Lib)
messages: 70815
nosy: erickt
severity: normal
status: open
title: pickle segfault with infinite loop in __getattr__
versions: Python 3.0
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3514
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3514] pickle segfault with infinite loop in __getattr__
Erick Tryzelaar [EMAIL PROTECTED] added the comment:
Guido van Rossum [EMAIL PROTECTED] added the comment:
Does this occur in 2.6 or 2.5?
It doesn't in python 2.5. The RuntimeError manages to get printed out.
I don't have 2.6 installed to test against at the moment. Here's the
equivalent code:
import pickle
class Foo:
def __getattr__(self, key):
self.foo
f = open('foo.db', 'w')
foo = Foo()
pickle.dump(foo, f)
f.close()
f = open('foo.db', 'r')
pickle.load(f)
f.close()
This also happens with cPickle.
--
nosy: +idadesub
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3514
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3413] typo in Mac/Makefile.in breaks installing IDLE
New submission from Erick Tryzelaar [EMAIL PROTECTED]: There's a slight typo in Mac/Makefile.in, where DESDIR was used instead of DESTDIR. This patch fixes it: --- /tmp/Makefile.in2008-07-18 19:42:29.0 -0700 +++ Mac/Makefile.in 2008-07-18 19:42:33.0 -0700 @@ -216,7 +216,7 @@ test -d $(DESTDIR)$(PYTHONAPPSDIR) || mkdir -p $(DESTDIR)$(PYTHONAPPSDIR) -test -d $(DESTDIR)$(PYTHONAPPSDIR)/IDLE.app rm -r $(DESTDIR)$(PYTHONAPPSDIR)/IDLE.app cp -PR IDLE/IDLE.app $(DESTDIR)$(PYTHONAPPSDIR) - ln -sf $(INSTALLED_PYTHONAPP) $(DESDIR)$(PYTHONAPPSDIR)/IDLE.app/Contents/MacOS/Python + ln -sf $(INSTALLED_PYTHONAPP) $(DESTDIR)$(PYTHONAPPSDIR)/IDLE.app/Contents/MacOS/Python touch $(DESTDIR)$(PYTHONAPPSDIR)/IDLE.app $(INSTALLED_PYTHONAPP): install_Python -- components: Build messages: 70001 nosy: erickt severity: normal status: open title: typo in Mac/Makefile.in breaks installing IDLE versions: Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3413 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3414] frameworkinstall doesn't create Python.app, which breaks python
New submission from Erick Tryzelaar [EMAIL PROTECTED]: Hello again! It looks like doing make frameworkinstall maninstall isn't creating Python.framework/Versions/3.0/Resources/Python.app, so when I try to run python it errors out with: python3.0: execv: /opt/local/Library/Frameworks/Python.framework/Versions/3.0/Resources/Py thon.app/Contents/MacOS/Python: No such file or directory. In order to get that file created, I need to manually run cd Mac make install_Python. This patch fixes it, but I'm not sure if this is the proper fix: --- Mac/Makefile.in.old 2008-07-18 20:59:44.0 -0700 +++ Mac/Makefile.in 2008-07-18 20:57:44.0 -0700 @@ -46,7 +46,7 @@ compileall=$(srcdir)/../Lib/compileall.py installapps: install_PythonLauncher install_IDLE checkapplepython install_pythonw \ - install_versionedtools + install_versionedtools install_Python installapps4way: install_Python4way install_BuildApplet install_PythonLauncher install_IDLE install_pythonw4way install_versionedtools -- components: Build messages: 70004 nosy: erickt severity: normal status: open title: frameworkinstall doesn't create Python.app, which breaks python type: behavior versions: Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3414 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3267] yield in list comprehensions possibly broken in 3.0
New submission from Erick Tryzelaar [EMAIL PROTECTED]: This may be a known consequence of python 3.0, but I couldn't find any reference to it, nor a test case that covers it. Here's a valid use of yield in 2.5.1: def foo(): ... x=[(yield x) for x in 1,2,3] ... yield 5 ... yield x x=foo() x.next() 1 x.send(6) 2 x.send(7) 3 x.send(8) 5 x.send(9) [6, 7, 8] x.send(10) Traceback (most recent call last): File stdin, line 1, in module StopIteration But in python 3.0, this code results in: def foo(): ... x=[(yield x) for x in (1,2,3)] ... yield 5 ... yield x x=foo() next(x) 5 x.send(6) generator object listcomp at 0x3678f0 x.send(7) Traceback (most recent call last): File stdin, line 1, in module StopIteration Looking further, it seems that this is a comprehension: def foo(): [(yield 5)] type(foo()) class 'generator' Whereas this is not: def foo(): [(yield 5) for x in range(3)] type(foo()) class 'NoneType' Is this expected behavior? -- components: Interpreter Core messages: 69168 nosy: erickt severity: normal status: open title: yield in list comprehensions possibly broken in 3.0 versions: Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3267 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3174] 3.0b1 doesn't seem to install on macs
New submission from Erick Tryzelaar [EMAIL PROTECTED]: Revision r63851 [1] by Benjamin Peterson removed a couple mac scripts, including cachersrc.py. Unfortunately, this script is still referenced in Mac/Makefile.in, so it fails to install on my mac. Anyone have a workaround I could add for packaging this up for macports? [1]: http://svn.python.org/view?rev=63851view=rev -- components: Installation messages: 68614 nosy: erickt severity: normal status: open title: 3.0b1 doesn't seem to install on macs type: behavior versions: Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3174 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3174] 3.0b1 doesn't seem to install on macs
Erick Tryzelaar [EMAIL PROTECTED] added the comment: I should add the error message: DYLD_FRAMEWORK_PATH=/opt/local/var/macports/build/_Users_Shared_erickt_P rojects_macports_dports.git_lang_python30/work/Python-3.0b1: ../python.exe ./scripts/cachersrc.py -v /opt/local/var/macports/build/_Users_Shared_erickt_Projects_macports_dpo rts.git_lang_python30/work/destroot/opt/local/Library/Frameworks/Python. framework/Versions/3.0/lib/python3.0/plat-mac /opt/local/var/macports/build/_Users_Shared_erickt_Projects_macports_dpo rts.git_lang_python30/work/destroot/opt/local/Library/Frameworks/Python. framework/Versions/3.0/Mac/Tools ../python.exe: can't open file './scripts/cachersrc.py': [Errno 2] No such file or directory make[1]: *** [installmacsubtree] Error 2 make: *** [frameworkinstallmaclib] Error 2 Also, I saw that someone else is having the same problem, so it's not just me: http://groups.google.com/group/python- dev2/browse_thread/thread/65813603fb4d93b9/2585073b7dcb2dbb? lnk=gstq=cachersrc#2585073b7dcb2dbb ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3174 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3174] 3.0b1 doesn't seem to install on macs
Erick Tryzelaar [EMAIL PROTECTED] added the comment: Hello again, I then have problems with it finding MacOS.py in the BuildApplet.py script: DYLD_FRAMEWORK_PATH=/opt/local/var/macports/build/_Users_Shared_erickt_Projects_macports_dports.git_lang_python30/work/Python-3.0b1: ../python.exe ./scripts/BuildApplet.py \ --destroot /opt/local/var/macports/build/_Users_Shared_erickt_Projects_macports_dports.git_lang_python30/work/destroot \ --python /opt/local/Library/Frameworks/Python.framework/Versions/3.0/Resources/Python.app/Contents/MacOS/Python \ --output /opt/local/var/macports/build/_Users_Shared_erickt_Projects_macports_dports.git_lang_python30/work/destroot/Applications/Python 3.0/Build Applet.app \ ./scripts/BuildApplet.py Traceback (most recent call last): File ./scripts/BuildApplet.py, line 14, in module import MacOS ImportError: No module named MacOS make[1]: *** [install_BuildApplet] Error 1 make: *** [frameworkinstallapps] Error 2 On Mon, Jun 23, 2008 at 1:09 PM, Benjamin Peterson [EMAIL PROTECTED] wrote: Benjamin Peterson [EMAIL PROTECTED] added the comment: If you just remove the reference to cachesrc.py, do you still have adverse effects? -- nosy: +benjamin.peterson ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3174 ___ -- nosy: +idadesub ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3174 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1753] TextIOWrapper.write writes utf BOM for every string
New submission from Erick Tryzelaar:
I was playing around with python 3's io functions, and I found that when trying
to write to
an encoded utf-16 file that TextIOWrapper.write re-writes the utf-16 bom for
every string:
f=open('foo', 'w', encoding='utf-16')
print('1234', file=f)
print('5678', file=f)
open('foo', 'rb').read()
b'\xff\xfe1\x002\x003\x004\x00\xff\xfe\n\x00\xff\xfe5\x006\x007\x008\x00\xff\xfe\n\x00'
open('foo', 'r', encoding='utf-16').read()
'1234\ufeff\n\ufeff5678\ufeff\n'
With the attached patch, it appears to generate the correct file:
f=open('foo', 'w', encoding='utf-16')
print('1234', file=f)
print('5678', file=f)
open('foo', 'rb').read()
b'\xff\xfe1\x002\x003\x004\x00\n\x005\x006\x007\x008\x00\n\x00'
open('foo', 'r', encoding='utf-16').read()
'1234\n5678\n'
--
components: Library (Lib)
files: io.py.patch
messages: 59438
nosy: erickt
severity: normal
status: open
title: TextIOWrapper.write writes utf BOM for every string
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file9091/io.py.patch
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1753
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
