[issue2539] Windows Registry issue with 2.5.2 AMD64 msi
Martin v. Löwis [EMAIL PROTECTED] added the comment: Do you perform a per-user or per-machine installation? When you look at the Python registry keys, which ones get written? -- nosy: +loewis __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2539 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2540] If HAVE_LONG_LONG is not defined, longval will not be initialized (_sqlite)
Martin v. Löwis [EMAIL PROTECTED] added the comment: Gerhard, what do you think? -- assignee: - ghaering nosy: +ghaering, loewis __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2540 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2540] If HAVE_LONG_LONG is not defined, longval will not be initialized (_sqlite)
Gerhard Häring [EMAIL PROTECTED] added the comment: My problem is that I can't really test (better than #undefining HAVE_LONG_LONG) this, because I have no platform to test on that doesn't have long longs. I'm not even sure SQLite *really* works when there is no 64-bit type. I'll ask on the SQLite mailing list. If that is so, then I'd like to get rid of the superfluous #ifdefs. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2540 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2542] PyErr_ExceptionMatches must not fail
New submission from Thomas Heller [EMAIL PROTECTED]: PyErr_ExceptionMatches must not fail, according to the docs. So an error code from PyObject_IsSubclass() cannot be returned. The attached patch calls PyErr_WriteUnraisable in this case, and returns an arbitrary value (0 was chosen in the patch). See also issue #2534. -- components: Interpreter Core files: errors.diff keywords: patch, patch messages: 64894 nosy: theller severity: normal status: open title: PyErr_ExceptionMatches must not fail type: crash versions: Python 2.6 Added file: http://bugs.python.org/file9931/errors.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2542 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2541] Unicode escape sequences not parsed in raw strings.
Benjamin Peterson [EMAIL PROTECTED] added the comment: You use the ur string mode. print ur\u0020 -- nosy: +benjamin.peterson resolution: - invalid status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2541 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2541] Unicode escape sequences not parsed in raw strings.
Benjamin Peterson [EMAIL PROTECTED] added the comment: Thanks for noticing, Amaury, and your patch works for me. -- priority: - critical __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2541 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2541] Unicode escape sequences not parsed in raw strings.
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment:
No, it's about python 3.0. I confirm the problem, and propose a patch:
--- Python/ast.c.original 2008-04-03 15:12:15.548389400 +0200
+++ Python/ast.c2008-04-03 15:12:28.359475800 +0200
@@ -3232,7 +3232,7 @@
return NULL;
}
}
-if (!*bytesmode !rawmode) {
+if (!*bytesmode) {
return decode_unicode(s, len, rawmode, encoding);
}
if (*bytesmode) {
--
nosy: +amaury.forgeotdarc
resolution: invalid -
status: closed - open
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2541
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2542] PyErr_ExceptionMatches must not fail
Daniel Diniz [EMAIL PROTECTED] added the comment: The tests pass and prints the ignores. But I still see an issue: import sys def g(): try: return g() except: return sys.exc_info() g() (type 'exceptions.RuntimeError', 'maximum recursion depth exceeded while calling a Python object', traceback object at 0xb7d3d75c) import sys Traceback (most recent call last): File stdin, line 1, in module RuntimeError: maximum recursion depth exceeded Then, I can raise that RuntimeError and clear things: sys.excepthook(*g()) Traceback (most recent call last): File stdin, line 3, in g RuntimeError: maximum recursion depth exceeded while calling a Python object import sys The attached patch adds a test for this condition, I hope someone more test-savvy than I can review it. -- nosy: +ajaksu2 Added file: http://bugs.python.org/file9932/test_exceptions.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2542 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2541] Unicode escape sequences not parsed in raw strings.
Benjamin Peterson [EMAIL PROTECTED] added the comment: Fixed in r62128. -- resolution: - fixed status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2541 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2475] Popen.poll always returns None
roudkerk [EMAIL PROTECTED] added the comment: The problem is that os.wait() does not play nicely with subprocess.py. Popen.poll() and Popen.wait() use os.waitpid(pid, ...) which will raise OSError if pid has already been reported by os.wait(). Popen.poll() swallows OSError and by default returns None. You can (sort of) fix your program by using p.popen(_deadstate='dead') in place of p.popen(). This will make poll() return 'dead' instead of None if OSError gets caught, but this is undocumented. Maybe a subprocess.wait() function could be added which would return a tuple (pid, exitcode, popen_object) where popen_object is None if the process is foreign (i.e. it was not created by the subprocess module). It would not be hard to implement this on unix if you don't care about thread safety. (On unix Popen.wait() is not thread-safe either, so maybe thread safety does not matter.) To implement something similar on windows you would probably need to use WaitForMultipleObjects() to check whether any process handles are signalled, but that would involve patching _subprocess.c or using ctypes or pywin32. -- nosy: +roudkerk __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2475 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2543] Make ctypes compatible with Python 2.3, 2.4, and 2.5, as per PEP291
New submission from Thomas Heller [EMAIL PROTECTED]: To be committed after the current release is out. -- assignee: theller components: ctypes files: ctypes-compat-py23.diff keywords: patch, patch messages: 64904 nosy: theller severity: normal status: open title: Make ctypes compatible with Python 2.3, 2.4, and 2.5, as per PEP291 type: compile error versions: Python 2.6 Added file: http://bugs.python.org/file9934/ctypes-compat-py23.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2543 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2455] stat.ST_CTIME and stat.ST_ATIME problem
Guilherme Polo [EMAIL PROTECTED] added the comment: Not here, ST_CTIME is 9 and ST_ATIME is 7, both are the correct indices at the tuple returned by os.stat. Could you recheck that and then and include some output (if it is really incorrect) ? -- nosy: +gpolo __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2455 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2516] Instance methods are misreporting the number of arguments
Benjamin Peterson [EMAIL PROTECTED] added the comment: Guido, what's your opinion on this? Is this a bug, and should it be fixed? -- nosy: +gvanrossum __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2516 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2544] link with gcc -shared on HP systems
New submission from Thomas Heller [EMAIL PROTECTED]: As discussed in issue #1582742, this patch uses 'gcc -shared' as linker on HP systems when compiling with gcc. It fixes a problem in the ctypes test-suite, that _ctypes_test.so cannot be dynloaded because of missing symbols. To be committed after the current alpha-release is out. -- assignee: theller components: Build files: configure.diff keywords: patch, patch messages: 64906 nosy: theller severity: normal status: open title: link with gcc -shared on HP systems versions: Python 2.6 Added file: http://bugs.python.org/file9935/configure.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2544 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1582742] Python is dumping core after the test test_ctypes
Thomas Heller [EMAIL PROTECTED] added the comment: See issue #2544, this problem will be solved in Python 2.6. In Python 2.5, ctypes does not work on HPUX. -- assignee: - theller resolution: - rejected status: open - closed _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1582742 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1733757] RuntimeWarning: tp_compare didn't return -1 or -2
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: The deadlock was resolved by r62136. I think I was lucky this time. I was close to disable sys.settrace before interpreter shutdown. But is would disallow debugging inside the finalization procedures. -- resolution: - fixed status: open - closed _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1733757 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2116] weakref copy module interaction
Rick Harris [EMAIL PROTECTED] added the comment: Sorry about forgetting the -c arg! The patch is intended for python/trunk/Lib/copy.py. It looks like Raymond Hettinger has made a similar-ish change recently to make Ellipsis copyable. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2116 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2516] Instance methods are misreporting the number of arguments
Raymond Hettinger [EMAIL PROTECTED] added the comment: It's definitely a bug, but I think the reason it has been around so long is that no-one has offerred a clean solution. I was hoping for something along the lines of functions raising an ArgumentError (a new subclass of TypeError) that could be trapped by the __call__ slot for bound methods and then reraised with a new argument count. The key is to find a *very* lightweight and minimal solution; otherwise, we should just live with it for another 18 years :- ) __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2516 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2475] Popen.poll always returns None
Josh Cogliati [EMAIL PROTECTED] added the comment: Hm. Well, after filing the bug, I created a thread for each subprocess, and had that thread do an wait on the process, and that worked fine. So, I guess at minimum it sounds like the documentation for poll could be improved to mention that it will not catch the state if something else does. I think a better fix would be for poll to return some kind of UnknownError instead of None if the process was finished, but python did not catch it for some reason (like using os.wait() :) __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2475 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2545] sphinx.ext.autodoc fails to expand tabs in docstrings
New submission from John Millikin [EMAIL PROTECTED]:
Sphinx seems to need tabs expanded in reST, but the autodoc extension
doesn't do so. The following patch is very small, and fixes the issue on
my system.
Oddly, I can reproduce this on a Linux system with doctools and docutils
trunk, but not on a Mac with doctools and docutils trunk vOv.
Index: ext/autodoc.py
===
--- ext/autodoc.py (revision 62140)
+++ ext/autodoc.py (working copy)
@@ -41,7 +41,8 @@
if not s or s.isspace():
return ['']
-nl = s.expandtabs().rstrip().find('\n')
+s = s.expandtabs ()
+nl = s.rstrip().find('\n')
if nl == -1:
# Only one line...
return [s.strip(), '']
--
assignee: georg.brandl
components: Documentation tools (Sphinx)
messages: 64912
nosy: georg.brandl, jmillikin
severity: normal
status: open
title: sphinx.ext.autodoc fails to expand tabs in docstrings
versions: Python 2.5
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2545
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2545] sphinx.ext.autodoc fails to expand tabs in docstrings
Changes by John Millikin [EMAIL PROTECTED]: -- type: - behavior __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2545 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2138] Add a factorial function
Terry J. Reedy [EMAIL PROTECTED] added the comment: The fact that other languages have factorial does not in itself impress me. What is the actual use case other than illustrating computational induction (whether by iteration or recursion) and for calculating binomial coefficients? I don't really like the idea of making factorial a method for the same reason that exp, sin, ... are not methods of float: there is no end. People should be able to learn basic classes without specialized functions attached. -- nosy: +tjreedy __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2138 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2539] Windows Registry issue with 2.5.2 AMD64 msi
Jason [EMAIL PROTECTED] added the comment: I did a per-machine installation (Install for all users). I don't have the registry information at the moment, but I'll do some more uninstalling and reinstalling and get that information to you. Martin v. Löwis wrote: Martin v. Löwis [EMAIL PROTECTED] added the comment: Do you perform a per-user or per-machine installation? When you look at the Python registry keys, which ones get written? -- nosy: +loewis __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2539 __ __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2539 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2546] Python-2.5.2: crash in visit_decref () at Modules/gcmodule.c:270
New submission from George Verbitsky [EMAIL PROTECTED]:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208408368 (LWP 2816)]
0x080edccd in visit_decref (op=0xbf9289ff, data=0x0) at
Modules/gcmodule.c:270
270 if (PyObject_IS_GC(op)) {
(gdb) bt
#0 0x080edccd in visit_decref (op=0xbf9289ff, data=0x0) at
Modules/gcmodule.c:270
#1 0x08099e19 in tupletraverse (o=0xb7f2380c, visit=0x80edcc0
visit_decref, arg=0x0)
at Objects/tupleobject.c:443
#2 0x080ee63e in collect (generation=0) at Modules/gcmodule.c:295
#3 0x080ef159 in _PyObject_GC_NewVar (tp=0x8170700, nitems=14) at
Modules/gcmodule.c:897
#4 0x08111f10 in PyFrame_New (tstate=0x8bdd128, code=0xb7d04410,
globals=0xb7cd3934, locals=0x0)
at Objects/frameobject.c:614
#5 0x080c521a in PyEval_EvalFrameEx (f=0x8cf0fb4, throwflag=0) at
Python/ceval.c:3639
#6 0x080c5265 in PyEval_EvalFrameEx (f=0x8ced7bc, throwflag=0) at
Python/ceval.c:3650
#7 0x080c5265 in PyEval_EvalFrameEx (f=0x8ced484, throwflag=0) at
Python/ceval.c:3650
#8 0x080c5265 in PyEval_EvalFrameEx (f=0x8ce7dbc, throwflag=0) at
Python/ceval.c:3650
#9 0x080c5265 in PyEval_EvalFrameEx (f=0x8ce7c5c, throwflag=0) at
Python/ceval.c:3650
#10 0x080c6075 in PyEval_EvalCodeEx (co=0xb7c2d608, globals=0xb7c18e84,
locals=0x0, args=0xb7f28378,
argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0)
at Python/ceval.c:2831
#11 0x08112871 in function_call (func=0xb7c2af44, arg=0xb7f2836c,
kw=0x0) at Objects/funcobject.c:517
#12 0x08061a17 in PyObject_Call (func=0x7, arg=0xb7f2836c, kw=0x0) at
Objects/abstract.c:1860
#13 0x08067937 in instancemethod_call (func=0xb7f1302c, arg=0xb7f2836c,
kw=0x0) at Objects/classobject.c:2497
#14 0x08061a17 in PyObject_Call (func=0x7, arg=0xb7f5202c, kw=0x0) at
Objects/abstract.c:1860
#15 0x0809d7cb in slot_tp_init (self=0xb7c3442c, args=0xb7f5202c,
kwds=0x0) at Objects/typeobject.c:4862
#16 0x080a0393 in type_call (type=0x8c5d04c, args=0xb7f5202c, kwds=0x0)
at Objects/typeobject.c:436
#17 0x08061a17 in PyObject_Call (func=0x7, arg=0xb7f5202c, kw=0x0) at
Objects/abstract.c:1860
#18 0x080c1149 in PyEval_EvalFrameEx (f=0x8ce7afc, throwflag=0) at
Python/ceval.c:3775
#19 0x080c6075 in PyEval_EvalCodeEx (co=0xb7c2d4a0, globals=0xb7c83934,
locals=0x0, args=0xb7f23818,
argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0)
at Python/ceval.c:2831
#20 0x08112871 in function_call (func=0xb7c2ae64, arg=0xb7f2380c,
kw=0x0) at Objects/funcobject.c:517
#21 0x08061a17 in PyObject_Call (func=0x7, arg=0xb7f2380c, kw=0x0) at
Objects/abstract.c:1860
#22 0x080be26c in PyEval_CallObjectWithKeywords (func=0xb7c2ae64,
arg=0xb7f2380c, kw=0x0)
at Python/ceval.c:3433
#23 0x08061c30 in PyObject_CallObject (o=0xb7c2ae64, a=0xb7f2380c) at
Objects/abstract.c:1851
#24 0x08061879 in C2py (func=0x81380c5 backend, nargs=1) at C2py.c:52
#25 0x0806191d in backend (output_filename=0xbf9289ff cla) at backend.c:5
#26 0x08056fa5 in main (argc=3, argv=0xbf9271b4) at main.c:33
(gdb)
--
components: Interpreter Core
messages: 64915
nosy: garikvm
severity: normal
status: open
title: Python-2.5.2: crash in visit_decref () at Modules/gcmodule.c:270
versions: Python 2.5
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2546
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2385] run_setup can fail if the setup script uses __file__
Fred L. Drake, Jr. [EMAIL PROTECTED] added the comment: I don't think these are the right thing to do. 1. Your run_setup() changes add a os.chdir(), but then uses the path to the script as passed in; this assumes that the provided path is absolute, which is not a good assumption. That is not currently required. The effect is that a path that works currently may not work after the change. A relative path will not be usable to locate support files in this case, since it no longer refers to the directory is used to. Also, the way you restore the current directory doesn't work; os.curdir isn't what you think it is. This isn't covered in the test, either. 2. Apparently there are setup.py scripts that test __name__ (this surprised me, but Google Code Search says there are many: http://www.google.com/codesearch?q=file%3Asetup.py+%22__main__%22). This change would affect those that are currently seeing __builtin__ (picked up from the built-in namespace). Arguably, it's reasonable to expect run_setup() to restore the current directory if a setup.py script does change it, but it's not clear that the change in behavior wouldn't cause problems for existing scripts. I've adjusted the patch so that the __file__ is supported, but the other behaviors are omitted. This has been commited in revision 62142 on the trunk. -- assignee: - fdrake nosy: +fdrake priority: - low __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2385 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2385] run_setup can fail if the setup script uses __file__
Fred L. Drake, Jr. [EMAIL PROTECTED] added the comment: Here's a patch that restores the current directory after running the script. The distutils-sig should probably determine if that's the right thing to do. Includes test. Added file: http://bugs.python.org/file9936/run_script-restores-cwd.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2385 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
