[ python-Bugs-1337400 ] Python.h should include system headers properly [POSIX]
Bugs item #1337400, was opened at 2005-10-25 14:38 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=1337400&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: Dimitri Papadopoulos (papadopo) Assigned to: Nobody/Anonymous (nobody) Summary: Python.h should include system headers properly [POSIX] Initial Comment: In Python 2.4.2, Python.h looks like this: #include [...] #include [...] #include #include #include #ifdef HAVE_UNISTD_H #include #endif On POSIX platforms should be included first! Indeed it includes headers such as on Solaris, on Irix, or on GNU systems, which define macros that specify the system interfaces to use, possibly depending on compiler options, which in turn may enable/disable/modify parts of other system headers such as or . By including , you ensure consistent systems interfaces are specified in all system headers included by Python sources. This may seem rather academic, but it actually breaks my Solaris builds: I need to compile Python using Sun's C compiler when building Python for performance and GNU's C++ compiler when building Python modules written in C++ for compatibility with C++ libraries used by these modules that can't be compiled with Sun's C++ compiler. So the same Python.h is used by Sun's C compiler (which it was created for in the first place) and GNU's C++ compiler. GNU's C++ compiler fails to compile some modules. Unfortunately I can't recall the exact modules and error messages right now, but including fixes the problem. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1337400&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1337400 ] Python.h should include system headers properly [POSIX]
Bugs item #1337400, was opened at 2005-10-25 14:38 Message generated for change (Comment added) made by papadopo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1337400&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: Dimitri Papadopoulos (papadopo) Assigned to: Nobody/Anonymous (nobody) Summary: Python.h should include system headers properly [POSIX] Initial Comment: In Python 2.4.2, Python.h looks like this: #include [...] #include [...] #include #include #include #ifdef HAVE_UNISTD_H #include #endif On POSIX platforms should be included first! Indeed it includes headers such as on Solaris, on Irix, or on GNU systems, which define macros that specify the system interfaces to use, possibly depending on compiler options, which in turn may enable/disable/modify parts of other system headers such as or . By including , you ensure consistent systems interfaces are specified in all system headers included by Python sources. This may seem rather academic, but it actually breaks my Solaris builds: I need to compile Python using Sun's C compiler when building Python for performance and GNU's C++ compiler when building Python modules written in C++ for compatibility with C++ libraries used by these modules that can't be compiled with Sun's C++ compiler. So the same Python.h is used by Sun's C compiler (which it was created for in the first place) and GNU's C++ compiler. GNU's C++ compiler fails to compile some modules. Unfortunately I can't recall the exact modules and error messages right now, but including fixes the problem. -- >Comment By: Dimitri Papadopoulos (papadopo) Date: 2005-10-25 15:57 Message: Logged In: YES user_id=52414 Oops... Instead of including fixes the problem. please read including first fixes the problem. Here is an example to reproduce the problem: $ cat > foo.cpp #include #include $ $ g++ -I/usr/local/python/include/python2.4 -c foo.cpp [...] /usr/local/gcc-4.0.2/lib/gcc/sparc-sun-solaris2.8/4.0.2/../../../../include/c++/4.0.2/cwchar:145: error: '::btowc' has not been declared [...] $ $ cat > foo.cpp #include #include #include $ $ g++ -I/usr/local/python/include/python2.4 -c foo.cpp [...] $ -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1337400&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-874534 ] Errors testing python 2.3.3
Bugs item #874534, was opened at 2004-01-10 19:32
Message generated for change (Comment added) made by spektrum
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=874534&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Pierre (pierre42)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Errors testing python 2.3.3
Initial Comment:
# gmake test
case $MAKEFLAGS in *-s*)
LD_LIBRARY_PATH=/tmp/Python-2.3.3:/usr/local/lib:/usr/local/qt/lib:/usr/local/kde/lib:/usr/local/pwlib/lib:/usr/local/openh323/lib
CC='gcc' LDSHARED='gcc -shared' OPT='-DNDEBUG -g -O3
-Wall -Wstrict-prototypes' ./python -E ./setup.py -q
build;; *)
LD_LIBRARY_PATH=/tmp/Python-2.3.3:/usr/local/lib:/usr/local/qt/lib:/usr/local/kde/lib:/usr/local/pwlib/lib:/usr/local/openh323/lib
CC='gcc' LDSHARED='gcc -shared' OPT='-DNDEBUG -g -O3
-Wall -Wstrict-prototypes' ./python -E ./setup.py build;; esac
running build
running build_ext
building 'dbm' extension
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC
-fno-strict-aliasing -DHAVE_NDBM_H -I.
-I/tmp/Python-2.3.3/./Include -I/usr/local/include
-I/tmp/Python-2.3.3/Include -I/tmp/Python-2.3.3 -c
/tmp/Python-2.3.3/Modules/dbmmodule.c -o
build/temp.linux-i686-2.3/dbmmodule.o
gcc -shared build/temp.linux-i686-2.3/dbmmodule.o
-L/usr/local/lib -o build/lib.linux-i686-2.3/dbm.so
*** WARNING: renaming "dbm" since importing it failed:
build/lib.linux-i686-2.3/dbm.so: undefined symbol:
dbm_firstkey
running build_scripts
find ./Lib -name '*.py[co]' -print | xargs rm -f
LD_LIBRARY_PATH=/tmp/Python-2.3.3:/usr/local/lib:/usr/local/qt/lib:/usr/local/kde/lib:/usr/local/pwlib/lib:/usr/local/openh323/lib
./python -E -tt ./Lib/test/regrtest.py -l
test_grammar
[...]
test_codecs
test test_codecs failed -- Traceback (most recent call
last):
File "/tmp/Python-2.3.3/Lib/test/test_codecs.py",
line 333, in test_nameprep
raise test_support.TestFailed("Test 3.%d: %s" %
(pos+1, str(e)))
TestFailed: Test 3.5: u'\u0143 \u03b9' != u'\u0144 \u03b9'
test_codeop
[...]
test_format
/tmp/Python-2.3.3/Lib/test/test_format.py:19:
FutureWarning: %u/%o/%x/%X of negative int will return
a signed string in Python 2.4 and up
result = formatstr % args
test_fpformat
[...]
test_re
test test_re produced unexpected output:
**
*** lines 2-3 of actual output doesn't appear in
expected output after line 1:
+ === Failed incorrectly ('(?u)\b.\b', u'\xc4', 0,
'found', u'\xc4')
+ === Failed incorrectly ('(?u)\w', u'\xc4', 0,
'found', u'\xc4')
**
test_regex
[...]
test_unicode
test test_unicode failed -- errors occurred in
test.test_unicode.UnicodeTest
test_unicode_file
test_unicode_file skipped -- No Unicode filesystem
semantics on this platform.
test_unicodedata
test test_unicodedata failed -- Traceback (most recent
call last):
File
"/tmp/Python-2.3.3/Lib/test/test_unicodedata.py", line
62, in test_method_checksum
self.assertEqual(result, self.expectedchecksum)
File "/tmp/Python-2.3.3/Lib/unittest.py", line 302,
in failUnlessEqual
raise self.failureException, AssertionError:
'c269de8355871e3210ae8710b45c2ddb0675b9d5' !=
'a37276dc2c158bef6dfd908ad34525c97180fad9'
test_univnewlines
[...]
test_zlib
222 tests OK.
4 tests failed:
test_codecs test_re test_unicode test_unicodedata
29 tests skipped:
test_aepack test_al test_bsddb185 test_bsddb3
test_cd test_cl
test_curses test_dbm test_email_codecs test_gl
test_imgfile
test_linuxaudiodev test_locale test_macfs
test_macostools test_nis
test_normalization test_ossaudiodev test_pep277
test_plistlib
test_scriptpackages test_socket_ssl test_socketserver
test_sunaudiodev test_timeout test_unicode_file
test_urllibnet
test_winreg test_winsound
2 skips unexpected on linux2:
test_dbm test_locale
gmake: *** [test] Error 1
--
Comment By: Matejcik (spektrum)
Date: 2005-10-25 17:29
Message:
Logged In: YES
user_id=631694
i can confirm it happens in 2.3.3 and 2.3.5
compiler is gcc 3.3.3 or 4.0.2, happens with and without
optimization
i used the following configure options:
--with-wctype-functions --with-fpectl --enable-shared
--enable-unicode
when using defaults, the tests pass
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-02 09:12
Message:
Logged In: YES
user_id=33168
Are you still having these problems? What compiler are you
using? Have you tried building without optimization to see
if the problems go away?
--
You can respond by visiting:
https://sourceforge.net/track
[ python-Bugs-1336623 ] tarfile can't extract some tar archives..
Bugs item #1336623, was opened at 2005-10-24 17:47
Message generated for change (Comment added) made by meren
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1336623&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: A. Murat EREN (meren)
Assigned to: Nobody/Anonymous (nobody)
Summary: tarfile can't extract some tar archives..
Initial Comment:
Here is a small demo to reproduce the same problem:
-8<-8<-8<-8<---
[EMAIL PROTECTED] /home/meren $ wget
ftp://ftp.sleepycat.com/releases/db.1.85.tar.gz
(...)
100%[>] 270,953 17.13K/sETA 00:00
20:21:09 (15.25 KB/s) - `db.1.85.tar.gz' saved [270,953]
[EMAIL PROTECTED] /home/meren $ file db.1.85.tar.gz
db.1.85.tar.gz: gzip compressed data, from Unix
[EMAIL PROTECTED] /home/meren $ python
>>> tar = tarfile.open("db.1.85.tar.gz", "r:gz")
>>> for tarinfo in tar:
... print tarinfo.name
...
db.1.85
db.1.85/btree
db.1.85/btree/Makefile.inc
db.1.85/btree/bt_close.c
db.1.85/btree/bt_conv.c
db.1.85/btree/bt_debug.c
db.1.85/btree/bt_delete.c
db.1.85/btree/btree.h
db.1.85/btree/bt_get.c
db.1.85/btree/bt_open.c
(...)
>>> for tarinfo in tar:
... tar.extract(tarinfo)
...
>>> Ctrl + D
[EMAIL PROTECTED] /home/meren $ ls db*
db.1.85
db.1.85.tar.gz
[EMAIL PROTECTED] /home/meren $ file db.1.85
db.1.85: empty
[EMAIL PROTECTED] /home/meren $ cat db.1.85
[EMAIL PROTECTED] /home/meren $
->8->8->8->8---
Also this file is extracting with the same result too:
ftp://ftp.linux.org.tr/pub/mirrors/gentoo/distfiles/ncompress-4.2.4.tar.gz
This thing is very rarely happening, but it is
happening. Also, I could extract these archives
properly via the native 'tar' binary..
Thanks in advance,
Ciao.
--
>Comment By: A. Murat EREN (meren)
Date: 2005-10-25 18:36
Message:
Logged In: YES
user_id=718263
I figured out that this is a very pesky problem.
The problem is coming from the tar archives themselves.
Simply, the "tarinfo.isdir()" check in the library returns
false for the directories and they are extracting like a
regular file.. How did they create these fool archives I
don't know, and I couldn't reproduce similar buggy archives
by myself. It would be nice to know.
Because of the problem is not in the python library, it is
very difficult to implement an efficent workaround to
properly extract this kind of buggy tar archives. I'm going
to attach a dirty workaround to show the idea (is anyone
reading these reports?)..
Ciao..
--
Comment By: A. Murat EREN (meren)
Date: 2005-10-24 18:19
Message:
Logged In: YES
user_id=718263
more examples:
ftp://ftp.porcupine.org/pub/security/portmap_5beta.tar.gz
ftp://ftp.porcupine.org/pub/security/tcp_wrappers_7.6.tar.gz
additionally, the same problem appearing when trying to extract
these archives with the "ark" (yet another kde tool, just a simple
front-end for the tar command. interesting, isn't it).
Ciao.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1336623&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1336623 ] tarfile can't extract some tar archives..
Bugs item #1336623, was opened at 2005-10-24 17:47
Message generated for change (Comment added) made by meren
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1336623&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: A. Murat EREN (meren)
Assigned to: Nobody/Anonymous (nobody)
Summary: tarfile can't extract some tar archives..
Initial Comment:
Here is a small demo to reproduce the same problem:
-8<-8<-8<-8<---
[EMAIL PROTECTED] /home/meren $ wget
ftp://ftp.sleepycat.com/releases/db.1.85.tar.gz
(...)
100%[>] 270,953 17.13K/sETA 00:00
20:21:09 (15.25 KB/s) - `db.1.85.tar.gz' saved [270,953]
[EMAIL PROTECTED] /home/meren $ file db.1.85.tar.gz
db.1.85.tar.gz: gzip compressed data, from Unix
[EMAIL PROTECTED] /home/meren $ python
>>> tar = tarfile.open("db.1.85.tar.gz", "r:gz")
>>> for tarinfo in tar:
... print tarinfo.name
...
db.1.85
db.1.85/btree
db.1.85/btree/Makefile.inc
db.1.85/btree/bt_close.c
db.1.85/btree/bt_conv.c
db.1.85/btree/bt_debug.c
db.1.85/btree/bt_delete.c
db.1.85/btree/btree.h
db.1.85/btree/bt_get.c
db.1.85/btree/bt_open.c
(...)
>>> for tarinfo in tar:
... tar.extract(tarinfo)
...
>>> Ctrl + D
[EMAIL PROTECTED] /home/meren $ ls db*
db.1.85
db.1.85.tar.gz
[EMAIL PROTECTED] /home/meren $ file db.1.85
db.1.85: empty
[EMAIL PROTECTED] /home/meren $ cat db.1.85
[EMAIL PROTECTED] /home/meren $
->8->8->8->8---
Also this file is extracting with the same result too:
ftp://ftp.linux.org.tr/pub/mirrors/gentoo/distfiles/ncompress-4.2.4.tar.gz
This thing is very rarely happening, but it is
happening. Also, I could extract these archives
properly via the native 'tar' binary..
Thanks in advance,
Ciao.
--
>Comment By: A. Murat EREN (meren)
Date: 2005-10-25 18:58
Message:
Logged In: YES
user_id=718263
no files attached.. sorry, here it is..
--
Comment By: A. Murat EREN (meren)
Date: 2005-10-25 18:36
Message:
Logged In: YES
user_id=718263
I figured out that this is a very pesky problem.
The problem is coming from the tar archives themselves.
Simply, the "tarinfo.isdir()" check in the library returns
false for the directories and they are extracting like a
regular file.. How did they create these fool archives I
don't know, and I couldn't reproduce similar buggy archives
by myself. It would be nice to know.
Because of the problem is not in the python library, it is
very difficult to implement an efficent workaround to
properly extract this kind of buggy tar archives. I'm going
to attach a dirty workaround to show the idea (is anyone
reading these reports?)..
Ciao..
--
Comment By: A. Murat EREN (meren)
Date: 2005-10-24 18:19
Message:
Logged In: YES
user_id=718263
more examples:
ftp://ftp.porcupine.org/pub/security/portmap_5beta.tar.gz
ftp://ftp.porcupine.org/pub/security/tcp_wrappers_7.6.tar.gz
additionally, the same problem appearing when trying to extract
these archives with the "ark" (yet another kde tool, just a simple
front-end for the tar command. interesting, isn't it).
Ciao.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1336623&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1191458 ] [AST] Failing tests
Bugs item #1191458, was opened at 2005-04-27 20:30 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1191458&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: AST Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Jeremy Hylton (jhylton) Summary: [AST] Failing tests Initial Comment: This tracker item is to be used to keep track of what tests are currently failing on the AST branch. This is somewhat important sinced there are so many failures it can be hard to detect if a change fixed what it was supposed to or actually managed to break more code. When posting follow-ups of fixed tests, please re-list the currently failing tests so as to make it simple to reference the current state of things. So, the current offenders are (from a straight ``regrtest.py`` run on my OS X box, which always has test__locale fail so I removed it):: test_compile test_cookielib test_dis test_doctest test_future test_genexps test_inspect test_itertools test_new test_peepholer test_scope test_socket test_sort test_subprocess test_symtable test_syntax test_trace test_traceback test_warnings test_zipfile -- >Comment By: Brett Cannon (bcannon) Date: 2005-10-25 15:03 Message: Logged In: YES user_id=357491 Yep, all tests pass, so that just leaves the test_trace tests that are currently commented out. -- Comment By: Neil Schemenauer (nascheme) Date: 2005-10-23 21:51 Message: Logged In: YES user_id=35752 I believe the only remaining broken tests are the ones commented out in test_trace. -- Comment By: Jeremy Hylton (jhylton) Date: 2005-10-07 11:46 Message: Logged In: YES user_id=31392 test_dis update: Fixed one of two failing tests. test_dis() was easy. test_bug_708901() is harder. The current AST only stores line numbers for statements. The test case is checking that the lnotab can assign a single statement multiple line numbers; in this case, the statement spans multiple lines and the disassembled code should reflect that. The fix is probably to add line numbers to expressions, which requires changing the AST definition and updating ast.c to assign line numbers. -- Comment By: Jeremy Hylton (jhylton) Date: 2005-10-07 11:01 Message: Logged In: YES user_id=31392 Here's a quick status report on Linux + GCC 3.2.2 from today: 12 tests failed: test_dis test_doctest test_future test_genexps test_inspect test_new test_peepholer test_pwd test_scope test_subprocess test_symtable test_trace 7 skips unexpected on linux2: test_hotshot test_bsddb test_email test_parser test_transformer test_email_codecs test_compiler I'm going to trace into the details of why each of these tests is failing. -- Comment By: Brett Cannon (bcannon) Date: 2005-07-10 21:15 Message: Logged In: YES user_id=357491 Scratch the "all open bugs" comment; didn't get to bug #1195576. -- Comment By: Brett Cannon (bcannon) Date: 2005-07-10 21:13 Message: Logged In: YES user_id=357491 After applying all patches associated with all open bugs, the failing tests from ``./python.exe Lib/test/regrtest.py`` are: 14 tests failed: test_cookielib test_dis test_future test_genexps test_inspect test_new test_peepholer test_scope test_subprocess test_symtable test_syntax test_trace test_traceback test_warnings -- Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 04:40 Message: Logged In: YES user_id=1038590 Fixing #1186353 (lambda argument unpacking) fixes test_sort and test_itertools: 17 tests failed: test_compile test_cookielib test_dis test_doctest test_future test_genexps test_inspect test_new test_ossaudiodev test_peepholer test_scope test_subprocess test_symtable test_syntax test_trace test_traceback test_warnings -- Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 01:33 Message: Logged In: YES user_id=1038590 Bumped bug priority to 9 so it stays on top of the SF tracker. Also, we can't merge the AST branch until this bug is closed, so it is fairly important to close out these issues :) Running "./python Lib/test/regrtest.py -uall" Suse Linux 9.1: 20 tests failed: test_compile test_cookielib test_dis te
[ python-Bugs-1337987 ] IDLE, F5 wrong external file content on error.
Bugs item #1337987, was opened at 2005-10-26 04:12 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=1337987&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: MvGulik (tyrell_rr) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE, F5 wrong external file content on error. Initial Comment: IDLE, F5 wrong external file content on error. using: Python 2.3.5 (#62, Feb 8 2005, 16:23:02) [MSC v.1200 32 bit (Intel)] on win32 IDLE 1.0.5 , TK: 8.4 The basic problem is that when a external file is reloaded, by using F5, and that file contains a error. IDLE will tell about the error, and highlight the error, but its still using the old file content in its GUI window and not the newly reloaded file content. when: (IDLE GUI) - using F5 to reload and restart a external script. - new and changed script file containing a error. what: - display is showing previous script content. - error highlight is pointing at the wrong code. (bad!) how: first file: (create, load and execute) --- a = 1 print a --- change to: --- a = 1 print a : print a --- use F5 to auto reload and execute. Anything I'm doing wrong, or I can do locally to fix this?. just let me know. ps: upgrade to 2.4.x is not really a option in my case. (not yet at leased) Cheers M.v.Gulik -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1337987&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1337990 ] doctest mishandles exceptions raised within generators
Bugs item #1337990, was opened at 2005-10-26 11:48
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=1337990&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: Tim Wegener (twegener)
Assigned to: Nobody/Anonymous (nobody)
Summary: doctest mishandles exceptions raised within generators
Initial Comment:
If a generator raises an exception while iterating over it, doctest
will only register the exception output, and will miss output that
occurred during previous loop iterations.
The following code clarifies and reproduces the problem:
(also included as an attachment)
"""Reproduce bug with exceptions in a generator in doctest tests.
This bug has been seen to occur in:
Linux (RH9):
Python 2.4.1
Python 2.3.5
Python 2.2.2 (using from __future__ import generators)
Windows XP:
Python 2.4.2
Python 2.3.5
"""
def error_generator():
"""Yield 0 to 2 and then try and raise an exception.
>>> for j in error_generator():
...print j
0
1
2
Traceback (most recent call last):
Exception: Contrived exception for sake of example
"""
# Note: This is obviously a contrived example of generator use.
for i in range(3):
yield i
if 1:
raise Exception("Contrived exception for sake of example")
raise StopIteration
if __name__ == '__main__':
# Run the doctest tests.
import sys
import doctest
doctest.testmod(sys.modules['__main__'])
print
print 'What should have happened...'
for j in error_generator():
print j
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1337990&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1337987 ] IDLE, F5 wrong external file content. (on error!)
Bugs item #1337987, was opened at 2005-10-26 04:12 Message generated for change (Comment added) made by tyrell_rr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1337987&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: MvGulik (tyrell_rr) Assigned to: Nobody/Anonymous (nobody) >Summary: IDLE, F5 wrong external file content. (on error!) Initial Comment: IDLE, F5 wrong external file content on error. using: Python 2.3.5 (#62, Feb 8 2005, 16:23:02) [MSC v.1200 32 bit (Intel)] on win32 IDLE 1.0.5 , TK: 8.4 The basic problem is that when a external file is reloaded, by using F5, and that file contains a error. IDLE will tell about the error, and highlight the error, but its still using the old file content in its GUI window and not the newly reloaded file content. when: (IDLE GUI) - using F5 to reload and restart a external script. - new and changed script file containing a error. what: - display is showing previous script content. - error highlight is pointing at the wrong code. (bad!) how: first file: (create, load and execute) --- a = 1 print a --- change to: --- a = 1 print a : print a --- use F5 to auto reload and execute. Anything I'm doing wrong, or I can do locally to fix this?. just let me know. ps: upgrade to 2.4.x is not really a option in my case. (not yet at leased) Cheers M.v.Gulik -- >Comment By: MvGulik (tyrell_rr) Date: 2005-10-26 04:37 Message: Logged In: YES user_id=779309 huu, little update. the error itself is not part of the real (code)problem. ( it is of course when its leading to misleading debug info ) but the display of the external file in just not updated after using F5. with or without a error being triggerd. M.v.Gulik -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1337987&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1337987 ] IDLE, F5 wrong external file content. (on error!)
Bugs item #1337987, was opened at 2005-10-25 21:12 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1337987&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: MvGulik (tyrell_rr) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE, F5 wrong external file content. (on error!) Initial Comment: IDLE, F5 wrong external file content on error. using: Python 2.3.5 (#62, Feb 8 2005, 16:23:02) [MSC v.1200 32 bit (Intel)] on win32 IDLE 1.0.5 , TK: 8.4 The basic problem is that when a external file is reloaded, by using F5, and that file contains a error. IDLE will tell about the error, and highlight the error, but its still using the old file content in its GUI window and not the newly reloaded file content. when: (IDLE GUI) - using F5 to reload and restart a external script. - new and changed script file containing a error. what: - display is showing previous script content. - error highlight is pointing at the wrong code. (bad!) how: first file: (create, load and execute) --- a = 1 print a --- change to: --- a = 1 print a : print a --- use F5 to auto reload and execute. Anything I'm doing wrong, or I can do locally to fix this?. just let me know. ps: upgrade to 2.4.x is not really a option in my case. (not yet at leased) Cheers M.v.Gulik -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-10-25 21:45 Message: Logged In: YES user_id=80475 Save with Control-S before pressing F5. -- Comment By: MvGulik (tyrell_rr) Date: 2005-10-25 21:37 Message: Logged In: YES user_id=779309 huu, little update. the error itself is not part of the real (code)problem. ( it is of course when its leading to misleading debug info ) but the display of the external file in just not updated after using F5. with or without a error being triggerd. M.v.Gulik -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1337987&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
