[ python-Bugs-1110705 ] list comprehension scope
Bugs item #1110705, was opened at 2005-01-27 15:27 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=1110705&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Simon Dahlbacka (sdahlbac) Assigned to: Nobody/Anonymous (nobody) Summary: list comprehension scope Initial Comment: The variable used for iteration in list comprehensions is still in scope after the list comprehension. >>>foo = [1, 2, 3] >>>bar = [dummy + 1 for dummy in foo] >>>dummy 3 Expected result: NameError: name 'dummy' is not defined -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110705&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1110705 ] list comprehension scope
Bugs item #1110705, was opened at 2005-01-27 15:27 Message generated for change (Comment added) made by sdahlbac You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110705&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Closed Resolution: Invalid Priority: 5 Submitted By: Simon Dahlbacka (sdahlbac) Assigned to: Nobody/Anonymous (nobody) Summary: list comprehension scope Initial Comment: The variable used for iteration in list comprehensions is still in scope after the list comprehension. >>>foo = [1, 2, 3] >>>bar = [dummy + 1 for dummy in foo] >>>dummy 3 Expected result: NameError: name 'dummy' is not defined -- >Comment By: Simon Dahlbacka (sdahlbac) Date: 2005-01-27 16:11 Message: Logged In: YES user_id=750513 Seemingly (according to: http://docs.python.org/ref/lists.html) this is indeed a bug that should be fixed. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-27 15:48 Message: Logged In: YES user_id=80475 This is not a bug. It is behaving as designed. The thought was to emulate the behavior of an equivalent for-loop. In future versions of Python, Guido would like to change the design to hide the induction variable. So, someday, you'll get your wish. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110705&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1110705 ] list comprehension scope
Bugs item #1110705, was opened at 2005-01-27 08:27 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110705&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Simon Dahlbacka (sdahlbac) Assigned to: Nobody/Anonymous (nobody) Summary: list comprehension scope Initial Comment: The variable used for iteration in list comprehensions is still in scope after the list comprehension. >>>foo = [1, 2, 3] >>>bar = [dummy + 1 for dummy in foo] >>>dummy 3 Expected result: NameError: name 'dummy' is not defined -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-27 08:48 Message: Logged In: YES user_id=80475 This is not a bug. It is behaving as designed. The thought was to emulate the behavior of an equivalent for-loop. In future versions of Python, Guido would like to change the design to hide the induction variable. So, someday, you'll get your wish. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110705&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1074011 ] write failure ignored in Py_Finalize()
Bugs item #1074011, was opened at 2004-11-27 00:02
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074011&group_id=5470
Category: Python Interpreter Core
Group: Python 2.3
Status: Closed
Resolution: Accepted
Priority: 6
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: write failure ignored in Py_Finalize()
Initial Comment:
[forwarded from http://bugs.debian.org/283108]
Write errors on stdout may be ignored, and hence may
result in loss of valuable user data.
Here's a quick demo:
$ ./close-bug
foo
$ ./close-bug > /dev/full && echo unreported write failure
unreported write failure
$ cat close-bug
#!/usr/bin/python
import sys
def main ():
try:
print 'foo'
sys.stdout.close ()
except IOError, e:
sys.stderr.write ('write failed: %s\n' % e)
sys.exit (1)
if __name__ == '__main__':
main ()
This particular failure comes from the following
unchecked fflush
of stdout in pythonrun.c:
static void
call_ll_exitfuncs(void)
{
while (nexitfuncs > 0)
(*exitfuncs[--nexitfuncs])();
fflush(stdout);
fflush(stderr);
}
Flushing the stream manually, python does raise an
exception.
Please note that simply adding a test for fflush
failure is
not sufficient. If you change the above to do this:
if (fflush(stdout) != 0)
{
...handle error...
}
It will appear to solve the problem.
But here is a counterexample:
import sys
def main ():
try:
print "x" * 4095
print
sys.stdout.close ()
except IOError, e:
sys.stderr.write ('write failed: %s\n' % e)
sys.exit (1)
if __name__ == '__main__':
main ()
If you run the above with stdout redirected to /dev/full,
it will silently succeed (exit 0) in spite of a write
failure.
That's what happens on my debian unstable system.
Instead of just checking the fflush return value,
it should also check ferror:
if (fflush(stdout) != 0 || ferror(stdout))
{
...handle error...
}
--
>Comment By: Martin v. Löwis (loewis)
Date: 2005-01-27 19:59
Message:
Logged In: YES
user_id=21627
The patch turns out to be incorrect: fflushing(stdin) causes
undefined behaviour, and indeed does cause problems on OS
X (fflush fails, and python returns with a non-zero exit
status).
Reverting the close function for stdin:
NEWS 1.831.4.166
sysmodule.c 2.120.6.3
NEWS 1.1193.2.16
sysmodule.c 2.126.2.2
NEWS 1.1234
sysmodule.c 2.128
--
Comment By: Martin v. Löwis (loewis)
Date: 2005-01-23 10:51
Message:
Logged In: YES
user_id=21627
Thanks for the report and the patch. Committed as
NEWS 1.1232
sysmodule.c 2.127
NEWS 1.1193.2.15
sysmodule.c 2.126.2.1
NEWS 1.831.4.164
sysmodule.c 2.120.6.2
--
Comment By: Jim Meyering (meyering)
Date: 2005-01-20 10:24
Message:
Logged In: YES
user_id=41497
Hi Martin,
I would have done that, but sys.stdout.close is already
defined *not* to close stdout. Here's the relevant FAQ:
1.4.7 Why doesn't closing sys.stdout (stdin, stderr)
really close it?
http://www.python.org/doc/faq/library.html#id28
--
Comment By: Martin v. Löwis (loewis)
Date: 2005-01-19 23:28
Message:
Logged In: YES
user_id=21627
I don't think the patch is right. If somebody explicitly
invokes sys.stdout.close(), this should have the same effect
as invoking fclose(stdout) in C.
It currently doesn't, but with meyering's patch from
2004-12-02 10:20, it still doesn't, so the patch is incorrect.
It might be better to explicitly invoke fclose() if the file
object has no associated f_close function.
--
Comment By: Ben Hutchings (wom-work)
Date: 2004-12-20 00:38
Message:
Logged In: YES
user_id=203860
Tim, these bugs are quite difficult to trigger, but they can
hide any kind of file error and lose arbitrarily large
amounts of data.
Here, the following program will run indefinitely:
full = open('/dev/full', 'w')
while 1:
print >>full, 'x' * 1023
print >>full
It seems to be essential that both the character that fills
the file buffer (here it is 1024 bytes long) and the next
are generated implicitly by print - otherwise the write
error will be detected.
--
Comment By: Tim Peters (tim_one)
Date: 2004-12-19 23:24
Message:
Logged In: YES
user_id=31435
Sorry, don't care enough to spend time on it (not a bug I've
had, not one I expect to have, don't care if it never
changes). Suggest not using /de
[ python-Bugs-1110998 ] RLock logging mispells "success"
Bugs item #1110998, was opened at 2005-01-27 12:05 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=1110998&group_id=5470 Category: Threads Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Matthew Bogosian (mbogosian) Assigned to: Nobody/Anonymous (nobody) Summary: RLock logging mispells "success" Initial Comment: When verbose logging is turned on for RLock objects (via the constructor), attempts to acquire the lock are logged, but spelling didn't seem to be a priority ;-) : Thread-2: <_RLock(Thread-2, 1)>.acquire(1): initial succes "succes" should be "success" This was present in my tests of 2.3 and 2.4. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110998&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1029561 ] test_pep277 fails
Bugs item #1029561, was opened at 2004-09-17 08:24 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1029561&group_id=5470 Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Marek Baczynski (imbaczek) Assigned to: Nobody/Anonymous (nobody) Summary: test_pep277 fails Initial Comment: Running regrtest.py: test_pep277 test test_pep277 produced unexpected output: ** *** mismatch between line 3 of expected output and line 3 of actual output: - ['???', '???', '??', '', 'G\xdf', 'Ge??-sa?', 'Gr\xfc\xdf-Gott', 'abc', 'ascii'] ? ^ + ['???', '???', '-???', '??', '', '?\xdf', 'Gr\xfc\xdf-Gott', 'abc', 'ascii'] ? ^ ** But when running just test_pep277.py: test_directory (__main__.UnicodeFileTests) ... u'\xdf-\u66e8\u66e9\u66eb' ok test_failures (__main__.UnicodeFileTests) ... ok test_listdir (__main__.UnicodeFileTests) ... ['???', '???', '-???', '??', '', '?\xdf', 'Gr\xfc\xdf-Gott', 'abc', 'ascii'] [u'Gr\xfc\xdf-Gott', u'abc', u'ascii', u'\u0393\u03b5\u03b9\u03ac-\u03c3\u03b1\u03c2', u'\u0417\u0434\u0440\u0430\u0432\u0441\u0442\u0432\u0443\u0439\u0442\u0435', u'\u05d4\u05e9\u05e7\u05e6\u05e5\u05e1', u'\u306b\u307d\u3093', u'\u66e8\u05e9\u3093\u0434\u0393\xdf', u'\u66e8\u66e9\u66eb'] ok test_open (__main__.UnicodeFileTests) ... ok test_rename (__main__.UnicodeFileTests) ... ok -- Ran 5 tests in 0.109s OK -- Comment By: George Yoshida (quiver) Date: 2005-01-28 05:58 Message: Logged In: YES user_id=671362 Changes against Lib/test/test_pep277.py(Revision 1.9) and Lib/test/output/test_pep277(Revision 1.3) ironed out the problem with Python 2.4, but the same error can be seen with Python 2.3.5 RC1. Is there any chance that they're backported to 2.3 branch before 2.3.5 final gets released? -- Comment By: Facundo Batista (facundobatista) Date: 2004-10-21 12:15 Message: Logged In: YES user_id=752496 The tests (through regrtest.py and alone) pass OK to me. Using (Win2k SP4), Python 2.4b1 (#57, Oct 15 2004, 15:23:38) [MSC v.1310 32 bit (Intel)] on win32, and: >>> import locale >>> locale.getlocale() ['Spanish_Argentina', '1252'] .Facundo -- Comment By: Miki Tebeka (tebeka) Date: 2004-10-18 01:06 Message: Logged In: YES user_id=358087 Fails for me on 2.4b1 on winXP -- Comment By: George Yoshida (quiver) Date: 2004-09-17 18:55 Message: Logged In: YES user_id=671362 Same for me. Fail for regrtest.py, but OK for test_277.py in isolation. (Python 2.4a3, Windows 2K SP4, locale:Japan) But my output is a bit different from yours. test test_pep277 produced unexpected output: ** *** mismatch between line 3 of expected output and line 3 of actual output: - ['???', '???', '??', '', 'G\xdf', 'Ge??- sa?', 'Gr\xfc\xdf-Gott', 'abc', 'ascii'] + ['??', '??\x82\xf1\x84t\x83\xa1s', '?\x9eG?', 'Grus- Gott', 'abc', 'ascii', '\x82\xc9\x82\xdb\x82\xf1', '\x83\xa1\x83 \xc3\x83\xc7?-\x83\xd0\x83\xbf?', '\x84H\x84t\x84\x82 \x84p\x84r\x84\x83\x84\x84\x84r\x84\x85\x84z\x84\x84\x84u'] ** This reminds me of the next thread: * More joy with test_strptime http://mail.python.org/pipermail/python-dev/2004- July/046046.html -- Comment By: Marek Baczynski (imbaczek) Date: 2004-09-17 08:25 Message: Logged In: YES user_id=838849 Forgot: Windows XP SP1, Python 2.4a3 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1029561&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-989338 ] test_unicode_file fails on win2k
Bugs item #989338, was opened at 2004-07-12 20:11 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989338&group_id=5470 Category: Python Library Group: Python 2.4 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: test_unicode_file fails on win2k Initial Comment: >>> test_support.verbose = 1 >>> test_unicode_file.test_main() test_directories (test.test_unicode_file.TestUnicodeFiles) ... ERROR test_equivalent_files (test.test_unicode_file.TestUnicodeFiles) ... ERROR test_single_files (test.test_unicode_file.TestUnicodeFiles) ... ERROR == ERROR: test_directories (test.test_unicode_file.TestUnicodeFiles) -- Traceback (most recent call last): File "C:\apps\Python24\lib\test\test_unicode_file.py", line 178, in test_directories self._do_directory(TESTFN_ENCODED+ext, TESTFN_ENCODED+ext, True) File "C:\apps\Python24\lib\test\test_unicode_file.py", line 112, in _do_directory os.mkdir(make_name) OSError: [Errno 22] Invalid argument: '@test-??.dir' == ERROR: test_equivalent_files (test.test_unicode_file.TestUnicodeFiles) -- Traceback (most recent call last): File "C:\apps\Python24\lib\test\test_unicode_file.py", line 170, in test_equivalent_files self._test_equivalent(TESTFN_ENCODED, TESTFN_UNICODE) File "C:\apps\Python24\lib\test\test_unicode_file.py", line 154, in _test_equivalent f = file(filename1, "w") IOError: [Errno 2] No such file or directory: '@test-??' == ERROR: test_single_files (test.test_unicode_file.TestUnicodeFiles) -- Traceback (most recent call last): File "C:\apps\Python24\lib\test\test_unicode_file.py", line 164, in test_single_files self._test_single(TESTFN_ENCODED) File "C:\apps\Python24\lib\test\test_unicode_file.py", line 136, in _test_single f = file(filename, "w") IOError: [Errno 2] No such file or directory: '@test-??' -- Ran 3 tests in 0.061s FAILED (errors=3) Traceback (most recent call last): File "", line 1, in -toplevel- test_unicode_file.test_main() File "C:\apps\Python24\lib\test\test_unicode_file.py", line 191, in test_main run_suite(suite) File "C:\apps\Python24\lib\test\test_support.py", line 274, in run_suite raise TestFailed(msg) TestFailed: errors occurred; run in verbose mode for details >>> This is Python2.4a1 on win2k pro -- Comment By: George Yoshida (quiver) Date: 2005-01-28 06:16 Message: Logged In: YES user_id=671362 Can anyone merge this(test_unicode_file.py rev 1.16) to release23-maint branch? This is not specific to Python 2.4. -- Comment By: Martin v. Löwis (loewis) Date: 2004-11-08 04:58 Message: Logged In: YES user_id=21627 This is now fixed in test_unicode_file.py 1.16. -- Comment By: Martin v. Löwis (loewis) Date: 2004-11-07 19:12 Message: Logged In: YES user_id=21627 I'm talking about the third tab on XP regional settings; I don't know how the user interface looks in W2k. This tab says something like "language for programs which don't support Unicode". It might be that this setting is simply not available on W2k. -- Comment By: Grzegorz Makarewicz (makaron) Date: 2004-11-03 17:23 Message: Logged In: YES user_id=115179 Martin, on other w2k pro (english) sp4 with POLISH locale set this test works as expected - "All the Unicode tests appeared to work". Both versions have the same settings for regional options - polish: On first tab (general) I have Polish location and other languages on the same tab selected: western europe and US, central europe. On last tab (6 = input locales) I have polish programmers and endglish (US). Third tab - currency ? Or this test fails on non english versions of W2K ? German ? Hungarian ? ... -- Comment By: Grzegorz Makarewicz (makaron) Date: 2004-11-03 02:28 Message: Logged In: YES user_id=115179 same effect on non french w2k (polish locale), this persists on any python 2.x version and is rather independent from windows version - in my case it is w2k pro sp4. file created with this encoding works fine with windows commander - if that matters -
[ python-Bugs-1110998 ] RLock logging mispells "success"
Bugs item #1110998, was opened at 2005-01-27 12:05 Message generated for change (Settings changed) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110998&group_id=5470 Category: Threads Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Matthew Bogosian (mbogosian) >Assigned to: Brett Cannon (bcannon) Summary: RLock logging mispells "success" Initial Comment: When verbose logging is turned on for RLock objects (via the constructor), attempts to acquire the lock are logged, but spelling didn't seem to be a priority ;-) : Thread-2: <_RLock(Thread-2, 1)>.acquire(1): initial succes "succes" should be "success" This was present in my tests of 2.3 and 2.4. -- >Comment By: Brett Cannon (bcannon) Date: 2005-01-27 14:52 Message: Logged In: YES user_id=357491 Fixed in rev. 1.48 for 2.5 and rev. 1.45.4.1 for 2.4 and rev. 1.38.6.5 for 2.3. Thanks, Matthew. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110998&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1111100 ] csv reader barfs encountering quote when quote_none is set
Bugs item #100, was opened at 2005-01-27 22:56
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=100&group_id=5470
Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: washington irving (washirv)
Assigned to: Nobody/Anonymous (nobody)
Summary: csv reader barfs encountering quote when quote_none is set
Initial Comment:
I'm including a python session that I cut paste from my
xterm. Essentially the problem boils down to when
QUOTE_NONE is set for the csv reader, and it encounters
a quote immediately after a separator, it assumes that
it is in a quoted field, and keeps going till it finds
the matching end quote. Either this is a bug, or the
meaning of QUOTE_NONE is not clear. My patch for it is
to check for QUOTE_NONE immediately after the
delimiter, and if so the state machine skips to
IN_FIELD state. The patch is against 2.3.3
134 wooster:~> python
Python 2.3.3 (#1, Dec 30 2004, 14:12:38)
[GCC 3.3.5 (Debian 1:3.3.5-5)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import csv
>>>
>>> class plain_dialect(csv.Dialect):
... delimiter="\t"
... escapechar="\"
... doublequote=False
... skipinitialspace=True
... lineterminator="\n"
... quoting=csv.QUOTE_NONE
... quotechar="'"
...
>>> csv.register_dialect("plain", plain_dialect)
>>> import StringIO
>>> s = StringIO.StringIO()
>>> w = csv.writer(s, dialect="plain")
>>> w.writerow(["foo", "'bar"])
>>> s.seek(0)
>>> s.read()
"foo\t'bar\n"
>>> s.seek(0)
>>> r = csv.reader(s, dialect="plain")
>>> r.next()
Traceback (most recent call last):
File "", line 1, in ?
_csv.Error: newline inside string
>>>
After patching:
135 wooster:~> python
Python 2.3.3 (#1, Dec 30 2004, 14:12:38)
[GCC 3.3.5 (Debian 1:3.3.5-5)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import csv
>>> class plain_dialect(csv.Dialect):
... delimiter="\t"
... escapechar="\"
... doublequote=False
... skipinitialspace=True
... lineterminator="\n"
... quoting=csv.QUOTE_NONE
... quotechar="'"
...
>>> csv.register_dialect("plain", plain_dialect)
>>> import StringIO
>>> s = StringIO.StringIO()
>>> w = csv.writer(s, dialect="plain")
>>> w.writerow(["foo", "'bar"])
>>> s.seek(0)
>>> s.read()
"foo\t'bar\n"
>>> s.seek(0)
>>> r = csv.reader(s, dialect="plain")
>>> r.next()
['foo', "'bar"]
>>>
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=100&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1111130 ] tkSimpleDialog broken on MacOS X (Aqua Tk)
Bugs item #130, was opened at 2005-01-27 15:52 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=130&group_id=5470 Category: Tkinter Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Martin v. Löwis (loewis) Summary: tkSimpleDialog broken on MacOS X (Aqua Tk) Initial Comment: On MacOS X 10.3.7 using the built-in python 2.3 and Aqua Tk 8.4.9, tkSimpleDialog.askfloat() with initialvalue specified misbehaves: - The entry box is displayed over the prompt. - Clicking on the entry box has no effect. - Clicking below the entry box (i.e. where it OUGHT to be displayed) acts as though you clicked in the entry box. If you omit the initial value then the bug does not appear. Also: on one particular unix system, similar code caused the entire Tkinter application to become unresponsive once the dialog box was dismissed. However, the parent window for that dialog was not root and I did not specify the parent argument to askfloat, so that may explain the hang. See the attached sample code for details. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=130&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-632323 ] Tkinter: BitmapImage vanishes if not stored in non-local var
Bugs item #632323, was opened at 2002-11-01 14:39
Message generated for change (Comment added) made by lpd
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=632323&group_id=5470
Category: Tkinter
Group: Python 2.2.2
Status: Open
Resolution: Invalid
Priority: 5
Submitted By: L. Peter Deutsch (lpd)
Assigned to: Nobody/Anonymous (nobody)
Summary: Tkinter: BitmapImage vanishes if not stored in non-local var
Initial Comment:
The following program incorrectly produces a blank canvas:
#!/usr/bin/env python
from Tkinter import *
class Me(Canvas):
def init1(self):
return BitmapImage(foreground = '#ff',
background = '#00ff00',
data = """#define t_width 8
#define t_height 8
static unsigned char t_bits[] = {
0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x3c, 0x3c};
""",
maskdata = """#define t_width 8
#define t_height 8
static unsigned char t_bits[] = {
0x18, 0x3c, 0x7e, 0xff, 0xff, 0x7e, 0x3c, 0x18};
""")
def init2(self, image):
self.create_image(32, 32, anchor = NW, image =
image)
self = Me()
self.pack(expand = 1, fill = BOTH)
self.init2(self.init1())
#img = self.init1()
#self.init2(img)
self.mainloop()
However, the following program correctly draws a small
red-and-green icon:
#!/usr/bin/env python
from Tkinter import *
class Me(Canvas):
def init1(self):
return BitmapImage(foreground = '#ff',
background = '#00ff00',
data = """#define t_width 8
#define t_height 8
static unsigned char t_bits[] = {
0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x3c, 0x3c};
""",
maskdata = """#define t_width 8
#define t_height 8
static unsigned char t_bits[] = {
0x18, 0x3c, 0x7e, 0xff, 0xff, 0x7e, 0x3c, 0x18};
""")
def init2(self, image):
self.create_image(32, 32, anchor = NW, image =
image)
self = Me()
self.pack(expand = 1, fill = BOTH)
#self.init2(self.init1())
img = self.init1()
self.init2(img)
self.mainloop()
The two programs are identical except that one of them
assigns the BitmapImage to a variable rather than
passing it directly as an argument.
Python 2.2.1, OS = Linux version 2.4.18-3
([EMAIL PROTECTED]) (gcc version 2.96
2731 (Red Hat Linux 7.3 2.96-110)) #1 Thu Apr 18
07:37:53 EDT 2002
--
>Comment By: L. Peter Deutsch (lpd)
Date: 2005-01-27 19:01
Message:
Logged In: YES
user_id=8861
SourceForge apparently failed to e-mail me a notification of
your follow-up, so I didn't find out about it until today
(exactly 1 month from your original posting), by accident.
The problem is definitely still there in 2.3.3, which is
what I currently have installed. I'll download and test
2.3.4 and 2.4 tomorrow. (I hope you'll give me an extra day!)
lpd
--
Comment By: Facundo Batista (facundobatista)
Date: 2004-12-27 18:02
Message:
Logged In: YES
user_id=752496
Please, could you verify if this problem persists in Python 2.3.4
or 2.4?
If yes, in which version? Can you provide a test case?
If the problem is solved, from which version?
Note that if you fail to answer in one month, I'll close this bug
as "Won't fix".
Thank you!
.Facundo
--
Comment By: Martin v. Löwis (loewis)
Date: 2002-12-11 03:59
Message:
Logged In: YES
user_id=21627
It's inconsistent with the rest of Tkinter. Everything in
Tkinter is an object, and so are images. If you want
strings, use plain _tkinter.
--
Comment By: Fredrik Lundh (effbot)
Date: 2002-12-11 01:33
Message:
Logged In: YES
user_id=38376
"..consider all common use cases -- if you don't do it
this way, you either end up with leaks, code that works
only by accident, or code that is a lot more convoluted
than the simple assignment that is necessary to work
around this problem in real life."
--
Comment By: Internet Discovery (idiscovery)
Date: 2002-12-11 01:01
Message:
Logged In: YES
user_id=33229
What's wrong with simply wrapping what Tk does with an image_create
method that returns a string and an image_delete method that accepts a string?
It's consistent with Tk usage. You can document the proper usage of image_delete
and leave the Image class for backwards compatability. Something like:
def image_create(self, imgtype, cnf={}, master=None, **kw):
if not master:
master = Tkinter._default_root
if not master:
raise RuntimeError, 'Too early to create image'
if kw and cnf: cnf = _cnfmerge((cnf, kw))
elif kw: cnf = kw
options = ()
for k, v in cnf.items():
