[ python-Bugs-1202533 ] a bunch of infinite C recursions
Bugs item #1202533, was opened at 2005-05-15 23:43
Message generated for change (Comment added) made by arigo
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: a bunch of infinite C recursions
Initial Comment:
There is a general way to cause unchecked infinite recursion at the C level,
and I have no clue at the moment how it could be reasonably fixed. The idea is
to define special __xxx__ methods in such a way that no Python code is actually
called before they invoke more special methods (e.g. themselves).
>>> class A: pass
>>> A.__mul__=new.instancemethod(operator.mul,None,A)
>>> A()*2
Segmentation fault
--
>Comment By: Armin Rigo (arigo)
Date: 2006-06-25 09:33
Message:
Logged In: YES
user_id=4771
Yes, it seems reasonable. You should probably manipulate
tstate->recursion_depth directly instead of via the
macros, as e.g. ceval.c does.
This would fix most crashes here. It would make the attached
test17.py segfault, though. This test17 already segfaults a
debug build of Python, but not a release build because the
recursive PyErr_NormalizeException() is turned into a tail
call by gcc. (What, a convoluted mind, mine?)
--
Comment By: Brett Cannon (bcannon)
Date: 2006-06-23 21:54
Message:
Logged In: YES
user_id=357491
I just had an idea, Armin. What if, at the recursive call
site in PyErr_NormalizeException(), we called
Py_LeaveRecursiveCall() before and Py_EnterRecursiveCall()
after? That would keep the recursion limit the same when
the normalization was done, but still allow the check in
PyObject_Call()::
Py_LeaveRecursiveCall();
PyErr_NormalizeException(exc, val, tb);
Py_EnterRecursiveCall("");
Since it is an internal call I think it would be safe to
"play" with the recursion depth value like this. What do
you think?
--
Comment By: Brett Cannon (bcannon)
Date: 2006-06-23 20:57
Message:
Logged In: YES
user_id=357491
The rev. that Armin checked in was actually r47061.
--
Comment By: Brett Cannon (bcannon)
Date: 2006-06-23 20:53
Message:
Logged In: YES
user_id=357491
I thought the check was in slot_tp_call and not
PyObject_Call. So yeah, I basically forgot. =)
The problem with allowing the segfault to stay is that it
destroys security in terms of protecting the interpreter,
which I am trying to deal with. So leaving random ways to
crash the interpreter is currently a no-no for me. I will
see if I can come up with another way to fix this issue.
--
Comment By: Armin Rigo (arigo)
Date: 2006-06-23 20:05
Message:
Logged In: YES
user_id=4771
I'd have answer "good idea, go ahead", if it were not for
what I found out a few days ago, which is that:
* you already checked yourself a Py_EnterRecursiveCall() into
PyObject_Call() -- that was in r46806 (I guess you forgot)
* I got a case of Python hanging on me in an infinite busy
loop, which turned out to be caused by this (!)
So I reverted r46806 in r47601, added a test (see log for an
explanation), and moved the PyEnter_RecursiveCall()
elsewhere, where it still catches the originally intended
case, but where it will probably not catch the cases of the
present tracker any more. Not sure what to do about it. I'd
suggest to be extra careful here; better some extremely
obscure and ad-hoc ways to provoke a segfault, rather than
busy-loop hangs in previously working programs...
--
Comment By: Brett Cannon (bcannon)
Date: 2006-06-23 19:44
Message:
Logged In: YES
user_id=357491
Do you have any objection to using the
Py_EnterRecursiveCall() in PyObject_Call(), Armin, to at
least deal with the crashers it fixes?
--
Comment By: Terry J. Reedy (tjreedy)
Date: 2005-09-01 20:39
Message:
Logged In: YES
user_id=593130
Bug submission [ 1267884 ] crash recursive __getattr__
appears to be another example of this problem, so I closed it as
a duplicate. If that turns out to be wrong, it should be reopened.
--
Comment By: Armin Rigo (arigo)
Date: 2005-05-29 12:23
Message:
Logged In: YES
user_id=4771
Adding a Py_EnterRecursiveCall() in PyObject_Call() seems to fix all the
examples so far, with the excepti
[ python-Bugs-1511964 ] Can't use sockets in 2.5b1
Bugs item #1511964, was opened at 2006-06-24 23:28 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1511964&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Bryan O'Sullivan (bos) Assigned to: Nobody/Anonymous (nobody) Summary: Can't use sockets in 2.5b1 Initial Comment: I'm testing Mercurial with Python 2.5b1, and I am getting severe badness in the socket module, complaining that _socket.socket doesn't have a recv_into method. + File "/tmp/hgtests.u_b_G-/install/lib/python/mercurial/httprangereader.py", line 24, in read +f = urllib2.urlopen(req) + File "/export/home/bos/src/py25/lib/python2.5/urllib2.py", line 121, in urlopen +return _opener.open(url, data) + File "/export/home/bos/src/py25/lib/python2.5/urllib2.py", line 374, in open +response = self._open(req, data) + File "/export/home/bos/src/py25/lib/python2.5/urllib2.py", line 392, in _open+'_open', req) + File "/export/home/bos/src/py25/lib/python2.5/urllib2.py", line 353, in _call_chain +result = func(*args) + File "/export/home/bos/src/py25/lib/python2.5/urllib2.py", line 1099, in http_open +return self.do_open(httplib.HTTPConnection, req) + File "/export/home/bos/src/py25/lib/python2.5/urllib2.py", line 1071, in do_open +h.request(req.get_method(), req.get_selector(), req.data, headers) + File "/export/home/bos/src/py25/lib/python2.5/httplib.py", line 862, in request +self._send_request(method, url, body, headers) + File "/export/home/bos/src/py25/lib/python2.5/httplib.py", line 885, in _send_request +self.endheaders() + File "/export/home/bos/src/py25/lib/python2.5/httplib.py", line 856, in endheaders +self._send_output() + File "/export/home/bos/src/py25/lib/python2.5/httplib.py", line 728, in _send_output +self.send(msg) + File "/export/home/bos/src/py25/lib/python2.5/httplib.py", line 695, in send +self.connect() + File "/export/home/bos/src/py25/lib/python2.5/httplib.py", line 666, in connect +self.sock = socket.socket(af, socktype, proto) + File "/export/home/bos/src/py25/lib/python2.5/socket.py", line 154, in __init__ +self.recv_into = self._sock.recv_into +AttributeError: '_socket.socket' object has no attribute 'recv_into' -- >Comment By: Armin Rigo (arigo) Date: 2006-06-25 09:38 Message: Logged In: YES user_id=4771 This looks like a broken install. The socket objects do have a recv_into() method in socketmodule.c. Try "make clean; make". If it does not help, check where the _socket module comes from with: python2.5 >>> import _socket >>> print _socket.__file__ and make sure that this file is among the ones you just recompiled. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1511964&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1507224 ] sys.path issue if sys.prefix contains a colon
Bugs item #1507224, was opened at 2006-06-16 11:22 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1507224&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Nobody/Anonymous (nobody) Summary: sys.path issue if sys.prefix contains a colon Initial Comment: If you install python in a directory whose path contains a colon sys.path will be wrong, the installation directory will be split into two strings and both of them are added to sys.path. The following session demonstrates the problem: bump:~/src/python/:colon bob$ ./python.exe -c "import sys; print sys.path" 'import site' failed; use -v for traceback ['', '/usr/local/lib/python25.zip', '/Users/bob/src/python/', 'colon/../ Lib/', '/Users/bob/src/python/', 'colon/../Lib/plat-darwin', '/Users/bob/ src/python/', 'colon/../Lib/plat-mac', '/Users/bob/src/python/', 'colon/../ Lib/plat-mac/lib-scriptpackages', '/Users/bob/src/python/', 'colon/../ Lib/lib-tk', '/Users/bob/src/python/', 'colon/Modules'] -- >Comment By: Armin Rigo (arigo) Date: 2006-06-25 10:04 Message: Logged In: YES user_id=4771 Internally, CPython sets up its path using a single ':'-separated string. I have no clue how, on Posix, you are supposed to use paths containing ':' in environment variables like $PATH - escape the colons somehow? If there is some escape mechanism, we could support it, both as an internal way to fix the present issue, and directly in parsing PYTHONPATH. If there is no such mechanism, then I can only conclude that having colons in paths will make many other things unhappy, not just Python. -- Comment By: Martin v. Löwis (loewis) Date: 2006-06-24 10:35 Message: Logged In: YES user_id=21627 I think this can be fixed. sys.prefix should be treated as unspittable when constructing sys.path, i.e. sys.prefix should be inserted only after the colon-splitting has been done. Not sure what the best way to implement that would be, though, so unassigning. -- Comment By: Georg Brandl (gbrandl) Date: 2006-06-22 19:08 Message: Logged In: YES user_id=849994 I don't know if something can be done here. A possibility would be, if one path segment doesn't exist, add the colon and the next segment and try again. Martin, do you have an opinion? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1507224&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1507224 ] sys.path issue if sys.prefix contains a colon
Bugs item #1507224, was opened at 2006-06-16 13:22 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1507224&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Nobody/Anonymous (nobody) Summary: sys.path issue if sys.prefix contains a colon Initial Comment: If you install python in a directory whose path contains a colon sys.path will be wrong, the installation directory will be split into two strings and both of them are added to sys.path. The following session demonstrates the problem: bump:~/src/python/:colon bob$ ./python.exe -c "import sys; print sys.path" 'import site' failed; use -v for traceback ['', '/usr/local/lib/python25.zip', '/Users/bob/src/python/', 'colon/../ Lib/', '/Users/bob/src/python/', 'colon/../Lib/plat-darwin', '/Users/bob/ src/python/', 'colon/../Lib/plat-mac', '/Users/bob/src/python/', 'colon/../ Lib/plat-mac/lib-scriptpackages', '/Users/bob/src/python/', 'colon/../ Lib/lib-tk', '/Users/bob/src/python/', 'colon/Modules'] -- >Comment By: Martin v. Löwis (loewis) Date: 2006-06-25 12:16 Message: Logged In: YES user_id=21627 The issue is not with environment variables at all; they play no role in this bug report. There is no convention for an escape mechanism in environment variables, and we should not introduce one, but again, this report is not about environment variables. -- Comment By: Armin Rigo (arigo) Date: 2006-06-25 12:04 Message: Logged In: YES user_id=4771 Internally, CPython sets up its path using a single ':'-separated string. I have no clue how, on Posix, you are supposed to use paths containing ':' in environment variables like $PATH - escape the colons somehow? If there is some escape mechanism, we could support it, both as an internal way to fix the present issue, and directly in parsing PYTHONPATH. If there is no such mechanism, then I can only conclude that having colons in paths will make many other things unhappy, not just Python. -- Comment By: Martin v. Löwis (loewis) Date: 2006-06-24 12:35 Message: Logged In: YES user_id=21627 I think this can be fixed. sys.prefix should be treated as unspittable when constructing sys.path, i.e. sys.prefix should be inserted only after the colon-splitting has been done. Not sure what the best way to implement that would be, though, so unassigning. -- Comment By: Georg Brandl (gbrandl) Date: 2006-06-22 21:08 Message: Logged In: YES user_id=849994 I don't know if something can be done here. A possibility would be, if one path segment doesn't exist, add the colon and the next segment and try again. Martin, do you have an opinion? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1507224&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1512124 ] OSX: debugger hangs IDLE
Bugs item #1512124, was opened at 2006-06-25 06:45 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512124&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: Aahz (aahz) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: OSX: debugger hangs IDLE Initial Comment: This has been previously found on 2.3/2.4 and verified again with 2.5b1 (was hoping that the 1.2 IDLE update would fix): When you bring up the debugger window in IDLE on OSX, you'll notice that it's vibrating, as if it's stuck in a resize loop. Unless you immediately resize the window manually, IDLE will hang the next time you try to do something that updates the debugger window. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512124&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1512163 ] mailbox (2.5b1): locking doesn't work (esp. on FreeBSD)
Bugs item #1512163, was opened at 2006-06-25 16:38 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512163&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: David Watson (baikie) Assigned to: Nobody/Anonymous (nobody) Summary: mailbox (2.5b1): locking doesn't work (esp. on FreeBSD) Initial Comment: fcntl/flock() locking of mailboxes is actually disabled due to a typo: --- mailbox.py.orig +++ mailbox.py @@ -15,7 +15,7 @@ import rfc822 import StringIO try: -import fnctl +import fcntl except ImportError: fcntl = None However, once enabled, it doesn't work on FreeBSD - the lock() method always raises ExternalClashError (tested on 5.3). This is because flock(), lockf() and fcntl locking share the same underlying mechanism on this system (and probably others), and so the second lock can never be acquired. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512163&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1472251 ] pdb 'run' crashes when the it's first argument is non-string
Bugs item #1472251, was opened at 2006-04-18 05:16
Message generated for change (Comment added) made by isandler
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472251&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 3
Submitted By: Kuba KoÅczyk (jakamkon)
Assigned to: Nobody/Anonymous (nobody)
Summary: pdb 'run' crashes when the it's first argument is non-string
Initial Comment:
Pdb 'run/runeval' commands fails to check the type of
given argument.When argument to 'run/runeval' is
non-string the functions crashes with further
impilications on (correctly)invoking this functions:
Python 2.5a1 (trunk:45527, Apr 18 2006, 11:12:31)
>>> def x(): pass
>>> import pdb
>>> pdb.run(x())
Traceback (most recent call last):
File "", line 1, in
File "/home/jkk/python/python-svn/Lib/pdb.py", line
1113, in run
Pdb().run(statement, globals, locals)
File "/home/jkk/python/python-svn/Lib/bdb.py", line
363, in run
cmd = cmd+'\n'
TypeError: unsupported operand type(s) for +:
'NoneType' and 'str'
>>> pdb.run('x()')
> /home/jkk/python/python-svn/Lib/pdb.py(1113)run()
-> Pdb().run(statement, globals, locals)
(Pdb)
# CTRL-D pressed
Traceback (most recent call last):
File "", line 1, in
File "/home/jkk/python/python-svn/Lib/pdb.py", line
1113, in run
Pdb().run(statement, globals, locals)
File "/home/jkk/python/python-svn/Lib/pdb.py", line
1113, in run
Pdb().run(statement, globals, locals)
File "/home/jkk/python/python-svn/Lib/bdb.py", line
48, in trace_dispatch
return self.dispatch_line(frame)
File "/home/jkk/python/python-svn/Lib/bdb.py", line
67, in dispatch_line
if self.quitting: raise BdbQuit
bdb.BdbQuit
The solution is to simply ensure that the first
argument passed to the 'run/runeval' functions is string.
--
Comment By: Ilya Sandler (isandler)
Date: 2006-06-25 11:54
Message:
Logged In: YES
user_id=971153
I have looked at what's happening in a bit more detail and
now I agree that the current behaviour seems wrong.
Apparently, when one passes a nonstring to bdb's run(), bdb
sets tracing first and only then throws an exception...
Leaving tracing on seems like a bad thing to do
Would calling settrace() a couple lines later be the
simplest solution then?
so relevant fragment of bdb.py's run() becomes:
if not isinstance(cmd, types.CodeType):
cmd = cmd+'\n'
sys.settrace(self.trace_dispatch)
This should prevent bdb from turning tracing too early.
What do you think?
--
Comment By: Kuba KoÅczyk (jakamkon)
Date: 2006-06-19 06:48
Message:
Logged In: YES
user_id=1491175
You're right,but don't you think that this kind of switching
between namespaces could confuse users?
--
Comment By: Ilya Sandler (isandler)
Date: 2006-05-22 20:36
Message:
Logged In: YES
user_id=971153
Well, I don't see anything in bdb's run which could
overwrite your namespace..
What seems to be happenning in your example is that bdb's
first line event happens while bdb is still in run(), so you
when you see pdb's prompt, are in bdb's namespace not in
yours.. If you do "next" you will get where you should be..
bagira:~> python2.4
Python 2.4.1 (#2, May 5 2005, 11:32:06)
>>> def x(): print "in x"
>>> import pdb
>>> pdb.run( x())
in x
TypeError: unsupported operand type(s) for +: 'NoneType'
and 'str'
>>> pdb.run( 'x()' )
> /usr/lib/python2.4/pdb.py(987)run()
-> Pdb().run(statement, globals, locals)
(Pdb) n #now you are back in your namespace
> (1)?()
(Pdb) p x#and you get your symbols back
(Pdb) p pdb
(Pdb) n
in x
--Return--
> (1)?()->None
What do you think?
--
Comment By: Kuba KoÅczyk (jakamkon)
Date: 2006-05-22 02:20
Message:
Logged In: YES
user_id=1491175
The point is that when you want to invoke pdb.run correctly
(with string argument) after getting TypeError as in above
example,
your namespace is probably overwritten or deleted so that
you don't have access to previously defined symbols.
>>> def x():pass
>>> import pdb
>>> pdb.run(x())
TypeError
>>> pdb.run('x()')
> /home/jkk/python-svn/Lib/pdb.py(1122)run()
-> Pdb().run(statement, globals, locals)
(Pdb) pdb
*** NameError: name 'pdb' is not defined
(Pdb) x
*** NameError: name 'x' is not defined
--
Comment By: Ilya Sandler (isandler)
Date: 2006-05-21 16:25
Message:
Logged In: YES
user_id=971153
I would not classify your example as a crash. You passed a
wrong value (None in your ca
[ python-Bugs-1512163 ] mailbox (2.5b1): locking doesn't work (esp. on FreeBSD)
Bugs item #1512163, was opened at 2006-06-25 08:38 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512163&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: David Watson (baikie) >Assigned to: A.M. Kuchling (akuchling) Summary: mailbox (2.5b1): locking doesn't work (esp. on FreeBSD) Initial Comment: fcntl/flock() locking of mailboxes is actually disabled due to a typo: --- mailbox.py.orig +++ mailbox.py @@ -15,7 +15,7 @@ import rfc822 import StringIO try: -import fnctl +import fcntl except ImportError: fcntl = None However, once enabled, it doesn't work on FreeBSD - the lock() method always raises ExternalClashError (tested on 5.3). This is because flock(), lockf() and fcntl locking share the same underlying mechanism on this system (and probably others), and so the second lock can never be acquired. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-25 12:52 Message: Logged In: YES user_id=33168 Andrew, are you helping maintain this module? David is correct that fcntl is mispelled in current svn. Not sure what to do about the locking issue. David, would it be possible for you to work on a patch to correct this problem? I'm not sure if any developer has access to a FreeBSD box similar to yours. (There are a couple that use FreeBSD though.) It would be great to come up with tests for this if the current ones don't stress this situation. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512163&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1512124 ] OSX: debugger hangs IDLE
Bugs item #1512124, was opened at 2006-06-25 15:45 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512124&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: Python 2.5 Status: Open >Resolution: Accepted Priority: 7 Submitted By: Aahz (aahz) >Assigned to: Nobody/Anonymous (nobody) Summary: OSX: debugger hangs IDLE Initial Comment: This has been previously found on 2.3/2.4 and verified again with 2.5b1 (was hoping that the 1.2 IDLE update would fix): When you bring up the debugger window in IDLE on OSX, you'll notice that it's vibrating, as if it's stuck in a resize loop. Unless you immediately resize the window manually, IDLE will hang the next time you try to do something that updates the debugger window. -- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-06-25 22:49 Message: Logged In: YES user_id=580910 And when you do resize the window layout sucks, automatic layout seems to be buggy here (although I must admit that I haven't seen IDLE on other platforms). I have no idea what is causing this bug. Upgrading the Tk version to the very latest instead of using the system version doesn't help. I've checked in a workaround in revision 47091. That patch avoids explicitly sizing the stackviewer widget on OSX, which seems to fix this problem. The debugger window now is rather less wide than it was before, which means users will likely have to resize the window if they want to use the debugger. I'm leaving this bug open and unassign it in the hope that someone who actually knows Tkinter proposed a better fix. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512124&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1507224 ] sys.path issue if sys.prefix contains a colon
Bugs item #1507224, was opened at 2006-06-16 13:22 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1507224&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Nobody/Anonymous (nobody) Summary: sys.path issue if sys.prefix contains a colon Initial Comment: If you install python in a directory whose path contains a colon sys.path will be wrong, the installation directory will be split into two strings and both of them are added to sys.path. The following session demonstrates the problem: bump:~/src/python/:colon bob$ ./python.exe -c "import sys; print sys.path" 'import site' failed; use -v for traceback ['', '/usr/local/lib/python25.zip', '/Users/bob/src/python/', 'colon/../ Lib/', '/Users/bob/src/python/', 'colon/../Lib/plat-darwin', '/Users/bob/ src/python/', 'colon/../Lib/plat-mac', '/Users/bob/src/python/', 'colon/../ Lib/plat-mac/lib-scriptpackages', '/Users/bob/src/python/', 'colon/../ Lib/lib-tk', '/Users/bob/src/python/', 'colon/Modules'] -- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-06-25 23:07 Message: Logged In: YES user_id=580910 One way to fix this to redefine Py_GetPath to return some kind of array instead string that is formatted like PYTHONPATH. Another option is returning a string where path elements are seperated by NUL bytes (with two NUL bytes at the end to make it possible to find the end of the path). A problem with this is that this would make it impossible to have empty strings in your PYTHONPATH (such as 'somedir::otherdir'). Both options have the disadvantage that they change a public interface (embedders can reimplement Py_GetPath to get full control over the construction of sys.path). BTW. This bug was found by a user of py2app, a py2exe-like tool for macosx. A user of his application complained that the application didn't run when it was stored in a directory with colons in its name. -- Comment By: Martin v. Löwis (loewis) Date: 2006-06-25 12:16 Message: Logged In: YES user_id=21627 The issue is not with environment variables at all; they play no role in this bug report. There is no convention for an escape mechanism in environment variables, and we should not introduce one, but again, this report is not about environment variables. -- Comment By: Armin Rigo (arigo) Date: 2006-06-25 12:04 Message: Logged In: YES user_id=4771 Internally, CPython sets up its path using a single ':'-separated string. I have no clue how, on Posix, you are supposed to use paths containing ':' in environment variables like $PATH - escape the colons somehow? If there is some escape mechanism, we could support it, both as an internal way to fix the present issue, and directly in parsing PYTHONPATH. If there is no such mechanism, then I can only conclude that having colons in paths will make many other things unhappy, not just Python. -- Comment By: Martin v. Löwis (loewis) Date: 2006-06-24 12:35 Message: Logged In: YES user_id=21627 I think this can be fixed. sys.prefix should be treated as unspittable when constructing sys.path, i.e. sys.prefix should be inserted only after the colon-splitting has been done. Not sure what the best way to implement that would be, though, so unassigning. -- Comment By: Georg Brandl (gbrandl) Date: 2006-06-22 21:08 Message: Logged In: YES user_id=849994 I don't know if something can be done here. A possibility would be, if one path segment doesn't exist, add the colon and the next segment and try again. Martin, do you have an opinion? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1507224&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1508369 ] logging module formatter problem with %(filename)s
Bugs item #1508369, was opened at 2006-06-19 04:08 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508369&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: Python 2.4 Status: Open >Resolution: Fixed Priority: 5 Submitted By: David Hess (david_k_hess) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: logging module formatter problem with %(filename)s Initial Comment: With Python 2.4.3 installed via the .dmg on to MacOS, when the python modules are compiled, they are compiled by specifying the path in such a way that it contains a double slash. This causes the logging module to not be able to figure out which module is the correct one to replace for % (filename)s. The following is the crux of the issue: >>> logging.debug.func_code.co_filename '/Library/Frameworks/Python.framework/Versions/2.4//lib/python2.4/ logging/__init__.py' >>> logging.__file__ '/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/ logging/__init__.pyc' >>> These two strings need to match for %(filename)s to work. I deleted /Library/Frameworks/Python.framework/Versions/2.4/lib/ python2.4/logging/__init__.pyc and recompiled it by just importing logging. That fixed the problem. I assume the fix will be in the installer somewhere. -- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-06-25 23:16 Message: Logged In: YES user_id=580910 Fixed in revision #47093 for python2.5. I'm not closing the bug yet because I haven't backported this to 2.4 yet. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508369&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-995019 ] Ensure -single_module on Mac OS X
Bugs item #995019, was opened at 2004-07-21 08:19 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995019&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bill Bumgarner (bbum) Assigned to: Jack Jansen (jackjansen) Summary: Ensure -single_module on Mac OS X Initial Comment: When building Python (and disutils based extensions) on Mac OS X, Python should ensure that the -single_module flag is being passed to the linker. This will ensure that any given .so, .dylib, or framework is linked as a single module. This will vastly reduce the startup times of python, reduce the load times of modules, and shave a bit of a performance hit off the top at runtime. This should also be applicable to the modules built by distutils. -- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-06-25 23:23 Message: Logged In: YES user_id=580910 Is this still relevant? -- Comment By: Jack Jansen (jackjansen) Date: 2004-07-22 23:09 Message: Logged In: YES user_id=45365 Am I doing something wrong? I see absolutely no difference in runtime with this option: I get 0.15 seconds realtime (0.08 user time, system time variable) both with the new OTHER_LIBTOOL_OPT and without it. (This is on a 933Mhz G4 iBook running 10.3.4). I've been trying this with 2.4a1+. What sort of speedups are you guys seeing? -- Comment By: Bob Ippolito (etrepum) Date: 2004-07-21 11:50 Message: Logged In: YES user_id=139309 time python -c pass is probably sufficient.. I guess the patch is to line 114 of Makefile.pre.in.. should change from: OTHER_LIBTOOL_OPT = -prebind -seg1addr 0x1000 to OTHER_LIBTOOL_OPT = -prebind -seg1addr 0xCFC0 -single_module Note I picked an arbitrary, probably unused, seg1addr. 0x1000 is *NOT* correct! It's in the Application Address Range See: http://developer.apple.com/documentation/Performance/Conceptual/ LaunchTime/index.html -- Comment By: Jack Jansen (jackjansen) Date: 2004-07-21 11:21 Message: Logged In: YES user_id=45365 Could either of you come up with a patch? Also, how would I measure any improvement, "time python -c pass" or are there other things that are influenced as well? -- Comment By: Bob Ippolito (etrepum) Date: 2004-07-21 10:25 Message: Logged In: YES user_id=139309 Not in the least. -- Comment By: Sjoerd Mullender (sjoerd) Date: 2004-07-21 08:57 Message: Logged In: YES user_id=43607 Is this related to bug 799088? -- Comment By: Bill Bumgarner (bbum) Date: 2004-07-21 08:35 Message: Logged In: YES user_id=103811 This is not applicable to the distutils modules as they are built now; only applicable to Python.framework (and like builds). -- Comment By: Bob Ippolito (etrepum) Date: 2004-07-21 08:29 Message: Logged In: YES user_id=139309 [I'm closing 995023, because bbum filed first] distutils extensions can not use -single_module because they are bundles, not dylibs. Frameworks and dylibs are synonymous, of course. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995019&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-922690 ] package manager page outdated link
Bugs item #922690, was opened at 2004-03-24 21:07 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=922690&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Jack Jansen (jackjansen) Summary: package manager page outdated link Initial Comment: The page http://www.python.org/packman/ has outdated links to Bob Ippolito's page. The correct link appears to be http://undefined.org/python/ (which includes links to various versions of the packages and to descriptions of the same). -- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-06-25 23:24 Message: Logged In: YES user_id=580910 Closing this bug, Package Manager is no longer maintained and was removed from the python repository before 2.5b1. -- Comment By: Georg Brandl (birkenfeld) Date: 2005-12-27 00:52 Message: Logged In: YES user_id=1188172 This is still a problem. The packman page needs update, as it seems. -- Comment By: Terry J. Reedy (tjreedy) Date: 2004-03-30 18:57 Message: Logged In: YES user_id=593130 To supplement the summary: the two links (xml and html) on the bottom of the packman page work but they are specific to (an older? verseion) the pimp package. The higher link suggested as a substitue lists other packages, including some that appear to have been extracted from pimp. Since the current page references aeve 0.0.3 while the suggested link references aeve 0.0.4, the suggest change seems proper. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=922690&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1087737 ] Mac: make frameworkinstall skips docs, scripts
Bugs item #1087737, was opened at 2004-12-19 01:09 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1087737&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: Mac: make frameworkinstall skips docs, scripts Initial Comment: "make frameworkinstall" for a framework build of Python installs a symlink to the interpreter in /usr/local, but it doesn't do the same for the man page, scripts and maybe other auxiliary files. Either it needs to install these, or it needs to be documented that they aren't installed, preferably with an option to install them with an extra make. -- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-06-25 23:27 Message: Logged In: YES user_id=580910 Current wisdom seems to be that it's better to add the directories inside the framework to relevant paths (PATH and MANPATH) instead of adding symlinks in /usr/local. The binary installer will install a symlink to the embedded documentation in / Developer/Documentation. IMHO this can be closed. BTW. 'make frameworkinstall' is deprecated as well, just use 'make install'. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1087737&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-887242 ] "-framework Python" for building modules is bad
Bugs item #887242, was opened at 2004-01-29 21:40 Message generated for change (Settings changed) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=887242&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: Platform-specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Jack Jansen (jackjansen) Summary: "-framework Python" for building modules is bad Initial Comment: We should use the -bundle_loader method for linking modules for both the framework and non-framework verisons of Python. All of these "version mismatch" errors would pretty much be avoided if this were the case, since a 10.2 and 10.3 MacPython 2.3 should be binary compatible. There are other reasons to use -bundle_loader, such as using the same suite of modules for both Stackless and regular Python. Besides, -bundle_loader is for building -bundles :) It's a simple change to the configure script, and it would be great if this could happen before OS X 10.4. -- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-06-25 23:28 Message: Logged In: YES user_id=580910 This was fixed a long time ago, the fix is present in 2.4. Hence closing this as fixed. -- Comment By: Jack Jansen (jackjansen) Date: 2004-06-03 14:42 Message: Logged In: YES user_id=45365 I checked in the mods I mentioned in my previous followup: configure.in rev. 1.455 configure rev. 1.444 Makefile.pre.in rev. 1.143 Lib/distutils/sysconfig.py rev.1.58 -- Comment By: Jack Jansen (jackjansen) Date: 2004-06-02 23:37 Message: Logged In: YES user_id=45365 I'm finally getting around to revisiting this bug, and I ran into another problem (that we've already discussed offline, but I'm adding it here for posterity): -undefined dynamic_lookup only works if you have MACOSX_DEPLOYMENT_TARGET set, and set to >= "10.2". I'm now experimenting with the following: if you have that variable set during configure time it will use dynamic_lookup. Moreover, it will record the value of MACOSX_DEPLOYMENT_TARGET in the Makefile. Distutils will check that the current value of MACOSX_DEPLOYMENT_TARGET is the same as that during configure time, and complain if not. I've resisted the temptation to force MACOSX_DEPLOYMENT_TARGET to the configure-time value in distutils, because I think we may break things that way. Feel free to convince me otherwise:-) I'm only doing this for 2.4 right now, as a straight backport to 2.3 is useless: the Makefile is already supplied by Apple. So, any fix for 2.3.X will need to be a band-aid in distutils (possibly triggered by an environment variable?). -- Comment By: Bob Ippolito (etrepum) Date: 2004-04-02 10:34 Message: Logged In: YES user_id=139309 minimal patch for Python 2.4 CVS configure.in (and configure) attached. -- Comment By: Bob Ippolito (etrepum) Date: 2004-01-30 00:21 Message: Logged In: YES user_id=139309 -undefined dynamic_lookup has a localized effect, it still uses two level namespaces and doesn't force the whole process to go flat. Apple uses this flag for Perl in 10.3 (maybe other things, like Apache), so presumably they designed it with situations like ours in mind. -- Comment By: Jack Jansen (jackjansen) Date: 2004-01-30 00:11 Message: Logged In: YES user_id=45365 Ok, I only tried -bundle_loader Python.framework, and when that didn't work I stopped trying. But I have some misgivings about the -undefined dynamic_lookup: doesn't this open up the whole flat namespace/undefined suppress can of worms that we had under 10.1? What we *really* want is to a way to tell the linker "at runtime, the host program must already have loaded a Python.framework, any Python.framework, and that is what we want to link against". -- Comment By: Bob Ippolito (etrepum) Date: 2004-01-30 00:05 Message: Logged In: YES user_id=139309 That's not true. -bundle_loader does not generate a mach header load command, it is merely so that ld can make sure that all of your symbols are defined at link time (it will work for an embedded Python, try it). You do need -undefined dynamic_lookup though, because -bundle_loader doesn't respect indirect symbols. I'm not sure it's possible to make Python.framework get "imported" into the executable so that it's possible to -bundle_loader w
[ python-Bugs-838144 ] PackageManager does not clean up after itself
Bugs item #838144, was opened at 2003-11-07 21:47 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=838144&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: Python 2.3 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Jack Jansen (jackjansen) Summary: PackageManager does not clean up after itself Initial Comment: This was discussed on-list, but PackageManager downloads files to /tmp, but never removes them. Documentation should at least mention this, perhaps also on the MacPython page. I will add this information to the pythonmac.org wiki as well. -- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-06-25 23:29 Message: Logged In: YES user_id=580910 Closed as 'won't fix' because PackageManager is no longer maintained and was dropped from the 2.5 tree. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=838144&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-779154 ] PackageManager maintainer missing documentation
Bugs item #779154, was opened at 2003-07-28 22:48 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779154&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: Python 2.3 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Jack Jansen (jackjansen) Summary: PackageManager maintainer missing documentation Initial Comment: I was unable to locate maintainer documentation on the schema of the PackageManager database ( http:// python.org/packman/version-0.3/darwin-6.6- Power_Macintosh.plist ). I was also unable to locate documentation for how a maintainer would build one of these databases (particularly for binary packages). However, I was able to reverse engineer it by looking at the Package Manager/PIMP sourcecode, and I've prototyped an example script for building a binary package and spitting out a template for its entry in the plist. It's attached. -- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-06-25 23:30 Message: Logged In: YES user_id=580910 Closed as "Won't Fix" because PackageManager was dropped in 2.5. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779154&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-758566 ] IDE preferences cleanup
Bugs item #758566, was opened at 2003-06-22 00:17 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=758566&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: IDE preferences cleanup Initial Comment: The IDE preferences need to go under the Application- >Preferences menu. I think the only reasonable way to do this without changing too much code is that that menu entry opens a window that shows the current settings, with buttons that open the windows that are used in the current implementation. The funny font selector for the GUI elements also needs to be named better. -- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-06-25 23:32 Message: Logged In: YES user_id=580910 Closed as "Won't Fix" because the Python IDE was dropped before 2.5b1. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=758566&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-778799 ] scripts destination directory not on default path
Bugs item #778799, was opened at 2003-07-28 10:36 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778799&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Jack Jansen (jackjansen) Summary: scripts destination directory not on default path Initial Comment: A distutils script that uses the 'scripts' directive will install the scripts in /Library/Frameworks/Versions/2.3/bin This directory is not on the path, and no documentation explains how to *put* it on the path. The end result is that 3rd party python libraries that install command line utilities don't work out of the box. If we need to have scripts and stuff dual homed in /Library/Frameworks/Versions/2.3/bin and /usr/local/bin, distutils will need to be patched to maintain the symlinks (although I personally feel putting anything in /usr/local/bin is a bad idea...). This of course will not be possible for the 2.3.0 release. -- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-06-25 23:36 Message: Logged In: YES user_id=580910 Current wisdom is that its better to add the directories inside the framework to your PATH. The binary installers for 2.4.3 and 2.5b1 do this for you (even if the solution used isn't ideal). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778799&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
