[ python-Bugs-1071248 ] Documented grammar for List displays incorrect (testlist)
Bugs item #1071248, was opened at 2004-11-22 15:26 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071248&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Lenard Lindstrom (kermode) >Assigned to: Jeremy Hylton (jhylton) Summary: Documented grammar for List displays incorrect (testlist) Initial Comment: In section 5.2.4 of the Python Reference Manual for Pythons 2.4 and 2.3 the definition testlist ::= test ( "," test )* [ "," ] should be testlist ::= test [ ( "," test )+ [ "," ] ] to conform with the definition of testlist_safe in the Grammar definition file. In other words, a trailing comma is not permitted if there is only one test in testlist. -- Comment By: engelbert gruber (grubert) Date: 2004-12-15 03:50 Message: Logged In: YES user_id=147070 but >>> testlist = 1, >>> testlist (1,) so testlist = 1 does not produce a list testlist ::= one "," ( another "," )* [and [","]] -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071248&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1083793 ] Python 2.4 crashes
Bugs item #1083793, was opened at 2004-12-12 09:25
Message generated for change (Comment added) made by tds33
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083793&group_id=5470
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Axel Kaiser (axel_kaiser)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.4 crashes
Initial Comment:
The new Python 2.4 crashes when starting some of my
programs. This happens under win xp as well as under
win nt. The crashes are reproduceble, but I didn't
succeed in finding the exact place where it happens.
In the attachment you find a Dr. Watson logfile. I hope
it helps. Otherwise I think I will be able to help with
more information.
Thanks in advance
Axel Kaiser
Germany
--
Comment By: Wolfgang Langner (tds33)
Date: 2004-12-15 15:16
Message:
Logged In: YES
user_id=600792
The FILE pointer is specific to your c-lib.
Different versions of the ms c-lib have incompatible
implementations of this structure.
To work arround such problems use python to get the right FILE*
Example (not tested):
/* use pythons std c library to produce a FILE object
to avoid mess with different c libs in debug or release mode
and different versions used to compile python
*/
PyObject* pyFile = PyFile_FromString(fileName, "r");
FILE* const file = PyFile_AsFile(pyFile);
assert(0 != file);
const int succ = PyRun_SimpleFile(file, fileName);
// now remove py file object
Py_XDECREF(pyFile);
--
Comment By: salyee (salyee)
Date: 2004-12-15 06:17
Message:
Logged In: YES
user_id=1178573
I have the same or similar problem.
While python24.dll(Python 2.4 for Windows) uses msvcr71.dll
for CRT, host C++ program embeding Python 2.4 as a script
engine, in my project, is compiled by VC++ 6.0 (msvcrt.dll).
So, the following code snip makes a crash.
FILE* fp = fopen("somecode.py", "rt"); // uses msvcrt.dll
PyRun_SimpleFile(fp, "somecode.py); // uses msvcr71.dll
inside. Cause of a crash.
In my case, I must use VC++ 6.0 and I want clients of my
program to install Python 2.4 from www.python.org.
How do I solve this problem ?
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-12 09:56
Message:
Logged In: YES
user_id=80475
The attachment didn't make it.
Be sure to check the upload box or it won't make it.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083793&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1085744 ] Bad interaction between PySequence_Fast and itertools
Bugs item #1085744, was opened at 2004-12-15 07:15 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085744&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Closed Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Raymond Hettinger (rhettinger) Summary: Bad interaction between PySequence_Fast and itertools Initial Comment: A little "my code is faster than your code" game on python-list showed up a pathological interaction between itertools.chain and str.join: C:\>python -m timeit -s "data = [map(str, range(x)) for x in range(1000)]; from itertools import chain" "''.join(chain(*data))" 10 loops, best of 3: 1.2 sec per loop ** OUCH!! Some extra experiments show that creating a list from the result of chain is fast, but creating a tuple is horrendously slow: C:\>python -m timeit -s "data = [map(str, range(x)) for x in range(1000)]; from itertools import chain" "''.join(list(chain(*data)))" 10 loops, best of 3: 107 msec per loop C:\>python -m timeit -s "data = [map(str, range(x)) for x in range(1000)]; from itertools import chain" "''.join(tuple(chain(*data)))" 10 loops, best of 3: 1.2 sec per loop Creating the tuple by means of a list is actually faster than creating the tuple directly: C:\>python -m timeit -s "data = [map(str, range(x)) for x in range(1000)]; from itertools import chain" "''.join(tuple(list(chain(*data" 10 loops, best of 3: 146 msec per loop A check with imap suggests the problem may be a more general interaction between PySequence_Fast and iterators which don't have __len__ methods: C:\>python -m timeit -s "data = [y for x in range(1000) for y in map(str, range(x))]; from itertools import imap; val = lambda arg: arg" "''.join(list(imap(val, data)))" 10 loops, best of 3: 310 msec per loop C:\>python -m timeit -s "data = [y for x in range(1000) for y in map(str, range(x))]; from itertools import imap; val = lambda arg: arg" "''.join(imap(val, data))" 10 loops, best of 3: 1.4 sec per loop Looking at the code supports that, too - PySequence_Fast uses PySequence_Tuple, which is great when PyObject_Size gives a nice answer, but can lead to a lot of tuple resizing when it isn't (one resize per 10 items beyond 10 up to 500, then one resize per 100 items beyond 500). 2.4's optimised list extension means that this *really* hurts performance wise. The other aspect is whether or not some of the utilities in itertools could benefit from a __len__ method that returned a sensible answer if their inputs defined __len__ methods, and returned -1 otherwise (this would certainly work well with PySequence_Tuple, but I realise it's a slightly odd behaviour for a __len__ method). -- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-15 12:14 Message: Logged In: YES user_id=80475 P.S. In your example, you can get an immediate improvement in performance by having Py_SequenceFast use PySequence_List instead of PySequence_Tuple. If you want to work on some Py2.5 optimizations along these lines, look at replacing the somewhat arbitrary over-allocation strategy in PySequence_Tuple. If you're super-motivated, see if you can improve on the algorithm for str.join. Since these are just strategy changes, they will improve some cases at the expense of others. The goal is to find the one that does the best, most of the time; not horribly in worst situations; and makes the fewest demands on memory. -- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-15 10:04 Message: Logged In: YES user_id=80475 Remain calm ;-) Also, please isolate the issues instead of clumping everything together. And this is likely best handled by email rather than SF (you're asking me to explain all of your timings rather than pointing to a buggy piece of code). The idea (feature request) to make iterators length transparent has already been explored and reached a dead end. I've implemented it already it the few situations where it can work (for example itertools.repeat(obj, n) and dict.iteritems() report their length). Most other situations run into logical inconsistencies due to mutable iterables being indistinguishable from iterators over those iterables. See Lib/test/test_iterlen.py for the gory details. Writing f(*it) is also its own issue -- for uses other than argument passing, Guido considers it an abuse (since * unwinds its components on to ceval's stack). Likewise, there is nothing unique to itertools here. All of the timings can be shown to have similar results if generators are used instead of itertools. This issue is really how consumers handle unsized iterable inputs. You cover three different consumers, ''.join(it), lis
[ python-Bugs-1083793 ] Python 2.4 crashes
Bugs item #1083793, was opened at 2004-12-12 10:25
Message generated for change (Comment added) made by axel_kaiser
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083793&group_id=5470
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Axel Kaiser (axel_kaiser)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.4 crashes
Initial Comment:
The new Python 2.4 crashes when starting some of my
programs. This happens under win xp as well as under
win nt. The crashes are reproduceble, but I didn't
succeed in finding the exact place where it happens.
In the attachment you find a Dr. Watson logfile. I hope
it helps. Otherwise I think I will be able to help with
more information.
Thanks in advance
Axel Kaiser
Germany
--
>Comment By: Axel Kaiser (axel_kaiser)
Date: 2004-12-15 21:58
Message:
Logged In: YES
user_id=1176563
Sorry, the attachment was not appended. By the way, the
problem occurs without any external modules/libraries. It
just juses python-source. The problem might be connected
with the use of module array.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-15 19:02
Message:
Logged In: YES
user_id=80475
Any objections to marking this as Invalid and closing the bug?
--
Comment By: Wolfgang Langner (tds33)
Date: 2004-12-15 16:16
Message:
Logged In: YES
user_id=600792
The FILE pointer is specific to your c-lib.
Different versions of the ms c-lib have incompatible
implementations of this structure.
To work arround such problems use python to get the right FILE*
Example (not tested):
/* use pythons std c library to produce a FILE object
to avoid mess with different c libs in debug or release mode
and different versions used to compile python
*/
PyObject* pyFile = PyFile_FromString(fileName, "r");
FILE* const file = PyFile_AsFile(pyFile);
assert(0 != file);
const int succ = PyRun_SimpleFile(file, fileName);
// now remove py file object
Py_XDECREF(pyFile);
--
Comment By: salyee (salyee)
Date: 2004-12-15 07:17
Message:
Logged In: YES
user_id=1178573
I have the same or similar problem.
While python24.dll(Python 2.4 for Windows) uses msvcr71.dll
for CRT, host C++ program embeding Python 2.4 as a script
engine, in my project, is compiled by VC++ 6.0 (msvcrt.dll).
So, the following code snip makes a crash.
FILE* fp = fopen("somecode.py", "rt"); // uses msvcrt.dll
PyRun_SimpleFile(fp, "somecode.py); // uses msvcr71.dll
inside. Cause of a crash.
In my case, I must use VC++ 6.0 and I want clients of my
program to install Python 2.4 from www.python.org.
How do I solve this problem ?
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-12 10:56
Message:
Logged In: YES
user_id=80475
The attachment didn't make it.
Be sure to check the upload box or it won't make it.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083793&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-944119 ] Signal reception problem. FreeBSD 4.8 and 4.9 after forkpty
Bugs item #944119, was opened at 2004-04-28 18:05 Message generated for change (Settings changed) made by levis501 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=944119&group_id=5470 Category: None Group: Platform-specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Steve Levis (levis501) Assigned to: Nobody/Anonymous (nobody) Summary: Signal reception problem. FreeBSD 4.8 and 4.9 after forkpty Initial Comment: The attached python file reproduces a bug whereby Python does not receive alarm signals from FreeBSD 4.9. This also appears to be the case in FreeBSD 4.8, and may be related to the addition of HyperThreading in FreeBSD 4.8. If Python (either 2.2.3 or 2.3.3) is configured with -without-threads before compiling, the bug does not exist. -- >Comment By: Steve Levis (levis501) Date: 2004-12-15 13:05 Message: Logged In: YES user_id=309698 The system in question has been upgraded to FreeBSD 5.2 and this problem no longer exists. Thanks aimacintyre and lukem. -- Comment By: Luke Mewburn (lukem) Date: 2004-08-21 18:08 Message: Logged In: YES user_id=135998 Please try the patch I provided in patch 975056; it fixes up various signal lossage on NetBSD & FreeBSD caused by python's intermixed use of signal(3) and sigaction(3). python wants non-SA_RESTART-able signals, yet signal(3) on *BSD traditionally sets SA_RESTART, and the mechanism that python uses to unset SA_RESTART when using sigaction(3) is flawed. It's quite possible that the os.read() non-interruptability you're noticing on FreeBSD is being caused by this issue. -- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2004-05-23 00:58 Message: Logged In: YES user_id=250749 There are a few things I haven't been able to figure out with this problem, but I think this is what's going on: - on FreeBSD the read(2) call is not interruptable, as ptys appear not to be considered "slow devices" by the kernel (whether this behavior is *BSD specific I don't really know; ordinary files and pipes aresimilarly affected so forkpty() is just the messenger here); - Python's signal handling is documented to behave such that signal handlers only get invoked between Python VM opcodes. As the os.read() call is a single VM instruction, the nett effect is that the signal handler will not execute until the os.read() call/instruction completes... which it never does. This also affects other signals, such as SIGINT :-( The signal handler being invoked between opcodes explains why the C version works and the Python version doesn't. Using select.select() (or select.poll()) is one way of avoiding this trap, as both select(2) and poll(2) are interruptable (in addition to supporting timeouts directly). I expect this approach would also be considered to be generally portable. I haven't dug into why a single-threaded build avoids the Python VM opcode scheduling - I can only speculate that because the VM doesn't have any thread locking, it can actually execute the signal handler while the os.read() call is still pending. I don't expect there to be a practical solution to this, and so I'm suggesting that the bug be closed as "Won't fix" (read "Can't fix"). -- Comment By: Steve Levis (levis501) Date: 2004-05-18 12:55 Message: Logged In: YES user_id=309698 I've uploaded failure_demo.c, which can be compiled with gcc -o failure_demo failure_demo.c -lutil. Written in C, the signal is properly delivered, and the test does not fail on either FreeBSD 4.7 or 4.9. -- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2004-05-18 02:05 Message: Logged In: YES user_id=250749 Hmm... are you in a position to write a C test case for this? The reason I ask is that I have seen other signal related problems involving a Python interpreter built --with-threads on FreeBSD 4.x which were traced back to issues with libc_r, and I suspect that this problem is similar. -- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2004-05-18 02:03 Message: Logged In: YES user_id=250749 Hmm... are you in a position to write a C test case for this? The reason I ask is that I have seen other signal related problems involving a Python interpreter built --with-threads on FreeBSD 4.x which were traced back to issues with libc_r, and I suspect that this problem is similar. -- Comment By: Steve Levis (levis501) Date: 2004-05-05 10:08 Message: Logged In: YES user_id=309698 Ooops, again! I ran on the standard kernel but had python compiled --without-
[ python-Bugs-518846 ] exception cannot be new-style class
Bugs item #518846, was opened at 2002-02-17 12:09 Message generated for change (Comment added) made by robey1 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=518846&group_id=5470 Category: Type/class unification Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Magnus Heino (magnusheino) Assigned to: Guido van Rossum (gvanrossum) Summary: exception cannot be new-style class Initial Comment: [EMAIL PROTECTED] magnus]$ python2.2 Python 2.2 (#1, Jan 26 2002, 14:27:24) [GCC 2.96 2731 (Red Hat Linux 7.1 2.96-98)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class foo(object): ... pass ... >>> raise foo() Traceback (most recent call last): File "", line 1, in ? TypeError: exceptions must be strings, classes, or instances, not foo >>> -- Comment By: Robey Pointer (robey1) Date: 2004-12-15 13:08 Message: Logged In: YES user_id=1179122 This caused me an hour of debugging a few nights ago. When using unified types, it's very confusing to find that not only does Exception not follow new-style object semantics, but it *can't*. Doing the obvious hack: class MyException (Exception, object): pass does not work! The interpreter (2.3) refuses to let you raise a unified-type object. And if you subclass exclusively from Exception, type(obj) returns 'instance' instead of the class (due to being an old-style object). Please fix this for 2.4! -- Comment By: Facundo Batista (facundobatista) Date: 2004-11-24 18:05 Message: Logged In: YES user_id=752496 Reproduced the bug in Py2.3. I think that this is a bug, at least because we "encourage" users to derive exceptions from Exception, so they should be able to not do it. The moment we say that they "must" derive from Exception, this can be closed (of course, this is my *very* personal opinion, ;) -- Comment By: Phillip J. Eby (pje) Date: 2002-07-11 13:12 Message: Logged In: YES user_id=56214 Just to make things even more interesting, the current 'raise' code *will* let you raise a new-style instance that derives from 'tuple'... of course, what it actually raises is the first element of said tuple-like thing. It seems to me that the very first thing that should be checked is whether the first argument to 'raise' is an instance of Exception, and if so, take its type and go from there. This would support both old and new-style instances of Exception subclasses, and I believe is the recommended approach to using 'raise'. (I.e., raise an instance of something that subclasses Exception.) All the other items like strings, tuples, etc., should be checked *after* a check for the "standard" approach, yes? -- Comment By: Walter Dörwald (doerwalter) Date: 2002-07-11 10:07 Message: Logged In: YES user_id=89016 test.py is a little script that executes various test cases. -- Comment By: Walter Dörwald (doerwalter) Date: 2002-07-11 09:12 Message: Logged In: YES user_id=89016 What about the following patch (diff.txt): It allows new style objects as exceptions and makes catching exceptions by basetype possible: class newint(int): pass try: raise newint(42) except int, exc: print exc With this patch subinstances of str become raisable and will be caught be type not identity. This could be changed to explicitely forbid str subinstances. And raise type(None), None becomes ambiguous: It is interpreted as raise type(None) i.e. it raises the type(None) object as an exception, not the object None (which is of type type(None)) As soon as Exception is a new style class we could limit the allowed objects to (sub)instances of Exception. -- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-05 16:07 Message: Logged In: YES user_id=6380 Sorry, HEAPTYPE is not the proper way to check for a new-style class; it would exclude any new-style classes defined by C code. I also think that if you want to do this it should done properly, and allow "raise C, C()" as well. At best there's agreement that it's not worth trying to fix Python to allow new-style classes as exceptions when we're also trying to encourage that exceptions derive from Exception. If your module declares its exceptions as deriving from Exception, a __metaclass__ = type should not have any effect on the exceptions you declare. So I'm not sure what your problem is? Here's another idea for a patch: a new-style class is allowed as long as it also inherits from Exception. (This is possible!) ---
[ python-Bugs-1086096 ] two strings holding the same value have different id
Bugs item #1086096, was opened at 2004-12-15 17:10 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=1086096&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Stefan Seefeld (stefan) Assigned to: Nobody/Anonymous (nobody) Summary: two strings holding the same value have different id Initial Comment: I'v run into a problem with a program that expects a string to be either 'resource' or 'test': type = ... if type is "resource": do_something() elif type is "test": do_something_else() The above comparison using 'is' works fine with python 2.3, but fails with python 2.4. Unfortunately I wasn't able to isolate the problem. To reproduce: Install qmtest from http://www.qmtest.com on windows xp with python 2.4 (I don't know yet whether other platforms are affected, too). Then follow the instructions from http://www.codesourcery.com/public/qmtest/qm-2.2/manual.html up to section 2.2 'Starting the Graphical Interface'. In the browser, click on the 'exec1' test, and you'll get an 'UnboundLocalError' because the application logic didn't expect some comparison to fail. The failed comparison in question is 't is "test"', which returns 'False' even though t == "test". -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086096&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1085208 ] Installation ends prematurely
Bugs item #1085208, was opened at 2004-12-14 17:18 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085208&group_id=5470 Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: anamh0001 (anamh0001) Assigned to: Nobody/Anonymous (nobody) Summary: Installation ends prematurely Initial Comment: Test machine: Pentium 4M 1.7Ghz Win XP Pro w/ SP2 512Mb RAM 30Gb HD .Net Framework 1.0 and 1.1 Windows Scripting Host 5.6 After double clicking the installation file. It proceeds to act like any other Windows Installer. After accepting c:\Python24 as the install directory, I am presented with this screen saying that there was an error and that the installation has ended prematurely. FYI, I tried to install over Python 2.3 (as in upgrade) but I got the same error. So I proceeded to uninstall Python 2.3 and other installed libraries. I then restarted the PC and tried to install Python 2.4 again. This bug is the symptom of this second try. Please find the screenshot attached showing the final screen. -- >Comment By: Martin v. Löwis (loewis) Date: 2004-12-15 23:35 Message: Logged In: YES user_id=21627 Can you please run msiexec /i python-2.4.msi /l*v python.log and attach the resulting python.log (do NOT paste it into the SF comment box). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085208&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1083793 ] Python 2.4 crashes
Bugs item #1083793, was opened at 2004-12-12 10:25
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083793&group_id=5470
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Axel Kaiser (axel_kaiser)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.4 crashes
Initial Comment:
The new Python 2.4 crashes when starting some of my
programs. This happens under win xp as well as under
win nt. The crashes are reproduceble, but I didn't
succeed in finding the exact place where it happens.
In the attachment you find a Dr. Watson logfile. I hope
it helps. Otherwise I think I will be able to help with
more information.
Thanks in advance
Axel Kaiser
Germany
--
>Comment By: Martin v. Löwis (loewis)
Date: 2004-12-15 23:39
Message:
Logged In: YES
user_id=21627
Can you create a small test case that demonstrates the problem?
--
Comment By: Axel Kaiser (axel_kaiser)
Date: 2004-12-15 21:58
Message:
Logged In: YES
user_id=1176563
Sorry, the attachment was not appended. By the way, the
problem occurs without any external modules/libraries. It
just juses python-source. The problem might be connected
with the use of module array.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-15 19:02
Message:
Logged In: YES
user_id=80475
Any objections to marking this as Invalid and closing the bug?
--
Comment By: Wolfgang Langner (tds33)
Date: 2004-12-15 16:16
Message:
Logged In: YES
user_id=600792
The FILE pointer is specific to your c-lib.
Different versions of the ms c-lib have incompatible
implementations of this structure.
To work arround such problems use python to get the right FILE*
Example (not tested):
/* use pythons std c library to produce a FILE object
to avoid mess with different c libs in debug or release mode
and different versions used to compile python
*/
PyObject* pyFile = PyFile_FromString(fileName, "r");
FILE* const file = PyFile_AsFile(pyFile);
assert(0 != file);
const int succ = PyRun_SimpleFile(file, fileName);
// now remove py file object
Py_XDECREF(pyFile);
--
Comment By: salyee (salyee)
Date: 2004-12-15 07:17
Message:
Logged In: YES
user_id=1178573
I have the same or similar problem.
While python24.dll(Python 2.4 for Windows) uses msvcr71.dll
for CRT, host C++ program embeding Python 2.4 as a script
engine, in my project, is compiled by VC++ 6.0 (msvcrt.dll).
So, the following code snip makes a crash.
FILE* fp = fopen("somecode.py", "rt"); // uses msvcrt.dll
PyRun_SimpleFile(fp, "somecode.py); // uses msvcr71.dll
inside. Cause of a crash.
In my case, I must use VC++ 6.0 and I want clients of my
program to install Python 2.4 from www.python.org.
How do I solve this problem ?
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-12 10:56
Message:
Logged In: YES
user_id=80475
The attachment didn't make it.
Be sure to check the upload box or it won't make it.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083793&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1080634 ] PythonWin Tray Icon in system Tray on Windows platform
Bugs item #1080634, was opened at 2004-12-07 14:56 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080634&group_id=5470 Category: Windows >Group: 3rd Party >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Dileep Nirala (dileep_nirala) Assigned to: Nobody/Anonymous (nobody) Summary: PythonWin Tray Icon in system Tray on Windows platform Initial Comment: The python icon remains in the system Tray even if you close the application. -- >Comment By: Martin v. Löwis (loewis) Date: 2004-12-15 23:41 Message: Logged In: YES user_id=21627 Pythonwin is not part of the Python project. Please report this to http://sourceforge.net/projects/pywin32 -- Comment By: Dileep Nirala (dileep_nirala) Date: 2004-12-08 16:31 Message: Logged In: YES user_id=1173293 PythonWin tray icons remains in the system tray once you close the application for Python-2.4.0-243 build on Windows platform. If you hover the mouse then only it goes off. If you open and close PythonWin application 10 times, you will see 10 tray icons. Any probable date, when this could get resolved. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080634&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1086096 ] two strings holding the same value have different id
Bugs item #1086096, was opened at 2004-12-15 17:10 Message generated for change (Comment added) made by goodger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086096&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Stefan Seefeld (stefan) Assigned to: Nobody/Anonymous (nobody) Summary: two strings holding the same value have different id Initial Comment: I'v run into a problem with a program that expects a string to be either 'resource' or 'test': type = ... if type is "resource": do_something() elif type is "test": do_something_else() The above comparison using 'is' works fine with python 2.3, but fails with python 2.4. Unfortunately I wasn't able to isolate the problem. To reproduce: Install qmtest from http://www.qmtest.com on windows xp with python 2.4 (I don't know yet whether other platforms are affected, too). Then follow the instructions from http://www.codesourcery.com/public/qmtest/qm-2.2/manual.html up to section 2.2 'Starting the Graphical Interface'. In the browser, click on the 'exec1' test, and you'll get an 'UnboundLocalError' because the application logic didn't expect some comparison to fail. The failed comparison in question is 't is "test"', which returns 'False' even though t == "test". -- >Comment By: David Goodger (goodger) Date: 2004-12-15 18:14 Message: Logged In: YES user_id=7733 I fully agree with Tim. If the example code worked before, it was accidental. "is" tests identity. ``"resource" is "resource"`` may create two independent string objects. Use "==" instead. Closed the bug report. -- Comment By: Tim Peters (tim_one) Date: 2004-12-15 17:27 Message: Logged In: YES user_id=31435 Sorry, the only bug I see here is in the code you posted using "is" to try to determine whether two strings are equal. "is" tests for object identity, not for equality, and whether two immutable objects are really the same object isn't in general defined by Python. You should use "==" to check two strings for equality. The only time it's reliable to use "is" for that purpose is when you've explicitly interned all strings being compared (via using the intern() builtin function). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086096&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-518846 ] exception cannot be new-style class
Bugs item #518846, was opened at 2002-02-17 12:09 Message generated for change (Comment added) made by robey1 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=518846&group_id=5470 Category: Type/class unification Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Magnus Heino (magnusheino) Assigned to: Guido van Rossum (gvanrossum) Summary: exception cannot be new-style class Initial Comment: [EMAIL PROTECTED] magnus]$ python2.2 Python 2.2 (#1, Jan 26 2002, 14:27:24) [GCC 2.96 2731 (Red Hat Linux 7.1 2.96-98)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class foo(object): ... pass ... >>> raise foo() Traceback (most recent call last): File "", line 1, in ? TypeError: exceptions must be strings, classes, or instances, not foo >>> -- Comment By: Robey Pointer (robey1) Date: 2004-12-15 15:39 Message: Logged In: YES user_id=1179122 Let me try to rephrase the problem so that it's obvious that this is a bug, and not a feature: 'type(e)' on an exception will not work in 2.3, and cannot be made to work from within python code. There's no way to throw an exception (ie an object with Exception in its ancestor list) that 'type(e)' will work on. :( -- Comment By: Martin v. Löwis (loewis) Date: 2004-12-15 13:59 Message: Logged In: YES user_id=21627 Whatever the solution to this problem, it is for sure that 2.4.x won't see it, because it will be a new feature. -- Comment By: Robey Pointer (robey1) Date: 2004-12-15 13:08 Message: Logged In: YES user_id=1179122 This caused me an hour of debugging a few nights ago. When using unified types, it's very confusing to find that not only does Exception not follow new-style object semantics, but it *can't*. Doing the obvious hack: class MyException (Exception, object): pass does not work! The interpreter (2.3) refuses to let you raise a unified-type object. And if you subclass exclusively from Exception, type(obj) returns 'instance' instead of the class (due to being an old-style object). Please fix this for 2.4! -- Comment By: Facundo Batista (facundobatista) Date: 2004-11-24 18:05 Message: Logged In: YES user_id=752496 Reproduced the bug in Py2.3. I think that this is a bug, at least because we "encourage" users to derive exceptions from Exception, so they should be able to not do it. The moment we say that they "must" derive from Exception, this can be closed (of course, this is my *very* personal opinion, ;) -- Comment By: Phillip J. Eby (pje) Date: 2002-07-11 13:12 Message: Logged In: YES user_id=56214 Just to make things even more interesting, the current 'raise' code *will* let you raise a new-style instance that derives from 'tuple'... of course, what it actually raises is the first element of said tuple-like thing. It seems to me that the very first thing that should be checked is whether the first argument to 'raise' is an instance of Exception, and if so, take its type and go from there. This would support both old and new-style instances of Exception subclasses, and I believe is the recommended approach to using 'raise'. (I.e., raise an instance of something that subclasses Exception.) All the other items like strings, tuples, etc., should be checked *after* a check for the "standard" approach, yes? -- Comment By: Walter Dörwald (doerwalter) Date: 2002-07-11 10:07 Message: Logged In: YES user_id=89016 test.py is a little script that executes various test cases. -- Comment By: Walter Dörwald (doerwalter) Date: 2002-07-11 09:12 Message: Logged In: YES user_id=89016 What about the following patch (diff.txt): It allows new style objects as exceptions and makes catching exceptions by basetype possible: class newint(int): pass try: raise newint(42) except int, exc: print exc With this patch subinstances of str become raisable and will be caught be type not identity. This could be changed to explicitely forbid str subinstances. And raise type(None), None becomes ambiguous: It is interpreted as raise type(None) i.e. it raises the type(None) object as an exception, not the object None (which is of type type(None)) As soon as Exception is a new style class we could limit the allowed objects to (sub)instances of Exception. -- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-05 16:07 Message: Logged In: YES user
[ python-Bugs-1086127 ] Typo in module os documentation
Bugs item #1086127, was opened at 2004-12-16 00:14 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086127&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Connelly (connelly) Assigned to: Nobody/Anonymous (nobody) Summary: Typo in module os documentation Initial Comment: In the docs for module os ( http://docs.python.org/lib/os-path.html ): pathsep The character conventionally used by the operating system to separate search patch components (as in PATH), such as ":" for POSIX or ";" for Windows. Also available via os.path. Replace "patch" with "path". - Connelly Barnes -- >Comment By: Walter Dörwald (doerwalter) Date: 2004-12-16 00:47 Message: Logged In: YES user_id=89016 Fixed in: Doc/lib/libos.tex 1.147 Doc/lib/libos.tex 1.146.2.1 Thanks for the report! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086127&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1071248 ] Documented grammar for List displays incorrect (testlist)
Bugs item #1071248, was opened at 2004-11-22 21:26 Message generated for change (Comment added) made by grubert You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071248&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Lenard Lindstrom (kermode) Assigned to: Nobody/Anonymous (nobody) Summary: Documented grammar for List displays incorrect (testlist) Initial Comment: In section 5.2.4 of the Python Reference Manual for Pythons 2.4 and 2.3 the definition testlist ::= test ( "," test )* [ "," ] should be testlist ::= test [ ( "," test )+ [ "," ] ] to conform with the definition of testlist_safe in the Grammar definition file. In other words, a trailing comma is not permitted if there is only one test in testlist. -- Comment By: engelbert gruber (grubert) Date: 2004-12-15 09:50 Message: Logged In: YES user_id=147070 but >>> testlist = 1, >>> testlist (1,) so testlist = 1 does not produce a list testlist ::= one "," ( another "," )* [and [","]] -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071248&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-1085304 ] Make array.array pickle-able
Feature Requests item #1085304, was opened at 2004-12-14 13:50 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1085304&group_id=5470 >Category: Python Library >Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nicolas Fleury (nidoizo) Assigned to: Raymond Hettinger (rhettinger) Summary: Make array.array pickle-able Initial Comment: Make array.array pickle-able. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1085304&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1085744 ] Bad interaction between PySequence_Fast and itertools
Bugs item #1085744, was opened at 2004-12-15 22:15 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085744&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: Bad interaction between PySequence_Fast and itertools Initial Comment: A little "my code is faster than your code" game on python-list showed up a pathological interaction between itertools.chain and str.join: C:\>python -m timeit -s "data = [map(str, range(x)) for x in range(1000)]; from itertools import chain" "''.join(chain(*data))" 10 loops, best of 3: 1.2 sec per loop ** OUCH!! Some extra experiments show that creating a list from the result of chain is fast, but creating a tuple is horrendously slow: C:\>python -m timeit -s "data = [map(str, range(x)) for x in range(1000)]; from itertools import chain" "''.join(list(chain(*data)))" 10 loops, best of 3: 107 msec per loop C:\>python -m timeit -s "data = [map(str, range(x)) for x in range(1000)]; from itertools import chain" "''.join(tuple(chain(*data)))" 10 loops, best of 3: 1.2 sec per loop Creating the tuple by means of a list is actually faster than creating the tuple directly: C:\>python -m timeit -s "data = [map(str, range(x)) for x in range(1000)]; from itertools import chain" "''.join(tuple(list(chain(*data" 10 loops, best of 3: 146 msec per loop A check with imap suggests the problem may be a more general interaction between PySequence_Fast and iterators which don't have __len__ methods: C:\>python -m timeit -s "data = [y for x in range(1000) for y in map(str, range(x))]; from itertools import imap; val = lambda arg: arg" "''.join(list(imap(val, data)))" 10 loops, best of 3: 310 msec per loop C:\>python -m timeit -s "data = [y for x in range(1000) for y in map(str, range(x))]; from itertools import imap; val = lambda arg: arg" "''.join(imap(val, data))" 10 loops, best of 3: 1.4 sec per loop Looking at the code supports that, too - PySequence_Fast uses PySequence_Tuple, which is great when PyObject_Size gives a nice answer, but can lead to a lot of tuple resizing when it isn't (one resize per 10 items beyond 10 up to 500, then one resize per 100 items beyond 500). 2.4's optimised list extension means that this *really* hurts performance wise. The other aspect is whether or not some of the utilities in itertools could benefit from a __len__ method that returned a sensible answer if their inputs defined __len__ methods, and returned -1 otherwise (this would certainly work well with PySequence_Tuple, but I realise it's a slightly odd behaviour for a __len__ method). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085744&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1085744 ] Bad interaction between PySequence_Fast and itertools
Bugs item #1085744, was opened at 2004-12-15 22:15 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085744&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) >Assigned to: Raymond Hettinger (rhettinger) Summary: Bad interaction between PySequence_Fast and itertools Initial Comment: A little "my code is faster than your code" game on python-list showed up a pathological interaction between itertools.chain and str.join: C:\>python -m timeit -s "data = [map(str, range(x)) for x in range(1000)]; from itertools import chain" "''.join(chain(*data))" 10 loops, best of 3: 1.2 sec per loop ** OUCH!! Some extra experiments show that creating a list from the result of chain is fast, but creating a tuple is horrendously slow: C:\>python -m timeit -s "data = [map(str, range(x)) for x in range(1000)]; from itertools import chain" "''.join(list(chain(*data)))" 10 loops, best of 3: 107 msec per loop C:\>python -m timeit -s "data = [map(str, range(x)) for x in range(1000)]; from itertools import chain" "''.join(tuple(chain(*data)))" 10 loops, best of 3: 1.2 sec per loop Creating the tuple by means of a list is actually faster than creating the tuple directly: C:\>python -m timeit -s "data = [map(str, range(x)) for x in range(1000)]; from itertools import chain" "''.join(tuple(list(chain(*data" 10 loops, best of 3: 146 msec per loop A check with imap suggests the problem may be a more general interaction between PySequence_Fast and iterators which don't have __len__ methods: C:\>python -m timeit -s "data = [y for x in range(1000) for y in map(str, range(x))]; from itertools import imap; val = lambda arg: arg" "''.join(list(imap(val, data)))" 10 loops, best of 3: 310 msec per loop C:\>python -m timeit -s "data = [y for x in range(1000) for y in map(str, range(x))]; from itertools import imap; val = lambda arg: arg" "''.join(imap(val, data))" 10 loops, best of 3: 1.4 sec per loop Looking at the code supports that, too - PySequence_Fast uses PySequence_Tuple, which is great when PyObject_Size gives a nice answer, but can lead to a lot of tuple resizing when it isn't (one resize per 10 items beyond 10 up to 500, then one resize per 100 items beyond 500). 2.4's optimised list extension means that this *really* hurts performance wise. The other aspect is whether or not some of the utilities in itertools could benefit from a __len__ method that returned a sensible answer if their inputs defined __len__ methods, and returned -1 otherwise (this would certainly work well with PySequence_Tuple, but I realise it's a slightly odd behaviour for a __len__ method). -- >Comment By: Nick Coghlan (ncoghlan) Date: 2004-12-15 22:17 Message: Logged In: YES user_id=1038590 Kicking in your direction Raymond, since this can badly affect the performance of itertools. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085744&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1085744 ] Bad interaction between PySequence_Fast and itertools
Bugs item #1085744, was opened at 2004-12-15 07:15 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085744&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 >Status: Closed Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Raymond Hettinger (rhettinger) Summary: Bad interaction between PySequence_Fast and itertools Initial Comment: A little "my code is faster than your code" game on python-list showed up a pathological interaction between itertools.chain and str.join: C:\>python -m timeit -s "data = [map(str, range(x)) for x in range(1000)]; from itertools import chain" "''.join(chain(*data))" 10 loops, best of 3: 1.2 sec per loop ** OUCH!! Some extra experiments show that creating a list from the result of chain is fast, but creating a tuple is horrendously slow: C:\>python -m timeit -s "data = [map(str, range(x)) for x in range(1000)]; from itertools import chain" "''.join(list(chain(*data)))" 10 loops, best of 3: 107 msec per loop C:\>python -m timeit -s "data = [map(str, range(x)) for x in range(1000)]; from itertools import chain" "''.join(tuple(chain(*data)))" 10 loops, best of 3: 1.2 sec per loop Creating the tuple by means of a list is actually faster than creating the tuple directly: C:\>python -m timeit -s "data = [map(str, range(x)) for x in range(1000)]; from itertools import chain" "''.join(tuple(list(chain(*data" 10 loops, best of 3: 146 msec per loop A check with imap suggests the problem may be a more general interaction between PySequence_Fast and iterators which don't have __len__ methods: C:\>python -m timeit -s "data = [y for x in range(1000) for y in map(str, range(x))]; from itertools import imap; val = lambda arg: arg" "''.join(list(imap(val, data)))" 10 loops, best of 3: 310 msec per loop C:\>python -m timeit -s "data = [y for x in range(1000) for y in map(str, range(x))]; from itertools import imap; val = lambda arg: arg" "''.join(imap(val, data))" 10 loops, best of 3: 1.4 sec per loop Looking at the code supports that, too - PySequence_Fast uses PySequence_Tuple, which is great when PyObject_Size gives a nice answer, but can lead to a lot of tuple resizing when it isn't (one resize per 10 items beyond 10 up to 500, then one resize per 100 items beyond 500). 2.4's optimised list extension means that this *really* hurts performance wise. The other aspect is whether or not some of the utilities in itertools could benefit from a __len__ method that returned a sensible answer if their inputs defined __len__ methods, and returned -1 otherwise (this would certainly work well with PySequence_Tuple, but I realise it's a slightly odd behaviour for a __len__ method). -- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-15 10:04 Message: Logged In: YES user_id=80475 Remain calm ;-) Also, please isolate the issues instead of clumping everything together. And this is likely best handled by email rather than SF (you're asking me to explain all of your timings rather than pointing to a buggy piece of code). The idea (feature request) to make iterators length transparent has already been explored and reached a dead end. I've implemented it already it the few situations where it can work (for example itertools.repeat(obj, n) and dict.iteritems() report their length). Most other situations run into logical inconsistencies due to mutable iterables being indistinguishable from iterators over those iterables. See Lib/test/test_iterlen.py for the gory details. Writing f(*it) is also its own issue -- for uses other than argument passing, Guido considers it an abuse (since * unwinds its components on to ceval's stack). Likewise, there is nothing unique to itertools here. All of the timings can be shown to have similar results if generators are used instead of itertools. This issue is really how consumers handle unsized iterable inputs. You cover three different consumers, ''.join(it), list(it), and tuple(it) which all take different approaches to unsized iterable inputs. So, it is no surprise that the three have different performance characteristics. str.join() is its own little bundle of joy whose behavior is dictated by its need to make multiple passes over the input. Improving its handling of unsized iterable inputs is a thorny subject. You're welcome to post a patch. The best way to analyze what is going on is to disregard the timings and instead draw little diagrams of what is memory at any given time. Also, draw a data migration path -- you want the algorithm to move the elements as few times as possible. Be sure to handle cases like dict.iteritems() which know their length but are not a list or tuple. Also, handl
[ python-Bugs-1085861 ] subprocess.Popen feature request
Bugs item #1085861, was opened at 2004-12-15 10:33 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=1085861&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michele Simionato (michele_s) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess.Popen feature request Initial Comment: I asked on comp.lang.python for a "kill" method in the Popen class. The answer was "the kill method is missing since it is not portable to Windows". However I got this message from Fredrik Lund """ I suggest filing a "bug" report about this. the Unix version is trivial, as you noticed, and it shouldn't take many minutes to add a TerminateProcess helper to _subprocess. """ So, I am following his suggestion ;-) Michele Simionato -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085861&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1083793 ] Python 2.4 crashes
Bugs item #1083793, was opened at 2004-12-12 04:25
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083793&group_id=5470
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Axel Kaiser (axel_kaiser)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.4 crashes
Initial Comment:
The new Python 2.4 crashes when starting some of my
programs. This happens under win xp as well as under
win nt. The crashes are reproduceble, but I didn't
succeed in finding the exact place where it happens.
In the attachment you find a Dr. Watson logfile. I hope
it helps. Otherwise I think I will be able to help with
more information.
Thanks in advance
Axel Kaiser
Germany
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-15 13:02
Message:
Logged In: YES
user_id=80475
Any objections to marking this as Invalid and closing the bug?
--
Comment By: Wolfgang Langner (tds33)
Date: 2004-12-15 10:16
Message:
Logged In: YES
user_id=600792
The FILE pointer is specific to your c-lib.
Different versions of the ms c-lib have incompatible
implementations of this structure.
To work arround such problems use python to get the right FILE*
Example (not tested):
/* use pythons std c library to produce a FILE object
to avoid mess with different c libs in debug or release mode
and different versions used to compile python
*/
PyObject* pyFile = PyFile_FromString(fileName, "r");
FILE* const file = PyFile_AsFile(pyFile);
assert(0 != file);
const int succ = PyRun_SimpleFile(file, fileName);
// now remove py file object
Py_XDECREF(pyFile);
--
Comment By: salyee (salyee)
Date: 2004-12-15 01:17
Message:
Logged In: YES
user_id=1178573
I have the same or similar problem.
While python24.dll(Python 2.4 for Windows) uses msvcr71.dll
for CRT, host C++ program embeding Python 2.4 as a script
engine, in my project, is compiled by VC++ 6.0 (msvcrt.dll).
So, the following code snip makes a crash.
FILE* fp = fopen("somecode.py", "rt"); // uses msvcrt.dll
PyRun_SimpleFile(fp, "somecode.py); // uses msvcr71.dll
inside. Cause of a crash.
In my case, I must use VC++ 6.0 and I want clients of my
program to install Python 2.4 from www.python.org.
How do I solve this problem ?
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-12 04:56
Message:
Logged In: YES
user_id=80475
The attachment didn't make it.
Be sure to check the upload box or it won't make it.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083793&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1085744 ] PySequence_Tuple not as fast as PySequence_List
Bugs item #1085744, was opened at 2004-12-15 07:15 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085744&group_id=5470 Category: Python Interpreter Core >Group: Python 2.5 >Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Raymond Hettinger (rhettinger) >Summary: PySequence_Tuple not as fast as PySequence_List Initial Comment: A little "my code is faster than your code" game on python-list showed up a pathological interaction between itertools.chain and str.join: C:\>python -m timeit -s "data = [map(str, range(x)) for x in range(1000)]; from itertools import chain" "''.join(chain(*data))" 10 loops, best of 3: 1.2 sec per loop ** OUCH!! Some extra experiments show that creating a list from the result of chain is fast, but creating a tuple is horrendously slow: C:\>python -m timeit -s "data = [map(str, range(x)) for x in range(1000)]; from itertools import chain" "''.join(list(chain(*data)))" 10 loops, best of 3: 107 msec per loop C:\>python -m timeit -s "data = [map(str, range(x)) for x in range(1000)]; from itertools import chain" "''.join(tuple(chain(*data)))" 10 loops, best of 3: 1.2 sec per loop Creating the tuple by means of a list is actually faster than creating the tuple directly: C:\>python -m timeit -s "data = [map(str, range(x)) for x in range(1000)]; from itertools import chain" "''.join(tuple(list(chain(*data" 10 loops, best of 3: 146 msec per loop A check with imap suggests the problem may be a more general interaction between PySequence_Fast and iterators which don't have __len__ methods: C:\>python -m timeit -s "data = [y for x in range(1000) for y in map(str, range(x))]; from itertools import imap; val = lambda arg: arg" "''.join(list(imap(val, data)))" 10 loops, best of 3: 310 msec per loop C:\>python -m timeit -s "data = [y for x in range(1000) for y in map(str, range(x))]; from itertools import imap; val = lambda arg: arg" "''.join(imap(val, data))" 10 loops, best of 3: 1.4 sec per loop Looking at the code supports that, too - PySequence_Fast uses PySequence_Tuple, which is great when PyObject_Size gives a nice answer, but can lead to a lot of tuple resizing when it isn't (one resize per 10 items beyond 10 up to 500, then one resize per 100 items beyond 500). 2.4's optimised list extension means that this *really* hurts performance wise. The other aspect is whether or not some of the utilities in itertools could benefit from a __len__ method that returned a sensible answer if their inputs defined __len__ methods, and returned -1 otherwise (this would certainly work well with PySequence_Tuple, but I realise it's a slightly odd behaviour for a __len__ method). -- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-15 16:27 Message: Logged In: YES user_id=80475 Attaching a small patch for PySequence_Tuple. Try it out and let me know if you find it to be an improvement. It also adds a bit of error checking that should have been there anyway. -- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-15 12:14 Message: Logged In: YES user_id=80475 P.S. In your example, you can get an immediate improvement in performance by having Py_SequenceFast use PySequence_List instead of PySequence_Tuple. If you want to work on some Py2.5 optimizations along these lines, look at replacing the somewhat arbitrary over-allocation strategy in PySequence_Tuple. If you're super-motivated, see if you can improve on the algorithm for str.join. Since these are just strategy changes, they will improve some cases at the expense of others. The goal is to find the one that does the best, most of the time; not horribly in worst situations; and makes the fewest demands on memory. -- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-15 10:04 Message: Logged In: YES user_id=80475 Remain calm ;-) Also, please isolate the issues instead of clumping everything together. And this is likely best handled by email rather than SF (you're asking me to explain all of your timings rather than pointing to a buggy piece of code). The idea (feature request) to make iterators length transparent has already been explored and reached a dead end. I've implemented it already it the few situations where it can work (for example itertools.repeat(obj, n) and dict.iteritems() report their length). Most other situations run into logical inconsistencies due to mutable iterables being indistinguishable from iterators over those iterables. See Lib/test/test_iterlen.py for the gory details. Writing f(*it) is also its own issue -- for uses other than argument passing,
[ python-Bugs-518846 ] exception cannot be new-style class
Bugs item #518846, was opened at 2002-02-17 21:09 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=518846&group_id=5470 Category: Type/class unification Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Magnus Heino (magnusheino) Assigned to: Guido van Rossum (gvanrossum) Summary: exception cannot be new-style class Initial Comment: [EMAIL PROTECTED] magnus]$ python2.2 Python 2.2 (#1, Jan 26 2002, 14:27:24) [GCC 2.96 2731 (Red Hat Linux 7.1 2.96-98)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class foo(object): ... pass ... >>> raise foo() Traceback (most recent call last): File "", line 1, in ? TypeError: exceptions must be strings, classes, or instances, not foo >>> -- >Comment By: Martin v. Löwis (loewis) Date: 2004-12-15 22:59 Message: Logged In: YES user_id=21627 Whatever the solution to this problem, it is for sure that 2.4.x won't see it, because it will be a new feature. -- Comment By: Robey Pointer (robey1) Date: 2004-12-15 22:08 Message: Logged In: YES user_id=1179122 This caused me an hour of debugging a few nights ago. When using unified types, it's very confusing to find that not only does Exception not follow new-style object semantics, but it *can't*. Doing the obvious hack: class MyException (Exception, object): pass does not work! The interpreter (2.3) refuses to let you raise a unified-type object. And if you subclass exclusively from Exception, type(obj) returns 'instance' instead of the class (due to being an old-style object). Please fix this for 2.4! -- Comment By: Facundo Batista (facundobatista) Date: 2004-11-25 03:05 Message: Logged In: YES user_id=752496 Reproduced the bug in Py2.3. I think that this is a bug, at least because we "encourage" users to derive exceptions from Exception, so they should be able to not do it. The moment we say that they "must" derive from Exception, this can be closed (of course, this is my *very* personal opinion, ;) -- Comment By: Phillip J. Eby (pje) Date: 2002-07-11 22:12 Message: Logged In: YES user_id=56214 Just to make things even more interesting, the current 'raise' code *will* let you raise a new-style instance that derives from 'tuple'... of course, what it actually raises is the first element of said tuple-like thing. It seems to me that the very first thing that should be checked is whether the first argument to 'raise' is an instance of Exception, and if so, take its type and go from there. This would support both old and new-style instances of Exception subclasses, and I believe is the recommended approach to using 'raise'. (I.e., raise an instance of something that subclasses Exception.) All the other items like strings, tuples, etc., should be checked *after* a check for the "standard" approach, yes? -- Comment By: Walter Dörwald (doerwalter) Date: 2002-07-11 19:07 Message: Logged In: YES user_id=89016 test.py is a little script that executes various test cases. -- Comment By: Walter Dörwald (doerwalter) Date: 2002-07-11 18:12 Message: Logged In: YES user_id=89016 What about the following patch (diff.txt): It allows new style objects as exceptions and makes catching exceptions by basetype possible: class newint(int): pass try: raise newint(42) except int, exc: print exc With this patch subinstances of str become raisable and will be caught be type not identity. This could be changed to explicitely forbid str subinstances. And raise type(None), None becomes ambiguous: It is interpreted as raise type(None) i.e. it raises the type(None) object as an exception, not the object None (which is of type type(None)) As soon as Exception is a new style class we could limit the allowed objects to (sub)instances of Exception. -- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-06 02:07 Message: Logged In: YES user_id=6380 Sorry, HEAPTYPE is not the proper way to check for a new-style class; it would exclude any new-style classes defined by C code. I also think that if you want to do this it should done properly, and allow "raise C, C()" as well. At best there's agreement that it's not worth trying to fix Python to allow new-style classes as exceptions when we're also trying to encourage that exceptions derive from Exception. If your module declares its exceptions as deriving from Exception,
[ python-Bugs-1086096 ] two strings holding the same value have different id
Bugs item #1086096, was opened at 2004-12-15 17:10 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086096&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Stefan Seefeld (stefan) Assigned to: Nobody/Anonymous (nobody) Summary: two strings holding the same value have different id Initial Comment: I'v run into a problem with a program that expects a string to be either 'resource' or 'test': type = ... if type is "resource": do_something() elif type is "test": do_something_else() The above comparison using 'is' works fine with python 2.3, but fails with python 2.4. Unfortunately I wasn't able to isolate the problem. To reproduce: Install qmtest from http://www.qmtest.com on windows xp with python 2.4 (I don't know yet whether other platforms are affected, too). Then follow the instructions from http://www.codesourcery.com/public/qmtest/qm-2.2/manual.html up to section 2.2 'Starting the Graphical Interface'. In the browser, click on the 'exec1' test, and you'll get an 'UnboundLocalError' because the application logic didn't expect some comparison to fail. The failed comparison in question is 't is "test"', which returns 'False' even though t == "test". -- >Comment By: Tim Peters (tim_one) Date: 2004-12-15 17:27 Message: Logged In: YES user_id=31435 Sorry, the only bug I see here is in the code you posted using "is" to try to determine whether two strings are equal. "is" tests for object identity, not for equality, and whether two immutable objects are really the same object isn't in general defined by Python. You should use "==" to check two strings for equality. The only time it's reliable to use "is" for that purpose is when you've explicitly interned all strings being compared (via using the intern() builtin function). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086096&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1086127 ] Typo in module os documentation
Bugs item #1086127, was opened at 2004-12-15 23:14 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=1086127&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Connelly (connelly) Assigned to: Nobody/Anonymous (nobody) Summary: Typo in module os documentation Initial Comment: In the docs for module os ( http://docs.python.org/lib/os-path.html ): pathsep The character conventionally used by the operating system to separate search patch components (as in PATH), such as ":" for POSIX or ";" for Windows. Also available via os.path. Replace "patch" with "path". - Connelly Barnes -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086127&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1076985 ] Incorrect behaviour of StreamReader.readline leads to crash
Bugs item #1076985, was opened at 2004-12-01 19:51
Message generated for change (Comment added) made by doerwalter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076985&group_id=5470
Category: Python Library
Group: Python 2.4
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Sebastian Hartte (dark-storm)
>Assigned to: M.-A. Lemburg (lemburg)
Summary: Incorrect behaviour of StreamReader.readline leads to crash
Initial Comment:
StreamReader.readline in codecs.py misinterprets the
size parameter. (File: codecs.py, Line: 296).
The reported crash happens if a file processed by the
python tokenizer is using a not built-in codec for
source file encoding (i.e. iso-8859-15) and has lines
that are longer than the define BUFSIZ in stdio.h on
the platform python is compiled on. (On Windows for
MSVC++ this define is 512, thus a line that is longer
than 511 characters should suffice to crash python with
the correct encoding).
The crash happens because the python core assumes that
the StreamReader.readline method returns a string
shorter than the platforms BUFSIZ macro (512 for MSVC).
The current StreamReader.readline() looks like this:
---
def readline(self, size=None, keepends=True):
""" Read one line from the input stream and
return the
decoded data.
size, if given, is passed as size argument
to the
read() method.
"""
if size is None:
size = 10
line = u""
while True:
data = self.read(size)
line += data
pos = line.find("\n")
if pos>=0:
self.charbuffer = line[pos+1:] +
self.charbuffer
if keepends:
line = line[:pos+1]
else:
line = line[:pos]
return line
elif not data:
return line
if size<8000:
size *= 2
---
However, the core expects readline() to return at most
a string of the length size. readline() instead passes
size to the read() function.
There are multiple ways of solving this issue.
a) Make the core reallocate the token memory if the
string returned by the readline function exceeds the
expected size (risky if the line is very long).
b) Fix, rename, remodel, change StreamReader.readline.
If no other part of the core or code expects size to do
nothing useful, the following readline() function does
behave correctly with arbitrarily long lines:
---
def readline(self, size=None, keepends=True):
""" Read one line from the input stream and
return the
decoded data.
size, if given, is passed as size argument
to the
read() method.
"""
if size is None:
size = 10
data = self.read(size)
pos = data.find("\n")
if pos>=0:
self.charbuffer = data[pos+1:] +
self.charbuffer
if keepends:
data = data[:pos+1]
else:
data = data[:pos]
return data
else:
return data # Return the data directly
since otherwise
# we would exceed the given size.
---
Reproducing this bug:
This bug can only be reproduced if your platform does
use a small BUFSIZ for stdio operations (i.e. MSVC), i
didn't check but Linux might use more than 8000 byte
for the default buffer size. That means you would have
to use a line with more than 8000 characters to
reproduce this.
In addition, this bug only shows if the python
libraries StreamReader.readline() method is used, if
internal codecs like Latin-1 are used, there is no
crash since the method isn't used.
I've attached a file that crashes my Python 2.4 on
Windows using the official binary released on
python.org today.
Last but not least here is the assertion that is broken
if python is compiled in debug mode with MSVC++ 7.1:
Assertion failed: strlen(str) < (size_t)size, file
\Python-2.4\Parser\tokenizer.
c, line 367
--
>Comment By: Walter Dörwald (doerwalter)
Date: 2004-12-16 00:55
Message:
Logged In: YES
user_id=89016
OK, here is a patch (fix_readline_and_read.diff) that keeps
the new readline behaviour when size is None and calls read
only once (i.e. the 2.3 behaviour) otherwise. The "read()
cleanup patch" is also included. Running dark-storm's test
script on Windows with the patch applied confirms that it
fixed this particular problem (of course the tokenizer should
still be fixed). Marc-André, if there are no objections, can I
check this in?
--
Comment By: Sebastian Hartte (dark-storm)
Date: 2004-12-03 22:45
Message:
Logged In: YES
