[ python-Bugs-532646 ] Recursive class instance "error"
Bugs item #532646, was opened at 2002-03-20 13:56
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=532646&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.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregor Mirai (gregmi)
>Assigned to: Brett Cannon (bcannon)
Summary: Recursive class instance "error"
Initial Comment:
If one writes the following code (tested on Python
2.1, 2.2 on platforms MacOS X Server, MacOS X, Windows
98, NT, 2000) one can easily produce several "errors".
MacOS X, MacOS X Server (Python 2.1, 2.2)
--
class A:
def __getattr__(self, name):
print name,
return A()
--
>>> a=A()
>>> a.foo
Segmentation fault
Win98, NT, 2000 (Python 2.1, 2.2)
--
class A:
def __getattr__(self, name):
print name
return A()
--
>>> a=A()
>>> a.foo
foo
__repr__ __call__ __call__ __call__ ... ad inf
--
>Comment By: Guido van Rossum (gvanrossum)
Date: 2006-04-18 04:09
Message:
Logged In: YES
user_id=6380
Ironically, I just found the same (?) crash in the p3yk
branch, in test_class.py (which is now testing new-style
classes for compatibility with the behavior of classic classes).
I can't fix this myself, so assigning to Brett.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-18 00:37
Message:
Logged In: YES
user_id=33168
Please add a test case to Lib/test/crashers.
--
Comment By: Brett Cannon (bcannon)
Date: 2006-04-17 20:00
Message:
Logged In: YES
user_id=357491
This was not fixed for new-style classes and still segfaults
the interpreter at least back to 2.4.
Reopening.
--
Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-13 17:50
Message:
Logged In: YES
user_id=6380
It was very specific to __call__ after all, and I found an
example that didn't involve __getattr__. See the comments I
checked in as part of the fix in classobject.c.
--
Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-13 16:41
Message:
Logged In: YES
user_id=6380
Hm. I'm tracing this in the debugger now, and it appears
that the problem is when trying to *print* an A instance.
The statement a.foo causes the problem simply because it
returns an A instance. (Proof: "a=A().foo; print a" fails in
the print.)
I think that instance_call may not be the real cause of the
problem...
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-12 18:38
Message:
Logged In: YES
user_id=33168
The problem is that there is mutual recursion
between instance_call() and PyObject_Call().
The recursion apparently goes through the eval_frame() loop.
This patch increases the recursion depth so the mutual recursion
will eventually end (otherwise, the stack grows without bounds).
ISTM the first check SHOULD be reached, but it is not.
I don't understand why. The recursion error must be set
in eval_frame().
The first block in the patch could be just this line:
++tstate->recursion_depth;
I didn't do it that way, since I didn't expect returning to
eval_frame(). I'm not sure if it's guaranteed to return
to eval_frame() which is why I left the first condition
in with the comment. I suppose the comment should say
something like: /* this condition doesn't seem to be triggered,
the recursion depth limit is exceeded in eval_frame */
The test for recursion_depth is necessary to ensure
that the recursion error isn't overwritten. If this check
is removed, the follow exception is raised:
AttributeError: A instance has no __call__ method
Hopefully this makes sense.
--
Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-10 12:08
Message:
Logged In: YES
user_id=6380
Can you explain how the fix works? Why does the first
comment say
/* this shouldn't be reached, but just in case */
and why is this test necesary
if (tstate->recursion_depth < Py_GetRecursionLimit()) {
???
And who *does* report the recursion error?
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-07 18:52
Message:
Logged In: YES
user_id=33168
The recursion fields are shared in the new patch.
-
[ python-Bugs-1472173 ] interactive: no cursors ctrl-a/e... in 2.5a1/linux/debian
Bugs item #1472173, was opened at 2006-04-18 11:20 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=1472173&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: Installation Group: None Status: Open Resolution: None Priority: 5 Submitted By: kxroberto (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: interactive: no cursors ctrl-a/e... in 2.5a1/linux/debian Initial Comment: cursors , ctrl-a ctrl-e ... not recognized? worked with previous pythons vs:/usr/src/Python-2.5a1# make altinstall ... vs:/usr/src/Python-2.5a1# python2.5 Python 2.5a1 (r25a1:43589, Apr 15 2006, 21:51:42) [GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> abcd^E^A^[[1~^[[4~ -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472173&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1472176 ] "idna" encoding (drawing unicodedata) necessary in httplib?
Feature Requests item #1472176, was opened at 2006-04-18 11:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1472176&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: None Status: Open Resolution: None Priority: 5 Submitted By: kxroberto (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: "idna" encoding (drawing unicodedata) necessary in httplib? Initial Comment: httplib employs the "idna" encoding. that leads to errors in py2exe/cxfreeze. And if forced into the installer, it draws the 400kB+ unicodedata.pyd (on Win) in innocent small apps. Otherwise no normal technical modules draw the unicodedata. Is that really necessary? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1472176&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1472173 ] interactive: no cursors ctrl-a/e... in 2.5a1/linux/debian
Bugs item #1472173, was opened at 2006-04-18 10:20 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472173&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: Installation Group: None Status: Open Resolution: None Priority: 5 Submitted By: kxroberto (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: interactive: no cursors ctrl-a/e... in 2.5a1/linux/debian Initial Comment: cursors , ctrl-a ctrl-e ... not recognized? worked with previous pythons vs:/usr/src/Python-2.5a1# make altinstall ... vs:/usr/src/Python-2.5a1# python2.5 Python 2.5a1 (r25a1:43589, Apr 15 2006, 21:51:42) [GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> abcd^E^A^[[1~^[[4~ -- >Comment By: Michael Hudson (mwh) Date: 2006-04-18 10:32 Message: Logged In: YES user_id=6656 You might need to install readline-devel or some such package. I don't think anything has changed in python here... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472173&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1472191 ] pdb 'clear' command doesn't clear selected bp's
Bugs item #1472191, was opened at 2006-04-18 09:49 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=1472191&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: Kuba KoÅczyk (jakamkon) Assigned to: Nobody/Anonymous (nobody) Summary: pdb 'clear' command doesn't clear selected bp's Initial Comment: Pdb 'clear x' command doesn't clear selected breakpoints that are already set: $ ./python -m pdb ../test.py > /home/xyz/python/test.py(3)() -> def t(x): (Pdb) break 5 Breakpoint 1 at /home/xyz/python/test.py:5 (Pdb) break Num Type Disp Enb Where 1 breakpoint keep yes at /home/xyz/python/test.py:5 (Pdb) clear 1 No breakpoint numbered 1 (Pdb) ... for i in numberlist: * if not (0 <= i < len(bdb.Breakpoint.bpbynumber)): print 'No breakpoint numbered', i ... Each i is a string and it's compared to 0 and len(...), so condition * is always True. The fix is trivial: * if not (0 <= int(i) < len(bdb.Breakpoint.bpbynumber)): Fix is in #1472184 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472191&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1472191 ] pdb 'clear' command doesn't clear selected bp's
Bugs item #1472191, was opened at 2006-04-18 09:49 Message generated for change (Settings changed) made by jakamkon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472191&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: 6 Submitted By: Kuba KoÅczyk (jakamkon) Assigned to: Nobody/Anonymous (nobody) Summary: pdb 'clear' command doesn't clear selected bp's Initial Comment: Pdb 'clear x' command doesn't clear selected breakpoints that are already set: $ ./python -m pdb ../test.py > /home/xyz/python/test.py(3)() -> def t(x): (Pdb) break 5 Breakpoint 1 at /home/xyz/python/test.py:5 (Pdb) break Num Type Disp Enb Where 1 breakpoint keep yes at /home/xyz/python/test.py:5 (Pdb) clear 1 No breakpoint numbered 1 (Pdb) ... for i in numberlist: * if not (0 <= i < len(bdb.Breakpoint.bpbynumber)): print 'No breakpoint numbered', i ... Each i is a string and it's compared to 0 and len(...), so condition * is always True. The fix is trivial: * if not (0 <= int(i) < len(bdb.Breakpoint.bpbynumber)): Fix is in #1472184 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472191&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1472176 ] "idna" encoding (drawing unicodedata) necessary in httplib?
Feature Requests item #1472176, was opened at 2006-04-18 11:28
Message generated for change (Comment added) made by lemburg
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1472176&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: kxroberto (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: "idna" encoding (drawing unicodedata) necessary in httplib?
Initial Comment:
httplib employs the "idna" encoding. that leads to
errors in py2exe/cxfreeze. And if forced into the
installer, it draws the 400kB+ unicodedata.pyd (on Win)
in innocent small apps. Otherwise no normal technical
modules draw the unicodedata.
Is that really necessary?
--
>Comment By: M.-A. Lemburg (lemburg)
Date: 2006-04-18 11:59
Message:
Logged In: YES
user_id=38388
I agree - in most cases, ASCII will be used for hostnames
(where the idna encoding is being used in httplib).
A little helper function to first try .encode('ascii') and
then revert to .encode('idna') would do wonders.
Patches are welcome !
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1472176&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 12:16
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=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: 5
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.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472251&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 12:16
Message generated for change (Settings changed) made by jakamkon
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: 6
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.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472251&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 12:16
Message generated for change (Comment added) made by jakamkon
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: 6
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: Kuba KoÅczyk (jakamkon)
Date: 2006-04-18 12:36
Message:
Logged In: YES
user_id=1491175
Patch is in #1472257
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472251&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1471423 ] reload(ctypes) leaks references
Bugs item #1471423, was opened at 2006-04-16 22:21 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471423&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Thomas Heller (theller) Summary: reload(ctypes) leaks references Initial Comment: Found by Neal Norwitz, reload(ctypes) leaks references: >>> reload(ctypes); gc.collect(); gc.collect(); gc.collect() 128 13 0 [34251 refs] >>> reload(ctypes); gc.collect(); gc.collect(); gc.collect() 128 13 0 [34786 refs] >>> reload(ctypes); gc.collect(); gc.collect(); gc.collect() 128 13 0 [35321 refs] >>> -- >Comment By: Thomas Heller (theller) Date: 2006-04-18 17:02 Message: Logged In: YES user_id=11105 Fixed in rev. 45535. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471423&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1471423 ] reload(ctypes) leaks references
Bugs item #1471423, was opened at 2006-04-16 22:21 Message generated for change (Settings changed) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471423&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Thomas Heller (theller) Summary: reload(ctypes) leaks references Initial Comment: Found by Neal Norwitz, reload(ctypes) leaks references: >>> reload(ctypes); gc.collect(); gc.collect(); gc.collect() 128 13 0 [34251 refs] >>> reload(ctypes); gc.collect(); gc.collect(); gc.collect() 128 13 0 [34786 refs] >>> reload(ctypes); gc.collect(); gc.collect(); gc.collect() 128 13 0 [35321 refs] >>> -- Comment By: Thomas Heller (theller) Date: 2006-04-18 17:02 Message: Logged In: YES user_id=11105 Fixed in rev. 45535. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471423&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1465834 ] bdist_wininst preinstall script support is broken in 2.5a1
Bugs item #1465834, was opened at 2006-04-06 18:40 Message generated for change (Settings changed) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465834&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Paul Moore (pmoore) Assigned to: Thomas Heller (theller) Summary: bdist_wininst preinstall script support is broken in 2.5a1 Initial Comment: The attached zip file contains a trivial module. Run "run_setup.bat" to create a bdist_wininst installer (you'll need to edit it to make the preinstall script path match where you unzipped the file). The resulting installer fails with an error "Running the pre-installation script failed". -- Comment By: Paul Moore (pmoore) Date: 2006-04-16 16:18 Message: Logged In: YES user_id=113328 Thomas, As I've just got my own build environment set up with the free MS compiler, I thought I'd show off and build my own copy :-) I can confirm that with the patch, the pywin32 installer also works (the one real-life case of a preinstall script that I know). Also, this patch fixes another funny issue I'd not quite managed to isolate - installers were failing to compile .py files (and conversely, the uninstaller was leaving .pyc files behind). Paul. -- Comment By: Thomas Heller (theller) Date: 2006-04-12 22:12 Message: Logged In: YES user_id=11105 Attached a patch which should fix this issue. Paul, if you want do further tests *now* I can upload a python25.dll, compiled from current SVN + patch, somewhere. Hopefully this will be compatible with a 2.5a1 installation. -- Comment By: Thomas Heller (theller) Date: 2006-04-11 19:19 Message: Logged In: YES user_id=11105 These apis are now macros, they were exported functions in Python 2.4: PyParser_SimpleParseFile PyParser_SimpleParseString PyRun_AnyFile PyRun_AnyFileEx PyRun_AnyFileFlags PyRun_File PyRun_FileEx PyRun_FileFlags PyRun_InteractiveLoop PyRun_InteractiveOne PyRun_SimpleFile PyRun_SimpleFileEx PyRun_SimpleString PyRun_String Py_CompileString All of them, to be safe, should probably exposed as exported functions again. See also this thread on python-dev: http://mail.python.org/pipermail/python-dev/2006-January/059374.html Raising the priority to 7 because this must be fixed before release. -- Comment By: Paul Moore (pmoore) Date: 2006-04-06 22:01 Message: Logged In: YES user_id=113328 Seems to be limited to installers with preinstall scripts, as far as I can tell. The main example is pywin32, which is irritatingly significant :-) (One oddness I couldn't check is that scripts don't seem to get compiled any more - don't know if this is related to the same issue. It's not a big deal either way, though). The fix sounds reasonable. -- Comment By: Thomas Heller (theller) Date: 2006-04-06 20:22 Message: Logged In: YES user_id=11105 bdist_wininst7.1.exe uses runtime dynamic linking to the python dll. Python25.dll doesn't export a PyRun_SimpleString function anymore, it has been replaced by a macro: #define PyRun_SimpleString(s) PyRun_SimpleStringFlags(s, NULL) bdist_wininst *could* be changed to use PyRun_SimpleStringFlags instead, however, installers built with previous versions of Python will then refuse to install pure distributions to Python 2.5. I have not checked if installers that do *not* have a pre-install script will work or not. I suggest to make PyRun_SimpleString an exported function again - this should be cheap. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465834&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-532646 ] Recursive class instance "error"
Bugs item #532646, was opened at 2002-03-20 10:56
Message generated for change (Comment added) made by bcannon
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=532646&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.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregor Mirai (gregmi)
Assigned to: Brett Cannon (bcannon)
Summary: Recursive class instance "error"
Initial Comment:
If one writes the following code (tested on Python
2.1, 2.2 on platforms MacOS X Server, MacOS X, Windows
98, NT, 2000) one can easily produce several "errors".
MacOS X, MacOS X Server (Python 2.1, 2.2)
--
class A:
def __getattr__(self, name):
print name,
return A()
--
>>> a=A()
>>> a.foo
Segmentation fault
Win98, NT, 2000 (Python 2.1, 2.2)
--
class A:
def __getattr__(self, name):
print name
return A()
--
>>> a=A()
>>> a.foo
foo
__repr__ __call__ __call__ __call__ ... ad inf
--
>Comment By: Brett Cannon (bcannon)
Date: 2006-04-18 12:08
Message:
Logged In: YES
user_id=357491
The test is already in crashers: infinite_rec_3 . And it is
the same crash as in py3k; that's how I found it.
--
Comment By: Guido van Rossum (gvanrossum)
Date: 2006-04-18 01:09
Message:
Logged In: YES
user_id=6380
Ironically, I just found the same (?) crash in the p3yk
branch, in test_class.py (which is now testing new-style
classes for compatibility with the behavior of classic classes).
I can't fix this myself, so assigning to Brett.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-17 21:37
Message:
Logged In: YES
user_id=33168
Please add a test case to Lib/test/crashers.
--
Comment By: Brett Cannon (bcannon)
Date: 2006-04-17 17:00
Message:
Logged In: YES
user_id=357491
This was not fixed for new-style classes and still segfaults
the interpreter at least back to 2.4.
Reopening.
--
Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-13 14:50
Message:
Logged In: YES
user_id=6380
It was very specific to __call__ after all, and I found an
example that didn't involve __getattr__. See the comments I
checked in as part of the fix in classobject.c.
--
Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-13 13:41
Message:
Logged In: YES
user_id=6380
Hm. I'm tracing this in the debugger now, and it appears
that the problem is when trying to *print* an A instance.
The statement a.foo causes the problem simply because it
returns an A instance. (Proof: "a=A().foo; print a" fails in
the print.)
I think that instance_call may not be the real cause of the
problem...
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-12 15:38
Message:
Logged In: YES
user_id=33168
The problem is that there is mutual recursion
between instance_call() and PyObject_Call().
The recursion apparently goes through the eval_frame() loop.
This patch increases the recursion depth so the mutual recursion
will eventually end (otherwise, the stack grows without bounds).
ISTM the first check SHOULD be reached, but it is not.
I don't understand why. The recursion error must be set
in eval_frame().
The first block in the patch could be just this line:
++tstate->recursion_depth;
I didn't do it that way, since I didn't expect returning to
eval_frame(). I'm not sure if it's guaranteed to return
to eval_frame() which is why I left the first condition
in with the comment. I suppose the comment should say
something like: /* this condition doesn't seem to be triggered,
the recursion depth limit is exceeded in eval_frame */
The test for recursion_depth is necessary to ensure
that the recursion error isn't overwritten. If this check
is removed, the follow exception is raised:
AttributeError: A instance has no __call__ method
Hopefully this makes sense.
--
Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-10 09:08
Message:
Logged In: YES
user_id=6380
Can you explain how the fix works? Why does the first
comment say
/* this shouldn't be reached, but just in case */
and why is this test necesary
if (tstate->recursion_depth < Py_GetRecursionLimit()) {
???
And who *does* report the re
[ python-Bugs-1465834 ] bdist_wininst preinstall script support is broken in 2.5a1
Bugs item #1465834, was opened at 2006-04-06 18:40 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465834&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Closed Resolution: Fixed Priority: 7 Submitted By: Paul Moore (pmoore) Assigned to: Thomas Heller (theller) Summary: bdist_wininst preinstall script support is broken in 2.5a1 Initial Comment: The attached zip file contains a trivial module. Run "run_setup.bat" to create a bdist_wininst installer (you'll need to edit it to make the preinstall script path match where you unzipped the file). The resulting installer fails with an error "Running the pre-installation script failed". -- >Comment By: Thomas Heller (theller) Date: 2006-04-18 21:48 Message: Logged In: YES user_id=11105 Compiling .py to .pyc/.pyo works the same way as the preinstall-script: By dynamically loading a pythonXY.dll and calling functions in it. The difference is that there's no error message when loading fails because of missing functions ;-). -- Comment By: Paul Moore (pmoore) Date: 2006-04-16 16:18 Message: Logged In: YES user_id=113328 Thomas, As I've just got my own build environment set up with the free MS compiler, I thought I'd show off and build my own copy :-) I can confirm that with the patch, the pywin32 installer also works (the one real-life case of a preinstall script that I know). Also, this patch fixes another funny issue I'd not quite managed to isolate - installers were failing to compile .py files (and conversely, the uninstaller was leaving .pyc files behind). Paul. -- Comment By: Thomas Heller (theller) Date: 2006-04-12 22:12 Message: Logged In: YES user_id=11105 Attached a patch which should fix this issue. Paul, if you want do further tests *now* I can upload a python25.dll, compiled from current SVN + patch, somewhere. Hopefully this will be compatible with a 2.5a1 installation. -- Comment By: Thomas Heller (theller) Date: 2006-04-11 19:19 Message: Logged In: YES user_id=11105 These apis are now macros, they were exported functions in Python 2.4: PyParser_SimpleParseFile PyParser_SimpleParseString PyRun_AnyFile PyRun_AnyFileEx PyRun_AnyFileFlags PyRun_File PyRun_FileEx PyRun_FileFlags PyRun_InteractiveLoop PyRun_InteractiveOne PyRun_SimpleFile PyRun_SimpleFileEx PyRun_SimpleString PyRun_String Py_CompileString All of them, to be safe, should probably exposed as exported functions again. See also this thread on python-dev: http://mail.python.org/pipermail/python-dev/2006-January/059374.html Raising the priority to 7 because this must be fixed before release. -- Comment By: Paul Moore (pmoore) Date: 2006-04-06 22:01 Message: Logged In: YES user_id=113328 Seems to be limited to installers with preinstall scripts, as far as I can tell. The main example is pywin32, which is irritatingly significant :-) (One oddness I couldn't check is that scripts don't seem to get compiled any more - don't know if this is related to the same issue. It's not a big deal either way, though). The fix sounds reasonable. -- Comment By: Thomas Heller (theller) Date: 2006-04-06 20:22 Message: Logged In: YES user_id=11105 bdist_wininst7.1.exe uses runtime dynamic linking to the python dll. Python25.dll doesn't export a PyRun_SimpleString function anymore, it has been replaced by a macro: #define PyRun_SimpleString(s) PyRun_SimpleStringFlags(s, NULL) bdist_wininst *could* be changed to use PyRun_SimpleStringFlags instead, however, installers built with previous versions of Python will then refuse to install pure distributions to Python 2.5. I have not checked if installers that do *not* have a pre-install script will work or not. I suggest to make PyRun_SimpleString an exported function again - this should be cheap. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465834&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1472566 ] import module with .dll extension
Bugs item #1472566, was opened at 2006-04-18 22:06
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=1472566&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: svenn (sven_nystrom)
Assigned to: Nobody/Anonymous (nobody)
Summary: import module with .dll extension
Initial Comment:
In previous versions, extension modules with the file
extension '.dll' could be imported using a
single 'import' statement.
In 2.5a1 this seems to have changed - here's an
example:
>>> import minx # Implemented in a .dll - fails
Traceback (most recent call last):
File "", line 1, in
ImportError: No module named minx
>>> import imp# Workaround
>>> import os
>>> minx = imp.load_dynamic('minx', os.getcwd()
+ '\\minx.dll')
I would really like this to remain the same; if that's
not possible, it would be helpful if the change itself
and a suggested approach were to be included in the
documentation.
/Sven
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472566&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1472695 ] 32/64bit pickled Random incompatiblity
Bugs item #1472695, was opened at 2006-04-19 01:10
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=1472695&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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Peter Maxwell (pm67nz)
Assigned to: Nobody/Anonymous (nobody)
Summary: 32/64bit pickled Random incompatiblity
Initial Comment:
The unsigned long integers which make up the state of a Random
instance are converted to Python integers via a cast to long in
_randommodule.c's random_getstate function, so on a 32bit platform
Random.getstate() returns a mix of postitive and negative integers, while
on a 64bit platform the negative numbers are replaced by larger positive
numbers, their 32bit-2s-complement equivalents.
As a result, unpicking a Random instance from a 64bit machine on a 32bit
platform produces the error "OverflowError: long int too large to convert
to int". Unpickling a 32bit Random on a 64bit machine succeeds, but the
resulting object is in a slightly confused state:
>>> r32 = cPickle.load(open('r32_3.pickle'))
>>> for i in range(3):
... print r64.random(), r32.random()
...
0.237964627092 4292886520.32
0.544229225296 0.544229225296
0.369955166548 4292886520.19
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472695&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1472710 ] Bug in threadmodule.c:local_traverse
Bugs item #1472710, was opened at 2006-04-18 22:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472710&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Bug in threadmodule.c:local_traverse Initial Comment: threadmodule.c's local_traverse function does not call Py_VISIT on self->key. Attached is a one-line patch against r45556 to add the call. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472710&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1472173 ] interactive: no cursors ctrl-a/e... in 2.5a1/linux/debian
Bugs item #1472173, was opened at 2006-04-18 02:20 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472173&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: Installation Group: None Status: Open Resolution: None Priority: 5 Submitted By: kxroberto (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: interactive: no cursors ctrl-a/e... in 2.5a1/linux/debian Initial Comment: cursors , ctrl-a ctrl-e ... not recognized? worked with previous pythons vs:/usr/src/Python-2.5a1# make altinstall ... vs:/usr/src/Python-2.5a1# python2.5 Python 2.5a1 (r25a1:43589, Apr 15 2006, 21:51:42) [GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> abcd^E^A^[[1~^[[4~ -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-18 21:16 Message: Logged In: YES user_id=33168 Hmmm, it's possible some of the configure magic changed. It might have been inadvertant. Can you attach your config.log? When you did a ./configure it should have printed out some things about readline and searching for it. That might help you diagnose the problem. -- Comment By: Michael Hudson (mwh) Date: 2006-04-18 02:32 Message: Logged In: YES user_id=6656 You might need to install readline-devel or some such package. I don't think anything has changed in python here... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472173&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1472710 ] Bug in threadmodule.c:local_traverse
Bugs item #1472710, was opened at 2006-04-18 22:34 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472710&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Bug in threadmodule.c:local_traverse Initial Comment: threadmodule.c's local_traverse function does not call Py_VISIT on self->key. Attached is a one-line patch against r45556 to add the call. -- >Comment By: Tim Peters (tim_one) Date: 2006-04-19 00:42 Message: Logged In: YES user_id=31435 It doesn't really matter: self->key is either NULL or a Python string object, and neither can be involved in a cycle, so for purposes of cyclic gc it's just a waste of time to pass the key to a visit() callback. The docs could be clearer about this. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472710&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
