[ python-Bugs-1486663 ] Over-zealous keyword-arguments check for built-in set class
Bugs item #1486663, was opened at 2006-05-11 16:17
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486663&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: Fixed
Priority: 8
Private: No
Submitted By: dib (dib_at_work)
Assigned to: Georg Brandl (gbrandl)
Summary: Over-zealous keyword-arguments check for built-in set class
Initial Comment:
The fix for bug #1119418 (xrange() builtin accepts
keyword arg silently) included in Python 2.4.2c1+
breaks code that passes keyword argument(s) into
classes derived from the built-in set class, even if
those derived classes explictly accept those keyword
arguments and avoid passing them down to the built-in
base class.
Simplified version of code in attached
BuiltinSetKeywordArgumentsCheckBroken.py fails at (G)
due to bug #1119418 if version < 2.4.2c1; if version >=
2.4.2c1 (G) passes thanks to that bug fix, but instead
(H) incorrectly-in-my-view fails.
[Presume similar cases would fail for xrange and the
other classes mentioned in #1119418.]
-- David Bruce
(Tested on 2.4, 2.4.2, 2.5a2 on linux2, win32.)
--
>Comment By: Georg Brandl (gbrandl)
Date: 2007-02-19 08:02
Message:
Logged In: YES
user_id=849994
Originator: NO
The exceptions.c one is in __init__, so it is not a problem when the
derived class doesn't pass along kwargs to super.__init__.
I deliberately left the others as they were since their type objects lack
the Py_TPFLAGS_BASETYPE flag.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2007-02-19 02:38
Message:
Logged In: YES
user_id=80475
Originator: NO
There are more of these that need to be fixed:
bufferobject.c:236: if (!_PyArg_NoKeywords("buffer()", kw))
classobject.c:2261: if (!_PyArg_NoKeywords("instancemethod", kw))
exceptions.c:57:if (!_PyArg_NoKeywords(self->ob_type->tp_name, kwds))
funcobject.c:653: if (!_PyArg_NoKeywords("classmethod", kwds))
funcobject.c:810: if (!_PyArg_NoKeywords("staticmethod", kwds))
rangeobject.c:48: if (!_PyArg_NoKeywords("xrange()", kw))
sliceobject.c:197: if (!_PyArg_NoKeywords("slice()", kw))
typeobject.c:5773: if (!_PyArg_NoKeywords("super", kwds))
--
Comment By: Georg Brandl (gbrandl)
Date: 2007-01-21 10:29
Message:
Logged In: YES
user_id=849994
Originator: NO
Committed as rev. 53509, 53510 (2.5).
--
Comment By: Georg Brandl (gbrandl)
Date: 2007-01-17 09:13
Message:
Logged In: YES
user_id=849994
Originator: NO
I'll create the testcases and commit the patch (as well as NEWS entries :)
when I find the time.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2007-01-17 07:22
Message:
Logged In: YES
user_id=33168
Originator: NO
Were these changes applied by Raymond? I don't think there were NEWS
entries though.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2007-01-11 20:43
Message:
Logged In: YES
user_id=80475
Originator: NO
That looks about right. Please add test cases that fail without the patch
and succeed with the patch. Also, put a comment in Misc/NEWS. If the
whole test suite passes, go ahead and check-in to Py2.5.1 and the head.
Thanks,
Raymond
--
Comment By: Georg Brandl (gbrandl)
Date: 2007-01-11 19:56
Message:
Logged In: YES
user_id=849994
Originator: NO
Attaching patch.
File Added: nokeywordchecks.diff
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2007-01-11 18:30
Message:
Logged In: YES
user_id=80475
Originator: NO
I fixed setobject.c in revisions 53380 and 53381.
Please apply similar fixes to all the other places being bitten my the
pervasive NoKeywords tests.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2007-01-11 00:49
Message:
Logged In: YES
user_id=80475
Originator: NO
My proposed solution:
- if(!PyArg_NoKeywords("set()", kwds)
+ if(type == &PySet_Type && !PyArg_NoKeywords("set()", kwds)
--
Comment By: Georg Brandl (gbrandl)
Date: 2007-01-10 21:30
Message:
Logged In: YES
user_id=849994
Originator: NO
I'll do that, only in set_init, you have
if (!PyArg_UnpackTuple(args, self->ob_type->tp_name, 0, 1, &iterable))
Ch
[ python-Bugs-1486663 ] Over-zealous keyword-arguments check for built-in set class
Bugs item #1486663, was opened at 2006-05-11 11:17
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486663&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: 8
Private: No
Submitted By: dib (dib_at_work)
Assigned to: Georg Brandl (gbrandl)
Summary: Over-zealous keyword-arguments check for built-in set class
Initial Comment:
The fix for bug #1119418 (xrange() builtin accepts
keyword arg silently) included in Python 2.4.2c1+
breaks code that passes keyword argument(s) into
classes derived from the built-in set class, even if
those derived classes explictly accept those keyword
arguments and avoid passing them down to the built-in
base class.
Simplified version of code in attached
BuiltinSetKeywordArgumentsCheckBroken.py fails at (G)
due to bug #1119418 if version < 2.4.2c1; if version >=
2.4.2c1 (G) passes thanks to that bug fix, but instead
(H) incorrectly-in-my-view fails.
[Presume similar cases would fail for xrange and the
other classes mentioned in #1119418.]
-- David Bruce
(Tested on 2.4, 2.4.2, 2.5a2 on linux2, win32.)
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2007-02-19 03:21
Message:
Logged In: YES
user_id=80475
Originator: NO
Okay, it looks like this bug was already fixed.
--
Comment By: Georg Brandl (gbrandl)
Date: 2007-02-19 03:02
Message:
Logged In: YES
user_id=849994
Originator: NO
The exceptions.c one is in __init__, so it is not a problem when the
derived class doesn't pass along kwargs to super.__init__.
I deliberately left the others as they were since their type objects lack
the Py_TPFLAGS_BASETYPE flag.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2007-02-18 21:38
Message:
Logged In: YES
user_id=80475
Originator: NO
There are more of these that need to be fixed:
bufferobject.c:236: if (!_PyArg_NoKeywords("buffer()", kw))
classobject.c:2261: if (!_PyArg_NoKeywords("instancemethod", kw))
exceptions.c:57:if (!_PyArg_NoKeywords(self->ob_type->tp_name, kwds))
funcobject.c:653: if (!_PyArg_NoKeywords("classmethod", kwds))
funcobject.c:810: if (!_PyArg_NoKeywords("staticmethod", kwds))
rangeobject.c:48: if (!_PyArg_NoKeywords("xrange()", kw))
sliceobject.c:197: if (!_PyArg_NoKeywords("slice()", kw))
typeobject.c:5773: if (!_PyArg_NoKeywords("super", kwds))
--
Comment By: Georg Brandl (gbrandl)
Date: 2007-01-21 05:29
Message:
Logged In: YES
user_id=849994
Originator: NO
Committed as rev. 53509, 53510 (2.5).
--
Comment By: Georg Brandl (gbrandl)
Date: 2007-01-17 04:13
Message:
Logged In: YES
user_id=849994
Originator: NO
I'll create the testcases and commit the patch (as well as NEWS entries :)
when I find the time.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2007-01-17 02:22
Message:
Logged In: YES
user_id=33168
Originator: NO
Were these changes applied by Raymond? I don't think there were NEWS
entries though.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2007-01-11 15:43
Message:
Logged In: YES
user_id=80475
Originator: NO
That looks about right. Please add test cases that fail without the patch
and succeed with the patch. Also, put a comment in Misc/NEWS. If the
whole test suite passes, go ahead and check-in to Py2.5.1 and the head.
Thanks,
Raymond
--
Comment By: Georg Brandl (gbrandl)
Date: 2007-01-11 14:56
Message:
Logged In: YES
user_id=849994
Originator: NO
Attaching patch.
File Added: nokeywordchecks.diff
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2007-01-11 13:30
Message:
Logged In: YES
user_id=80475
Originator: NO
I fixed setobject.c in revisions 53380 and 53381.
Please apply similar fixes to all the other places being bitten my the
pervasive NoKeywords tests.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2007-01-10 19:49
Message:
Logged In: YES
user_id=80475
Originator: NO
My proposed solution:
- if(!PyArg_NoKeywords("set()", kwds)
+ if(type == &PySet_Type && !PyArg_NoKeywords("set()", kwds)
--
[ python-Bugs-1663329 ] subprocess/popen close_fds perform poor if SC_OPEN_MAX is hi
Bugs item #1663329, was opened at 2007-02-19 11:17
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=1663329&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: Performance
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: H. von Bargen (hvbargen)
Assigned to: Nobody/Anonymous (nobody)
Summary: subprocess/popen close_fds perform poor if SC_OPEN_MAX is hi
Initial Comment:
If the value of sysconf("SC_OPEN_MAX") is high
and you try to start a subprocess with subprocess.py or os.popen2 with
close_fds=True, then starting the other process is very slow.
This boils down to the following code in subprocess.py:
def _close_fds(self, but):
for i in xrange(3, MAXFD):
if i == but:
continue
try:
os.close(i)
except:
pass
resp. the similar code in popen2.py:
def _run_child(self, cmd):
if isinstance(cmd, basestring):
cmd = ['/bin/sh', '-c', cmd]
for i in xrange(3, MAXFD):
try:
os.close(i)
except OSError:
pass
There has been an optimization already (range has been replaced by xrange to
reduce memory impact), but I think the problem is that for high values of
MAXFD, usually a high percentage of the os.close statements will fail, raising
an exception (which is an "expensive" operation).
It has been suggested already to add a C implementation called "rclose" or
"close_range" that tries to close all FDs in a given range (min, max) without
the overhead of Python exception handling.
I'd like emphasize that this is not a theoretical, but a real world problem:
We have a Python application in a production environment on Sun Solaris. Some
other software running on the same server needed a high value of 26 for
SC_OPEN_MAX (set with ulimit -n XXX or in some /etc/-file (don't know which
one).
Suddenly calling any other process with subprocess.Popen (..., close_fds=True)
now took 14 seconds (!) instead of some microseconds.
This caused a huge performance degradation, since the subprocess itself only
needs only a few seconds.
See also:
Patches item #1607087 "popen() slow on AIX due to large FOPEN_MAX value".
This contains a fix, but only for AIX - and I think the patch does not support
the "but" argument used in subprocess.py.
The correct solution should be coded in C, and should
do the same as the _close_fds routine in subprocess.py.
It could be optimized to make use of (operating-specific) system calls to close
all handles from (but+1) to MAX_FD with "closefrom" or "fcntl" as proposed in
the patch.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1663329&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1663392 ] PyType_IsSubtype segfaults
Bugs item #1663392, was opened at 2007-02-19 17:12 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=1663392&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.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: navtej singh (nsbuttar) Assigned to: Nobody/Anonymous (nobody) Summary: PyType_IsSubtype segfaults Initial Comment: It seems the issue is similar to bug#560215. I was not able to reopen the last bug so I have opened a new one. I am using an external python extension which seems to be buggy. I am still investigating the actual cause of the bug in the said extension library. PyType_IsSubType segfault reason is NULL pointer derefrence @ PyType_IsSubtype (a=0x0, b=0xb7f1ea00) attaching the gdb bt as attachment. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1663392&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1663392 ] PyType_IsSubtype segfaults
Bugs item #1663392, was opened at 2007-02-19 17:12 Message generated for change (Comment added) made by nsbuttar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1663392&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.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: navtej singh (nsbuttar) Assigned to: Nobody/Anonymous (nobody) Summary: PyType_IsSubtype segfaults Initial Comment: It seems the issue is similar to bug#560215. I was not able to reopen the last bug so I have opened a new one. I am using an external python extension which seems to be buggy. I am still investigating the actual cause of the bug in the said extension library. PyType_IsSubType segfault reason is NULL pointer derefrence @ PyType_IsSubtype (a=0x0, b=0xb7f1ea00) attaching the gdb bt as attachment. -- >Comment By: navtej singh (nsbuttar) Date: 2007-02-19 17:16 Message: Logged In: YES user_id=847825 Originator: YES Additional Information cat /etc/gentoo-release ; uname -r; python -V Gentoo Base System release 1.12.9 2.6.19-suspend2-r2 Python 2.4.4 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1663392&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1663392 ] PyType_IsSubtype segfaults
Bugs item #1663392, was opened at 2007-02-19 11:42 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1663392&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.4 >Status: Pending >Resolution: Invalid Priority: 5 Private: No Submitted By: navtej singh (nsbuttar) Assigned to: Nobody/Anonymous (nobody) Summary: PyType_IsSubtype segfaults Initial Comment: It seems the issue is similar to bug#560215. I was not able to reopen the last bug so I have opened a new one. I am using an external python extension which seems to be buggy. I am still investigating the actual cause of the bug in the said extension library. PyType_IsSubType segfault reason is NULL pointer derefrence @ PyType_IsSubtype (a=0x0, b=0xb7f1ea00) attaching the gdb bt as attachment. -- >Comment By: Georg Brandl (gbrandl) Date: 2007-02-19 12:21 Message: Logged In: YES user_id=849994 Originator: NO I don't think this is a bug in the core. Most Python API functions may not be passed NULL pointers; it is expected that the user of the function checks for that condition. -- Comment By: navtej singh (nsbuttar) Date: 2007-02-19 11:46 Message: Logged In: YES user_id=847825 Originator: YES Additional Information cat /etc/gentoo-release ; uname -r; python -V Gentoo Base System release 1.12.9 2.6.19-suspend2-r2 Python 2.4.4 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1663392&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
