[ python-Bugs-1163563 ] Sub threads execute in restricted mode
Bugs item #1163563, was opened at 2005-03-15 09:56 Message generated for change (Comment added) made by yetanothermax You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163563&group_id=5470 Category: Threads Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: anothermax (yetanothermax) Assigned to: Nobody/Anonymous (nobody) Summary: Sub threads execute in restricted mode Initial Comment: I'm using the JEP product which allows integration of Java with Python (see http://jepp.sourceforge.net) via starting a Python interpreter in the same process as the JVM. This integrates with python via the C interface, allowing the user to 'eval' python code (amongst other features). It seems that since Python 2.3.5 any threads (using the threading module) created via code that has been evaluated through the jep.eval() interface (i.e.Python C interface )are executed in restricted mode and cannot, for example, create files. Code that is just evaled (i.e not in a subthread) thread has no restrictions. The error reported is: IOError: file() constructor not accessible in restricted mode (see http://sourceforge.net/forum/forum.php? thread_id=1247793&forum_id=376782) - I've given a JEP specific example here. There seems to be a similar problem with mod_python (see http://www.modpython.org/pipermail/mod_python/2005- January/017129.html) Reading through the release notes for Python 2.3.5 I see: Bug #754449: threading.Thread will no longer mask exceptions raised during interpreter shutdown with another exception caused by attempting to output the initial exception. This fix also includes a backport of rev. 1.41 from HEAD. This might be the problem as it seems to involve the porting of 2.4 threading code back to the 2.3 tree. I've attached a Java file which shows the problem when using JEP. The error output is: Exception in thread Thread-1: Traceback (most recent call last): File "C:\Python24\Lib\threading.py", line 442, in __bootstrap File "", line 5, in run IOError: file() constructor not accessible in restricted mode 2.4.1c1 (#63, Mar 10 2005, 10:36:41) [MSC v.1310 32 bit (Intel)] Creating file from main thread... Done Creating file from sub thread... Done -- >Comment By: anothermax (yetanothermax) Date: 2005-04-21 14:05 Message: Logged In: YES user_id=1218811 I've attached a file (threadtest.c) that is adapted from the the way JEP uses Py_NewInterpreter. This runs correctly under 2.3.4 but fails under 2.3.5 and later Pythons. -- Comment By: mrjohnson (mrjohnson0) Date: 2005-04-21 07:51 Message: Logged In: YES user_id=1044885 In interactive mode, Jep uses Py_NewInterpreter, Py_CompileString, and PyRun_String for its eval(). This file handles java -> python: http://204.156.146.230/cgi-bin/viewcvs.cgi/jep/pyembed.c?rev=1.29&content-type=text/vnd.viewcvs-markup You'd be looking for pyembed_eval(). -- Comment By: Mark Hammond (mhammond) Date: 2005-04-21 05:11 Message: Logged In: YES user_id=14198 Can anyone tell me specifically what Python C API function is involved here? ie, the "entry point" that these external threads use to call into Python. -- Comment By: anothermax (yetanothermax) Date: 2005-04-20 13:51 Message: Logged In: YES user_id=1218811 I didn't see jbelmote's comment, perhaps my updated threadmodule.c will reopen the #1010677 bug. -- Comment By: anothermax (yetanothermax) Date: 2005-04-20 13:39 Message: Logged In: YES user_id=1218811 Here's the updated threadmodule.c for 2.4.1 -- Comment By: anothermax (yetanothermax) Date: 2005-04-20 13:36 Message: Logged In: YES user_id=1218811 I've finally got access to a C compiler and it looks like the 'pure' Python changes for #754449 are in the clear (apologies to bcannon). The problem actually seems to relate to changes to threadmodule.c of the Python Modules directory. In versions greater than 2.3.4 it uses the PyGILState_XXX constructs t_bootstrap() function. These do not seem to be compatible with running sub interpreters as JEP (and probably mod_python) do. The python documentation (http://docs.python.org/api/threads.html) says "Note that the PyGILState_*() functions assume there is only one global interpreter (created automatically by Py_Initialize()). Python still supports the creation of additional interpreters (using Py_NewInterpreter()), but mixing multiple interpreters and the PyGILState_*() API is unsupported. " I've compiled a new versions of the python2X.dll for both 2.3.5 and 2.4.1 changing the use of these PyGIL_S
[ python-Bugs-1184449 ] Read-only property attributes raise wrong exception
Bugs item #1184449, was opened at 2005-04-16 19:16 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1184449&group_id=5470 Category: Python Interpreter Core Group: Python 2.5 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Read-only property attributes raise wrong exception Initial Comment: In http://mail.python.org/pipermail/python-dev/2005-April/052681.html I describe how attributes defined as properties raise inconsistent errors depending on whether the property is defined in C or Python. By default in C, you'll get a TypeError while in Python you'll get an AttributeError. I think both should raise AttributeErrors. Here is a patch against Python 2.4 which should be ported to 2.5 (and possibly 2.3 if we care). -- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-04-21 09:18 Message: Logged In: YES user_id=12800 The change is in 2.5 and will /not/ be backported to 2.4. -- Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-04-16 19:23 Message: Logged In: YES user_id=12800 Well, I was going to attach a patch, but it seems SF is borked and won't let me upload anything (yes the stupid checkbox was checked). The patch is simple though: change PyExc_TypeError to PyExc_AttributeError on lines 147 and 202 in Objects/descrobject.c (rev 2.38) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1184449&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1184380 ] example broken in section 1.12 of Extending & Embedding
Bugs item #1184380, was opened at 2005-04-16 19:36 Message generated for change (Comment added) made by lbruno You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1184380&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 1 Submitted By: bamoore (bamoore) Assigned to: Nobody/Anonymous (nobody) Summary: example broken in section 1.12 of Extending & Embedding Initial Comment: In section 1.12 of Extending and Embedding the Python Interpreter Release 2.4, the example (spammodule) does not compile on linux with distutils. I get the following: ~/sandbox/python/c_api_test$ python2.4 spam-setup.py build running build running build_ext building 'spam' extension creating build creating build/temp.linux-i686-2.4 gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I/usr/include/python2.4 -c spammodule.c -o build/temp.linux-i686-2.4/spammodule.o spammodule.c:7: error: conflicting types for `PySpam_System' spammodule.h:21: error: previous declaration of `PySpam_System' error: command 'gcc' failed with exit status 1 I think the solution is to change line 12 of the spammodule header file listing from: #define PySpam_System_PROTO (char *command) to: #define PySpam_System_PROTO (const char *command) as that seems to compile for me. (though not tested from another C extension). -- Comment By: Luis Bruno (lbruno) Date: 2005-04-21 14:05 Message: Logged In: YES user_id=1263795 AIUI, your solution is correct; a cursory glance through the PyArg_ParseTuple() documentation and the system() manual page leads me to believe we're expecting a const char *. I'll submit a patch. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1184380&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1187437 ] TypeError message on bad iteration is misleading
Bugs item #1187437, was opened at 2005-04-21 10:58 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=1187437&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Roy Smith (roysmith) Assigned to: Nobody/Anonymous (nobody) Summary: TypeError message on bad iteration is misleading Initial Comment: >>> for i in 5: ... pass ... Traceback (most recent call last): File "", line 1, in ? TypeError: iteration over non-sequence I know this is kind of a trivial point, but the message "iteration of non-sequence" should really be something like "iteration of non-iterable object", since not all iterable things are sequences. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1187437&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1187437 ] TypeError message on bad iteration is misleading
Bugs item #1187437, was opened at 2005-04-21 10:58 Message generated for change (Settings changed) made by roysmith You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1187437&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None >Priority: 2 Submitted By: Roy Smith (roysmith) Assigned to: Nobody/Anonymous (nobody) Summary: TypeError message on bad iteration is misleading Initial Comment: >>> for i in 5: ... pass ... Traceback (most recent call last): File "", line 1, in ? TypeError: iteration over non-sequence I know this is kind of a trivial point, but the message "iteration of non-sequence" should really be something like "iteration of non-iterable object", since not all iterable things are sequences. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1187437&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1178624 ] 2.4.1 breaks pyTTS
Bugs item #1178624, was opened at 2005-04-07 17:25
Message generated for change (Comment added) made by doerwalter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178624&group_id=5470
Category: None
Group: None
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Dieter Deyke (deyke)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.4.1 breaks pyTTS
Initial Comment:
On my Windows XP PRO SP2 system, the combination of
Python 2.4, pywin32-203.win32-py2.4, and
pyTTS-3.0.win32-py2.4 did work. Updating to 2.4.1 broke
pyTTS. Removing everythin, then installing 2.4.1,
win32, and pyTTS resulted in the same failure. Removing
everything again, and installing 2.4, win32, and pyTTS
fixed it again.
The problem is that with 2.4.1 pyTTS reported that
"SAPI" was not supported. Looking deeper I saw that it
got a syntax error reading a generated com interface file.
--
>Comment By: Walter Dörwald (doerwalter)
Date: 2005-04-21 22:57
Message:
Logged In: YES
user_id=89016
I think this is a duplicate of 1175396, so I'm closing the
report.
--
Comment By: Walter Dörwald (doerwalter)
Date: 2005-04-07 22:33
Message:
Logged In: YES
user_id=89016
There's no uploaded file! You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.
Please try again.
(This is a SourceForge annoyance that we can do
nothing about. :-( )
--
Comment By: Dieter Deyke (deyke)
Date: 2005-04-07 18:49
Message:
Logged In: YES
user_id=132928
I attached the generated interface file. Loading this file
into python by itself does NOT generate an error, but going
into the pyTTS dir, starting python, and typing "import
sapi" shows:
C:\Python24\Lib\site-packages\pyTTS>python
Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more
information.
>>> import sapi
Traceback (most recent call last):
File "", line 1, in ?
File "C:\Python24\lib\site-packages\pyTTS\sapi.py", line
10, in ?
sapi_mod =
gencache.EnsureModule('{C866CA3A-32F7-11D2-9602-00C04F8EE628}',
0
, 5, 0)
File
"C:\Python24\lib\site-packages\win32com\client\gencache.py",
line 393, in
EnsureModule
module = GetModuleForTypelib(typelibCLSID, lcid, major,
minor)
File
"C:\Python24\lib\site-packages\win32com\client\gencache.py",
line 258, in
GetModuleForTypelib
mod = _GetModule(modName)
File
"C:\Python24\lib\site-packages\win32com\client\gencache.py",
line 629, in
_GetModule
mod = __import__(mod_name)
File
"C:\Python24\lib\site-packages\win32com\gen_py\C866CA3A-32F7-11D2-9602-00
C04F8EE628x0x5x0.py", line 1192
"""Add"""
^
SyntaxError: invalid syntax
>>>
--
Comment By: Walter Dörwald (doerwalter)
Date: 2005-04-07 17:56
Message:
Logged In: YES
user_id=89016
Can you post the generated inferface file? Does this file
contain long lines? Does it use a PEP 263 encoding directive?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178624&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1178484 ] Erroneous line number error in Py2.4.1
Bugs item #1178484, was opened at 2005-04-07 14:33 Message generated for change (Settings changed) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178484&group_id=5470 Category: Parser/Compiler Group: Python 2.4 Status: Open Resolution: Accepted Priority: 5 Submitted By: Timo Linna (tilinna) >Assigned to: Walter Dörwald (doerwalter) Summary: Erroneous line number error in Py2.4.1 Initial Comment: For some reason Python 2.3.5 reports the error in the following program correctly: File "C:\Temp\problem.py", line 7 SyntaxError: unknown decode error ..whereas Python 2.4.1 reports an invalid line number: File "C:\Temp\problem.py", line 2 SyntaxError: unknown decode error - problem.py starts - # -*- coding: ascii -*- """ Foo bar """ # Ä is not allowed in ascii coding - problem.py ends - Without the encoding declaration both Python versions report the usual deprecation warning (just like they should be doing). My environment: Windows 2000 + SP3. -- Comment By: Walter Dörwald (doerwalter) Date: 2005-04-07 16:28 Message: Logged In: YES user_id=89016 The reason for this is the new codec buffering code in 2.4: The codec might read and decode more data from the byte stream than is neccessary for decoding one line. I.e. when reading line n, the codec might decode bytes that belong to line n+1, n+2 etc. too. If there's a decoding error in this data, line n gets reported. I don't think there's a simple fix for this. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178484&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1175396 ] codecs.readline sometimes removes newline chars
Bugs item #1175396, was opened at 2005-04-02 17:14 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1175396&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: Accepted Priority: 5 Submitted By: Irmen de Jong (irmen) Assigned to: Walter Dörwald (doerwalter) Summary: codecs.readline sometimes removes newline chars Initial Comment: In Python 2.4.1 i observed a new bug in codecs.readline, it seems that with certain inputs it removes newline characters from the end of the line Probably related to bug #1076985 (Incorrect behaviour of StreamReader.readline leads to crash) and bug #1098990 codec readline() splits lines apart (both with status closed) so I'm assigning this to Walter. See the attached files that demonstrate the problem. Reproduced with Python 2.4.1 on windows XP and on Linux. The problem does not occur with Python 2.4. (btw, it seems bug #1076985 was fixed in python 2.4.1, but the other one (#1098990) not? ) -- >Comment By: Walter Dörwald (doerwalter) Date: 2005-04-21 23:55 Message: Logged In: YES user_id=89016 OK, I've checked in the following: Lib/codecs.py 1.44 Lib/test/test_codecs.py 1.23 Lib/codecs.py 1.35.2.7 Lib/test/test_codecs.py 1.15.2.5 with the following changes as suggested by glchapman: If a chunk read has a trailing "\r", read one more character even if the user has passed a size parameter. Remove the atcr logic. This should fix most of the problems. There are three open issues: 1) How do we handle the problem of a truncated line, if the data comes from the charbuffer instead of being read from the stream? 2) How do we handle error reporting? The buffering code might read more data than the current line. If this data has a decoding error the caller might report a wrong line number. (See bug #1178484) 3) Fixing the tokenizer. -- Comment By: Walter Dörwald (doerwalter) Date: 2005-04-15 20:16 Message: Logged In: YES user_id=89016 The current readline() is implemented so that even if the complete line ending (i.e. '\r\n') can't be read within size bytes, at least something that might work as a line end (i.e. '\r') is available at the end of the string, so that the user knowns that the line is complete. The atcr members makes sure that the '\n' that is read next isn't misinterpreted as another line. Unfortunately the import mechanisn doesn't work that way: It demands a '\n' as line terminator and will continue reading if it only finds the '\r'. This means that the '\n' will be skipped and the import mechanisn treats those two lines as one. IMHO the best solution would be the read the extra character even if size is None, as glchapman suggested, so the above situation would really only happen if the last character from the stream is '\r'. I think the tokenizer should be able to survive this. What it didn't survive in 2.4 was that readline() tried to get it's hand on a complete line even if the length of the line was way bigger than the size passed in. If we remove the "size is None" restriction from the current code, then I think we should remove the atcr logic too, because it could only happen under exceptional circumstances and the old handling might be better for those users that don't recognize '\r' as a line end. But in any case the tokenizer should be fixed to be able to handle any line length returned from readline(). I'd really like to get a review by Martin v. Löwis of glchapman's patch #1101726. Of course the simplest solution would be: "If you want a complete line, don't pass a size parameter to readline()". I don't know if it would make sense to change the PEP263 machinery to support this. The other problem is if readline() returns data from the charbuffer. I don't really see how this can be fixed. We might call read() with a size parameter even if there are characters in the charbuffer, but what happens if the user calls readline(size=10) first and then readline(size=10)? The first readline() call might put a very long string into the charbuffer and then the second call will return a unicode string whose length is in no way correlated to the size parameter. (This happens even even with the current code of course, so the message should be: Don't trust the size parameter, it only tells the underlying stream how many bytes to read (approximately), it's doesn't tell you *anything* about the amount of data returned.). This was different in 2.3.x, because the readline() method of the underlying stream was used, which handled this properly, but only worked if an encoded linefeed was recognizable as a normal 8bit '\n' linefeed by the underlying readline() (i.e. the UTF-16 encodings didn't work). -- Comment By: Greg C
[ python-Bugs-1117048 ] Dictionary Parsing Problem
Bugs item #1117048, was opened at 2005-02-05 17:50 Message generated for change (Comment added) made by walterbrunswick You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117048&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 2 Submitted By: WalterBrunswick (walterbrunswick) Assigned to: Nobody/Anonymous (nobody) Summary: Dictionary Parsing Problem Initial Comment: Python Version: Python 2.4 OS Version: Microsoft Windows XP [Version 5.1.2600] There may or may not be (according to some people on #python on irc.freenode.net) a fault, if you will, in the way that Python evaluates dictionaries (in this case, globals()). apparently printing of dicts are optimized not to produce the entire output string before printing it This may be an advantage when it comes to processing speed and memory management, but when it comes to catching errors, this could very well be a problem. (I am waltz.) ... you think it should print a dict with an error in it? ha! caught ya there! well, if there's an error, it should break. and it did. It shouldn't print AT ALL. why not? Because of the ERROR! ... I'm saying it should raise an abstract exception (something like DictError) BEFORE printing, as to allow the programmer to handle the error. Some people don't agree with my argument, but I'll let you (the core developers) decide what's best. I just thought I should mention this issue, to help improve Python to the max! -- >Comment By: WalterBrunswick (walterbrunswick) Date: 2005-04-21 22:59 Message: Logged In: YES user_id=1164416 As much as I'd like to take credit for writing the constants module, credit goes to Alex Martelli who submitted the script to the ActiveState Programmer Network (http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/652 07); however, I did append the __getattr__ attribute, as well as __delattr__ -- that is where the errors occurred. But again, lest we forget, the issue is the dictionary parsing problem, which I have clearly marked. But as it has been mentioned, data is streamed in blocks rather than buffered, as to save memory. I'm closing this report. Sorry for any inconvenience. -- Comment By: Sean Reifschneider (jafo) Date: 2005-04-19 23:48 Message: Logged In: YES user_id=81797 Just to chime in, I am ok with the current behavior. -- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-16 23:30 Message: Logged In: YES user_id=593130 The Python interpreter does not print blank lines except as requested. While a starting linefeed would look nicer in this particular circumstance (error while outputting), I would not want it for two reasons: 1) the circumstance is extremely rare, should usually only result from a program bug, and cannot hardly be detected, so a starting linefeed would nearly always produce an extraneous blank line; 2) without the linefeed, it is completely clear that the error occured in mid-sentence, so to speak. Looking at the informative output, which I don't see as nasty, I see the following: * the error occurred while trying to get the repr of the object (a module) associated with the name 'const'. * in const, you defined a function with the special name __getattr__, which apparently gets treated as a method that overrides the default. (I was not aware you could do this for modules.) * because of the presence of __getattr__, or perhaps because of something else in const, repr() asked const, via __getattr__, whether it has a method __repr__. * your __getattr__ raised proprietary const.ConstError * since this is something other than the expected "return the (computed) attribute value or raise an AttributeError exception" (Ref Man 3.3.2 Customizing attribute access), this ended the globals() call and triggered a traceback. Without seeing the code for const, I wonder whether you really need a custom __setattr__ and __getattr__ (once fixed) or should get rid of them and use the default mechanism. Unless you see a real bug that I missed, please close this report. -- Comment By: Scott Baldwin (linkmastersab) Date: 2005-02-16 19:08 Message: Logged In: YES user_id=1135743 My opinion on the most feasible solution is to simple insert a linebreak before the traceback begins, so that the traceback stands out more. An exception for this kind of trivial bug is too expensive for any good that would come out of it. -- Comment By: Scott Baldwin (linkmastersab) Date: 2005-02-16 19:05 Message: Logged In: YES user_id=1135743 My opinion on the most feasible solution is to simple insert a linebreak
