[ python-Bugs-1633863 ] AIX: configure ignores $CC; problems with C++ style comments
Bugs item #1633863, was opened at 2007-01-12 09:46 Message generated for change (Comment added) made by jabt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633863&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: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Johannes Abt (jabt) Assigned to: Nobody/Anonymous (nobody) Summary: AIX: configure ignores $CC; problems with C++ style comments Initial Comment: CC=xlc_r ./configure does not work on AIX-5.1, because configure unconditionally sets $CC to "cc_r": case $ac_sys_system in AIX*) CC=cc_r without_gcc=;; It would be better to leave $CC and just add "-qthreaded" to $CFLAGS. Furthermore, much of the C source code of Python uses C++ /C99 comments. This is an error with the standard AIX compiler. Please add the compiler flag "-qcpluscmt". An alternative would be to use a default of "xlc_r" for CC on AIX. This calls the compiler in a mode that both accepts C++ comments and generates reentrant code. Regards, Johannes -- >Comment By: Johannes Abt (jabt) Date: 2007-01-30 14:07 Message: Logged In: YES user_id=1563402 Originator: YES Sorry about the C++ comments... all the C++ comments I have found concern Windows, PC or Darwin. I must have confused this with another project I have been compiling. Though there still the issue with setting $CC. -- Comment By: Neal Norwitz (nnorwitz) Date: 2007-01-19 06:47 Message: Logged In: YES user_id=33168 Originator: NO There shouldn't be any C++ comments in the Python code. If there are, it is a mistake. I did see some get removed recently. Could you let me know where you see the C++ comments? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633863&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1647541 ] SystemError with re.match(array)
Bugs item #1647541, was opened at 2007-01-30 00:04
Message generated for change (Comment added) made by arigo
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1647541&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: None
Status: Open
Resolution: None
Priority: 4
Private: No
Submitted By: Armin Rigo (arigo)
Assigned to: Armin Rigo (arigo)
Summary: SystemError with re.match(array)
Initial Comment:
An small issue which I guess is to be found in
the implementation of the buffer interface
for zero-length arrays:
>>> a = array.array("c")
>>> r = re.compile("bla")
>>> r.match(a)
SystemError: error return without exception set
--
>Comment By: Armin Rigo (arigo)
Date: 2007-01-30 13:37
Message:
Logged In: YES
user_id=4771
Originator: YES
It seems to me that an empty array should be
equivalent to an empty string. Accessing it as a
buffer should return a buffer of length 0, not
raise ValueError.
In all cases, the fix in _sre.c is sensible.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2007-01-30 05:21
Message:
Logged In: YES
user_id=33168
Originator: NO
Armin, what do you think of the attached patch?
File Added: empty-array.diff
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1647541&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1648179 ] set update problem with class derived from dict
Bugs item #1648179, was opened at 2007-01-30 20:00 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=1648179&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: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: duncan (urubu147) Assigned to: Nobody/Anonymous (nobody) Summary: set update problem with class derived from dict Initial Comment: Class derived from dict with __iter__ method returning itervalues() has keys (rather than values) added to set when using set update method. Works as expected in 2.4. Windows XP (Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win32). Unsure of platform for Peter Otten's minimal example in (hopefully) attached file. Duncan Smith -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1648179&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1124861 ] subprocess fails on GetStdHandle in interactive GUI
Bugs item #1124861, was opened at 2005-02-17 17:23
Message generated for change (Comment added) made by astrand
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124861&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: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: davids (davidschein)
Assigned to: Nobody/Anonymous (nobody)
Summary: subprocess fails on GetStdHandle in interactive GUI
Initial Comment:
Using the suprocess module from with IDLE or PyWindows,
it appears that calls GetStdHandle (STD__HANDLE)
returns None, which causes an error. (All appears fine
on Linux, the standard Python command-line, and ipython.)
For example:
>>> import subprocess
>>> p = subprocess.Popen("dir", stdout=subprocess.PIPE)
Traceback (most recent call last):
File "", line 1, in -toplevel-
p = subprocess.Popen("dir", stdout=subprocess.PIPE)
File "C:\Python24\lib\subprocess.py", line 545, in
__init__
(p2cread, p2cwrite,
File "C:\Python24\lib\subprocess.py", line 605, in
_get_handles
p2cread = self._make_inheritable(p2cread)
File "C:\Python24\lib\subprocess.py", line 646, in
_make_inheritable
DUPLICATE_SAME_ACCESS)
TypeError: an integer is required
The error originates in the mswindows implementation of
_get_handles. You need to set one of stdin, stdout, or
strerr because the first line in the method is:
if stdin == None and stdout == None and stderr == None:
...return (None, None, None, None, None, None)
I added "if not handle: return GetCurrentProcess()" to
_make_inheritable() as below and it worked. Of course,
I really do not know what is going on, so I am letting
go now...
def _make_inheritable(self, handle):
..."""Return a duplicate of handle, which is inheritable"""
...if not handle: return GetCurrentProcess()
...return DuplicateHandle(GetCurrentProcess(), handle,
GetCurrentProcess(),
0, 1,
DUPLICATE_SAME_ACCESS)
--
>Comment By: Peter Åstrand (astrand)
Date: 2007-01-30 21:04
Message:
Logged In: YES
user_id=344921
Originator: NO
File Added: 1124861.3.patch
--
Comment By: Peter Åstrand (astrand)
Date: 2007-01-29 22:42
Message:
Logged In: YES
user_id=344921
Originator: NO
Some ideas of possible solutions for this bug:
1) As Roger Upole suggests, throw an readable error when GetStdHandle
fails. This would not really change much, besides of subprocess being a
little less confusing.
2) Automatically create PIPEs for those handles that fails. The PIPE could
either be left open or closed. A WriteFile in the child would get
ERROR_BROKEN_PIPE, if the parent has closed it. Not as good as
ERROR_INVALID_HANDLE, but pretty close. (Or should I say pretty closed?
:-)
3) Try to attach the handles to a NUL device, as 1238747 suggests.
4) Hope for the best and actually pass invalid handles in
startupinfo.hStdInput, startupinfo.hStdOutput, or
startupinfo.hStdError. It would be nice if this was possible: If
GetStdHandle fails in the current process, it makes sense that
GetStdHandle will fail in the child as well. But, as far as I understand,
it's not possible or safe to pass invalid handles in the startupinfo
structure.
Currently, I'm leaning towards solution 2), with closing the parents PIPE
ends.
--
Comment By: Peter Åstrand (astrand)
Date: 2007-01-22 20:36
Message:
Logged In: YES
user_id=344921
Originator: NO
The following bugs have been marked as duplicate of this bug:
1358527
1603907
1126208
1238747
--
Comment By: craig (codecraig)
Date: 2006-10-13 17:54
Message:
Logged In: YES
user_id=1258995
On windows, this seems to work
from subprocess import *
p = Popen(cmd, stdin=PIPE, stdout=PIPE, stderr=PIPE)
in some cases (depending on what command you are
executing, a command prompt window may appear). Do not show
a window use this...
import win32con
p = Popen(cmd, stdin=PIPE, stdout=PIPE, stderr=PIPE,
creationflags=win32con.CREATE_NO_WINDOW)
...google for Microsoft Process Creation Flags for more info
--
Comment By: Steven Bethard (bediviere)
Date: 2005-09-26 16:53
Message:
Logged In: YES
user_id=945502
This issue was discussed on comp.lang.python[1] and Roger
Upole suggested:
"""
Basically, gui apps like VS don't have a console, so
GetStdHandle returns 0. _subprocess.GetStdHandle
returns None if the handle is 0, which gives the original
error. Pywin32 just returns the 0, so the process gets
one step further but still hits the above er
[ python-Bugs-1124861 ] subprocess fails on GetStdHandle in interactive GUI
Bugs item #1124861, was opened at 2005-02-17 17:23
Message generated for change (Comment added) made by astrand
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124861&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: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: davids (davidschein)
Assigned to: Nobody/Anonymous (nobody)
Summary: subprocess fails on GetStdHandle in interactive GUI
Initial Comment:
Using the suprocess module from with IDLE or PyWindows,
it appears that calls GetStdHandle (STD__HANDLE)
returns None, which causes an error. (All appears fine
on Linux, the standard Python command-line, and ipython.)
For example:
>>> import subprocess
>>> p = subprocess.Popen("dir", stdout=subprocess.PIPE)
Traceback (most recent call last):
File "", line 1, in -toplevel-
p = subprocess.Popen("dir", stdout=subprocess.PIPE)
File "C:\Python24\lib\subprocess.py", line 545, in
__init__
(p2cread, p2cwrite,
File "C:\Python24\lib\subprocess.py", line 605, in
_get_handles
p2cread = self._make_inheritable(p2cread)
File "C:\Python24\lib\subprocess.py", line 646, in
_make_inheritable
DUPLICATE_SAME_ACCESS)
TypeError: an integer is required
The error originates in the mswindows implementation of
_get_handles. You need to set one of stdin, stdout, or
strerr because the first line in the method is:
if stdin == None and stdout == None and stderr == None:
...return (None, None, None, None, None, None)
I added "if not handle: return GetCurrentProcess()" to
_make_inheritable() as below and it worked. Of course,
I really do not know what is going on, so I am letting
go now...
def _make_inheritable(self, handle):
..."""Return a duplicate of handle, which is inheritable"""
...if not handle: return GetCurrentProcess()
...return DuplicateHandle(GetCurrentProcess(), handle,
GetCurrentProcess(),
0, 1,
DUPLICATE_SAME_ACCESS)
--
>Comment By: Peter Åstrand (astrand)
Date: 2007-01-30 21:05
Message:
Logged In: YES
user_id=344921
Originator: NO
Please review 1124861.3.patch.
--
Comment By: Peter Åstrand (astrand)
Date: 2007-01-30 21:04
Message:
Logged In: YES
user_id=344921
Originator: NO
File Added: 1124861.3.patch
--
Comment By: Peter Åstrand (astrand)
Date: 2007-01-29 22:42
Message:
Logged In: YES
user_id=344921
Originator: NO
Some ideas of possible solutions for this bug:
1) As Roger Upole suggests, throw an readable error when GetStdHandle
fails. This would not really change much, besides of subprocess being a
little less confusing.
2) Automatically create PIPEs for those handles that fails. The PIPE could
either be left open or closed. A WriteFile in the child would get
ERROR_BROKEN_PIPE, if the parent has closed it. Not as good as
ERROR_INVALID_HANDLE, but pretty close. (Or should I say pretty closed?
:-)
3) Try to attach the handles to a NUL device, as 1238747 suggests.
4) Hope for the best and actually pass invalid handles in
startupinfo.hStdInput, startupinfo.hStdOutput, or
startupinfo.hStdError. It would be nice if this was possible: If
GetStdHandle fails in the current process, it makes sense that GetStdHandle
will fail in the child as well. But, as far as I understand, it's not
possible or safe to pass invalid handles in the startupinfo structure.
Currently, I'm leaning towards solution 2), with closing the parents PIPE
ends.
--
Comment By: Peter Åstrand (astrand)
Date: 2007-01-22 20:36
Message:
Logged In: YES
user_id=344921
Originator: NO
The following bugs have been marked as duplicate of this bug:
1358527
1603907
1126208
1238747
--
Comment By: craig (codecraig)
Date: 2006-10-13 17:54
Message:
Logged In: YES
user_id=1258995
On windows, this seems to work
from subprocess import *
p = Popen(cmd, stdin=PIPE, stdout=PIPE, stderr=PIPE)
in some cases (depending on what command you are
executing, a command prompt window may appear). Do not show
a window use this...
import win32con
p = Popen(cmd, stdin=PIPE, stdout=PIPE, stderr=PIPE,
creationflags=win32con.CREATE_NO_WINDOW)
...google for Microsoft Process Creation Flags for more info
--
Comment By: Steven Bethard (bediviere)
Date: 2005-09-26 16:53
Message:
Logged In: YES
user_id=945502
This issue was discussed on comp.lang.python[1] and Roger
Upole suggested:
"""
Basically, gui apps like VS don't have a
[ python-Bugs-1648191 ] Grammatical error
Bugs item #1648191, was opened at 2007-01-30 14:18 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=1648191&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: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Chris Beelby (mrchris007) Assigned to: Nobody/Anonymous (nobody) Summary: Grammatical error Initial Comment: I was viewing the documentation located at: http://docs.python.org/lib/module-imageop.html Which is section 19.2 (imageop -- Manipulate raw image data) of the Python Library Reference. Under the description for the crop() method the first line reads: "Return the selected part of image, which should **by** width by height in size..." (I added the asterisk's) The word which I highlighted with the asterik's should be "be", not "by". -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1648191&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1648191 ] Grammatical error
Bugs item #1648191, was opened at 2007-01-30 20:18 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1648191&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: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Chris Beelby (mrchris007) Assigned to: Nobody/Anonymous (nobody) Summary: Grammatical error Initial Comment: I was viewing the documentation located at: http://docs.python.org/lib/module-imageop.html Which is section 19.2 (imageop -- Manipulate raw image data) of the Python Library Reference. Under the description for the crop() method the first line reads: "Return the selected part of image, which should **by** width by height in size..." (I added the asterisk's) The word which I highlighted with the asterik's should be "be", not "by". -- >Comment By: Georg Brandl (gbrandl) Date: 2007-01-30 20:22 Message: Logged In: YES user_id=849994 Originator: NO Thanks for the report, fixed in rev. 53603, 53604 (2.5). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1648191&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1648179 ] set update problem with class derived from dict
Bugs item #1648179, was opened at 2007-01-30 20:00 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1648179&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: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: duncan (urubu147) >Assigned to: Raymond Hettinger (rhettinger) Summary: set update problem with class derived from dict Initial Comment: Class derived from dict with __iter__ method returning itervalues() has keys (rather than values) added to set when using set update method. Works as expected in 2.4. Windows XP (Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win32). Unsure of platform for Peter Otten's minimal example in (hopefully) attached file. Duncan Smith -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1648179&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1568075 ] GUI scripts always return to an interpreter
Bugs item #1568075, was opened at 2006-09-29 16:00 Message generated for change (Comment added) made by jejackson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568075&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.5 >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: jjackson (jejackson) Assigned to: Jack Jansen (jackjansen) Summary: GUI scripts always return to an interpreter Initial Comment: I installed the latest version of 2.5 from the web last night: Python 2.5 (r25:51918, Sep 19 2006, 08:49:13) [GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin When I run a wxPython script, using something like pythonw myScript.py from the Terminal, I find myself in an interpreter after I use the quit menu. The menubar becomes a single, hung python menu, and a shell window pops up with an interpreter prompt. Cntrl-D kills the interpreter. It's as if python was stuck in "-i" mode: pythonw -i myScript.py gives the same results. (python and pythonw give the same results. It appears from comments on the web that they are now the same. They appear so from a diff. If so, why not a symlink?) Running the lastest wxPython demo gives this warning in the console, 2006-09-29 15:40:06.681 wxPython Demo[942] WARNING: _wrapRunLoopWithAutoreleasePoolHandler got kCFRunLoopExit, but there are no autorelease pools in the stack. which may or may not be related. -- >Comment By: jjackson (jejackson) Date: 2007-01-30 13:20 Message: Logged In: YES user_id=1497873 Originator: YES After a bunch of troubleshooting, I've determined that the problem is caused by the Unsanity Application Enhancer Module (APE) 2.0.2. Deactivating or removing that module and the problem goes away. Maybe they are patching something that causes the python.app to hang on exit. I've set the resolution to invalid as this is not wxpython or python's problem. -- Comment By: jjackson (jejackson) Date: 2006-09-30 14:48 Message: Logged In: YES user_id=1497873 I tried: Olivos:~ jj$ echo $PYTHONINSPECT Olivos:~ jj$ Looks like it isn't set. However, this might be a wxPython bug. I tried a tcl/tk app from the demos: Applications/MacPython 2.5/Extras/Demo/tkinter/guido/solitaire.py. Quitting it worked fine. I'll post something on the wxPython mac list. -- Comment By: Georg Brandl (gbrandl) Date: 2006-09-30 11:24 Message: Logged In: YES user_id=849994 Could you check if it is set? (using echo $PYTHONINSPECT in a console?) -- Comment By: jjackson (jejackson) Date: 2006-09-30 10:55 Message: Logged In: YES user_id=1497873 No, I didn't set the PYTHONINSPECT env variable. If it was set, it was by something else. -- Comment By: Georg Brandl (gbrandl) Date: 2006-09-30 00:47 Message: Logged In: YES user_id=849994 Did you (or someone else) perhaps set the PYTHONINSPECT environment variable? I can't imagine another cause for this problem. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568075&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1648268 ] Parameter list mismatches (portation problem)
Bugs item #1648268, was opened at 2007-01-30 22:15
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=1648268&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
Private: No
Submitted By: ked-tao (ked-tao)
Assigned to: Nobody/Anonymous (nobody)
Summary: Parameter list mismatches (portation problem)
Initial Comment:
On the system I'm porting to(*), an application will trap if the caller does
not pass the exact parameter list that the callee requires. This is causing
problems running Python.
One common instance where this appears to be causing problems is where
functions are registered as METH_NOARGS methods. For example, in
Obejcts/dictobject.c, dict_popitem() is declared:
static PyObject *dict_popitem(dictobject *mp);
However, as it is declared in the method array as METH_NOARGS, it will be
called by Objects/methodobject.c:PyCFunction_Call() as "(*meth)(self, NULL)"
(i.e., an extra NULL parameter is passed for some reason). This will fail on my
target system.
I've no problem submitting a patch for this (dictobject.c is by no means the
only place this is happening - it's just the first one encountered because it's
used so much - though some places _do_ correctly declare a second, ignored
parameter). However, I'd like to get agreement on the correct form it should be
changed to before I put the effort in to produce a patch (it's going to be a
fairly tedious process to identify and fix all these).
In various modules, the functions are called internally as well as being
registered as METH_NOARGS methods.
Therefore, the change can either be:
static PyObject *foo(PyObject *self)
{
...
}
static PyObject *foo_noargs(PyObject *self, void *noargs_null)
{
return foo(self);
}
... where 'foo' is called internally and 'foo_noargs' is registered as a
METH_NOARGS method.
or:
static PyObject *foo(PyObject *self, void *noargs_null)
{
...
}
... and any internal calls in the module have to pass a second, NULL, argument
in each call.
The former favours internal module calls over METH_NOARGS calls, the latter
penalises them. Which is preferred? Should this be raised on a different forum?
Does anyone care? ;)
Thanks, Kev.
(*) Details on request.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1648268&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
