[issue6154] Python 3.1 rc1 will not build on OS X 10.5.7
Brett Cannon br...@python.org added the comment: Didn't work when I turned on --enable-framework, but I have no clue how the framework build works so I am of no help with that. -- ___ 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
[issue5798] test_asynchat fails on Mac OSX
Ned Deily n...@acm.org added the comment: Still happening on 3.1rc1. Should this be considered a release blocker for 3.1? -- nosy: +benjamin.peterson, nad ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5798 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6186] test_thread occasionally reports unhandled exceptions on OS X
New submission from Ned Deily n...@acm.org: I've recently started seeing occasional regression test error messages on OS X from test_thread. The test reports running OK but tracebacks are displayed. It's not reproducible at will but has shown up on both 10.5 Intel and 10.5 PPC machines with various recent top of py3k builds. Here are two examples: n...@pbg4:/Library/Frameworks/Python.framework/Versions/3.1$ ./bin/python3.1 -S ./lib/python3.1/test/regrtest.py -w test_thread test_thread Unhandled exception in thread started by bound method ThreadRunningTests.task of test.test_thread.ThreadRunningTests testMethod=test_stack_size Traceback (most recent call last): File /Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/test/te st_thread.py, line 49, in task self.done_mutex.release() _thread.error: release unlocked lock Unhandled exception in thread started by bound method ThreadRunningTests.task of test.test_thread.ThreadRunningTests testMethod=test_stack_size Traceback (most recent call last): File /Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/test/te st_thread.py, line 49, in task self.done_mutex.release() _thread.error: release unlocked lock Unhandled exception in thread started by bound method ThreadRunningTests.task of test.test_thread.ThreadRunningTests testMethod=test_stack_size Traceback (most recent call last): File /Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/test/te st_thread.py, line 49, in task self.done_mutex.release() _thread.error: release unlocked lock Unhandled exception in thread started by bound method ThreadRunningTests.task of test.test_thread.ThreadRunningTests testMethod=test_stack_size Traceback (most recent call last): File /Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/test/te st_thread.py, line 49, in task self.done_mutex.release() _thread.error: release unlocked lock Unhandled exception in thread started by bound method ThreadRunningTests.task of test.test_thread.ThreadRunningTests testMethod=test_starting_threads Traceback (most recent call last): File /Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/test/te st_thread.py, line 49, in task self.done_mutex.release() _thread.error: release unlocked lock 1 test OK. and n...@fimt:/Library/Frameworks/Python.framework/Versions/3.1$ ./bin/python3.1 -S ./lib/python3.1/test/regrtest.py -w test_thread test_thread Unhandled exception in thread started by bound method ThreadRunningTests.task of test.test_thread.ThreadRunningTests testMethod=test_stack_size Traceback (most recent call last): File /Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/test/te st_thread.py, line 49, in task self.done_mutex.release() _thread.error: release unlocked lock Unhandled exception in thread started by bound method ThreadRunningTests.task of test.test_thread.ThreadRunningTests testMethod=test_starting_threads Traceback (most recent call last): File /Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/test/te st_thread.py, line 49, in task self.done_mutex.release() _thread.error: release unlocked lock 1 test OK. Are the tracebacks from a harmless race condition and, if so, can the test be modified to eliminate them? Or is there some new real problem? -- components: Tests messages: 88799 nosy: nad severity: normal status: open title: test_thread occasionally reports unhandled exceptions on OS X versions: Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6186 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4806] Function calls taking a generator as star argument can mask TypeErrors in the generator
Hagen Fürstenau hfuerste...@gmx.net added the comment: I added a simple check for iterables. This is not very elegant, but performance is only affected in the case of an exception. Patch and corresponsing test are attached as TypeError.patch. As I pointed out above, the actual error message must be a sequence is also inconsistent with the implementation (and tests) which allows any kind of iterable. The attached and independent patch message_and_docs.patch changes this to must be an iterable and corrects docs and tests accordingly. -- keywords: +patch versions: +Python 2.7, Python 3.1 Added file: http://bugs.python.org/file14166/TypeError.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4806 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1943] improved allocation of PyUnicode objects
Marc-Andre Lemburg m...@egenix.com added the comment: That's unfortunate; it would clearly have been easier to change this in 3.1. That said, I'm not sure anyone *should* be subclassing PyUnicode. Maybe Marc-Andre can explain why he is doing this (or point to the message in this thread where he explained this before)? The Unicode type was designed to be a basic useful type with as much functionality as needed, but no more. Since it was clear that we would get sub-typing at the time, the aim was to move special use cases into such sub-types. One such example was the referencing logic used in Fredrik's implementation and often requested by the Python community. I removed that logic from the implementation due to the issues this would have caused by accidentally keeping alive large referenced Unicode objects due to references pointing to them. However, it's easy to add it back by sub-typing the Unicode type: http://downloads.egenix.com/python/unicoderef-0.0.1.tar.gz Other special use cases: * sub-types which hold a reference to the original bytes string, e.g. to implement a round-trip safe storage even of broken text data or text that uses multiple encodings * sub-types that get their data from a memory mapped file or a shared memory area without copying * sub-types that implement indexing based on glyphs (ie. the human recognizable notion of a character) rather than code points * sub-types that implement special extra methods or provide case insensitive operations * sub-types that implement special text data forms, such as URLs, OS paths, UID strings, etc. and custom operations on those Sub-typing is also encouraged by the documentation: http://docs.python.org/library/userdict.html#module-UserString ... and after all: one of the main points in making all built-in types sub-typeable was to actually do it :-) If it's a viable use case, it should be possible to have some symbol or a few symbols whose presence can be tested in the preprocessor by code that needs to subclass; we should design the patch with that in mind and Marc-Andre could help testing it. All this is assuming the speed-up is important enough to bother. Has anyone run a comparison benchmark using the Unladen Swallow benchmarks? I trust those much more than micro-benchmarks (including, I assume, stringbench.py). I do expect that reducing the number of allocations for short-to-medium-size strings from 2 to 1 would be a significant speed-up, but I can't guess how much. While the Unladen Swallow aims at providing high-level benchmarks, it's current state doesn't really implement that promise (yet). If you look at the list of benchmarks they use, most appear to be dealing with pickling. That doesn't strike me as particularly useful for testing real life Python usage. If a high level benchmark is indeed what's wanted, then they should setup pre-configured Django and Zope instances and run those through a series of real-life usage scenarios to cover the web application use space. For scientific use cases, it would be good to have similar setups using BioPython, NumPy and matplotlib. And so on. Much like the high level benchmarks you have in the Windows world. Depending on the use case, the results of benchmarks for this particular change are difficult to predict or interpret. Here's a summary message with my reasoning for rejecting the patch: http://bugs.python.org/issue1943#msg88307 Instead of changing PyUnicodeObject from a PyObject to a PyVarObject, making sub-typing a lot harder, I'd much rather apply a single change for 3.1: raising the KEEPALIVE_SIZE_LIMIT to 32 as explained and motivated here: http://bugs.python.org/issue1943#msg64215 That's a simple non-disruptive change which makes a lot of sense due to the advances in CPU designs in the last 9 years. I determined the original value of 9 using benchmarks and similar statistics in 1999/2000. It's probably also a good time to remove the warning, now that the implementation has proven itself for so many years... /* Limit for the Unicode object free list stay alive optimization. The implementation will keep allocated Unicode memory intact for all objects on the free list having a size less than this limit. This reduces malloc() overhead for small Unicode objects. At worst this will result in PyUnicode_MAXFREELIST * (sizeof(PyUnicodeObject) + KEEPALIVE_SIZE_LIMIT + malloc()-overhead) bytes of unused garbage. Setting the limit to 0 effectively turns the feature off. Note: This is an experimental feature ! If you get core dumps when using Unicode objects, turn this feature off. */ #define KEEPALIVE_SIZE_LIMIT 9 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1943 ___ ___ Python-bugs-list mailing list Unsubscribe:
[issue1943] improved allocation of PyUnicode objects
Antoine Pitrou pit...@free.fr added the comment: Instead of changing PyUnicodeObject from a PyObject to a PyVarObject, making sub-typing a lot harder, I'd much rather apply a single change for 3.1: raising the KEEPALIVE_SIZE_LIMIT to 32 as explained and motivated here: You make it sound like an alternative to this patch, while it is quite independent. You could open a separate entry about it, together with benchmarks results etc. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1943 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4806] Function calls taking a generator as star argument can mask TypeErrors in the generator
Amaury Forgeot d'Arc amaur...@gmail.com added the comment: This patch leaks a reference on each call to PyObject_GetIter(). And I'm not sure it is a good idea to call this function again: it may be very expensive! I'd prefer a simple check on the tp_iter member. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4806 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1943] improved allocation of PyUnicode objects
Marc-Andre Lemburg m...@egenix.com added the comment: Antoine Pitrou wrote: Instead of changing PyUnicodeObject from a PyObject to a PyVarObject, making sub-typing a lot harder, I'd much rather apply a single change for 3.1: raising the KEEPALIVE_SIZE_LIMIT to 32 as explained and motivated here: You make it sound like an alternative to this patch, while it is quite independent. You could open a separate entry about it, together with benchmarks results etc. You're right, I could open a separate ticket for it, but it does fit the title of the ticket and was also discussed at length on this ticket, since part of your original patch included changes to the free list management in the Unicode implementation. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1943 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6187] Improvement in doc of Extending and Embedding the Python Interpreter, 5.3 Beyond Very High Level Embedding: An overview
New submission from Jon Blubinger blubdie...@gmail.com: It should me mentioned, that the Python variable PYTHONPATH has to be set to the directory where the multiply.py file is. This can be achieved via export in Linux or via the PySys_SetPath() function in C (see attachment) It should also be mentioned that otherwise the program will have following output: ImportError: No module named multiply Failed to load multiply -- assignee: georg.brandl components: Documentation files: interp3.c messages: 88805 nosy: blubdiebla, georg.brandl severity: normal status: open title: Improvement in doc of Extending and Embedding the Python Interpreter, 5.3 Beyond Very High Level Embedding: An overview versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1 Added file: http://bugs.python.org/file14168/interp3.c ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6187 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1943] improved allocation of PyUnicode objects
Amaury Forgeot d'Arc amaur...@gmail.com added the comment: Let's apply simple and noncontroversial patches first, and then see if the bigger changes are still worth it. Please open a new ticket. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1943 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6185] 2to3 misses buffer slicing
Changes by Benjamin Peterson benja...@python.org: -- assignee: - benjamin.peterson nosy: +benjamin.peterson priority: - normal ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6185 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4806] Function calls taking a generator as star argument can mask TypeErrors in the generator
Hagen Fürstenau hfuerste...@gmx.net added the comment: Sorry, I had meant to use PyIter_Check instead of PyObject_GetIter. Don't know why I didn't do so... ;-) I corrected the patch. -- Added file: http://bugs.python.org/file14169/TypeError2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4806 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4806] Function calls taking a generator as star argument can mask TypeErrors in the generator
Changes by Hagen Fürstenau hfuerste...@gmx.net: Removed file: http://bugs.python.org/file14166/TypeError.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4806 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1943] improved allocation of PyUnicode objects
Changes by STINNER Victor victor.stin...@haypocalc.com: -- nosy: -haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1943 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6188] Error Evaluating float(x) ** float(y)
New submission from Stephen Paul Chappell noctis.skyto...@gmail.com: This is what I get while the interactive interpreter (IDLE 3.0.1) on the platform Python 3.0.1 (r301:69561, Feb 13 2009, 20:04:18) [MSC v.1500 32 bit (Intel)] on win32 a = -6.276479035564047 b = -5.7974497499584849 a ** b != -6.276479035564047 ** -5.7974497499584849 True Something is wrong. The float values are the same but not evaluated as being equal. After writing an automated testing program, these sample numbers were generated and found to create erroneous symptoms in the system being automatically tested. -- components: Interpreter Core messages: 88808 nosy: Zero severity: normal status: open title: Error Evaluating float(x) ** float(y) type: behavior versions: Python 3.0 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6188 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6188] Error Evaluating float(x) ** float(y)
Jean-Paul Calderone exar...@divmod.com added the comment: Have you checked to see what the result of a ** b is? -- nosy: +exarkun ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6188 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6189] subprocess module not compatible with python 2.5
New submission from Israel Tsadok itsa...@gmail.com: According to PEP 291, the subprocess module is supposed to be compatible with python 2.2 and up. rev 60097 introduced the use of os.closerange(), which is new in python 2.6. Either PEP-291 needs to be revised, rev 60097 be reverted, or some sort of fallback mechanism needs to be added. -- components: Library (Lib) files: subprocess.patch keywords: patch messages: 88810 nosy: itsadok severity: normal status: open title: subprocess module not compatible with python 2.5 type: compile error versions: Python 2.6 Added file: http://bugs.python.org/file14170/subprocess.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6189 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6188] Error Evaluating float(x) ** float(y)
Mark Dickinson dicki...@gmail.com added the comment: This is not a bug: Python's operator precedence rules mean that the expression -6.276479035564047 ** -5.7974497499584849 is treated as: -(6.276479035564047 ** -5.7974497499584849). a = -6.276479035564047 b = -5.7974497499584849 a ** b != -6.276479035564047 ** -5.7974497499584849 True a ** b == (-6.276479035564047) ** -5.7974497499584849 True -- nosy: +marketdickinson resolution: - invalid status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6188 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1208304] urllib2's urlopen() method causes a memory leak
BULOT steph...@bulot.org added the comment:
Hello,
I'm facing a urllib2 memory leak issue in one of my scripts that is not
threaded. I made a few tests in order to check what was going on and I
found this already existing bug thread (but old).
I'm not able to figure out what is the issue yet, but here are a few
informations:
Platform: Debian
Python version 2.5.4
I made a script (2 attached files) in order to make access to a web page
(http://www.google.com) every second, that monitors number of file
descriptors and memory footprint.
I also introduced the gc module (Garbage Collector) in order to retrieve
numbers of objects that are not freed (like already proposed in this
thread but more focussed on gc.DEBUG_LEAK flag)
Here are my results:
First acces output:
gc: collectable dict 0xb793c604
gc: collectable HTTPResponse instance at 0xb7938f6c
gc: collectable dict 0xb793c4f4
gc: collectable HTTPMessage instance at 0xb793d0ec
gc: collectable dict 0xb793c02c
gc: collectable list 0xb7938e8c
gc: collectable list 0xb7938ecc
gc: collectable instancemethod 0xb79cf824
gc: collectable dict 0xb793c79c
gc: collectable HTTPResponse instance at 0xb793d2cc
gc: collectable instancemethod 0xb79cf874
unreachable objects: 11
File descriptors number: 32
Memory: 4612
Thenth access:
gc: collectable dict 0xb78f14f4
gc: collectable HTTPResponse instance at 0xb78f404c
gc: collectable dict 0xb78f13e4
gc: collectable HTTPMessage instance at 0xb78f462c
gc: collectable dict 0xb78e5f0c
gc: collectable list 0xb78eeb4c
gc: collectable list 0xb78ee2ac
gc: collectable instancemethod 0xb797b7fc
gc: collectable dict 0xb78f168c
gc: collectable HTTPResponse instance at 0xb78f442c
gc: collectable instancemethod 0xb78eaa7c
unreachable objects: 110
File descriptors number: 32
Memory: 4680
After hundred access:
gc: collectable dict 0x89e2e84
gc: collectable HTTPResponse instance at 0x89e3e2c
gc: collectable dict 0x89e2d74
gc: collectable HTTPMessage instance at 0x89e3ccc
gc: collectable dict 0x89db0b4
gc: collectable list 0x89e3cac
gc: collectable list 0x89e32ec
gc: collectable instancemethod 0x89d8964
gc: collectable dict 0x89e60b4
gc: collectable HTTPResponse instance at 0x89e50ac
gc: collectable instancemethod 0x89ddb1c
unreachable objects: 1100
File descriptors number: 32
Memory: 5284
Each call to urllib2.urlopen() gives 11 new unreachable objects,
increases memory footprint without giving new open files.
Do you have any idea?
With the hack proposed in message
http://bugs.python.org/issue1208304#msg60751, number of unreachable
objects goes down to 8 unreachable objects remaining, but still memory
increases.
Regards.
stephbul
PS
My urlib2leak.py test calls monitor script (not able to attach it):
#! /bin/sh
PROCS='urllib2leak.py'
RUNPID=`ps aux | grep $PROCS | grep -v grep | awk '{printf $2}'`
FDESC=`lsof -p $RUNPID | wc -l`
MEM=`ps aux | grep $PROCS | grep -v grep | awk '{printf $6 }'`
echo File descriptors number: $FDESC
echo Memory: $MEM
--
nosy: +stephbul
versions: -Python 2.6, Python 2.7
Added file: http://bugs.python.org/file14171/urllib2leak.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1208304
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1856] shutdown (exit) can hang or segfault with daemon threads running
Changes by Floris Bruynooghe floris.bruynoo...@gmail.com: -- nosy: +flub ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1856 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5798] test_asynchat fails on Mac OSX
Josiah Carlson josiahcarl...@users.sourceforge.net added the comment: If it's failing, and asyncore is still in 3.1, then I would argue yes. I'll submit a fix to trunk and 3.1 based on my version below (unless anyone has any outstanding concerns, or believes that it doesn't work for them). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5798 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5230] pydoc reports misleading failure if target module raises an ImportError
Lucas Prado Melo lukepada...@gmail.com added the comment: I had lots of stuff to do lately, sorry it took me so long to answer. Here is the patch as we intended, but there is a bug yet. What if the non-existent imported module has the same name of the module itself? $ cat pydoc_badimport3.py import this_doesnt_exist.pydoc_badimport3 $ pydoc pydoc_badimport3 I tested this possibility, and I found out that there is a bug in this situation yet: pydoc still tells the user that the module couldn't be found. -- Added file: http://bugs.python.org/file14172/pydocs.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5230 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5230] pydoc reports misleading failure if target module raises an ImportError
Changes by Lucas Prado Melo lukepada...@gmail.com: Removed file: http://bugs.python.org/file14140/pydocs.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5230 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5798] test_asynchat fails on Mac OSX
Changes by Benjamin Peterson benja...@python.org: -- priority: high - release blocker ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5798 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6184] py3k build gets spurious errors from libinstall target compile of lib2to3 files
Changes by Benjamin Peterson benja...@python.org: -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6184 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6184] py3k build gets spurious errors from libinstall target compile of lib2to3 files
Benjamin Peterson benja...@python.org added the comment: Fixed those in r73177. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6184 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1943] improved allocation of PyUnicode objects
Guido van Rossum gu...@python.org added the comment: Hm, so the extra pointer is a feature. I guess a compromise would be to keep the extra indirection but make it point into the same object in the base class. Thinking about how memory caching in modern CPUs work, this would probably be quite fast but it would still cost 8 bytes on most future (i.e., 64-bit) architectures. Still, I expect that a vanishingly small number of users will actually use that feature. Is it worth to make everyone pay for that flexibility, for what must be the first- or second-most commonly used type in Python 3.x (the other being int), which is still significantly slower than the common (8-bit) string type in 2.x? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1943 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6178] Core error in Py_EvalFrameEx 2.6.2
Tim Savannah tsava...@arinc.com added the comment: recompiled with pydebug enabled, and recompiled all site-packages. Still getting exceptions, however they are occuring within the python binary now and not libpython2.6.1 . pythonLaunch.py[25914]: segfault at 0068 rip 004c7694 rsp 4181a4c0 error 4 pythonLaunch.py[1421]: segfault at 0068 rip 004c7694 rsp 432914c0 error 4 pythonLaunch.py[2552]: segfault at 0068 rip 004c7694 rsp 41f7d4c0 error 4 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6178 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6178] Core error in Py_EvalFrameEx 2.6.2
Tim Savannah tsava...@arinc.com added the comment: to update, no additional output was seen from pydebug. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6178 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1943] improved allocation of PyUnicode objects
Collin Winter coll...@gmail.com added the comment: On Wed, Jun 3, 2009 at 2:36 AM, Marc-Andre Lemburg rep...@bugs.python.org wrote: Marc-Andre Lemburg m...@egenix.com added the comment: All this is assuming the speed-up is important enough to bother. Has anyone run a comparison benchmark using the Unladen Swallow benchmarks? I trust those much more than micro-benchmarks (including, I assume, stringbench.py). I do expect that reducing the number of allocations for short-to-medium-size strings from 2 to 1 would be a significant speed-up, but I can't guess how much. While the Unladen Swallow aims at providing high-level benchmarks, it's current state doesn't really implement that promise (yet). If you look at the list of benchmarks they use, most appear to be dealing with pickling. That doesn't strike me as particularly useful for testing real life Python usage. I would take issue with your characterization of those benchmarks. There are several benchmarks for cPickle, true, both macro and micro benchmarks, but I would not describe their number as most of [our] benchmarks. For example, slowpickle and slowunpickle both use the pure-Python pickle.py, and are testing how close we can get that implementation to the tuned cPickle version. Regardless, I don't know that any of our benchmarks really stress unicode performance. We so far haven't cared about improving the performance of unicode objects. 2to3 uses unicode internally, so that might be a good benchmark to run. If a high level benchmark is indeed what's wanted, then they should setup pre-configured Django and Zope instances and run those through a series of real-life usage scenarios to cover the web application use space. We have a benchmark for Django and Spitfire templates, both of which are heavily used in the web application use space. We focused on template languages because in talking to Google's web app teams, they found their primary CPU bottlenecks to be templating systems, not ORMs or other components. For scientific use cases, it would be good to have similar setups using BioPython, NumPy and matplotlib. And so on. Much like the high level benchmarks you have in the Windows world. We have NumPy in our correctness test suite, but no benchmarks based on it. Looking at all the packages you just named, they make heavy use of C/C++ extensions (with BioPython and matplotpib both depending on NumPy) or large C libraries (matplotlib can depend on Cairo, I see). We've been focusing on pure-Python performance, so I'm skeptical that benchmarks with such large C components would be a useful guide for our work. I'm happy to talk about this further outside of this thread, though. Collin -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1943 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6185] 2to3 misses buffer slicing
Benjamin Peterson benja...@python.org added the comment: Thanks for the patch! Fixed in r73179. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6185 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6136] Make logging configuration files easier to use
Geoffrey Bache gjb1...@users.sourceforge.net added the comment: OK, I'll take point (c) further on comp.lang.python. As for the others, it would be useful if you could at least understand my points. a) I'm aware that there isn't necessarily a one-to-one correspondence between loggers and files, don't see why that's relevant. I have no idea what the common way of using logging is, if there is one. Having lots of files in a logging set up doesn't seem to me in any way unusual, even if the number of loggers is potentially even larger. The main question is the one I posed before: what is the point of opening files that will never be written to and sockets that will never be used? Or to put it another way, if I submitted a patch that only created handlers that were used by at least one logger, would you look at it? b) compulsory as in compulsory as an entry in the config file. The code would be if qualname in opts: qn = cp.get(sectname, qualname) else: qn = log To make life easier for those of us who don't see the point in naming loggers differently in the config file and in the code... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6136 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5798] test_asynchat fails on Mac OSX
Changes by Josiah Carlson josiahcarl...@users.sourceforge.net: Removed file: http://bugs.python.org/file13934/asyncore_fix_mac_2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5798 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5798] test_asynchat fails on Mac OSX
Josiah Carlson josiahcarl...@users.sourceforge.net added the comment: Fixed in trunk in 73182, fixed in py3k in 73183. Closing as fixed. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5798 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6190] Tutorial 3.1.2 (Strings) has duplicate lines
New submission from Michael Markert markert.mich...@gmail.com: Lines 242 - 246 of `introduction.rst` are the exact duplicate of 202 - 206 in the same file. 246+247 resemble 206+207. The attached patch deletes the second notion. -- assignee: georg.brandl components: Documentation files: introduction.rst.patch keywords: patch messages: 88823 nosy: cofi, georg.brandl severity: normal status: open title: Tutorial 3.1.2 (Strings) has duplicate lines versions: Python 3.1 Added file: http://bugs.python.org/file14173/introduction.rst.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6190 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1943] improved allocation of PyUnicode objects
Antoine Pitrou pit...@free.fr added the comment: Still, I expect that a vanishingly small number of users will actually use that feature. Apart from the example Marc-André just posted (and which is a 0.0.1 proof of concept he apparently just wrote), the number of users is, AFAICT, zero. Unless there's some closed source extension which happens to extend unicode as a C subtype. Now, as for easing the subclassing of unicode in C, there are probably several possibilities which range from devising a clever set of macros to abusing the ob_size field for a tagged pointer. People who really care should do a concrete proposal (and I don't know who these people are, apart from Marc-André). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1943 ___ ___ 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
Evan Behar beh...@gmail.com added the comment:
Nevermind, my bad. With Brett's patch, the build does not work with
--enable-framework
It appears that configure.in makes no assignment to FRAMEWORKLINK or
AC_SUBST call with it, and so it is deposited in the final Makefile
verbatim as @FRAMEWORKLINK@
If --enable-framework is defined, then this compiler command in
Makefile.pre:461 gets executed:
$(CC) -o $(LDLIBRARY) -dynamiclib \
-isysroot ${UNIVERSALSDK} \
-all_load $(LIBRARY) -Wl,-single_module \
-install_name
$(DESTDIR)$(PYTHONFRAMEWORKINSTALLDIR)/Versions/$(VERSION)/$(PYTHONFRAMEWORK)
\
-compatibility_version $(VERSION) \
-current_version $(VERSION) \
$(FRAMEWORKLINK);
Which expands $(FRAMEWORKLINK) to @FRAMEWORKLINK@ because of this.
This makes no use of LIBS or any other environment variable that might
contain -lintl or -framework CoreFoundation, and the build will fail
with linker errors citing undefined intl and CFString symbols.
Attached is a patch that fixes this issue; it combines brett's lintl
patch with the fix for --enable-framework.
--
Added file: http://bugs.python.org/file14174/darwin_lintl_framework.patch
___
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
[issue6189] subprocess module not compatible with python 2.5
Changes by Giampaolo Rodola' billiej...@users.sourceforge.net: -- nosy: +giampaolo.rodola ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6189 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6137] Pickle migration: Should pickle map copy_reg to copyreg?
Antoine Pitrou pit...@free.fr added the comment: Unpickling e.g. StringIO objects doesn't seem to work: s = pickle.load(open(stringio.pickle, rb)) Traceback (most recent call last): File stdin, line 1, in module File /home/antoine/py3k/picklecompat-6137/Lib/pickle.py, line 1351, in load encoding=encoding, errors=errors).load() AttributeError: '_io.BytesIO' object has no attribute '__dict__' -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6137 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6190] Tutorial 3.1.2 (Strings) has duplicate lines
Georg Brandl ge...@python.org added the comment: Thanks, fixed in r73185. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6190 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6174] What's new in 2.6, wrong indentation in code sample
Georg Brandl ge...@python.org added the comment: Thanks, fixed in r73186. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6174 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2713] Py3k warn on unicode escapes in raw strings
Amaury Forgeot d'Arc amaur...@gmail.com added the comment: Why was this patch rejected? with python2.6, len(ur'\u1234') == 1 with python3.0, len( r'\u1234') == 6 This is worth a warning IMO. See also issue2570. -- nosy: +amaury.forgeotdarc ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2713 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1943] improved allocation of PyUnicode objects
Guido van Rossum gu...@python.org added the comment: On Wed, Jun 3, 2009 at 1:41 PM, Antoine Pitrou rep...@bugs.python.org wrote: Apart from the example Marc-André just posted (and which is a 0.0.1 proof of concept he apparently just wrote), the number of users is, AFAICT, zero. IIUC Marc-Andre extracted that from a larger code base (MX) which he owns and has been maintaining for a decade or so. Unless there's some closed source extension which happens to extend unicode as a C subtype. I believe part of MX is closed source. Now, as for easing the subclassing of unicode in C, there are probably several possibilities which range from devising a clever set of macros to abusing the ob_size field for a tagged pointer. People who really care should do a concrete proposal (and I don't know who these people are, apart from Marc-André). Not really if the core code uses a macro that depends on the layout of the object (i.e. the data immediately following the header, like old 8-bit strings), unless you change the core (or the macro) to only use this if the type matches exactly, and for subtypes use a more expensive API. But that would slow down unnecessarily for subclasses written in Python (of which there are plenty). But I would like to point out that few people if any have ever complained about the contiguous allocation for 8-bit strings in Python [0-2].x. And we certainly wouldn't have given in. Now that Unicode is no longer some fancy-schmancy advanced concept but the basis for *all* Python string processing I think we should apply the same policy. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1943 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6137] Pickle migration: Should pickle map copy_reg to copyreg?
Antoine Pitrou pit...@free.fr added the comment: An improved patch with tests. It has no tests for fix_imports=False, though. -- Added file: http://bugs.python.org/file14175/compat_pickle2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6137 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2590] S_unpack_from() Read Access Violation
Amaury Forgeot d'Arc amaur...@gmail.com added the comment: All expressions are of type Py_ssize_t, which is signed. buffer_len is positive; the subtraction (buffer_len - offset) can overflow only if offset is a (large) negative number, but then the first part of the test is already fulfilled. Closing unless more evidence is given. -- resolution: - works for me status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2590 ___ ___ 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
Brett Cannon br...@python.org added the comment: So Evan's patch didn't work for me. But I did take Evan's point that LIBS was not being used in the framework build step and simply added $(LIBS) to Makefile.pre.in where the linking for the Python executable happens (attached a new patch with that in it). That got ``--with-pydebug --enable-framework`` working, but the build still fails under ``--with-pydebug --enable-framework --enable-universalsdk``. Why does it fail? Well because ``-lintl`` ends up not being set in $(LIBS), that's why! =) I have burned way too much time on this to finish debugging this autoconf crap. This is getting hairy enough that either a) get more help from python-dev, b) revert the static linking of _locale, c) get Ronald involved. -- Added file: http://bugs.python.org/file14176/lintl_for_frameworks.patch ___ 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
[issue5267] Subversion problem with PythonLauncher after building 3.0 or 3.1 on Mac
Ronald Oussoren ronaldousso...@mac.com added the comment: Fixed for 3.1 in r73187, and for 3.0 in r73188. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5267 ___ ___ 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
Benjamin Peterson benja...@python.org added the comment: I take it the build problem is because intl isn't a universal library? In that case, I think the best solution is to not define WITH_INTL if --enable-universalsdk is passed. Ronald, do you have an opinion? -- nosy: +ronaldoussoren ___ 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
[issue6154] Python 3.1 rc1 will not build on OS X 10.5.7 with macports libintl
Changes by Benjamin Peterson benja...@python.org: -- title: Python 3.1 rc1 will not build on OS X 10.5.7 - Python 3.1 rc1 will not build on OS X 10.5.7 with macports libintl ___ 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
[issue6137] Pickle migration: Should pickle map copy_reg to copyreg?
Antoine Pitrou pit...@free.fr added the comment: A new patch which also includes reverse mappings, so that protocol = 2 pickles created with 3.x can also work under 2.x. (that is, it also solves #3675) -- dependencies: +Python 2.6 can't read sets pickled with Python 3.0 Added file: http://bugs.python.org/file14177/compat_pickle3.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6137 ___ ___ 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 with macports libintl
Evan Behar beh...@gmail.com added the comment: Curiously, if I define --with-pydebug I get ld: Undefined symbols: ___eprintf If I don't define --with-pydebug but I do use --enable-universalsdk I get a whole different problem: gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -DPy_BUILD_CORE -c ./Modules/_localemodule.c -o Modules/_localemodule.o ./Modules/_localemodule.c:28:21: error: libintl.h: No such file or directory This leads to whole bunch of other crap. libintl.h is used in other forms of the build, so I'm not sure why this is cropping up. I also have no idea what ___eprintf is. -- ___ 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
[issue6137] Pickle migration: Should pickle map copy_reg to copyreg?
Antoine Pitrou pit...@free.fr added the comment: Updated patch with a couple of documentation and function prototype fixes. -- dependencies: -Python 2.6 can't read sets pickled with Python 3.0 Added file: http://bugs.python.org/file14178/compat_pickle4.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6137 ___ ___ 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 with macports libintl
Ronald Oussoren ronaldousso...@mac.com added the comment:
Do you have a copy of libintl in /usr/local or ~brett//local/lib? If so,
could you run 'file' on that library to check if it is a universal
library?
All system libraries on OSX are universal binaries and work just fine
with a universal build of Python, that's why I believe you have a non-
universal copy of some libraries on your systems and those won't work
when you try to do a universal build.
Removing -lintl for a universal build would not be a valid solution,
unless -lintl is completely unnecessary on OSX.
And for the record: I cannot reproduce this on my system, the end of
build with --enable-universalsdk:
Python build finished, but the necessary bits to build these modules
were not found:
_gdbm ossaudiodevreadline
spwd
To find the necessary bits, look in setup.py in detect_modules() for the
module's name.
Failed to build these modules:
_gestalt _tkinter
And the output of file:
file python.exe
python.exe: Mach-O universal binary with 2 architectures
python.exe (for architecture ppc): Mach-O executable ppc
python.exe (for architecture i386): Mach-O executable i386
Al of this is with a fresh checkout (r73188) of the py3k branch.
P.S. I'd love to know a clean way to exclude /usr/local/{include,lib}
from the search paths of GCC, I've had a number of bugreports for other
projects where the compiler picked up a non-universal library in
/usr/local that the user didn't even know they had installed and didn't
want to use.
--
___
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
[issue6154] Python 3.1 rc1 will not build on OS X 10.5.7 with macports libintl
Ronald Oussoren ronaldousso...@mac.com added the comment: I have two procedural questions: 1) Who should I contact to get e-mail for all bugs that get tagged with the Macintosh component? 2) Please tag all mac-related bugs with the 'Macintosh' component, that's the one I most often check for new issues. -- ___ 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
[issue6137] Pickle migration: Should pickle map copy_reg to copyreg?
Antoine Pitrou pit...@free.fr added the comment: Sorry, last patch had a couple of minor issues -- Added file: http://bugs.python.org/file14179/compat_pickle5.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6137 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6137] Pickle migration: Should pickle map copy_reg to copyreg?
Changes by Antoine Pitrou pit...@free.fr: Removed file: http://bugs.python.org/file14177/compat_pickle3.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6137 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6137] Pickle migration: Should pickle map copy_reg to copyreg?
Changes by Antoine Pitrou pit...@free.fr: Removed file: http://bugs.python.org/file14178/compat_pickle4.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6137 ___ ___ 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 with macports libintl
Benjamin Peterson benja...@python.org added the comment: 2009/6/3 Ronald Oussoren rep...@bugs.python.org: Ronald Oussoren ronaldousso...@mac.com added the comment: I have two procedural questions: 1) Who should I contact to get e-mail for all bugs that get tagged with the Macintosh component? Create an issue on the meta tracker: http://psf.upfronthosting.co.za/roundup/meta 2) Please tag all mac-related bugs with the 'Macintosh' component, that's the one I most often check for new issues. I will tell the bug triage people that. -- ___ 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
[issue6154] Python 3.1 rc1 will not build on OS X 10.5.7 with macports libintl
Ronald Oussoren ronaldousso...@mac.com added the comment: I just noticed the update of the title. I propose to close this issue if this is caused by a non-universal version of libintl that's installed by macports. Macports can install universal binaries of its packages (the +universal variant), use that if you want to link a universal build of python with macports libraries (and if you don't want to link with macports you shouldn't add the macports $prefix to the search path of the compiler) -- ___ 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
[issue6154] Python 3.1 rc1 will not build on OS X 10.5.7 with macports libintl
Benjamin Peterson benja...@python.org added the comment: 2009/6/3 Ronald Oussoren rep...@bugs.python.org: Ronald Oussoren ronaldousso...@mac.com added the comment: I just noticed the update of the title. I propose to close this issue if this is caused by a non-universal version of libintl that's installed by macports. Actually, it can happen with regular builds, but the attached patches fix that issue. Macports can install universal binaries of its packages (the +universal variant), use that if you want to link a universal build of python with macports libraries (and if you don't want to link with macports you shouldn't add the macports $prefix to the search path of the compiler) That sounds reasonable. -- ___ 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
[issue6154] Python 3.1 rc1 will not build on OS X 10.5.7 with macports libintl
Evan Behar beh...@gmail.com added the comment: I haven't got any library issues using --enable-universalsdk, it won't get to the linking stage becaue it doesn't find libintl.h And with --with-pydebug still doesn't build because it won't find ___eprintf, whatever that is. The only version of libintl on my system is universal, so I don't think that's related. -- ___ 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
[issue6154] Python 3.1 rc1 will not build on OS X 10.5.7 with macports libintl
Ronald Oussoren ronaldousso...@mac.com added the comment: On 4 Jun, 2009, at 0:59, Evan Behar wrote: Evan Behar beh...@gmail.com added the comment: I haven't got any library issues using --enable-universalsdk, it won't get to the linking stage becaue it doesn't find libintl.h And with --with-pydebug still doesn't build because it won't find ___eprintf, whatever that is. The only version of libintl on my system is universal, so I don't think that's related. The --with-pydebug issue is unrelated to this one, and IIRC there is already a tracker item for that, at least when you're running OSX 10.4. I don't have problems with --with-pydebug on 10.5 -- title: Python 3.1 rc1 will not build on OS X 10.5.7 with macports libintl - Python 3.1 rc1 will not build on OS X 10.5.7 with macports libintl Added file: http://bugs.python.org/file14180/smime.p7s ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6154 ___ smime.p7s Description: S/MIME cryptographic signature ___ 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 with macports libintl
Ronald Oussoren ronaldousso...@mac.com added the comment: On 4 Jun, 2009, at 0:59, Benjamin Peterson wrote: Benjamin Peterson benja...@python.org added the comment: 2009/6/3 Ronald Oussoren rep...@bugs.python.org: Ronald Oussoren ronaldousso...@mac.com added the comment: I just noticed the update of the title. I propose to close this issue if this is caused by a non-universal version of libintl that's installed by macports. Actually, it can happen with regular builds, but the attached patches fix that issue. How can it happen with regular builds? This can only happen if there is a non-universal copy of used libraries on the compiler search-path, or rather if there are libraries with incompatible architectures on the search-path. This would also happen with readline, or if you have a ppc-only library on an intel machine. Not having the right archtectures of libraries is IMHO in don't do that then territory. Ronald -- Added file: http://bugs.python.org/file14181/smime.p7s ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6154 ___ smime.p7s Description: S/MIME cryptographic signature ___ 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 with macports libintl
Ronald Oussoren ronaldousso...@mac.com added the comment: On 4 Jun, 2009, at 0:59, Benjamin Peterson wrote: Benjamin Peterson benja...@python.org added the comment: 2009/6/3 Ronald Oussoren rep...@bugs.python.org: Ronald Oussoren ronaldousso...@mac.com added the comment: I just noticed the update of the title. I propose to close this issue if this is caused by a non-universal version of libintl that's installed by macports. Actually, it can happen with regular builds, but the attached patches fix that issue. How can it happen with regular builds? This can only happen if there is a non-universal copy of used libraries on the compiler search-path, or rather if there are libraries with incompatible architectures on the search-path. This would also happen with readline, or if you have a ppc-only library on an intel machine. Not having the right archtectures of libraries is IMHO in don't do that then territory. Ronald -- Added file: http://bugs.python.org/file14182/smime.p7s ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6154 ___ smime.p7s Description: S/MIME cryptographic signature ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5649] OS X Installer: only include PythonSystemFixes package if target includes 10.3
Ned Deily n...@acm.org added the comment:
Further investigation reveals that the underlying script
Mac/Tools/fixapplepython23.py is broken on 3.x:
1. the version test using platform.mac_ver is incorrect
Traceback (most recent call last):
File fixapplepython23.py, line 131, in module
main()
File fixapplepython23.py, line 103, in main
if osver != '10.3' and os.ver '10.3.':
AttributeError: 'module' object has no attribute 'ver'
2. and, even if the typo is corrected, osver returns a tuple
osver = platform.mac_ver()
osver
('10.5.7', ('', '', ''), 'PowerPC')
The above are only seen on PPC builds since the script bails out earlier
if running on an Intel platform.
At this point, it is a minor issue and the number of users who might be
impacted must be few and getting fewer; eventually PythonSystemFixes
should be removed when or before 10.3 is no longer supported.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5649
___
___
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 with macports libintl
Ronald Oussoren ronaldousso...@mac.com added the comment: On 4 Jun, 2009, at 0:59, Evan Behar wrote: Evan Behar beh...@gmail.com added the comment: I haven't got any library issues using --enable-universalsdk, it won't get to the linking stage becaue it doesn't find libintl.h And with --with-pydebug still doesn't build because it won't find ___eprintf, whatever that is. The only version of libintl on my system is universal, so I don't think that's related. The --with-pydebug issue is unrelated to this one, and IIRC there is already a tracker item for that, at least when you're running OSX 10.4. I don't have problems with --with-pydebug on 10.5 -- Added file: http://bugs.python.org/file14183/smime.p7s ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6154 ___ smime.p7s Description: S/MIME cryptographic signature ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6170] Mac 'make frameworkinstall' error: [...]/Python.framework/Versions/3.1/bin/2to3: Too many levels of symbolic links
Sridhar Ratnakumar sridh...@activestate.com added the comment: Ronald, a quick note - your fix unfortunately did not solve the issue. [quote]'To help with the repro, may I suggest running the following in the same order: make frameworkinstallframework DESTDIR=image make frameworkinstallapps DESTDIR=image make frameworkinstall frameworkinstallextras DESTDIR=image '[endquote[ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6170 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6170] Mac 'make frameworkinstall' error: [...]/Python.framework/Versions/3.1/bin/2to3: Too many levels of symbolic links
Ronald Oussoren ronaldousso...@mac.com added the comment: Don't do that, use 'make install DESTDIR=$PWD/image'. As I mentioned earlier 'make frameworkinstallframework' is an internal step that shouldn't be used on its own. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6170 ___ ___ 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 with macports libintl
Benjamin Peterson benja...@python.org added the comment: There's a broader issue than just the non-universal intl problem. If intl.h is defined, then configure causes _localemodule.c to use functions from it, but it wasn't being linked to. -- ___ 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
[issue5798] test_asynchat fails on Mac OSX
Ned Deily n...@acm.org added the comment: Verified test_asynchat no longer fails in trunk nor py3k. Thanks! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5798 ___ ___ 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 with macports libintl
Brett Cannon br...@python.org added the comment: As Benjamin said, this was failing on non-universal framework builds and just a regular build because '-lintl' was not getting added to LIBS in configure.in and LIBS was not being passed into the framework compile rule (for both universal and non-universal). As for my copy of libintl.dylib, 'file' says:: /unix/macports/lib/libintl.dylib: Mach-O dynamically linked shared library i386 From my reading of that it means gettext was not built as a universal library (which I will go fix and so for other libraries I have through MacPorts). Ronald, can you look at the changes I proposed on Makefile.pre.in to make sure LIBS from configure get used in the framework builds? If you do then that change with the configure.in change I suggested should solve all of this. -- ___ 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
[issue5839] RegOpenKeyEx key failed on Vista 64Bit with return 2
Amaury Forgeot d'Arc amaur...@gmail.com added the comment: I don't understand what 2.6.2 source(32bit) is. Did you install a binary distribution (.msi), or did you compile the source files? -- nosy: +amaury.forgeotdarc ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5839 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5648] OS X Installer: do not install obsolete documentation within Python.app bundle
Ned Deily n...@acm.org added the comment: Verified fixed by r72779 in trunk and r72791 in py3k. Can be closed. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5648 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5373] TypeError when '\x00' in docstring
Alexandre Vassalotti alexan...@peadrop.com added the comment: Patch committed in r73195. -- resolution: - accepted status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5373 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6137] Make pickle generated by Python 3.x compatible with 2.x and vice-versa.
Alexandre Vassalotti alexan...@peadrop.com added the comment: Here is an updated patch based on Antoine's latest patch. Summary of changes: * Updated docstrings of Pickler and Unpickler in the pickle module. * Fixed pickle._Pickler to consider fix_imports only for protocol 3 * Made module name remapping in _pickle more robust: - added PyUnicode_Check on global_name and module_name; - used PyDict_GetItemWithError instead of PyDict_GetItem * Changed Py_BuildValue((OO), ...) to its faster equivalent PyTuple_Pack(2, ...). I don't really the idea of remapping names generated by Pickler, since it breaks the identity guarantee in save_global(). However, I agree this is an example where practicality beats purity. So, I do not oppose to the change. -- assignee: - alexandre.vassalotti title: Pickle migration: Should pickle map copy_reg to copyreg? - Make pickle generated by Python 3.x compatible with 2.x and vice-versa. Added file: http://bugs.python.org/file14184/compat_pickle6.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6137 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3675] Python 2.6 can't read sets pickled with Python 3.0
Alexandre Vassalotti alexan...@peadrop.com added the comment: Superseded by issue #6137. -- resolution: - duplicate status: open - closed superseder: - Make pickle generated by Python 3.x compatible with 2.x and vice-versa. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3675 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2057] difflib: add patch capability
Changes by Todd Whiteman twhit...@yahoo.com.au: -- nosy: +twhitema ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2057 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
