[ python-Bugs-1250389 ] The -m option to python does not search zip files
Bugs item #1250389, was opened at 2005-08-03 02:55 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1250389&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Paul Moore (pmoore) Assigned to: Nobody/Anonymous (nobody) Summary: The -m option to python does not search zip files Initial Comment: The -m option, to run a module from sys.path as a main program, does not work when the module is in a zip file. Here is an example demonstrating: D:\Data>type zipmtest.py def a(): print "Hello, world" if __name__ == '__main__': a() D:\Data>python -m zipmtest Hello, world D:\Data>zip -9 zipm zipmtest.* adding: zipmtest.py (92 bytes security) (deflated 8%) D:\Data>set PYTHONPATH=zipm.zip D:\Data>del zipmtest.py Deleting D:\Data\zipmtest.py 1 file deleted D:\Data>python -m zipmtest python: module zipmtest not found D:\Data>python -c "import zipmtest" (note the last import - python can find the zipmtest module quite happily, but -m misses it). This is a fairly severe limitation on -m, particularly as use of "egg" distributions (which are basically zipfiles) becomes more common. -- >Comment By: Nick Coghlan (ncoghlan) Date: 2005-11-10 19:05 Message: Logged In: YES user_id=1038590 I agree this is a significant limitation on -m, although I think it actually pales in comparison to the fact you can't use modules inside packages. So please take a look at PEP 328 and provide feedback on it. I've had absolutely *zero* feedback on it since I wrote it, and have had to assume that no-one else was bothered by the current limitations. -- Comment By: Paul Moore (pmoore) Date: 2005-08-12 04:33 Message: Logged In: YES user_id=113328 I have looked into this, and it appears that _PyImportHooks_Init is getting called properly, and the zipimport mechanism is getting initialised (python -v -m a where a.py is in a zip file on sys.path shows this). The problem seems to be that main.c calls, in Py_Main, _PyImport_FindModule, with the "loader" argument set to NULL, which disables handling of PEP 302 style import hooks. This makes sense, to the extent that the current code needs a real FILE* to call PyRun_AnyFileExFlags, it should be possible (by calling PyRun_SimpleStringFlags instead, maybe?) to execute a module loaded from a hook. Unfortunately, I can't take this any further at present, as I don't have the means to build Python in order to test a patch. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1250389&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1250389 ] The -m option to python does not search zip files
Bugs item #1250389, was opened at 2005-08-02 17:55 Message generated for change (Comment added) made by pmoore You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1250389&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Paul Moore (pmoore) Assigned to: Nobody/Anonymous (nobody) Summary: The -m option to python does not search zip files Initial Comment: The -m option, to run a module from sys.path as a main program, does not work when the module is in a zip file. Here is an example demonstrating: D:\Data>type zipmtest.py def a(): print "Hello, world" if __name__ == '__main__': a() D:\Data>python -m zipmtest Hello, world D:\Data>zip -9 zipm zipmtest.* adding: zipmtest.py (92 bytes security) (deflated 8%) D:\Data>set PYTHONPATH=zipm.zip D:\Data>del zipmtest.py Deleting D:\Data\zipmtest.py 1 file deleted D:\Data>python -m zipmtest python: module zipmtest not found D:\Data>python -c "import zipmtest" (note the last import - python can find the zipmtest module quite happily, but -m misses it). This is a fairly severe limitation on -m, particularly as use of "egg" distributions (which are basically zipfiles) becomes more common. -- >Comment By: Paul Moore (pmoore) Date: 2005-11-10 10:26 Message: Logged In: YES user_id=113328 I assume you meant PEP 338. I'm completely in favour of that. I didn't give feedback simply because I had nothing constructive to add beyond "+1"... (And I agree that PEP 338 is more important than this bug - but I'd like to see both sorted :-)) -- Comment By: Nick Coghlan (ncoghlan) Date: 2005-11-10 09:05 Message: Logged In: YES user_id=1038590 I agree this is a significant limitation on -m, although I think it actually pales in comparison to the fact you can't use modules inside packages. So please take a look at PEP 328 and provide feedback on it. I've had absolutely *zero* feedback on it since I wrote it, and have had to assume that no-one else was bothered by the current limitations. -- Comment By: Paul Moore (pmoore) Date: 2005-08-11 19:33 Message: Logged In: YES user_id=113328 I have looked into this, and it appears that _PyImportHooks_Init is getting called properly, and the zipimport mechanism is getting initialised (python -v -m a where a.py is in a zip file on sys.path shows this). The problem seems to be that main.c calls, in Py_Main, _PyImport_FindModule, with the "loader" argument set to NULL, which disables handling of PEP 302 style import hooks. This makes sense, to the extent that the current code needs a real FILE* to call PyRun_AnyFileExFlags, it should be possible (by calling PyRun_SimpleStringFlags instead, maybe?) to execute a module loaded from a hook. Unfortunately, I can't take this any further at present, as I don't have the means to build Python in order to test a patch. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1250389&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1328278 ] __getslice__ taking priority over __getitem__
Bugs item #1328278, was opened at 2005-10-17 11:22 Message generated for change (Comment added) made by krumms You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1328278&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Josh Marshall (jpmarshall) Assigned to: Nobody/Anonymous (nobody) Summary: __getslice__ taking priority over __getitem__ Initial Comment: When creating a class that uses __getitem__ to implement slicing, if __getattr__ is also implemented, slicing will fail. This is due to the (deprecated) __getslice__ method being called before __getitem__. The attached file demonstrates this. If __getitem__ is implemented on its own, all is rosy. When we add __getattr__ and do not raise an AttributeError when __getslice__ is searched for, the slicing fails. If we raise this AttributeError, __getitem__ is called next. The only other reference I could find to this bug is on the jython mailing list, from 2003: http://sourceforge.net/mailarchive/forum.php? thread_id=2350972&forum_id=5586 My question is; why is __getslice__ called before __getitem__? I assumed that because it is deprecated, it would be the last resort for a slicing. Is this planned to be fixed, or is there existing behaviour that is reliant on it? -- Comment By: Thomas Lee (krumms) Date: 2005-11-11 00:48 Message: Logged In: YES user_id=315535 This seems to be the documented, expected behavior: http://www.python.org/doc/2.4.2/ref/sequence-methods.html As to _why_ __getslice__ is called before __getitem__, I'm not sure - but it's right there in the docs. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1328278&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1353269 ] poplib.POP3_SSL() class incompatible with socket.timeout
Bugs item #1353269, was opened at 2005-11-10 10:34 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=1353269&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.4 Status: Open Resolution: None Priority: 5 Submitted By: Charles (melicertes) Assigned to: Nobody/Anonymous (nobody) Summary: poplib.POP3_SSL() class incompatible with socket.timeout Initial Comment: If you call socket.setdefaulttimeout() to enable timeout mode, then create a POP3-over-SSL connection by instantiating a poplib.POP3_SSL() object, the resulting connection can hang because the underlying socket.ssl() object doesn't work when timeouts are enabled. If, after creating the POP3_SSL object, you call object.conn.sock.setblocking(1), the hangs will not happen. This is exactly the same bug as happened with IMAP SSL connections, as I reported in bug #977680. The Python documentation still does not mention that socket SSL support is not compatible with socket timeout support. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1353269&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1353344 ] python.desktop
Feature Requests item #1353344, was opened at 2005-11-10 19:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1353344&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: Installation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Björn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: python.desktop Initial Comment: I would very much like a /usr/share/applications/python.desktop file so that Python can be started from the Program-menu in Linux, just like you can from the Start-menu in Windows. I think it would be very neat and good for beginners. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1353344&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1353433 ] Http redirection error in urllib2.py
Bugs item #1353433, was opened at 2005-11-10 15:25
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=1353433&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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Dehn (dehn)
Assigned to: Nobody/Anonymous (nobody)
Summary: Http redirection error in urllib2.py
Initial Comment:
A url request returns a redirect that contains a space ' '
character. Python urllib2.py does not replace this
character with '%20' and fails.
Entering a line after line 507 of:
newurl=re.sub(' ','%20',newurl)
Corrects my problem.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1353433&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1346547 ] _subprocess.c calls PyInt_AsLong without error checking
Bugs item #1346547, was opened at 2005-11-03 03:34
Message generated for change (Settings changed) made by effbot
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1346547&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: 5
Submitted By: Luke (luked)
>Assigned to: Fredrik Lundh (effbot)
Summary: _subprocess.c calls PyInt_AsLong without error checking
Initial Comment:
_subprocess.c calls PyInt_AsLong without checking
whether the conversion produced an error.
This bug can cause an error to be reported at the wrong
point, eg:
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 subprocess
>>> si = subprocess.STARTUPINFO()
>>> si.wShowWindow = 2**65
>>> obj = subprocess.Popen('notepad.exe', startupinfo=si)
>>> 1+1
OverflowError: long int too large to convert to int
>>>
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-11-03 06:20
Message:
Logged In: YES
user_id=33168
This code (for startupinfo) is only valid on Windows. The
problem seems to be at lines 379 and 380 in
PC/_subprocess.c. I'll let someone who can test this one
take care of it. The return result from getint() needs to
be checked.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1346547&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1350498 ] CVS migration not in www.python.org docs
Bugs item #1350498, was opened at 2005-11-07 08:52 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1350498&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 Submitted By: Jim Jewett (jimjjewett) Assigned to: Brett Cannon (bcannon) Summary: CVS migration not in www.python.org docs Initial Comment: The development head has recently moved from CVS on sourceforge to subversion on python.org. The www.python.org documentation still sends people to the sourceforge cvs via (1) The left hand navigation link (main page) under Documenation section, python project, cvs. (The similar link on http://www.python.org/dev/ has been updated.) (2) The text of http://www.python.org/dev/ still says that deveopment takes place on sourceforge and sends people to the sourceforge cvs browser It also includes a link to (sourceforge) CVS instructions, but no mention of subversion. (3) The tools link then points to http://www.python. org/dev/tools.html, which still refers to CVS and CVS instructions. (4) The developer FAQ (http://www.python.org/dev/ devfaq.html) contains sections 1.2 and 1.4 for subversion (combine them?) and 1.3 for CVS -- section 1.3 seems to imply that the CVS tree is still active. -- >Comment By: Brett Cannon (bcannon) Date: 2005-11-10 13:49 Message: Logged In: YES user_id=357491 Everything but tools.html has been fixed. That doc really just needs to be replaced (see python-dev and the thread on the dev FAQ update for any discussion on the topic) and so fixing it is not on my list of things to do. =) I will leave this bug open, though, until the doc is deleted. -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-09 21:48 Message: Logged In: YES user_id=33168 Brett, did you finish updating all these docs? Is this bug dead now? -- Comment By: Martin v. Löwis (loewis) Date: 2005-11-07 15:19 Message: Logged In: YES user_id=21627 I fixed the first two. The latter will be modified later this year, or next year. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1350498&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1353504 ] Python drops core when stdin is bogus
Bugs item #1353504, was opened at 2005-11-10 16:16 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=1353504&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 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: Python drops core when stdin is bogus Initial Comment: Someone here at work had the bright idea to execute a Python script from a Solaris 10 ~/.dtprofile file. Apparently, at the time that script is run stdin is bogus. Python core dumps with this gdb backtrace: #0 0x0807d290 in PyDict_SetItem (op=0x815b79c, key=0x8163f20, value=0x0) at ../Objects/dictobject.c:549 #1 0x0807e0f7 in PyDict_SetItemString (v=0x815b79c, key=0x8118df2 "stdin", item=0x0) at ../Objects/dictobject.c:1988 #2 0x080e0d03 in _PySys_Init () at ../Python/sysmodule.c:977 #3 0x080ddfdb in Py_InitializeEx (install_sigs=1) at ../Python/pythonrun.c:190 #4 0x080dfa89 in Py_Initialize () at ../Python/pythonrun.c:283 #5 0x0805cd55 in Py_Main (argc=3, argv=0x8047c08) at ../Modules/main.c:418 #6 0x0805ca13 in main (argc=3, argv=0x8047c08) at ../Modules/python.c:23 (This is from 2.4.2, but it also happens in 2.3.4.) Looking at the code in _PySys_Init it calls sysin = PyFile_FromFile(stdin, "", "r", NULL); which returns NULL. In PyFile_FromFile it creates a new PyFileObject, then initializes it by calling a static function, fill_file_fields. This apparently fails, causing a NULL pointer return. Back in _PySys_Init it checks PyErr_Occurred, but fill_file_fields never raised an except. The NULL pointer is passed to PyDict_SetItemString and havoc ensues. I haven't checked CVS, but 2.4 (and probably 2.3) should be fixed. I suggest raising an IOError in fill_file_fields instead of just setting f to NULL and returning it. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1353504&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1346547 ] _subprocess.c calls PyInt_AsLong without error checking
Bugs item #1346547, was opened at 2005-11-03 03:34
Message generated for change (Comment added) made by effbot
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1346547&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: 5
Submitted By: Luke (luked)
Assigned to: Fredrik Lundh (effbot)
Summary: _subprocess.c calls PyInt_AsLong without error checking
Initial Comment:
_subprocess.c calls PyInt_AsLong without checking
whether the conversion produced an error.
This bug can cause an error to be reported at the wrong
point, eg:
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 subprocess
>>> si = subprocess.STARTUPINFO()
>>> si.wShowWindow = 2**65
>>> obj = subprocess.Popen('notepad.exe', startupinfo=si)
>>> 1+1
OverflowError: long int too large to convert to int
>>>
--
>Comment By: Fredrik Lundh (effbot)
Date: 2005-11-10 23:43
Message:
Logged In: YES
user_id=38376
I've added a fix to the subprocess patch over at
http://www.python.org/sf/1351997
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-11-03 06:20
Message:
Logged In: YES
user_id=33168
This code (for startupinfo) is only valid on Windows. The
problem seems to be at lines 379 and 380 in
PC/_subprocess.c. I'll let someone who can test this one
take care of it. The return result from getint() needs to
be checked.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1346547&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1351692 ] Switch to make pprint.pprint display ints and longs in hex
Feature Requests item #1351692, was opened at 2005-11-08 22:29 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1351692&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: None Status: Open Resolution: None Priority: 5 Submitted By: Mark Hirota (markhirota) Assigned to: Nobody/Anonymous (nobody) Summary: Switch to make pprint.pprint display ints and longs in hex Initial Comment: It would be nice to have some sort of switch or hook to allow 'pretty-printing' of integers and long integers in hexidecimal. So, for example: >>> import pprint >>> pprint.pprint(range(10)) # instead of this: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> pprint.hexint = True >>> pprint.pprint(range(10)) # you would get this: [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] >>> pprint.pprint(range(0x1,0x10010)) # and this: [0x1L, 0x10001L, 0x10002L, 0x10003L, 0x10004L, 0x10005L, 0x10006L, 0x10007L, 0x10008L, 0x10009L, 0x1000AL, 0x1000BL, 0x1000CL, 0x1000DL, 0x1000EL, 0x1000FL] >>> Thanks, --MH -- >Comment By: Walter Dörwald (doerwalter) Date: 2005-11-10 23:56 Message: Logged In: YES user_id=89016 In theory this should be possible by subclassing pprint.PrettyPrinter and overwritting the format method: import pprint class MyPrettyPrinter(pprint.PrettyPrinter): def format(self, object, context, maxlevels, level): if isinstance(object, int): return hex(object), True, False else: return pprint.PrettyPrinter.format(self, object, context, maxlevels, level) mpp = MyPrettyPrinter() mpp.pprint(range(50)) This doesn't work reliable though: When the string is short enough, format() seems to be bypassed and repr() is called directly. -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-11-09 22:45 Message: Logged In: YES user_id=1188172 Moving to Feature Requests. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1351692&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1163244 ] Syntax error on large file with MBCS encoding
Bugs item #1163244, was opened at 2005-03-14 15:20 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163244&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: Parser/Compiler Group: Python 2.4 Status: Open Resolution: Accepted Priority: 7 Submitted By: Tim N. van der Leeuw (tnleeuw) Assigned to: Nobody/Anonymous (nobody) Summary: Syntax error on large file with MBCS encoding Initial Comment: Large files generated by make-py.py from the win32all extensions cannot be compiled by Python2.4.1rc1 - they give a syntax error. This is a regression from 2.3.5 (With Python2.4, the interpreter crashes. That is fixed now.) Removing the mbcs encoding line from the top of the file, compilation succeeds. File should be attached, as zip-file. Probably requires win32all extensions to be installed to be compiled / imported (generated using build 203 of the win32all extensions). -- >Comment By: Tim Peters (tim_one) Date: 2005-11-10 22:31 Message: Logged In: YES user_id=31435 Is this still an issue in 2.4.2? I downloaded the zip file, and didn't have any problem importing the .py file on Windows using 2.4.2. A number of problems with encoding directives were fixed in 2.4.2, so I doubt that's an accident ;-) -- Comment By: James Kew (jkew) Date: 2005-08-04 13:10 Message: Logged In: YES user_id=598066 http://sourceforge.net/tracker/? func=detail&aid=1166627&group_id=78018&atid=551954 -- Comment By: Christos Georgiou (tzot) Date: 2005-08-04 03:50 Message: Logged In: YES user_id=539787 Are you sure about the bug number? pywin32 seems not to have such a bug. -- Comment By: James Kew (jkew) Date: 2005-08-04 02:56 Message: Logged In: YES user_id=598066 Is pywin32 bug 1166627 relevant/related? -- Comment By: Simon Dahlbacka (sdahlbac) Date: 2005-07-21 06:38 Message: Logged In: YES user_id=750513 For what it's worth: I have two files (that I unfortunately cannot attach) which works fine on 2.3 that now on 2.4.1 produces spurious syntax errors when they have # -*- coding: ascii -*- if I change that to something that does not match the coding regex I do not get any syntax error (winxp) -- Comment By: Niki Spahiev (nikis) Date: 2005-06-02 12:11 Message: Logged In: YES user_id=27708 i have reproductable test case with encoding cp1251 file is 1594 bytes long, how to attach it? -- Comment By: Walter Dörwald (doerwalter) Date: 2005-04-14 19:40 Message: Logged In: YES user_id=89016 Importing foo2.py on Linux (with the current CVS HEAD version of Python) gives me a segmentation fault with the following stacktrace: 0x080606cc in instance_repr (inst=0xb7c158bc) at Objects/classobject.c:880 880 classname = inst->in_class->cl_name; (gdb) bt #0 0x080606cc in instance_repr (inst=0xb7c158bc) at Objects/classobject.c:880 #1 0x08082235 in PyObject_Repr (v=0xb7c158bc) at Objects/object.c:308 #2 0x080f3ccd in err_input (err=0xbfffe000) at Python/pythonrun.c:1478 #3 0x080f3956 in PyParser_SimpleParseFileFlags (fp=0x818d6e0, filename=0xbfffe530 "foo2.py", start=257, flags=0) at Python/pythonrun.c:1348 #4 0x080f3982 in PyParser_SimpleParseFile (fp=0x818d6e0, filename=0xbfffe530 "foo2.py", start=257) at Python/pythonrun.c:1355 #5 0x080e6fef in parse_source_module (pathname=0xbfffe530 "foo2.py", fp=0x818d6e0) at Python/import.c:761 #6 0x080e72db in load_source_module (name=0xbfffe9d0 "foo2", pathname=0xbfffe530 "foo2.py", fp=0x818d6e0) at Python/import.c:885 #7 0x080e86b4 in load_module (name=0xbfffe9d0 "foo2", fp=0x818d6e0, buf=0xbfffe530 "foo2.py", type=1, loader=0x0) at Python/import.c:1656 #8 0x080e9d52 in import_submodule (mod=0x8145768, subname=0xbfffe9d0 "foo2", fullname=0xbfffe9d0 "foo2") at Python/import.c:2250 #9 0x080e9511 in load_next (mod=0x8145768, altmod=0x8145768, p_name=0xbfffedf0, buf=0xbfffe9d0 "foo2", p_buflen=0xbfffe9cc) at Python/import.c:2070 #10 0x080e8e5e in import_module_ex (name=0x0, globals=0xb7d62e94, locals=0xb7d62e94, fromlist=0x8145768) at Python/import.c:1905 #11 0x080e914b in PyImport_ImportModuleEx (name=0xb7cd8824 "foo2", globals=0xb7d62e94, locals=0xb7d62e94, fromlist=0x8145768) at Python/import.c:1946 #12 0x080b5c87 in builtin___import__ (self=0x0, args=0xb7d1e634) at Python/bltinmodule.c:45 #13 0x0811d32e i
[ python-Bugs-1163244 ] Syntax error on large file with MBCS encoding
Bugs item #1163244, was opened at 2005-03-15 07:20 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163244&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: Parser/Compiler Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Tim N. van der Leeuw (tnleeuw) Assigned to: Nobody/Anonymous (nobody) Summary: Syntax error on large file with MBCS encoding Initial Comment: Large files generated by make-py.py from the win32all extensions cannot be compiled by Python2.4.1rc1 - they give a syntax error. This is a regression from 2.3.5 (With Python2.4, the interpreter crashes. That is fixed now.) Removing the mbcs encoding line from the top of the file, compilation succeeds. File should be attached, as zip-file. Probably requires win32all extensions to be installed to be compiled / imported (generated using build 203 of the win32all extensions). -- >Comment By: Mark Hammond (mhammond) Date: 2005-11-11 16:20 Message: Logged In: YES user_id=14198 Thanks Tim! I can confirm that I can no longer reproduce it with the svn release24-maint branch - so I'm going out on a limb and closing it. I haven't tested Linux, so it would be great of some others could also confirm it fixed (or reopen it if not) -- Comment By: Tim Peters (tim_one) Date: 2005-11-11 14:31 Message: Logged In: YES user_id=31435 Is this still an issue in 2.4.2? I downloaded the zip file, and didn't have any problem importing the .py file on Windows using 2.4.2. A number of problems with encoding directives were fixed in 2.4.2, so I doubt that's an accident ;-) -- Comment By: James Kew (jkew) Date: 2005-08-05 03:10 Message: Logged In: YES user_id=598066 http://sourceforge.net/tracker/? func=detail&aid=1166627&group_id=78018&atid=551954 -- Comment By: Christos Georgiou (tzot) Date: 2005-08-04 17:50 Message: Logged In: YES user_id=539787 Are you sure about the bug number? pywin32 seems not to have such a bug. -- Comment By: James Kew (jkew) Date: 2005-08-04 16:56 Message: Logged In: YES user_id=598066 Is pywin32 bug 1166627 relevant/related? -- Comment By: Simon Dahlbacka (sdahlbac) Date: 2005-07-21 20:38 Message: Logged In: YES user_id=750513 For what it's worth: I have two files (that I unfortunately cannot attach) which works fine on 2.3 that now on 2.4.1 produces spurious syntax errors when they have # -*- coding: ascii -*- if I change that to something that does not match the coding regex I do not get any syntax error (winxp) -- Comment By: Niki Spahiev (nikis) Date: 2005-06-03 02:11 Message: Logged In: YES user_id=27708 i have reproductable test case with encoding cp1251 file is 1594 bytes long, how to attach it? -- Comment By: Walter Dörwald (doerwalter) Date: 2005-04-15 09:40 Message: Logged In: YES user_id=89016 Importing foo2.py on Linux (with the current CVS HEAD version of Python) gives me a segmentation fault with the following stacktrace: 0x080606cc in instance_repr (inst=0xb7c158bc) at Objects/classobject.c:880 880 classname = inst->in_class->cl_name; (gdb) bt #0 0x080606cc in instance_repr (inst=0xb7c158bc) at Objects/classobject.c:880 #1 0x08082235 in PyObject_Repr (v=0xb7c158bc) at Objects/object.c:308 #2 0x080f3ccd in err_input (err=0xbfffe000) at Python/pythonrun.c:1478 #3 0x080f3956 in PyParser_SimpleParseFileFlags (fp=0x818d6e0, filename=0xbfffe530 "foo2.py", start=257, flags=0) at Python/pythonrun.c:1348 #4 0x080f3982 in PyParser_SimpleParseFile (fp=0x818d6e0, filename=0xbfffe530 "foo2.py", start=257) at Python/pythonrun.c:1355 #5 0x080e6fef in parse_source_module (pathname=0xbfffe530 "foo2.py", fp=0x818d6e0) at Python/import.c:761 #6 0x080e72db in load_source_module (name=0xbfffe9d0 "foo2", pathname=0xbfffe530 "foo2.py", fp=0x818d6e0) at Python/import.c:885 #7 0x080e86b4 in load_module (name=0xbfffe9d0 "foo2", fp=0x818d6e0, buf=0xbfffe530 "foo2.py", type=1, loader=0x0) at Python/import.c:1656 #8 0x080e9d52 in import_submodule (mod=0x8145768, subname=0xbfffe9d0 "foo2", fullname=0xbfffe9d0 "foo2") at Python/import.c:2250 #9 0x080e9511 in load_next (mod=0x8145768, altmod=0x8145768, p_name=0xbfffedf0, buf=0xbfffe9d0 "foo2", p_buflen=0xbfffe9
[ python-Bugs-1353504 ] Python drops core when stdin is bogus
Bugs item #1353504, was opened at 2005-11-10 14:16 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1353504&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: Works For Me Priority: 5 Submitted By: Skip Montanaro (montanaro) >Assigned to: Skip Montanaro (montanaro) Summary: Python drops core when stdin is bogus Initial Comment: Someone here at work had the bright idea to execute a Python script from a Solaris 10 ~/.dtprofile file. Apparently, at the time that script is run stdin is bogus. Python core dumps with this gdb backtrace: #0 0x0807d290 in PyDict_SetItem (op=0x815b79c, key=0x8163f20, value=0x0) at ../Objects/dictobject.c:549 #1 0x0807e0f7 in PyDict_SetItemString (v=0x815b79c, key=0x8118df2 "stdin", item=0x0) at ../Objects/dictobject.c:1988 #2 0x080e0d03 in _PySys_Init () at ../Python/sysmodule.c:977 #3 0x080ddfdb in Py_InitializeEx (install_sigs=1) at ../Python/pythonrun.c:190 #4 0x080dfa89 in Py_Initialize () at ../Python/pythonrun.c:283 #5 0x0805cd55 in Py_Main (argc=3, argv=0x8047c08) at ../Modules/main.c:418 #6 0x0805ca13 in main (argc=3, argv=0x8047c08) at ../Modules/python.c:23 (This is from 2.4.2, but it also happens in 2.3.4.) Looking at the code in _PySys_Init it calls sysin = PyFile_FromFile(stdin, "", "r", NULL); which returns NULL. In PyFile_FromFile it creates a new PyFileObject, then initializes it by calling a static function, fill_file_fields. This apparently fails, causing a NULL pointer return. Back in _PySys_Init it checks PyErr_Occurred, but fill_file_fields never raised an except. The NULL pointer is passed to PyDict_SetItemString and havoc ensues. I haven't checked CVS, but 2.4 (and probably 2.3) should be fixed. I suggest raising an IOError in fill_file_fields instead of just setting f to NULL and returning it. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-10 23:24 Message: Logged In: YES user_id=33168 This should be fixed in 2.4.3 and CVS (2.3.5 is probably affected too). I remember dealing with directories specifically. Checkout the current sysmodule.c. Here's the checkin: r39652 | nnorwitz | 2005-10-02 18:03:46 -0700 (Sun, 02 Oct 2005) | 5 lines SF bug #887946. Let me know if this bug is different and the patch doesn't solve the problem. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1353504&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
