[ python-Bugs-1579029 ] --disable-sunaudiodev --disable-tk does not work
Bugs item #1579029, was opened at 2006-10-17 17:03 Message generated for change (Comment added) made by thurnerrupert You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579029&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: Tkinter Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: ThurnerRupert (thurnerrupert) Assigned to: Martin v. Löwis (loewis) Summary: --disable-sunaudiodev --disable-tk does not work Initial Comment: trying to disable sunaudiodev and tk does not really work in solaris. ./configure --prefix=/usr/local/Python-2.5 --enable- shared --disable-sunaudiodev --disable-tk building 'sunaudiodev' extension gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -I. -I/usr/local/Python- 2.5/./Include -I/cs/ecms/2.0.0/include -I./Include - I. -I/usr/local/include -I/usr/local/Python- 2.5/Include -I/usr/local/Python-2.5 - c /usr/local/Python-2.5/Modules/sunaudiodev.c -o build/temp.solaris-2.8-sun4u-2.5/usr/local/Python- 2.5/Modules/sunaudiodev.o /usr/local/Python-2.5/Modules/sunaudiodev.c:20:25: sun/audioio.h: No such file or directory building '_tkinter' extension gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -DWITH_APPINIT=1 - I/usr/openwin/include -I. -I/usr/local/Python- 2.5/./Include -I/cs/ecms/2.0.0/include -I./Include - I. -I/usr/local/include -I/usr/local/Python- 2.5/Include -I/usr/local/Python-2.5 - c /usr/local/Python-2.5/Modules/_tkinter.c -o build/temp.solaris-2.8-sun4u-2.5/usr/local/Python- 2.5/Modules/_tkinter.o In file included from /usr/local/Python- 2.5/Modules/_tkinter.c:67: /usr/local/include/tk.h:96:23: X11/Xlib.h: No such file or directory In file included from /usr/local/Python- 2.5/Modules/_tkinter.c:67: /usr/local/include/tk.h:572: error: syntax error before "Window" /usr/local/include/tk.h:572: error: `Window' declared as function returning a function /usr/local/include/tk.h:575: error: syntax error before "XEvent" /usr/local/include/tk.h:584: error: syntax error before "Tk_ClassCreateProc" /usr/local/include/tk.h:592: error: syntax error before '}' token /usr/local/include/tk.h:678: error: syntax error before "Bool" is it possible to correct this or state clearly in the configure options how to disable it correctly? we also checked the Modules/Setup and both seems commented. -- >Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-06 10:23 Message: Logged In: YES user_id=1597584 i would appreciate if the build completes without errors. i won't care if it attemts to build, but it should figure out that the sunaudiodev is not there. to my knowledge servers do not need that component. and python should not need it too then. do you see any reason why these components are vital for python? -- Comment By: Martin v. Löwis (loewis) Date: 2006-11-04 00:25 Message: Logged In: YES user_id=21627 It doesn't build the modules, as it doesn't succeed when attempting to. Why do you want it not to attempt? -- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-03 12:56 Message: Logged In: YES user_id=1597584 what do you suggest then to convince the build not to build it? -- Comment By: Martin v. Löwis (loewis) Date: 2006-11-02 06:40 Message: Logged In: YES user_id=21627 Re: enable/disable: What makes you think "sunaudiodev" and "tk" are valid values for "FEATURE"? configure --help lists the valid values for FEATURE, namely universalsdk, framework, shared, profiling, toolbox-glue, ipv6, and unicode. Re: there is a compilation error. Sure, an error is reported. However, compilation should not fail because of that. Instead, compilation should complete successfully, and just end up not building these modules. -- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-02 00:31 Message: Logged In: YES user_id=1597584 and there is no X on the server. -- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-01 23:49 Message: Logged In: YES user_id=1597584 and what does that mean? Optional Features: --disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no) --enable-FEATURE[=ARG] include FEATURE [ARG=yes] -- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-01 23:47 Message: Logged In: YES user_id=1597584 because there is a compilation error with both. sunaudio.h seems not
[ python-Bugs-1591035 ] update urlparse to RFC 3986
Bugs item #1591035, was opened at 2006-11-05 15:27 Message generated for change (Comment added) made by dalke You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1591035&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: Feature Request Status: Open Resolution: None Priority: 5 Private: No Submitted By: Andrew Dalke (dalke) Assigned to: Nobody/Anonymous (nobody) Summary: update urlparse to RFC 3986 Initial Comment: urlparse implements RFC 1808. That is strongly out of date. The most recent is RFC 3986. Here is a text from 4Suite # Reasons to avoid using urllib.basejoin() and urlparse.urljoin(): # - Both are partial implementations of long-obsolete specs. # - Both accept relative URLs as the base, which no spec allows. # - urllib.basejoin() mishandles the '' and '..' references. # - If the base URL uses a non-hierarchical or relative path, #or if the URL scheme is unrecognized, the result is not #always as expected (partly due to issues in RFC 1808). # - If the authority component of a 'file' URI is empty, #the authority component is removed altogether. If it was #not present, an empty authority component is in the result. # - '.' and '..' segments are not always collapsed as well as they #should be (partly due to issues in RFC 1808). # - Effective Python 2.4, urllib.basejoin() *is* urlparse.urljoin(), #but urlparse.urljoin() is still based on RFC 1808. See also the back python-dev discussions on "urlparse" for examples of people wanting a better/more up-to-date urlparse/urljoin. -- >Comment By: Andrew Dalke (dalke) Date: 2006-11-06 02:47 Message: Logged In: YES user_id=190903 See also bug 1462525 which has a 'uriparse.py' replacement for urlparse, claiming better compliance. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1591035&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1591319 ] replace groups doesn't work in this special case
Bugs item #1591319, was opened at 2006-11-06 12: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=1591319&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: Regular Expressions
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Thomas K. (tomek74)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: replace groups doesn't work in this special case
Initial Comment:
If you have a regular expression like this:
([0-9])([a-z])?
matching this string:
1 1a
and replacing with this:
yx
you get what expected:
yx yx
BUT:
If you replace with this:
\1\2
you get nothing replaced, because the group \2
doesn't exist for the pattern "1".
But it does exist for the pattern "1a"!
We have multiple possibilities here:
1.) The string "1" gives no result, because \2
doesn't exist. The string "1a" gives a result, so the
output should be: 1a
2.) The sring "1" gives a result, because \2 is
handled like an empty string. The string "1a" gives a
result, so the output should be: 1 1a
I think the case that the sring "1" has no results,
but effects the string "1a" wich would normaly have a
result, is bad.
What are your thoughts on it?
Test code:
import re
# common variables
rawstr = r"""([0-9])([a-z])?"""
embedded_rawstr = r"""([0-9])([a-z])?"""
matchstr = """1 1a"""
# method 1: using a compile object
compile_obj = re.compile(rawstr)
match_obj = compile_obj.search(matchstr)
# method 2: using search function (w/ external flags)
match_obj = re.search(rawstr, matchstr)
# method 3: using search function (w/ embedded flags)
match_obj = re.search(embedded_rawstr, matchstr)
# Retrieve group(s) from match_obj
all_groups = match_obj.groups()
# Retrieve group(s) by index
group_1 = match_obj.group(1)
group_2 = match_obj.group(2)
# Replace string
newstr = compile_obj.subn('\1\2', 0)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1591319&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1591319 ] replace groups doesn't work in this special case
Bugs item #1591319, was opened at 2006-11-06 11:49
Message generated for change (Comment added) made by niemeyer
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1591319&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: Regular Expressions
Group: Python 2.4
>Status: Closed
>Resolution: Works For Me
Priority: 5
Private: No
Submitted By: Thomas K. (tomek74)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: replace groups doesn't work in this special case
Initial Comment:
If you have a regular expression like this:
([0-9])([a-z])?
matching this string:
1 1a
and replacing with this:
yx
you get what expected:
yx yx
BUT:
If you replace with this:
\1\2
you get nothing replaced, because the group \2
doesn't exist for the pattern "1".
But it does exist for the pattern "1a"!
We have multiple possibilities here:
1.) The string "1" gives no result, because \2
doesn't exist. The string "1a" gives a result, so the
output should be: 1a
2.) The sring "1" gives a result, because \2 is
handled like an empty string. The string "1a" gives a
result, so the output should be: 1 1a
I think the case that the sring "1" has no results,
but effects the string "1a" wich would normaly have a
result, is bad.
What are your thoughts on it?
Test code:
import re
# common variables
rawstr = r"""([0-9])([a-z])?"""
embedded_rawstr = r"""([0-9])([a-z])?"""
matchstr = """1 1a"""
# method 1: using a compile object
compile_obj = re.compile(rawstr)
match_obj = compile_obj.search(matchstr)
# method 2: using search function (w/ external flags)
match_obj = re.search(rawstr, matchstr)
# method 3: using search function (w/ embedded flags)
match_obj = re.search(embedded_rawstr, matchstr)
# Retrieve group(s) from match_obj
all_groups = match_obj.groups()
# Retrieve group(s) by index
group_1 = match_obj.group(1)
group_2 = match_obj.group(2)
# Replace string
newstr = compile_obj.subn('\1\2', 0)
--
>Comment By: Gustavo Niemeyer (niemeyer)
Date: 2006-11-06 12:17
Message:
Logged In: YES
user_id=7887
Hello Thomas,
I don't understand exactly what you mean here.
This doesn't work:
>>> re.compile("([0-9])([a-z])?").subn(r"<\1\2>", "1 1a")
Traceback (most recent call last):
...
sre_constants.error: unmatched group
And this works fine:
>>> re.compile("([0-9])([a-z]?)").subn(r"<\1\2>", "1 1a")
('<1> <1a>', 2)
The example code you provided doesn't run here, because
'subn()' is being provided
bad data (check http://docs.python.org/lib/node46.html for
docs). It's also
being passed '\1\2', which is really '\x01\x02', and won't
do what you want.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1591319&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1579029 ] --disable-sunaudiodev --disable-tk does not work
Bugs item #1579029, was opened at 2006-10-17 17:03 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579029&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: Tkinter Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: ThurnerRupert (thurnerrupert) Assigned to: Martin v. Löwis (loewis) Summary: --disable-sunaudiodev --disable-tk does not work Initial Comment: trying to disable sunaudiodev and tk does not really work in solaris. ./configure --prefix=/usr/local/Python-2.5 --enable- shared --disable-sunaudiodev --disable-tk building 'sunaudiodev' extension gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -I. -I/usr/local/Python- 2.5/./Include -I/cs/ecms/2.0.0/include -I./Include - I. -I/usr/local/include -I/usr/local/Python- 2.5/Include -I/usr/local/Python-2.5 - c /usr/local/Python-2.5/Modules/sunaudiodev.c -o build/temp.solaris-2.8-sun4u-2.5/usr/local/Python- 2.5/Modules/sunaudiodev.o /usr/local/Python-2.5/Modules/sunaudiodev.c:20:25: sun/audioio.h: No such file or directory building '_tkinter' extension gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -DWITH_APPINIT=1 - I/usr/openwin/include -I. -I/usr/local/Python- 2.5/./Include -I/cs/ecms/2.0.0/include -I./Include - I. -I/usr/local/include -I/usr/local/Python- 2.5/Include -I/usr/local/Python-2.5 - c /usr/local/Python-2.5/Modules/_tkinter.c -o build/temp.solaris-2.8-sun4u-2.5/usr/local/Python- 2.5/Modules/_tkinter.o In file included from /usr/local/Python- 2.5/Modules/_tkinter.c:67: /usr/local/include/tk.h:96:23: X11/Xlib.h: No such file or directory In file included from /usr/local/Python- 2.5/Modules/_tkinter.c:67: /usr/local/include/tk.h:572: error: syntax error before "Window" /usr/local/include/tk.h:572: error: `Window' declared as function returning a function /usr/local/include/tk.h:575: error: syntax error before "XEvent" /usr/local/include/tk.h:584: error: syntax error before "Tk_ClassCreateProc" /usr/local/include/tk.h:592: error: syntax error before '}' token /usr/local/include/tk.h:678: error: syntax error before "Bool" is it possible to correct this or state clearly in the configure options how to disable it correctly? we also checked the Modules/Setup and both seems commented. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-11-06 18:51 Message: Logged In: YES user_id=21627 The component isn't vital. It shouldn't be relevant for building sunaudiodev whether an audio device is present in the system, as this device isn't necessary for *building* Python. Instead, presence of /usr/include/sys/audioio.h is necessary. I'm puzzled that this file isn't there (it is part of the core development environment, AFAIK); the build process assumes that the header is present if the system name is "sunos5". -- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-06 10:23 Message: Logged In: YES user_id=1597584 i would appreciate if the build completes without errors. i won't care if it attemts to build, but it should figure out that the sunaudiodev is not there. to my knowledge servers do not need that component. and python should not need it too then. do you see any reason why these components are vital for python? -- Comment By: Martin v. Löwis (loewis) Date: 2006-11-04 00:25 Message: Logged In: YES user_id=21627 It doesn't build the modules, as it doesn't succeed when attempting to. Why do you want it not to attempt? -- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-03 12:56 Message: Logged In: YES user_id=1597584 what do you suggest then to convince the build not to build it? -- Comment By: Martin v. Löwis (loewis) Date: 2006-11-02 06:40 Message: Logged In: YES user_id=21627 Re: enable/disable: What makes you think "sunaudiodev" and "tk" are valid values for "FEATURE"? configure --help lists the valid values for FEATURE, namely universalsdk, framework, shared, profiling, toolbox-glue, ipv6, and unicode. Re: there is a compilation error. Sure, an error is reported. However, compilation should not fail because of that. Instead, compilation should complete successfully, and just end up not building these modules. -- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-02 00:31 Message: Logged In: YES user_id=1597584 and there is no X on the server. ---
[ python-Bugs-1590864 ] subprocess deadlock
Bugs item #1590864, was opened at 2006-11-05 11:06 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590864&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 Private: No Submitted By: Michael Tsai (michaeltsai) >Assigned to: Peter Åstrand (astrand) Summary: subprocess deadlock Initial Comment: When I use subprocess.py from a child thread, sometimes it deadlocks. I determined that the new process is blocked during an import: #0 0x90024427 in semaphore_wait_signal_trap () #1 0x90028414 in pthread_cond_wait () #2 0x004c77bf in PyThread_acquire_lock (lock=0x3189a0, waitflag=1) at Python/thread_pthread.h:452 #3 0x004ae2a6 in lock_import () at Python/import.c:266 #4 0x004b24be in PyImport_ImportModuleLevel (name=0xaad74 "errno", globals=0xbaed0, locals=0x502aa0, fromlist=0xc1378, level=-1) at Python/import.c:2054 #5 0x0048d2e2 in builtin___import__ (self=0x0, args=0x53724c90, kwds=0x0) at Python/bltinmodule.c:47 #6 0x0040decb in PyObject_Call (func=0xa94b8, arg=0x53724c90, kw=0x0) at Objects/abstract.c:1860 and that the code in question is in os.py: def _execvpe(file, args, env=None): from errno import ENOENT, ENOTDIR I think the problem is that since exec (the C function) hasn't yet been called in the new process, it's inherited from the fork a lock that's already held. The main process will eventually release its copy of the lock, but this will not unlock it in the new process, so it deadlocks. If I change os.py so that it imports the constants outside of _execvpe, the new process no longer blocks in this way. This is on Mac OS X 10.4.8. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590864&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1566331 ] Bad behaviour in .obuf*
Bugs item #1566331, was opened at 2006-09-27 09:19 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566331&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.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Sam Dennis (samdennis) >Assigned to: Greg Ward (gward) Summary: Bad behaviour in .obuf* Initial Comment: The _ssize() function in ossaudiodev.c (2.4.3, but it's the same in svn) calls SNDCTL_SET_CHANNELS with channels=0 as part of an attempt to determine the total number of samples per second for the current configuration of the audio device, but as far as I can tell this is not guaranteed to act as a query and at least two implementations treat it as a request for a monaural format (the ALSA pcm-oss module and the alsa-oss library). What this can safely be replaced with I don't know; both Linux's OSS drivers and ALSA support SOUND_PCM_READ_CHANNELS but this is not standard to the best of my knowledge. Storing the value returned when the program calls .setfmt or .setparameters may be an option. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566331&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1202533 ] a bunch of infinite C recursions
Bugs item #1202533, was opened at 2005-05-15 16:43 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Armin Rigo (arigo) Assigned to: Armin Rigo (arigo) Summary: a bunch of infinite C recursions Initial Comment: There is a general way to cause unchecked infinite recursion at the C level, and I have no clue at the moment how it could be reasonably fixed. The idea is to define special __xxx__ methods in such a way that no Python code is actually called before they invoke more special methods (e.g. themselves). >>> class A: pass >>> A.__mul__=new.instancemethod(operator.mul,None,A) >>> A()*2 Segmentation fault -- >Comment By: Brett Cannon (bcannon) Date: 2006-11-06 15:27 Message: Logged In: YES user_id=357491 I was waiting on Armin to do a final review, but if you are willing to sign off on it I can check it in. And I agree that it isn't worth backporting to 2.5 because of the hassle. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-11-05 16:41 Message: Logged In: YES user_id=33168 What's the status of this patch? It seems like it's ready to checkin. Since this change isn't b/w compatible, should we do anything to fix these in 2.5? For example, bug 1590036. We could add recursion checks one by one, but I'm tempted to ignore 2.5. It seems too little of a gain to fix 2.5 and 2.6 in incompatible ways for such unlikely bugs like these. -- Comment By: Brett Cannon (bcannon) Date: 2006-06-30 17:46 Message: Logged In: YES user_id=357491 OK, new patch, with the check in PyObject_Call() (and thus slot_tp_call() recursion check removed), the addition of PyExc_RecursionErrorInst which is an instance of RuntimeError and a reasonable message set, and PyErr_NormalizeException() checking the recursion depth directly and using PyExc_RecursionErrorInst when the limit is hit. Hopefully this does it. =) -- Comment By: Brett Cannon (bcannon) Date: 2006-06-30 10:06 Message: Logged In: YES user_id=357491 Seems reasonable to me. I will try to cook up a patch after I am done trying to fix the xml_parsers.py crasher. -- Comment By: Armin Rigo (arigo) Date: 2006-06-30 00:14 Message: Logged In: YES user_id=4771 Looks quite obscure, a hack to avoid the bad effects of the previous hack of temporarily decreasing the recursion depth (which no other piece of code does). I'd be much more confident that I'm looking at correct code if we used a more explicit approach. What about a prebuilt RuntimeError instance with the message "maximum recursion depth exceeded", similar to the prebuilt MemoryError instance? Then at least PyObject_Call() could raise this instance directly, with PyErr_SetObject(). We'd get an already-normalized exception in this way, and remove any need for tstate recursion_depth mangling. -- Comment By: Brett Cannon (bcannon) Date: 2006-06-26 12:31 Message: Logged In: YES user_id=357491 Yes, Armin, that is a rather evil piece of code. =) But I have a possible simple solution. =) If you add a check after the PyExceptionClass_Check() in the 'if' statement that tstate->recursion_depth is greater than 0, you short-circuit the infinite recursion and still get a sensible output. I have attached a patch with my proposed changes for PyObject_Call() and PyErr_NormalizeException() and the remove of the recursion check for slot_tp_call(). The only issue I can see with this is if the recursion_depth check turns out to be too small of a number. But I really doubt that will be an issue since one shouldn't be having a depth of tracebacks greater than the current recursion depth. Let me know what you think of the patch. -- Comment By: Armin Rigo (arigo) Date: 2006-06-25 02:33 Message: Logged In: YES user_id=4771 Yes, it seems reasonable. You should probably manipulate tstate->recursion_depth directly instead of via the macros, as e.g. ceval.c does. This would fix most crashes here. It would make the attached test17.py segfault, though. This test17 already segfaults a debug build of Python, but not a release build because the recursive PyErr_NormalizeException() is turned into a tail call by gcc. (What, a convoluted
[ python-Bugs-1202533 ] a bunch of infinite C recursions
Bugs item #1202533, was opened at 2005-05-15 16:43 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Armin Rigo (arigo) Assigned to: Armin Rigo (arigo) Summary: a bunch of infinite C recursions Initial Comment: There is a general way to cause unchecked infinite recursion at the C level, and I have no clue at the moment how it could be reasonably fixed. The idea is to define special __xxx__ methods in such a way that no Python code is actually called before they invoke more special methods (e.g. themselves). >>> class A: pass >>> A.__mul__=new.instancemethod(operator.mul,None,A) >>> A()*2 Segmentation fault -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-11-06 15:58 Message: Logged In: YES user_id=33168 Armin mentioned in the other bug that if this patch fixes that too (class ... __getattr__ = getattr), this patch should be applied. It seems to be generally in the right direction. I did review the patch and couldn't find any issues. I'm sure Armin will speak up if he disagrees. So go ahead and check in when you are ready. Don't forget to move all the crashers tests into the real test suites and include tests for getattr/hasattr from the other bug report. Thanks! -- Comment By: Brett Cannon (bcannon) Date: 2006-11-06 15:27 Message: Logged In: YES user_id=357491 I was waiting on Armin to do a final review, but if you are willing to sign off on it I can check it in. And I agree that it isn't worth backporting to 2.5 because of the hassle. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-11-05 16:41 Message: Logged In: YES user_id=33168 What's the status of this patch? It seems like it's ready to checkin. Since this change isn't b/w compatible, should we do anything to fix these in 2.5? For example, bug 1590036. We could add recursion checks one by one, but I'm tempted to ignore 2.5. It seems too little of a gain to fix 2.5 and 2.6 in incompatible ways for such unlikely bugs like these. -- Comment By: Brett Cannon (bcannon) Date: 2006-06-30 17:46 Message: Logged In: YES user_id=357491 OK, new patch, with the check in PyObject_Call() (and thus slot_tp_call() recursion check removed), the addition of PyExc_RecursionErrorInst which is an instance of RuntimeError and a reasonable message set, and PyErr_NormalizeException() checking the recursion depth directly and using PyExc_RecursionErrorInst when the limit is hit. Hopefully this does it. =) -- Comment By: Brett Cannon (bcannon) Date: 2006-06-30 10:06 Message: Logged In: YES user_id=357491 Seems reasonable to me. I will try to cook up a patch after I am done trying to fix the xml_parsers.py crasher. -- Comment By: Armin Rigo (arigo) Date: 2006-06-30 00:14 Message: Logged In: YES user_id=4771 Looks quite obscure, a hack to avoid the bad effects of the previous hack of temporarily decreasing the recursion depth (which no other piece of code does). I'd be much more confident that I'm looking at correct code if we used a more explicit approach. What about a prebuilt RuntimeError instance with the message "maximum recursion depth exceeded", similar to the prebuilt MemoryError instance? Then at least PyObject_Call() could raise this instance directly, with PyErr_SetObject(). We'd get an already-normalized exception in this way, and remove any need for tstate recursion_depth mangling. -- Comment By: Brett Cannon (bcannon) Date: 2006-06-26 12:31 Message: Logged In: YES user_id=357491 Yes, Armin, that is a rather evil piece of code. =) But I have a possible simple solution. =) If you add a check after the PyExceptionClass_Check() in the 'if' statement that tstate->recursion_depth is greater than 0, you short-circuit the infinite recursion and still get a sensible output. I have attached a patch with my proposed changes for PyObject_Call() and PyErr_NormalizeException() and the remove of the recursion check for slot_tp_call(). The only issue I can see with this is if the recursion_depth check turns out to be too small of a number. But I really doubt that will be an issue since one shouldn't be having a depth of tracebacks greater than the c
[ python-Bugs-1591122 ] problem building python in vs8express
Bugs item #1591122, was opened at 2006-11-05 20:31 Message generated for change (Comment added) made by thomashsouthern You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1591122&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: Thomas Southern (thomashsouthern) Assigned to: Nobody/Anonymous (nobody) Summary: problem building python in vs8express Initial Comment: When I tried to build pythoncore in vc++8 express, it worked without a hitch until the link stage when i got an unresolved external _init_types. Python compiles just fine and pythonw compiles up to the link where it comes accross the same error. If I am suppose to contact someone else about my issue please sent me in the wright direction. my email is [EMAIL PROTECTED] -- >Comment By: Thomas Southern (thomashsouthern) Date: 2006-11-06 16:59 Message: Logged In: YES user_id=1638546 I am using python 2.5 -- Comment By: Georg Brandl (gbrandl) Date: 2006-11-05 23:46 Message: Logged In: YES user_id=849994 Which version of the sources are you using? I think this is fixed in the SVN HEAD. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1591122&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1591774 ] Urllib2.urlopen() raises OSError w/bad HTTP Location header
Bugs item #1591774, was opened at 2006-11-07 03:08 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=1591774&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 Private: No Submitted By: nikitathespider (nikitathespider) Assigned to: Nobody/Anonymous (nobody) Summary: Urllib2.urlopen() raises OSError w/bad HTTP Location header Initial Comment: The documentation for urllib2.urlopen() says that it "[r]aises URLError on errors". But if urllib2 requests a resource from a (misconfigured) Web server and that server returns 302 response with the Location header set to "file:", urlopen raises "OSError: [Errno 2] No such file or directory: ''". I have seen such a misconfiguration in the wild; I've also created a URL on my server that reproduces the problem in case the real-world URL disappears or is fixed. Both URLs are in the attachment with code to reproduce the problem. I can recreate this under Python 2.3 - 2.5 under Mac OS X, FreeBSD and Win2k. I would be satisfied if the module simply followed the documentation and actually returned URLError. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1591774&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1570255 ] redirected cookies
Bugs item #1570255, was opened at 2006-10-04 09:37 Message generated for change (Comment added) made by hans_moleman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1570255&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: hans_moleman (hans_moleman) Assigned to: Nobody/Anonymous (nobody) Summary: redirected cookies Initial Comment: Cookies are not resend when a redirect is requested. Blurb: I've been trying to get a response off a server using Python. The response so far differs from the response using Firefox. In Python, I have set headers and cookies the way Firefox does it. I noticed that the server accepts the POST request, and redirects the client to another address with the result on it. This happens both with Python and Firefox correctly. Cookie handling differs though: The Python client, when redirected, using the standard redirect handler, does not resend its cookies to the redirected address. Firefox does resend the cookies from the original request. When I redefine the redirect handler and code it so that it adds the cookies from the original request, the response is the same as Firefox's response. This confirms then that resending cookies is required to get the server to respond correctly. Is the default Python redirection cookie policy different from Firefox's policy? Could we improve the default redirection handler to work like Firefox? Is it a bug? I noticed an old open bug report 511786, that looks very much like this problem. It suggests it is fixed. Cheers Hans Moleman. -- >Comment By: hans_moleman (hans_moleman) Date: 2006-11-07 16:59 Message: Logged In: YES user_id=1610873 I believe that a bit of coding is missing. When a cookie is added in 'add_cookie_header' in cookielib.py, it is added under the request.unredirected_hdrs. Line 1317. When a request is resend after a redirect request in 'redirect_request' in urllib2.py, the request.headers are used. Line 509. Additional coding is required that moves cookies from 'unredirected_hdrs' to 'headers' if the domain of the original request matches the domain of the redirected request. I've used http://www.w3.org/Protocols/rfc2109/rfc2109 for that. No idea if that rfc is still current though. -- Comment By: hans_moleman (hans_moleman) Date: 2006-10-30 07:53 Message: Logged In: YES user_id=1610873 OK. I'll have a look at that. Thanks for the pointers. -- Comment By: A.M. Kuchling (akuchling) Date: 2006-10-28 01:16 Message: Logged In: YES user_id=11375 Given the sensitive data in your script, it's certainly best to not post it. You'll have to dig into urllib2 yourself, I think. Start by looking at the code in redirect_request(), around line 520 of urllib2.py, and adding some debug prints. Print out the contents of req.headers; is the cookie line in there? Change the __init__ of AbstractHTTPHandler to default debuglevel to 1, not 0; this will print out all the HTTP lines being sent and received. -- Comment By: hans_moleman (hans_moleman) Date: 2006-10-27 17:20 Message: Logged In: YES user_id=1610873 I am using this script to obtain monthly internet usage statistics from my ISP. My ISP provides a screen via HTTPS, to enter a usercode and password, after which the usage statistics are displayed on a different address. I cannot send this script with my usercode and password. My ISP might not like me doing this either. Therefore I'll try to find another server that behaves similarly, and send you that. -- Comment By: A.M. Kuchling (akuchling) Date: 2006-10-27 09:16 Message: Logged In: YES user_id=11375 More detail is needed to figure out if there's a problem; can you give a sample URL to exhibit the problem? can you provide your code? From the description, it's unclear if this might be a bug in the handling of redirects or in the CookieProcessor class. The bug in 511786 is still fixed; that bug includes sample code, so I could check it. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1570255&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1202533 ] a bunch of infinite C recursions
Bugs item #1202533, was opened at 2005-05-15 23:43 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Armin Rigo (arigo) Assigned to: Armin Rigo (arigo) Summary: a bunch of infinite C recursions Initial Comment: There is a general way to cause unchecked infinite recursion at the C level, and I have no clue at the moment how it could be reasonably fixed. The idea is to define special __xxx__ methods in such a way that no Python code is actually called before they invoke more special methods (e.g. themselves). >>> class A: pass >>> A.__mul__=new.instancemethod(operator.mul,None,A) >>> A()*2 Segmentation fault -- >Comment By: Armin Rigo (arigo) Date: 2006-11-07 04:33 Message: Logged In: YES user_id=4771 Yes, the patch fixes the other bug too. It looks ready to be checked in (the examples should be added as tests). All the crashers/infinite_rec_*.py now pass, but infinite_rec_2 produces no output instead of a RuntimeError. This is probably an unrelated problem swallowing the exception silently... -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-11-06 23:58 Message: Logged In: YES user_id=33168 Armin mentioned in the other bug that if this patch fixes that too (class ... __getattr__ = getattr), this patch should be applied. It seems to be generally in the right direction. I did review the patch and couldn't find any issues. I'm sure Armin will speak up if he disagrees. So go ahead and check in when you are ready. Don't forget to move all the crashers tests into the real test suites and include tests for getattr/hasattr from the other bug report. Thanks! -- Comment By: Brett Cannon (bcannon) Date: 2006-11-06 23:27 Message: Logged In: YES user_id=357491 I was waiting on Armin to do a final review, but if you are willing to sign off on it I can check it in. And I agree that it isn't worth backporting to 2.5 because of the hassle. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-11-06 00:41 Message: Logged In: YES user_id=33168 What's the status of this patch? It seems like it's ready to checkin. Since this change isn't b/w compatible, should we do anything to fix these in 2.5? For example, bug 1590036. We could add recursion checks one by one, but I'm tempted to ignore 2.5. It seems too little of a gain to fix 2.5 and 2.6 in incompatible ways for such unlikely bugs like these. -- Comment By: Brett Cannon (bcannon) Date: 2006-07-01 00:46 Message: Logged In: YES user_id=357491 OK, new patch, with the check in PyObject_Call() (and thus slot_tp_call() recursion check removed), the addition of PyExc_RecursionErrorInst which is an instance of RuntimeError and a reasonable message set, and PyErr_NormalizeException() checking the recursion depth directly and using PyExc_RecursionErrorInst when the limit is hit. Hopefully this does it. =) -- Comment By: Brett Cannon (bcannon) Date: 2006-06-30 17:06 Message: Logged In: YES user_id=357491 Seems reasonable to me. I will try to cook up a patch after I am done trying to fix the xml_parsers.py crasher. -- Comment By: Armin Rigo (arigo) Date: 2006-06-30 07:14 Message: Logged In: YES user_id=4771 Looks quite obscure, a hack to avoid the bad effects of the previous hack of temporarily decreasing the recursion depth (which no other piece of code does). I'd be much more confident that I'm looking at correct code if we used a more explicit approach. What about a prebuilt RuntimeError instance with the message "maximum recursion depth exceeded", similar to the prebuilt MemoryError instance? Then at least PyObject_Call() could raise this instance directly, with PyErr_SetObject(). We'd get an already-normalized exception in this way, and remove any need for tstate recursion_depth mangling. -- Comment By: Brett Cannon (bcannon) Date: 2006-06-26 19:31 Message: Logged In: YES user_id=357491 Yes, Armin, that is a rather evil piece of code. =) But I have a possible simple solution. =) If you add a check after the PyExceptionClass_Check() in the 'if' statement that tstate->recursion_depth is
[ python-Bugs-1531415 ] parsetok.c emits warnings by writing to stderr
Bugs item #1531415, was opened at 2006-07-31 07:37 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531415&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: Jp Calderone (kuran) Assigned to: Nobody/Anonymous (nobody) Summary: parsetok.c emits warnings by writing to stderr Initial Comment: Warnings should be emitted with the warning system, via PyErr_Warn. -- >Comment By: Anthony Baxter (anthonybaxter) Date: 2006-11-07 17:03 Message: Logged In: YES user_id=29957 Should we change these to all just default to a SyntaxWarning? I agree that just spitting out warnings to stderr is extremely suboptimal. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531415&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1531415 ] parsetok.c emits warnings by writing to stderr
Bugs item #1531415, was opened at 2006-07-31 07:37 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531415&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: Jp Calderone (kuran) Assigned to: Nobody/Anonymous (nobody) Summary: parsetok.c emits warnings by writing to stderr Initial Comment: Warnings should be emitted with the warning system, via PyErr_Warn. -- >Comment By: Anthony Baxter (anthonybaxter) Date: 2006-11-07 17:07 Message: Logged In: YES user_id=29957 Neal points out there could be a bootstrapping problem if warnings.py needs to be imported. We could do something like check for 'warnings' in sys.modules, and still default to stderr if it's not been imported. A more thorough fix is to get warnings.py converted to C code, but that's going to be a 2.6 thing, not a 2.5.1 thing. -- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-11-07 17:03 Message: Logged In: YES user_id=29957 Should we change these to all just default to a SyntaxWarning? I agree that just spitting out warnings to stderr is extremely suboptimal. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531415&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
