[ python-Bugs-1080424 ] Inplace set merge produces wrong results
Bugs item #1080424, was opened at 2004-12-07 00:36 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080424&group_id=5470 Category: Python Interpreter Core Group: Not a Bug Status: Closed Resolution: Invalid Priority: 6 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: Inplace set merge produces wrong results Initial Comment: [forwarded from http://bugs.debian.org/284490] the inplace set merge can produce wrong results compared to the a = a | b non in-place (and slower) version. Please see the attached tarball: running the "test" script shows the problem. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-07 06:35 Message: Logged In: YES user_id=80475 On line 39, replace self.items[t] = add_elements with self.items[t] = add_elements.copy() That will fix all three. -- Comment By: Tim Peters (tim_one) Date: 2004-12-07 02:46 Message: Logged In: YES user_id=31435 I can pretty much guarantee this isn't a bug in Python, but is in some aspect of your algorithm that *relies* on not sharing mutable sets. For example, if I leave Debtags1.py's self.items[t] |= add_elements alone but add this right after it: self.items[t] = self.items[t].copy() then Debtags1.py produces the same output as Debtags.py. Same thing with Debtags2.py: adding that line also makes Debtag2.py's output the same. That proves the problem isn't in the implementations of "|=" or .update(). It strongly suggests that you're mutating a shared set that you're not expecting to mutate, or aren't expecting is shared. For example, your driver does s = db.elset(sys.argv[1]) for t in sys.argv[2:]: s &= db.elset(t) and that mutates the set in self.items[sys.argv[1]]. If you don't intend that computing output will mutate the sets in db, then that code is confused. That's not the source of your differing output, but "something like it" probably is. In fact, the problem is probably here: self.items[t] = add_elements That can assign the same add_elements as the value associated with *many* distinct values of t. Then you try to update those later in place, but "those" is a single shared set. Changing the value associated with one of the t's then changes the value associated with all of the t's that originally got assigned the same "add_elements" set. If I go back to the original Debtags1.py, and replace self.items[t] = add_elements with self.items[t] = add_elements.copy() then the later updates-in-place do no harm, and it produces the output you said you expected. If you don't understand this, here's a dead simple example: >>> x = set([1]) >>> y = x # y and x are the *same* set now >>> x |= set([2]) # so mutating x in place ... >>> x set([1, 2]) >>> y # ... also mutates the set bound to y set([1, 2]) >>> -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080424&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1080387 ] IDLE and old color themes
Bugs item #1080387, was opened at 2004-12-06 19:54 Message generated for change (Comment added) made by projecktzero You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080387&group_id=5470 Category: IDLE Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: projecktzero (projecktzero) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE and old color themes Initial Comment: After uninstalling Python 2.3.4 on my Windows 2000 workstation, I installed Python 2.4. Unfortunately, IDLE refused to start up. I would just see some hard drive activity, then nothing. Getting some help from the tutor list(Danny Yoo), I was told to try... import idlelib.PyShell idlelib.PyShell.main() from the Python command prompt. IDLE fired up, but it complained about my color theme(which I had created in Python 2.3.4). Unfortunately, I do not have the errors/warnings. I deleted the color theme from IDLE, and now IDLE fires up without issue. The color theme must have been left over from Python 2.3.4. -- >Comment By: projecktzero (projecktzero) Date: 2004-12-07 06:08 Message: Logged In: YES user_id=1173237 >From IDLE, I removed Deleted the Custom Theme. I will attempt to reproduce the issue and report on what warnings and/or errors appear from the Python command line. I'll uninstall 2.4. Reinstall 2.3.4. Add a theme to IDLE. Uninstall 2.3.4. Install 2.4 and see if I can capture the warnings/errors. -- Comment By: Kurt B. Kaiser (kbk) Date: 2004-12-06 22:13 Message: Logged In: YES user_id=149084 The (un)installer doesn't know about the user's .idlerc file. There should not be any incompatiblility between 2.3.4 and 2.4 regarding the color themes. It's too bad you didn't save the error messages. Could you describe exactly what you mean by "I deleted the color theme?" . What files or parts of files were removed? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080387&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1080440 ] float issue for NaN type in .pyc file
Bugs item #1080440, was opened at 2004-12-07 13:24 Message generated for change (Comment added) made by dileep_nirala You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080440&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dileep Nirala (dileep_nirala) Assigned to: Nobody/Anonymous (nobody) Summary: float issue for NaN type in .pyc file Initial Comment: There is a difference in output between .pyc and .py file, while dealing with NaN float. In fact I am doing a float range validation as part of my requirement. The content of my sample program [test.py] aboveMax = 1.8e+308 belowMin = -1.8e+308 print aboveMax, belowMin While execution: command: python test.py output: 1.#INF -1.#INF This output is expected and good, however if I use compiled python file as below, command: python test.pyc output: 1.0 -1.0 This output is wrong, it does not show Nan floating point. -- >Comment By: Dileep Nirala (dileep_nirala) Date: 2004-12-07 20:54 Message: Logged In: YES user_id=1173293 My test cases passes for the first time but fails second times onward since .pyc gets loaded since it's existing. -- Comment By: Tim Peters (tim_one) Date: 2004-12-07 14:51 Message: Logged In: YES user_id=31435 Python guarantees nothing about behavior in the presence of NaNs, infinities, or signed zeroes. Anything you see then is a platform-dependent accident. This should be closed with a reference to PEP 42 (I don't have time to look it all up now -- "non-accidental" IEEE behavior is a longstanding feature request, but one unlikely to be resolved in the foreseeable future; the particular problem here is that the marshal format deals in accidental ways with infinities, NaNs, and signed zeroes, so accidents in .py files may not be reproduced from .pyc files) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080440&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 ] Python Icon in system Tray
Bugs item #1080634, was opened at 2004-12-07 20: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=1080634&group_id=5470 Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Dileep Nirala (dileep_nirala) Assigned to: Nobody/Anonymous (nobody) Summary: Python Icon in system Tray Initial Comment: The python icon remains in the system Tray even if you close the application. -- 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-1080387 ] IDLE and old color themes
Bugs item #1080387, was opened at 2004-12-06 19:54 Message generated for change (Comment added) made by projecktzero You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080387&group_id=5470 Category: IDLE Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: projecktzero (projecktzero) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE and old color themes Initial Comment: After uninstalling Python 2.3.4 on my Windows 2000 workstation, I installed Python 2.4. Unfortunately, IDLE refused to start up. I would just see some hard drive activity, then nothing. Getting some help from the tutor list(Danny Yoo), I was told to try... import idlelib.PyShell idlelib.PyShell.main() from the Python command prompt. IDLE fired up, but it complained about my color theme(which I had created in Python 2.3.4). Unfortunately, I do not have the errors/warnings. I deleted the color theme from IDLE, and now IDLE fires up without issue. The color theme must have been left over from Python 2.3.4. -- >Comment By: projecktzero (projecktzero) Date: 2004-12-07 07:35 Message: Logged In: YES user_id=1173237 I was able to reproduce the problem. I'm attaching the warning messages in a text file. -- Comment By: projecktzero (projecktzero) Date: 2004-12-07 06:08 Message: Logged In: YES user_id=1173237 >From IDLE, I removed Deleted the Custom Theme. I will attempt to reproduce the issue and report on what warnings and/or errors appear from the Python command line. I'll uninstall 2.4. Reinstall 2.3.4. Add a theme to IDLE. Uninstall 2.3.4. Install 2.4 and see if I can capture the warnings/errors. -- Comment By: Kurt B. Kaiser (kbk) Date: 2004-12-06 22:13 Message: Logged In: YES user_id=149084 The (un)installer doesn't know about the user's .idlerc file. There should not be any incompatiblility between 2.3.4 and 2.4 regarding the color themes. It's too bad you didn't save the error messages. Could you describe exactly what you mean by "I deleted the color theme?" . What files or parts of files were removed? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080387&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1080660 ] thread.error: release unlocked lock on Queue put
Bugs item #1080660, was opened at 2004-12-07 09: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=1080660&group_id=5470 Category: Threads Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: John Speno (corvus) Assigned to: Nobody/Anonymous (nobody) Summary: thread.error: release unlocked lock on Queue put Initial Comment: System is Python 2.3.3 on Solaris 9. I'm using the classic Python thread model. Main thread puts stuff into a Queue.Queue() and worker threads get stuff out of it and do their thing. On occaision, I get an exception in the main thread when it tries to put something into the Queue. File "/usr/local/bin/poller.py", line 47, in fragnap_it work_queue.put((foo, bar, baz)) File "/usr/local/lib/python2.3/Queue.py", line 106, in put self.fsema.release() thread.error: release unlocked lock This error still happens intermittently, and I haven't been able to reduce it to a simple case. I can alter my applications to do something useful for debugging this problem when it happens, if you can figure out what "something useful" would be. Just let me know. The queue is unbounded, and I'm using blocking get/put. The main thread creates 20 worker threads, and 1 recorder thread. Then it puts upto 1500 items in the Queue.Queue named work_queue. The 20 worker threads take stuff out work_queue, process some using pure python code, or others by using subprocess.py. Results from the workers are put into another Queue.Queue named results_queue. The Recorder thread gets from the results_queue and writes stuff to a MySQL db. I've never seen the error happen when putting into the results_queue, only from the main thread putting into the work_queue. Thread defines in my python config.h are: #define HAVE_PTHREAD_H 1 #define HAVE_PTHREAD_SIGMASK 1 #define HAVE_THREAD_H 1 #define PTHREAD_SYSTEM_SCHED_SUPPORTED 1 #define SIZEOF_PTHREAD_T 4 #define WITH_THREAD 1 And all the thread related python tests (test_thread, test_threading, and test_queue) pass. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080660&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1080440 ] float issue for NaN type in .pyc file
Bugs item #1080440, was opened at 2004-12-07 06:24 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080440&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dileep Nirala (dileep_nirala) Assigned to: Nobody/Anonymous (nobody) Summary: float issue for NaN type in .pyc file Initial Comment: There is a difference in output between .pyc and .py file, while dealing with NaN float. In fact I am doing a float range validation as part of my requirement. The content of my sample program [test.py] aboveMax = 1.8e+308 belowMin = -1.8e+308 print aboveMax, belowMin While execution: command: python test.py output: 1.#INF -1.#INF This output is expected and good, however if I use compiled python file as below, command: python test.pyc output: 1.0 -1.0 This output is wrong, it does not show Nan floating point. -- >Comment By: Michael Hudson (mwh) Date: 2004-12-07 14:51 Message: Logged In: YES user_id=6656 I know first hand how much of a pain this issue can be. However it's not clear what can be done about it. My vote would go towards complaining at compile time that the literals cannot be represented as a regular double, but even that isn't the easiest thing to do portably! -- Comment By: Dileep Nirala (dileep_nirala) Date: 2004-12-07 13:54 Message: Logged In: YES user_id=1173293 My test cases passes for the first time but fails second times onward since .pyc gets loaded since it's existing. -- Comment By: Tim Peters (tim_one) Date: 2004-12-07 07:51 Message: Logged In: YES user_id=31435 Python guarantees nothing about behavior in the presence of NaNs, infinities, or signed zeroes. Anything you see then is a platform-dependent accident. This should be closed with a reference to PEP 42 (I don't have time to look it all up now -- "non-accidental" IEEE behavior is a longstanding feature request, but one unlikely to be resolved in the foreseeable future; the particular problem here is that the marshal format deals in accidental ways with infinities, NaNs, and signed zeroes, so accidents in .py files may not be reproduced from .pyc files) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080440&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1080713 ] os.ttyname() accepts wrong arguments
Bugs item #1080713, was opened at 2004-12-07 08:32 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=1080713&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Christian Höltje (docwhat) Assigned to: Nobody/Anonymous (nobody) Summary: os.ttyname() accepts wrong arguments Initial Comment: Problem: The doc for os.ttyname says it accepts an fd What Happens: It raises a type error and says it expects an integer instead. Experimentally, it seems to accept fd.fileno() as input What should happen: It should an accept an fd (file object) I have attached a test case for this. The output I get using python 2.2 & 2.3 is: Documentation Sez: ttyname(fd) -> String Return the name of the terminal device connected to 'fd'. TTY Name (should work):exceptions.TypeError an integer is required TTY Name (shouldn't work): /dev/pts/2 Ciao! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080713&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-1080727 ] Add encoding to DocFileSuite
Feature Requests item #1080727, was opened at 2004-12-07 17:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1080727&group_id=5470 Category: Unicode Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bjorn Tillenius (bjoti) Assigned to: Nobody/Anonymous (nobody) Summary: Add encoding to DocFileSuite Initial Comment: If one writes doctests within documentation strings of classes and functions, it's possible to use non-ASCII characters since one can specify the encoding used in the source file. But if one wants to combine the documentation and testing, by writing a text file, and thus use DocFileSuite, it's not possible to use non-ASCII characters in the tests. This is because there's no way of specifying which encoding the text file uses. Instead one has to \-quote all non-ASCII characters, and that makes the tests harder to read IMHO. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1080727&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1080440 ] float issue for NaN type in .pyc file
Bugs item #1080440, was opened at 2004-12-07 01:24 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080440&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dileep Nirala (dileep_nirala) Assigned to: Nobody/Anonymous (nobody) Summary: float issue for NaN type in .pyc file Initial Comment: There is a difference in output between .pyc and .py file, while dealing with NaN float. In fact I am doing a float range validation as part of my requirement. The content of my sample program [test.py] aboveMax = 1.8e+308 belowMin = -1.8e+308 print aboveMax, belowMin While execution: command: python test.py output: 1.#INF -1.#INF This output is expected and good, however if I use compiled python file as below, command: python test.pyc output: 1.0 -1.0 This output is wrong, it does not show Nan floating point. -- >Comment By: Tim Peters (tim_one) Date: 2004-12-07 12:13 Message: Logged In: YES user_id=31435 dileep_nirala: Yes, I understood the problem. That your test passed the first time was an accident. That your test failed the second time was also an accident. Nothing is defined about what happens in Python in the presence of NaNs. The most likely accident is that no spelling of an infinity, NaN, or negative 0.0 will survive when loaded from a .pyc file. That the literal "1.8e+308" gave you an infinity to begin with was also a platform-dependent accident. Python has no support for these things. Whatever support may *appear* to exist derives from more-or-less random behaviors dervied from the platform C compiler and runtime libraries. That won't be fixed unless someone unexpectedly volunteers a lot of new work in this area. -- Comment By: Michael Hudson (mwh) Date: 2004-12-07 09:51 Message: Logged In: YES user_id=6656 I know first hand how much of a pain this issue can be. However it's not clear what can be done about it. My vote would go towards complaining at compile time that the literals cannot be represented as a regular double, but even that isn't the easiest thing to do portably! -- Comment By: Dileep Nirala (dileep_nirala) Date: 2004-12-07 08:54 Message: Logged In: YES user_id=1173293 My test cases passes for the first time but fails second times onward since .pyc gets loaded since it's existing. -- Comment By: Tim Peters (tim_one) Date: 2004-12-07 02:51 Message: Logged In: YES user_id=31435 Python guarantees nothing about behavior in the presence of NaNs, infinities, or signed zeroes. Anything you see then is a platform-dependent accident. This should be closed with a reference to PEP 42 (I don't have time to look it all up now -- "non-accidental" IEEE behavior is a longstanding feature request, but one unlikely to be resolved in the foreseeable future; the particular problem here is that the marshal format deals in accidental ways with infinities, NaNs, and signed zeroes, so accidents in .py files may not be reproduced from .pyc files) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080440&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1080440 ] float issue for NaN type in .pyc file
Bugs item #1080440, was opened at 2004-12-07 01:24 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080440&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dileep Nirala (dileep_nirala) Assigned to: Nobody/Anonymous (nobody) Summary: float issue for NaN type in .pyc file Initial Comment: There is a difference in output between .pyc and .py file, while dealing with NaN float. In fact I am doing a float range validation as part of my requirement. The content of my sample program [test.py] aboveMax = 1.8e+308 belowMin = -1.8e+308 print aboveMax, belowMin While execution: command: python test.py output: 1.#INF -1.#INF This output is expected and good, however if I use compiled python file as below, command: python test.pyc output: 1.0 -1.0 This output is wrong, it does not show Nan floating point. -- >Comment By: Tim Peters (tim_one) Date: 2004-12-07 12:33 Message: Logged In: YES user_id=31435 BTW, while nothing is guaranteed here, your best shot at working (albeit still by accident) portable code is to use expressions that don't tickle IEEE special values directly. For example, use pinf = 1e300 * 1e300 minf = -pinf nan = pinf - pinf That will work the same way from .py or .pyc. Whether pinf is actually +Infinity and nan is actually a NaN then remain platform-dependent accidents, but they will be on the majority platforms (Linux and Windows, using gcc or MSVC to compile Python). -- Comment By: Tim Peters (tim_one) Date: 2004-12-07 12:13 Message: Logged In: YES user_id=31435 dileep_nirala: Yes, I understood the problem. That your test passed the first time was an accident. That your test failed the second time was also an accident. Nothing is defined about what happens in Python in the presence of NaNs. The most likely accident is that no spelling of an infinity, NaN, or negative 0.0 will survive when loaded from a .pyc file. That the literal "1.8e+308" gave you an infinity to begin with was also a platform-dependent accident. Python has no support for these things. Whatever support may *appear* to exist derives from more-or-less random behaviors dervied from the platform C compiler and runtime libraries. That won't be fixed unless someone unexpectedly volunteers a lot of new work in this area. -- Comment By: Michael Hudson (mwh) Date: 2004-12-07 09:51 Message: Logged In: YES user_id=6656 I know first hand how much of a pain this issue can be. However it's not clear what can be done about it. My vote would go towards complaining at compile time that the literals cannot be represented as a regular double, but even that isn't the easiest thing to do portably! -- Comment By: Dileep Nirala (dileep_nirala) Date: 2004-12-07 08:54 Message: Logged In: YES user_id=1173293 My test cases passes for the first time but fails second times onward since .pyc gets loaded since it's existing. -- Comment By: Tim Peters (tim_one) Date: 2004-12-07 02:51 Message: Logged In: YES user_id=31435 Python guarantees nothing about behavior in the presence of NaNs, infinities, or signed zeroes. Anything you see then is a platform-dependent accident. This should be closed with a reference to PEP 42 (I don't have time to look it all up now -- "non-accidental" IEEE behavior is a longstanding feature request, but one unlikely to be resolved in the foreseeable future; the particular problem here is that the marshal format deals in accidental ways with infinities, NaNs, and signed zeroes, so accidents in .py files may not be reproduced from .pyc files) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080440&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1080811 ] full test with all unicode text files
Bugs item #1080811, was opened at 2004-12-07 19:53 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=1080811&group_id=5470 Category: None Group: Not a Bug Status: Open Resolution: None Priority: 5 Submitted By: Grzegorz Makarewicz (makaron) Assigned to: Nobody/Anonymous (nobody) Summary: full test with all unicode text files Initial Comment: samall bug? while performing full test on pythonthon core with all required files (unicode). This can be found when "python -u regrtest.py -uall" is executed - perhaps some encodings are not preserved - test_codecmaps_kr fails with message: "JOHAB.TXT not found, download from http://www.unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/KSC/JOHAB.TXT " this file exists on my system and is placed in lib/test, as required. when its running as standalone test everything is OK. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080811&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1080864 ] locale.py doesn't recognize valid locale setting
Bugs item #1080864, was opened at 2004-12-07 21:23 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=1080864&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: stas Z (childsplay) Assigned to: Nobody/Anonymous (nobody) Summary: locale.py doesn't recognize valid locale setting Initial Comment: [EMAIL PROTECTED]:~$ locale LANG=nb_NO [...] [EMAIL PROTECTED]:~$ python Python 2.3.4 (#2, Sep 24 2004, 08:39:09) [GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import locale >>> locale.getdefaultlocale() Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/locale.py", line 346, in getdefaultlocale return _parse_localename(localename) File "/usr/lib/python2.3/locale.py", line 280, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: nb_NO >>> -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080864&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1080864 ] locale.py doesn't recognize valid locale setting
Bugs item #1080864, was opened at 2004-12-07 21:23 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080864&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: stas Z (childsplay) Assigned to: Nobody/Anonymous (nobody) Summary: locale.py doesn't recognize valid locale setting Initial Comment: [EMAIL PROTECTED]:~$ locale LANG=nb_NO [...] [EMAIL PROTECTED]:~$ python Python 2.3.4 (#2, Sep 24 2004, 08:39:09) [GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import locale >>> locale.getdefaultlocale() Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/locale.py", line 346, in getdefaultlocale return _parse_localename(localename) File "/usr/lib/python2.3/locale.py", line 280, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: nb_NO >>> -- >Comment By: Martin v. Löwis (loewis) Date: 2004-12-07 21:25 Message: Logged In: YES user_id=21627 Why do you want to use getdefaultlocale()? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080864&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1080864 ] locale.py doesn't recognize valid locale setting
Bugs item #1080864, was opened at 2004-12-07 21:23 Message generated for change (Comment added) made by zgoda You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080864&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: stas Z (childsplay) Assigned to: Nobody/Anonymous (nobody) Summary: locale.py doesn't recognize valid locale setting Initial Comment: [EMAIL PROTECTED]:~$ locale LANG=nb_NO [...] [EMAIL PROTECTED]:~$ python Python 2.3.4 (#2, Sep 24 2004, 08:39:09) [GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import locale >>> locale.getdefaultlocale() Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/locale.py", line 346, in getdefaultlocale return _parse_localename(localename) File "/usr/lib/python2.3/locale.py", line 280, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: nb_NO >>> -- Comment By: Jarek Zgoda (zgoda) Date: 2004-12-07 22:39 Message: Logged In: YES user_id=9 getdefaultlocale() is often used to get default encoding for current system locale. And, if function is provided in standard library, why shouldn't one use it? -- Comment By: Martin v. Löwis (loewis) Date: 2004-12-07 21:25 Message: Logged In: YES user_id=21627 Why do you want to use getdefaultlocale()? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080864&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1080387 ] IDLE and old color themes
Bugs item #1080387, was opened at 2004-12-06 21:54 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080387&group_id=5470 Category: IDLE Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: projecktzero (projecktzero) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE and old color themes Initial Comment: After uninstalling Python 2.3.4 on my Windows 2000 workstation, I installed Python 2.4. Unfortunately, IDLE refused to start up. I would just see some hard drive activity, then nothing. Getting some help from the tutor list(Danny Yoo), I was told to try... import idlelib.PyShell idlelib.PyShell.main() from the Python command prompt. IDLE fired up, but it complained about my color theme(which I had created in Python 2.3.4). Unfortunately, I do not have the errors/warnings. I deleted the color theme from IDLE, and now IDLE fires up without issue. The color theme must have been left over from Python 2.3.4. -- >Comment By: Kurt B. Kaiser (kbk) Date: 2004-12-07 16:44 Message: Logged In: YES user_id=149084 Thanks for the report. I'll try to reproduce the problem myself. What is supposed to happen is if IDLE has a problem retreiving the theme, it's supposed to load the default theme from config-highlight.def and if that fails it's supposed to use a fallback theme written into the code itself. Clearly all this complexity isn't working too well, and the error messages aren't particularly helpful. -- Comment By: projecktzero (projecktzero) Date: 2004-12-07 09:35 Message: Logged In: YES user_id=1173237 I was able to reproduce the problem. I'm attaching the warning messages in a text file. -- Comment By: projecktzero (projecktzero) Date: 2004-12-07 08:08 Message: Logged In: YES user_id=1173237 >From IDLE, I removed Deleted the Custom Theme. I will attempt to reproduce the issue and report on what warnings and/or errors appear from the Python command line. I'll uninstall 2.4. Reinstall 2.3.4. Add a theme to IDLE. Uninstall 2.3.4. Install 2.4 and see if I can capture the warnings/errors. -- Comment By: Kurt B. Kaiser (kbk) Date: 2004-12-07 00:13 Message: Logged In: YES user_id=149084 The (un)installer doesn't know about the user's .idlerc file. There should not be any incompatiblility between 2.3.4 and 2.4 regarding the color themes. It's too bad you didn't save the error messages. Could you describe exactly what you mean by "I deleted the color theme?" . What files or parts of files were removed? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080387&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1080864 ] locale.py doesn't recognize valid locale setting
Bugs item #1080864, was opened at 2004-12-07 21:23 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080864&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: stas Z (childsplay) Assigned to: Nobody/Anonymous (nobody) Summary: locale.py doesn't recognize valid locale setting Initial Comment: [EMAIL PROTECTED]:~$ locale LANG=nb_NO [...] [EMAIL PROTECTED]:~$ python Python 2.3.4 (#2, Sep 24 2004, 08:39:09) [GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import locale >>> locale.getdefaultlocale() Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/locale.py", line 346, in getdefaultlocale return _parse_localename(localename) File "/usr/lib/python2.3/locale.py", line 280, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: nb_NO >>> -- >Comment By: Martin v. Löwis (loewis) Date: 2004-12-07 23:13 Message: Logged In: YES user_id=21627 To get the default encoding for the current locale, you should use locale.getpreferredencoding(). You should not use getdefaultlocale becaus it is (IMO) inherently broken, and should not have been part of the standard library in the first place. -- Comment By: Jarek Zgoda (zgoda) Date: 2004-12-07 22:39 Message: Logged In: YES user_id=9 getdefaultlocale() is often used to get default encoding for current system locale. And, if function is provided in standard library, why shouldn't one use it? -- Comment By: Martin v. Löwis (loewis) Date: 2004-12-07 21:25 Message: Logged In: YES user_id=21627 Why do you want to use getdefaultlocale()? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080864&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1080864 ] locale.py doesn't recognize valid locale setting
Bugs item #1080864, was opened at 2004-12-07 21:23 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080864&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: stas Z (childsplay) Assigned to: Nobody/Anonymous (nobody) Summary: locale.py doesn't recognize valid locale setting Initial Comment: [EMAIL PROTECTED]:~$ locale LANG=nb_NO [...] [EMAIL PROTECTED]:~$ python Python 2.3.4 (#2, Sep 24 2004, 08:39:09) [GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import locale >>> locale.getdefaultlocale() Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/locale.py", line 346, in getdefaultlocale return _parse_localename(localename) File "/usr/lib/python2.3/locale.py", line 280, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: nb_NO >>> -- >Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-08 00:08 Message: Logged In: YES user_id=38388 Of course, I don't agree with you, Martin :-) locale.getdefaultlocale() does server a purpose, namely that of getting the default locale setting. The encoding information is an often used extension when setting the locale in the OS environment. If not set, the module provides common defaults. The locale "nb_NO" is not known to the module alias table. Which locale, language and encoding would that be ? -- Comment By: Martin v. Löwis (loewis) Date: 2004-12-07 23:13 Message: Logged In: YES user_id=21627 To get the default encoding for the current locale, you should use locale.getpreferredencoding(). You should not use getdefaultlocale becaus it is (IMO) inherently broken, and should not have been part of the standard library in the first place. -- Comment By: Jarek Zgoda (zgoda) Date: 2004-12-07 22:39 Message: Logged In: YES user_id=9 getdefaultlocale() is often used to get default encoding for current system locale. And, if function is provided in standard library, why shouldn't one use it? -- Comment By: Martin v. Löwis (loewis) Date: 2004-12-07 21:25 Message: Logged In: YES user_id=21627 Why do you want to use getdefaultlocale()? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080864&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1081045 ] readline module doesn't build on MacOSX
Bugs item #1081045, was opened at 2004-12-07 20:19 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=1081045&group_id=5470 Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Brett Cannon (bcannon) Summary: readline module doesn't build on MacOSX Initial Comment: Recent changes to either configure or setup.py seem to have conspired to prevent the readline module from building on MacOSX. I configured and built with LDFLAGS='-L/sw/lib' CPPFLAGS='-I/sw/include' ../ configure '--prefix=/Users/skip/local' make The relevant readline bits are in /sw/... but the module is not built. The following bits containing /sw grep out of the generated Makefile: INSTALL=/sw/bin/install -c CPPFLAGS= -I. -I$(srcdir)/Include -I/sw/include LDFLAGS=-L/sw/lib CONFIG_ARGS='--prefix=/Users/skip/local' 'CPPFLAGS=-I/sw/include' 'LDFLAGS=-L/sw/lib' Assigning to Brett since he touched this most recently. Skip -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1081045&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1081045 ] readline module doesn't build on MacOSX
Bugs item #1081045, was opened at 2004-12-07 20:19 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1081045&group_id=5470 Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Brett Cannon (bcannon) Summary: readline module doesn't build on MacOSX Initial Comment: Recent changes to either configure or setup.py seem to have conspired to prevent the readline module from building on MacOSX. I configured and built with LDFLAGS='-L/sw/lib' CPPFLAGS='-I/sw/include' ../ configure '--prefix=/Users/skip/local' make The relevant readline bits are in /sw/... but the module is not built. The following bits containing /sw grep out of the generated Makefile: INSTALL=/sw/bin/install -c CPPFLAGS= -I. -I$(srcdir)/Include -I/sw/include LDFLAGS=-L/sw/lib CONFIG_ARGS='--prefix=/Users/skip/local' 'CPPFLAGS=-I/sw/include' 'LDFLAGS=-L/sw/lib' Assigning to Brett since he touched this most recently. Skip -- >Comment By: Skip Montanaro (montanaro) Date: 2004-12-07 20:46 Message: Logged In: YES user_id=44345 More on this... Sticking a print of lib_dirs just before setup.py checks for readline shows that /sw/lib is not in that list. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1081045&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1080864 ] locale.py doesn't recognize valid locale setting
Bugs item #1080864, was opened at 2004-12-07 21:23 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080864&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: stas Z (childsplay) Assigned to: Nobody/Anonymous (nobody) Summary: locale.py doesn't recognize valid locale setting Initial Comment: [EMAIL PROTECTED]:~$ locale LANG=nb_NO [...] [EMAIL PROTECTED]:~$ python Python 2.3.4 (#2, Sep 24 2004, 08:39:09) [GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import locale >>> locale.getdefaultlocale() Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/locale.py", line 346, in getdefaultlocale return _parse_localename(localename) File "/usr/lib/python2.3/locale.py", line 280, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: nb_NO >>> -- >Comment By: Martin v. Löwis (loewis) Date: 2004-12-08 08:04 Message: Logged In: YES user_id=21627 There is no "default locale setting" in most operating systems. In what sense is the value of the LANG environment variable a "default"? -- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-08 00:08 Message: Logged In: YES user_id=38388 Of course, I don't agree with you, Martin :-) locale.getdefaultlocale() does server a purpose, namely that of getting the default locale setting. The encoding information is an often used extension when setting the locale in the OS environment. If not set, the module provides common defaults. The locale "nb_NO" is not known to the module alias table. Which locale, language and encoding would that be ? -- Comment By: Martin v. Löwis (loewis) Date: 2004-12-07 23:13 Message: Logged In: YES user_id=21627 To get the default encoding for the current locale, you should use locale.getpreferredencoding(). You should not use getdefaultlocale becaus it is (IMO) inherently broken, and should not have been part of the standard library in the first place. -- Comment By: Jarek Zgoda (zgoda) Date: 2004-12-07 22:39 Message: Logged In: YES user_id=9 getdefaultlocale() is often used to get default encoding for current system locale. And, if function is provided in standard library, why shouldn't one use it? -- Comment By: Martin v. Löwis (loewis) Date: 2004-12-07 21:25 Message: Logged In: YES user_id=21627 Why do you want to use getdefaultlocale()? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080864&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
