[ python-Bugs-1007046 ] os.startfile() doesn't accept Unicode filenames
Bugs item #1007046, was opened at 2004-08-11 08:47
Message generated for change (Comment added) made by lemburg
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1007046&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: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Huening (huening)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: os.startfile() doesn't accept Unicode filenames
Initial Comment:
WinXP, Python 2.3.4
os.startfile() seems to have problems with Unicode
filenames. Example:
>>> import tkFileDialog
>>> import os
>>> f = tkFileDialog.askopenfilename()
>>> type(f)
>>> os.startfile(f)
Traceback (most recent call last):
File "", line 1, in -toplevel-
os.startfile(f)
UnicodeEncodeError: 'ascii' codec can't encode
characters in position 14-16: ordinal not in range(128)
>>>
--
>Comment By: M.-A. Lemburg (lemburg)
Date: 2005-09-01 10:27
Message:
Logged In: YES
user_id=38388
The path looks OK, but I can't test it on Windows
(os.startfile() is only available on Windows).
A note on style: you should always try to keep lines shorter
than 80 characters, e.g.:
--- CVS-Python/Modules/posixmodule.c2005-08-15
10:15:27.0 +0200
+++ Dev-Python/Modules/posixmodule.c2005-09-01
10:23:06.555633134 +0200
@@ -7248,7 +7248,8 @@
{
char *filepath;
HINSTANCE rc;
- if (!PyArg_ParseTuple(args, "s:startfile", &filepath))
+ if (!PyArg_ParseTuple(args, "et:startfile",
+ Py_FileSystemDefaultEncoding,
&filepath))
return NULL;
Py_BEGIN_ALLOW_THREADS
rc = ShellExecute((HWND)0, NULL, filepath, NULL,
NULL, SW_SHOWNORMAL);
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-08-24 07:18
Message:
Logged In: YES
user_id=80475
I'm unicode illiterate. Passing to MAL for review.
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-26 23:24
Message:
Logged In: YES
user_id=1188172
Attaching a patch which should fix that.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1007046&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1278102 ] help() broken, especially on Windows
Bugs item #1278102, was opened at 2005-09-01 08:37 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1278102&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: Bryan G. Olson (bryango) >Assigned to: Ka-Ping Yee (ping) Summary: help() broken, especially on Windows Initial Comment: The for loop that pydoc.Helper's __init__ uses to find the location of Python docs doesn't work. It will reject the standard setting of 'http://www.python.org/doc/current/lib/'. Also, the loop should probably break after setting self.docdir. On Windows, setting PYTHONDOCS to the installation's doc directory will not make it work, because the doc is now distributed as a single file, 'Python24.chm', so there is no 'lib' sub-directory. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1278102&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-853698 ] pythonw.exe should not flash DOS windows
Feature Requests item #853698, was opened at 2003-12-04 00:49 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=853698&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Amir Helzer (eehelzer) Assigned to: Nobody/Anonymous (nobody) Summary: pythonw.exe should not flash DOS windows Initial Comment: Python version 2.3. I'm using pythonw (and py2exe) to build a windows application. When new processes are launched, using os.system() or os.spawn a DOS windows flashes for a moment and then vanishes. It makes the application look funny. When the same application is run via python (and not pythonw) this doesn't happen. New processes don't create a flashing DOS window. It would be nice if pythonw.exe could function similar to python.exe, just without the constant DOS window in the background. The same behavior occures when running the program via pythonw.exeor when compiling with py2exe -w. Amir -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-01 12:56 Message: Logged In: YES user_id=1188172 Closing as Won't Fix, then. -- Comment By: Martin v. Löwis (loewis) Date: 2004-01-18 11:04 Message: Logged In: YES user_id=21627 The "flashing window" is created by the Microsoft C library, in its system() and spawn() implementations. If you don't want that window, you need to use CreateProcess instead. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=853698&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1278906 ] invalid syntax in os.walk() first example
Bugs item #1278906, was opened at 2005-09-01 13:55
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=1278906&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: YoHell (yohell)
Assigned to: Nobody/Anonymous (nobody)
Summary: invalid syntax in os.walk() first example
Initial Comment:
Hi!
The first example code block in the documentation for
os.walk() has invalid syntax in it.
The docs are available here:
http://www.python.org/doc/current/lib/os-file-dir.html#l2h-1466
This is the example code block:
import os
from os.path import join, getsize
for root, dirs, files in os.walk('python/Lib/email'):
print root, "consumes",
print sum(getsize(join(root, name)) for name in files),
print "bytes in", len(files), "non-directory files"
if 'CVS' in dirs:
dirs.remove('CVS') # don't visit CVS directories
Line 5 has the the invalid syntax:
print sum(getsize(join(root, name)) for name in files),
The example works if brackets are added like so:
print sum([getsize(join(root, name)) for name in
files]),
I recommend that someone responsible should make this
update in the docs.
You guys are brilliant. Thanks for a splendid language
with docs to match!
Cheers!
/Joel Hedlund
PhD student,
IFM Bioinfomatics, Linköping University
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1278906&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1235646 ] codecs.StreamRecoder.next doesn't encode
Bugs item #1235646, was opened at 2005-07-10 18:55 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235646&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: Unicode Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Sebastian Wangnick (wangnick) Assigned to: Walter Dörwald (doerwalter) Summary: codecs.StreamRecoder.next doesn't encode Initial Comment: Codecs.StreamRecode.next does't encode the data it gets from self.reader.next. This breaks the "for line in codecs.EncodedFile(...)" idiom. -- >Comment By: Walter Dörwald (doerwalter) Date: 2005-09-01 14:22 Message: Logged In: YES user_id=89016 Checked in as: Lib/codecs.py 1.48/1.35.2.10 I'll try to add tests for StreamRecoder tomorrow. StreamRecoder is broken in its current form, as it uses the stateless codec for the frontend encoding. Recoding from e.g. latin-1 to utf-16 will return a BOM for every call to read() which is clearly wrong. What gets read from the backend stream should be pushed through a *stateful* encoder. BTW, a feed style API would help here ;) -- Comment By: M.-A. Lemburg (lemburg) Date: 2005-08-31 22:58 Message: Logged In: YES user_id=38388 Looks good, Walter. Please check it in. Thanks. -- Comment By: Walter Dörwald (doerwalter) Date: 2005-08-31 18:11 Message: Logged In: YES user_id=89016 Here's a simple patch -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235646&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1278906 ] invalid syntax in os.walk() first example
Bugs item #1278906, was opened at 2005-09-01 06:55
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1278906&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: YoHell (yohell)
Assigned to: Nobody/Anonymous (nobody)
Summary: invalid syntax in os.walk() first example
Initial Comment:
Hi!
The first example code block in the documentation for
os.walk() has invalid syntax in it.
The docs are available here:
http://www.python.org/doc/current/lib/os-file-dir.html#l2h-1466
This is the example code block:
import os
from os.path import join, getsize
for root, dirs, files in os.walk('python/Lib/email'):
print root, "consumes",
print sum(getsize(join(root, name)) for name in files),
print "bytes in", len(files), "non-directory files"
if 'CVS' in dirs:
dirs.remove('CVS') # don't visit CVS directories
Line 5 has the the invalid syntax:
print sum(getsize(join(root, name)) for name in files),
The example works if brackets are added like so:
print sum([getsize(join(root, name)) for name in
files]),
I recommend that someone responsible should make this
update in the docs.
You guys are brilliant. Thanks for a splendid language
with docs to match!
Cheers!
/Joel Hedlund
PhD student,
IFM Bioinfomatics, Linköping University
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-09-01 07:44
Message:
Logged In: YES
user_id=80475
I suspect you are using Py2.4 documentation while running
Py2.3 or earlier. In Py2.4, the bracketless syntax was
introduced with new semantics which produce a similar result
but run with a generator instead of a list comprehension,
resulting in a significant savings in memory.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1278906&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1277903 ] logging module broken for multiple threads?
Bugs item #1277903, was opened at 2005-08-31 23:49
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1277903&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: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Lenny G. Arbage (alengarbage)
>Assigned to: Vinay Sajip (vsajip)
Summary: logging module broken for multiple threads?
Initial Comment:
After upgrading from python 2.2, I noticed that the
logging facility doesn't seem to work in my code anymore.
As far as I can tell, after spending a bit of time
isolating the problem, this is an issue with threading.
In the main thread, logging works without a hitch. In
the secondary thread (which is run via
twisted.reactor), any attempt to write to the log
results in:
Traceback (most recent call last):
File "/usr/lib/python2.4/logging/__init__.py", line
712, in emit
self.stream.write(fs % msg)
ValueError: I/O operation on closed file
The code that initializes the logger is as follows:
logger = logging.getLogger('mylogger')
screenhandler = logging.StreamHandler()
screenhandler.setLevel(logging.INFO)
logger.addHandler(self.screenhandler)
logfile = "/tmp/testlog"
if os.path.isfile(logfile):
os.remove(logfile)
handler = logging.FileHandler(logfile)
formatter = logging.Formatter('%(asctime)s
%(levelname)s: %(message)s')
handler.setFormatter(formatter)
logger.addHandler(handler)
logger.setLevel(logging.INFO)
Alone, this works fine. It is only when a the second
thread does a 'logger = logging.getLogger('mylogger')
and subsequently calls 'logger.log()' that the above
error is produced.
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-09-01 07:54
Message:
Logged In: YES
user_id=80475
It looks to me like you've created a race condition that
became evident only when switching Python versions.
Assigning to Vijay so he can give advice on the best way to
code this (most likely by moving resource competing calls to
the main thread).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1277903&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1066546 ] test_pwd fails on 64bit system (Opteron)
Bugs item #1066546, was opened at 2004-11-15 04:34
Message generated for change (Comment added) made by cmobarry
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1066546&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Miki Tebeka (tebeka)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_pwd fails on 64bit system (Opteron)
Initial Comment:
test test_pwd failed -- Traceback (most recent call last):
File "/tmp/miki/Python-2.4b2/Lib/test/test_pwd.py",
line 42, in test_values
self.assert_(pwd.getpwuid(e.pw_uid) in
entriesbyuid[e.pw_uid])
OverflowError: signed integer is greater than maximum
$ cat /proc/version
Linux version 2.4.21-20.ELsmp
([EMAIL PROTECTED]) (gcc version 3.2.3
20030502 (Red Hat Linux 3.2.3-42)) #1 SMP Wed Aug 18
20:34:58 EDT 2004
Processor is AMD Opteron 2.4MHz
--
Comment By: Clark Mobarry (cmobarry)
Date: 2005-09-01 08:57
Message:
Logged In: YES
user_id=1035073
The suggested patch by heffler worked brilliantly for my 64
bit environment. Thanks. My bug submission was on
2005-08-03 14:40.
--
Comment By: Marvin Heffler (heffler)
Date: 2005-08-11 14:19
Message:
Logged In: YES
user_id=298758
I think I figued out the problem with python handling uids and
gids greater than 2147483647 when using the grp.getgrgid
and pwd.getpwuid functions. Both of the functions call
PyArg_ParseTuple with a type of "i", thus indicating the
argument is a signed integer. Instead they should be
using "I" (upper-case i) for an unsigned integer. The fix is
fairly simple. Here are the two patches necessary to the
python source:
diff -Naur Python-2.4.orig/Modules/grpmodule.c Python-
2.4/Modules/grpmodule.c
--- Python-2.4.orig/Modules/grpmodule.c 2004-01-20
16:06:00.0 -0500
+++ Python-2.4/Modules/grpmodule.c 2005-08-11
13:36:48.0 -0400
@@ -87,7 +87,7 @@
{
int gid;
struct group *p;
-if (!PyArg_ParseTuple(args, "i:getgrgid", &gid))
+if (!PyArg_ParseTuple(args, "I:getgrgid", &gid))
return NULL;
if ((p = getgrgid(gid)) == NULL) {
PyErr_Format(PyExc_KeyError, "getgrgid(): gid not
found: %d", gid);
diff -Naur Python-2.4.orig/Modules/pwdmodule.c Python-
2.4/Modules/pwdmodule.c
--- Python-2.4.orig/Modules/pwdmodule.c 2004-01-20
16:07:23.0 -0500
+++ Python-2.4/Modules/pwdmodule.c 2005-08-11
13:36:27.0 -0400
@@ -104,7 +104,7 @@
{
int uid;
struct passwd *p;
- if (!PyArg_ParseTuple(args, "i:getpwuid", &uid))
+ if (!PyArg_ParseTuple(args, "I:getpwuid", &uid))
return NULL;
if ((p = getpwuid(uid)) == NULL) {
PyErr_Format(PyExc_KeyError,
Hopefully, someone from the python project can verify my
patch and get it incorporated into a future release.
--
Comment By: Clark Mobarry (cmobarry)
Date: 2005-08-03 14:40
Message:
Logged In: YES
user_id=1035073
The same error occurs for an Intel P4-521 processor running
RedHat Enterprise Linux WS v4 Intel EM64T 64bit.
$ cat /proc/version
Linux version 2.6.9-5.ELsmp ([EMAIL PROTECTED])
(gcc version 3.4.3 20041212 (Red Hat 3.4.3-9.EL4)) #1 SMP
Wed Jan 5 19:29:47 EST 2005
test test_grp failed -- Traceback (most recent call last):
File
"/home/cmobarry/downloads/Python-2.4.1/Lib/test/test_grp.py",
line 29, in test_values
e2 = grp.getgrgid(e.gr_gid)
OverflowError: signed integer is greater than maximum
test test_pwd failed -- Traceback (most recent call last):
File
"/home/cmobarry/downloads/Python-2.4.1/Lib/test/test_pwd.py",
line 42, in test_values
self.assert_(pwd.getpwuid(e.pw_uid) in
entriesbyuid[e.pw_uid])
OverflowError: signed integer is greater than maximum
--
Comment By: Miki Tebeka (tebeka)
Date: 2005-03-17 04:20
Message:
Logged In: YES
user_id=358087
I've tried the patch - no luck :-(
I'm stealing time on these machines since they belong to
another group.
However I see that SF's compile farm
(http://sourceforge.net/docman/display_doc.php?docid=762&group_id=1)
have an AMD64 host (amd64-linux1)
Maybe you can shorten the loop ...
--
Comment By: Walter Dörwald (doerwalter)
Date: 2005-03-14 17:17
Message:
Logged In: YES
user_id=89016
On a 32bit system adding the line
nobody:x:4294967294:65534:nobody:/:/bin/false
to /etc/passwd pwd.getpwall() gives me an entry:
('nobody', 'x', -2, 65534, 'nobody', '/', '/bin/false')
and
pwd.getpwuid(-2)
gives me
('nobody', 'x', -2, 65534, 'nobody', '/
[ python-Feature Requests-1275677 ] add a get() method to sets
Feature Requests item #1275677, was opened at 2005-08-29 08:49 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1275677&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Antoine Pitrou (pitrou) Assigned to: Raymond Hettinger (rhettinger) Summary: add a get() method to sets Initial Comment: Hi, I would like to propose a new method for the builtin set objects. Currently we have a pop() method which pops an element from the set. What I often need, though, is a method that gets an arbitrary element without removing it (because adding / removing stuff is dealt with in another part of the program). Right now the simplest way to do that is : value = iter(my_set).next() There are two problems with this: 1. it's ugly and not very intuitive 2. it is not atomic; this means if another thread updates the set, I can get a "RuntimeError: dictionary changed size during iteration" (btw, the message is slightly wrong, it should be "set" instead of "dictionary") Although the first problem is rather minor (but annoying nevertheless), the second one is a real showstopper in some cases - yes, I did encounter it for real. There is a way to avoid the second problem : value = list(my_set)[0] But of course, not only it is still ugly, but it is also highly inefficient when the set is big. So in the end I am forced to use an explicit lock around the aforementioned construct (value = iter(my_set).next()) as well as around any other piece of code that can update the set from another thread. This is tedious and error-prone, and probably a bit inefficient. So for the bottom line: it would be in some cases very useful to have an atomic get() method in addition to the pop() method on sets. (it could probably be applied to frozensets and dicts too) The implementation would probably not be very difficult, since it's the same as pop() with the removal feature removed. ;) But I'm not familiar with the Python internals. What do you think ? Regards Antoine. -- Comment By: Antoine Pitrou (pitrou) Date: 2005-08-31 08:50 Message: Logged In: YES user_id=133955 > Those two answers suggest this RFE is unnecessary. If you > guys agree, please close. If not, I'll ponder it further. > Right now, I'm disinclined to introduce a method that I > think is awkward to use. Well, closing the request is fine for me. Although I don't think choose() would be very awkward to use, we can probably live without it. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-30 15:06 Message: Logged In: YES user_id=80475 For the record, here are some research results. Java's set objects do not have a choose() method: http://java.sun.com/j2se/1.4.2/docs/api/java/util/Set.html In contrast, SETL does provide a function for extracting arbitrary elements. The empty set case is handled by returning Om which is a singleton object guaranteed not to be an element of any set. The Om value is especially useful in SETL because it can be passed upward through other functions (much in the same way that NANs can trickle through a calculation without killing it). Python has no equivalent of Om. http://www.cs.nyu.edu/~bacon/setl-doc.html#arb Core Perl only has arrays and hashes. Mathematica provides set operations on lists (union, intersection, complement). Rather than having a set specific function for extraction, list functions are used. The one providing choose-like functionality is First(). It is equivalent to indexing: a[0] http://documents.wolfram.com/mathematica/functions/First -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-30 06:47 Message: Logged In: YES user_id=80475 > > Question for everyone: Is there any known application for > > choose() that isn't met by pop()/add() irrespective of > > whether it "feels right"? [Antoine] > I don't think so indeed. [mwh] > Mmm, the "v, = s" approach hadn't occurred to me and it > seems ok. Those two answers suggest this RFE is unnecessary. If you guys agree, please close. If not, I'll ponder it further. Right now, I'm disinclined to introduce a method that I think is awkward to use. -- Comment By: Michael Hudson (mwh) Date: 2005-08-30 02:03 Message: Logged In: YES user_id=6656 Mmm, the "v, = s" approach hadn't occurred to me and it seems ok. The others are all rather horribly indirect... (and, obviously, it's not about "need").
[ python-Bugs-1277903 ] logging module broken for multiple threads?
Bugs item #1277903, was opened at 2005-08-31 22:49
Message generated for change (Comment added) made by alenlpeacock
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1277903&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: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Lenny G. Arbage (alengarbage)
Assigned to: Vinay Sajip (vsajip)
Summary: logging module broken for multiple threads?
Initial Comment:
After upgrading from python 2.2, I noticed that the
logging facility doesn't seem to work in my code anymore.
As far as I can tell, after spending a bit of time
isolating the problem, this is an issue with threading.
In the main thread, logging works without a hitch. In
the secondary thread (which is run via
twisted.reactor), any attempt to write to the log
results in:
Traceback (most recent call last):
File "/usr/lib/python2.4/logging/__init__.py", line
712, in emit
self.stream.write(fs % msg)
ValueError: I/O operation on closed file
The code that initializes the logger is as follows:
logger = logging.getLogger('mylogger')
screenhandler = logging.StreamHandler()
screenhandler.setLevel(logging.INFO)
logger.addHandler(self.screenhandler)
logfile = "/tmp/testlog"
if os.path.isfile(logfile):
os.remove(logfile)
handler = logging.FileHandler(logfile)
formatter = logging.Formatter('%(asctime)s
%(levelname)s: %(message)s')
handler.setFormatter(formatter)
logger.addHandler(handler)
logger.setLevel(logging.INFO)
Alone, this works fine. It is only when a the second
thread does a 'logger = logging.getLogger('mylogger')
and subsequently calls 'logger.log()' that the above
error is produced.
--
Comment By: Alen Peacock (alenlpeacock)
Date: 2005-09-01 10:00
Message:
Logged In: YES
user_id=1239721
I'm attaching a minimal program that demonstrates the
behavior. You'll need twisted installed to run it. I've
tested on python 2.4.1 and 2.4.14, both produce the error.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-09-01 06:54
Message:
Logged In: YES
user_id=80475
It looks to me like you've created a race condition that
became evident only when switching Python versions.
Assigning to Vijay so he can give advice on the best way to
code this (most likely by moving resource competing calls to
the main thread).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1277903&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1277903 ] logging module broken for multiple threads?
Bugs item #1277903, was opened at 2005-08-31 23:49
Message generated for change (Comment added) made by alengarbage
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1277903&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: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Lenny G. Arbage (alengarbage)
Assigned to: Vinay Sajip (vsajip)
Summary: logging module broken for multiple threads?
Initial Comment:
After upgrading from python 2.2, I noticed that the
logging facility doesn't seem to work in my code anymore.
As far as I can tell, after spending a bit of time
isolating the problem, this is an issue with threading.
In the main thread, logging works without a hitch. In
the secondary thread (which is run via
twisted.reactor), any attempt to write to the log
results in:
Traceback (most recent call last):
File "/usr/lib/python2.4/logging/__init__.py", line
712, in emit
self.stream.write(fs % msg)
ValueError: I/O operation on closed file
The code that initializes the logger is as follows:
logger = logging.getLogger('mylogger')
screenhandler = logging.StreamHandler()
screenhandler.setLevel(logging.INFO)
logger.addHandler(self.screenhandler)
logfile = "/tmp/testlog"
if os.path.isfile(logfile):
os.remove(logfile)
handler = logging.FileHandler(logfile)
formatter = logging.Formatter('%(asctime)s
%(levelname)s: %(message)s')
handler.setFormatter(formatter)
logger.addHandler(handler)
logger.setLevel(logging.INFO)
Alone, this works fine. It is only when a the second
thread does a 'logger = logging.getLogger('mylogger')
and subsequently calls 'logger.log()' that the above
error is produced.
--
>Comment By: Lenny G. Arbage (alengarbage)
Date: 2005-09-01 11:04
Message:
Logged In: YES
user_id=1338323
file attached
--
Comment By: Alen Peacock (alenlpeacock)
Date: 2005-09-01 11:00
Message:
Logged In: YES
user_id=1239721
I'm attaching a minimal program that demonstrates the
behavior. You'll need twisted installed to run it. I've
tested on python 2.4.1 and 2.4.14, both produce the error.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-09-01 07:54
Message:
Logged In: YES
user_id=80475
It looks to me like you've created a race condition that
became evident only when switching Python versions.
Assigning to Vijay so he can give advice on the best way to
code this (most likely by moving resource competing calls to
the main thread).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1277903&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1277903 ] logging module broken for multiple threads?
Bugs item #1277903, was opened at 2005-08-31 23:49
Message generated for change (Comment added) made by alengarbage
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1277903&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: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Lenny G. Arbage (alengarbage)
Assigned to: Vinay Sajip (vsajip)
Summary: logging module broken for multiple threads?
Initial Comment:
After upgrading from python 2.2, I noticed that the
logging facility doesn't seem to work in my code anymore.
As far as I can tell, after spending a bit of time
isolating the problem, this is an issue with threading.
In the main thread, logging works without a hitch. In
the secondary thread (which is run via
twisted.reactor), any attempt to write to the log
results in:
Traceback (most recent call last):
File "/usr/lib/python2.4/logging/__init__.py", line
712, in emit
self.stream.write(fs % msg)
ValueError: I/O operation on closed file
The code that initializes the logger is as follows:
logger = logging.getLogger('mylogger')
screenhandler = logging.StreamHandler()
screenhandler.setLevel(logging.INFO)
logger.addHandler(self.screenhandler)
logfile = "/tmp/testlog"
if os.path.isfile(logfile):
os.remove(logfile)
handler = logging.FileHandler(logfile)
formatter = logging.Formatter('%(asctime)s
%(levelname)s: %(message)s')
handler.setFormatter(formatter)
logger.addHandler(handler)
logger.setLevel(logging.INFO)
Alone, this works fine. It is only when a the second
thread does a 'logger = logging.getLogger('mylogger')
and subsequently calls 'logger.log()' that the above
error is produced.
--
>Comment By: Lenny G. Arbage (alengarbage)
Date: 2005-09-01 11:04
Message:
Logged In: YES
user_id=1338323
file attached
--
Comment By: Lenny G. Arbage (alengarbage)
Date: 2005-09-01 11:04
Message:
Logged In: YES
user_id=1338323
file attached
--
Comment By: Alen Peacock (alenlpeacock)
Date: 2005-09-01 11:00
Message:
Logged In: YES
user_id=1239721
I'm attaching a minimal program that demonstrates the
behavior. You'll need twisted installed to run it. I've
tested on python 2.4.1 and 2.4.14, both produce the error.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-09-01 07:54
Message:
Logged In: YES
user_id=80475
It looks to me like you've created a race condition that
became evident only when switching Python versions.
Assigning to Vijay so he can give advice on the best way to
code this (most likely by moving resource competing calls to
the main thread).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1277903&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1235646 ] codecs.StreamRecoder.next doesn't encode
Bugs item #1235646, was opened at 2005-07-10 18:55 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235646&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: Unicode Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Sebastian Wangnick (wangnick) Assigned to: Walter Dörwald (doerwalter) Summary: codecs.StreamRecoder.next doesn't encode Initial Comment: Codecs.StreamRecode.next does't encode the data it gets from self.reader.next. This breaks the "for line in codecs.EncodedFile(...)" idiom. -- >Comment By: M.-A. Lemburg (lemburg) Date: 2005-09-01 20:28 Message: Logged In: YES user_id=38388 Thanks, Walter. StreamRecorder is not broken: it works as advertised (see the .__init__() doc-string and interface) and yes, this means that only stateless encodings can be used, such as e.g. UTF-16-LE, simply because the encode and decode functions are defined as being stateless. -- Comment By: Walter Dörwald (doerwalter) Date: 2005-09-01 14:22 Message: Logged In: YES user_id=89016 Checked in as: Lib/codecs.py 1.48/1.35.2.10 I'll try to add tests for StreamRecoder tomorrow. StreamRecoder is broken in its current form, as it uses the stateless codec for the frontend encoding. Recoding from e.g. latin-1 to utf-16 will return a BOM for every call to read() which is clearly wrong. What gets read from the backend stream should be pushed through a *stateful* encoder. BTW, a feed style API would help here ;) -- Comment By: M.-A. Lemburg (lemburg) Date: 2005-08-31 22:58 Message: Logged In: YES user_id=38388 Looks good, Walter. Please check it in. Thanks. -- Comment By: Walter Dörwald (doerwalter) Date: 2005-08-31 18:11 Message: Logged In: YES user_id=89016 Here's a simple patch -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235646&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1267884 ] crash recursive __getattr__
Bugs item #1267884, was opened at 2005-08-24 06:22 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1267884&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: Closed >Resolution: Duplicate Priority: 5 Submitted By: pinzo (rodrigo_rc) Assigned to: Nobody/Anonymous (nobody) Summary: crash recursive __getattr__ Initial Comment: The following code eats all stack space and crashes, both in Windows and Linux: 8<- class C: def __getattr__(self, a): return object.__getattribute__(self, a) c = C() str(c) 8<- It shoud probably raise "RuntimeError: maximum recursion depth exceeded" or similar instead. -- >Comment By: Terry J. Reedy (tjreedy) Date: 2005-09-01 16:35 Message: Logged In: YES user_id=593130 I believe this is essentially the same as open bug [ 1202533 ] a bunch of infinite C recursions Closing as duplicate and adding note to 1202533. Reopen if a fix to the above, if and when there is one, does not fix this. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1267884&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1202533 ] a bunch of infinite C recursions
Bugs item #1202533, was opened at 2005-05-15 19:43
Message generated for change (Comment added) made by tjreedy
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: a bunch of infinite C recursions
Initial Comment:
There is a general way to cause unchecked infinite recursion at the C level,
and I have no clue at the moment how it could be reasonably fixed. The idea is
to define special __xxx__ methods in such a way that no Python code is actually
called before they invoke more special methods (e.g. themselves).
>>> class A: pass
>>> A.__mul__=new.instancemethod(operator.mul,None,A)
>>> A()*2
Segmentation fault
--
>Comment By: Terry J. Reedy (tjreedy)
Date: 2005-09-01 16:39
Message:
Logged In: YES
user_id=593130
Bug submission [ 1267884 ] crash recursive __getattr__
appears to be another example of this problem, so I closed it as
a duplicate. If that turns out to be wrong, it should be reopened.
--
Comment By: Armin Rigo (arigo)
Date: 2005-05-29 08:23
Message:
Logged In: YES
user_id=4771
Adding a Py_EnterRecursiveCall() in PyObject_Call() seems to fix all the
examples so far, with the exception of the "__get__=getattr" one, where we get
a strange result instead of a RuntimeError (I suspect careless exception eating
is taking place).
The main loop in ceval.c doesn't call PyObject_Call() very often: it usually
dispatches directly itself for performance, which is exactly what we want here,
as recursion from ceval.c is already protected by a Py_EnterRecursiveCall().
So this change has a minor impact on performance. Pystone for example issues
only three PyObject_Call() per loop, to call classes. This has an
almost-unmeasurable impact ( < 0.4%).
Of course I'll think a bit more and search for examples that don't go through
PyObject_Call() :-)
--
Comment By: Armin Rigo (arigo)
Date: 2005-05-23 09:52
Message:
Logged In: YES
user_id=4771
When I thought about the same problem for PyPy, I imagined
that it would be easy to use the call graph computed by
the type inferencer ("annotator"). We would find an
algorithm that figures out the minimal number of places
that need a Py_EnterRecursiveCall so that every cycle goes
through at least one of them. For CPython it might be
possible to go down the same path if someone can find a C
code analyzer smart enough to provide the required
information -- a call graph including indirect calls through
function pointers. Not sure it's sane, though.
--
Comment By: Michael Hudson (mwh)
Date: 2005-05-23 09:16
Message:
Logged In: YES
user_id=6656
I agree with Armin that this could easily be a never ending story. Perhaps
it would suffice to sprinkle Py_EnterRecursiveCall around as we find holes.
It might have to, because I can't really think of a better way of doing this.
The only other approach I know is that of SBCL (a Common Lisp
implementation): it mprotects a page at the end of the stack and installs a
SIGSEGV handler (and uses sigaltstack) that knows how to abort the
current lisp operation. Somehow, I don't think we want to go down this
line.
Anybody have any other ideas?
--
Comment By: Martin v. Löwis (loewis)
Date: 2005-05-23 09:06
Message:
Logged In: YES
user_id=21627
It has been a long-time policy that you should not be able
to crash the Python interpreter even with malicious code. I
think this is a good policy, because it provides people
always with a back-trace, which is much easier to analyse
than a core dump.
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-05-23 03:41
Message:
Logged In: YES
user_id=341410
I personally think that the CPython runtime should make a
best-effort to not crash when running code that makes sense.
But when CPython is running on input that is nonsensical
(in each of the examples that Armin provides, no return
value could make sense), I think that as long as the
behavior is stated clearly, it is sufficient.
Certainly it would be nice if CPython did not crash in such
cases, but I don't know if the performance penalty and code
maintenance outweigh the cases where users write bad code.
Perhaps a compile-time option, enabled by default based on
whether or not we want a safer or faster CPython
[ python-Bugs-1267884 ] crash recursive __getattr__
Bugs item #1267884, was opened at 2005-08-24 06:22 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1267884&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: Closed Resolution: Duplicate Priority: 5 Submitted By: pinzo (rodrigo_rc) Assigned to: Nobody/Anonymous (nobody) Summary: crash recursive __getattr__ Initial Comment: The following code eats all stack space and crashes, both in Windows and Linux: 8<- class C: def __getattr__(self, a): return object.__getattribute__(self, a) c = C() str(c) 8<- It shoud probably raise "RuntimeError: maximum recursion depth exceeded" or similar instead. -- >Comment By: Terry J. Reedy (tjreedy) Date: 2005-09-01 16:37 Message: Logged In: YES user_id=593130 I believe this is essentially the same as open bug [ 1202533 ] a bunch of infinite C recursions Closing as duplicate and adding a cross-reference note to 1202533. Reopen if a fix to the above, if and when there is one, does not fix this. -- Comment By: Terry J. Reedy (tjreedy) Date: 2005-09-01 16:35 Message: Logged In: YES user_id=593130 I believe this is essentially the same as open bug [ 1202533 ] a bunch of infinite C recursions Closing as duplicate and adding note to 1202533. Reopen if a fix to the above, if and when there is one, does not fix this. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1267884&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1280061 ] time.strptime() fails with unicode date string, de_DE locale
Bugs item #1280061, was opened at 2005-09-01 13:06 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=1280061&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Adam Monsen (meonkeys) Assigned to: Nobody/Anonymous (nobody) Summary: time.strptime() fails with unicode date string, de_DE locale Initial Comment: Trying to parse a German date string fails in Python 2.4.1. Test case attached. Since there's no indenting, I suppose the test case can also be pasted here: import locale, time locale.setlocale(locale.LC_TIME, 'de_DE') date = u'10. September 2005 um 17:26' format = '%d. %B %Y um %H:%M' time.strptime(date, format) -- Adam Monsen http://adammonsen.com/ -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1280061&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1277718 ] Lambda and deepcopy
Bugs item #1277718, was opened at 2005-08-31 16:10
Message generated for change (Comment added) made by tjreedy
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1277718&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: Python 2.3
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Joshua Ginsberg (jaginsberg)
Assigned to: Nobody/Anonymous (nobody)
Summary: Lambda and deepcopy
Initial Comment:
Howdy --
I have a class that has an attribute that is a
dictionary that contains an object that has a kword
argument that is a lambda. Confused yet? Simplified
example:
import copy
class Foo:
def __init__(self, fn=None):
self.fn = fn
class Bar:
d = {'foobar': Foo(fn=lambda x: x*x)}
def cp(self):
self.xerox = copy.deepcopy(self.d)
When I execute:
b = Bar()
b.cp()
Using Python version:
Python 2.3 (#1, Sep 13 2003, 00:49:11)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on
darwin
I get:
Traceback (most recent call last):
File "", line 1, in ?
File "", line 5, in cp
File
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/copy.py",
line 179, in deepcopy
y = copier(x, memo)
File
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/copy.py",
line 270, in _deepcopy_dict
y[deepcopy(key, memo)] = deepcopy(value, memo)
File
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/copy.py",
line 179, in deepcopy
y = copier(x, memo)
File
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/copy.py",
line 307, in _deepcopy_inst
state = deepcopy(state, memo)
File
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/copy.py",
line 179, in deepcopy
y = copier(x, memo)
File
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/copy.py",
line 270, in _deepcopy_dict
y[deepcopy(key, memo)] = deepcopy(value, memo)
File
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/copy.py",
line 206, in deepcopy
y = _reconstruct(x, rv, 1, memo)
File
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/copy.py",
line 338, in _reconstruct
y = callable(*args)
File
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/copy_reg.py",
line 92, in __newobj__
return cls.__new__(cls, *args)
TypeError: function() takes at least 2 arguments (0 given)
I've googled for deepcopy and lambda and found somebody
else asking the same question on a LUG somewhere, but
they gave no advice and nobody else seems to have run
into this. Any ideas on what the problem is/how to get
around it? Thanks!
-jag
--
>Comment By: Terry J. Reedy (tjreedy)
Date: 2005-09-01 17:38
Message:
Logged In: YES
user_id=593130
Python does not have lambdas. It has functions. Among other
ways, they can be produced by lambda expressions. The *only*
residue of lambda origin is the otherwise invalid
.func_name ''.
General bug-seeking advice:
1. If you can, upgrade to at least 2.3.5, the last 2.3 series
release, with its several bug fixes.
2. If at all possible, test code with the lastest release. Each
release has numerous bug fixes. (But not needed here.)
3. Reduce code to the minimum needed to get the apparent
buggy behavior. You code is mostly noise for this purpose. I
believe copy.deepcopy(lambda x: x) would be sufficient to get an
exception.
4. Read (or reread) the manual for the modules and methods
giving you trouble. From
http://docs.python.org/lib/module-copy.html and from
http://www.python.org/doc/2.3/lib/module-copy.html:
"This version does not copy types like module, class, function..."
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1277718&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1277903 ] logging module broken for multiple threads?
Bugs item #1277903, was opened at 2005-08-31 23:49
Message generated for change (Comment added) made by alengarbage
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1277903&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: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Lenny G. Arbage (alengarbage)
Assigned to: Vinay Sajip (vsajip)
Summary: logging module broken for multiple threads?
Initial Comment:
After upgrading from python 2.2, I noticed that the
logging facility doesn't seem to work in my code anymore.
As far as I can tell, after spending a bit of time
isolating the problem, this is an issue with threading.
In the main thread, logging works without a hitch. In
the secondary thread (which is run via
twisted.reactor), any attempt to write to the log
results in:
Traceback (most recent call last):
File "/usr/lib/python2.4/logging/__init__.py", line
712, in emit
self.stream.write(fs % msg)
ValueError: I/O operation on closed file
The code that initializes the logger is as follows:
logger = logging.getLogger('mylogger')
screenhandler = logging.StreamHandler()
screenhandler.setLevel(logging.INFO)
logger.addHandler(self.screenhandler)
logfile = "/tmp/testlog"
if os.path.isfile(logfile):
os.remove(logfile)
handler = logging.FileHandler(logfile)
formatter = logging.Formatter('%(asctime)s
%(levelname)s: %(message)s')
handler.setFormatter(formatter)
logger.addHandler(handler)
logger.setLevel(logging.INFO)
Alone, this works fine. It is only when a the second
thread does a 'logger = logging.getLogger('mylogger')
and subsequently calls 'logger.log()' that the above
error is produced.
--
>Comment By: Lenny G. Arbage (alengarbage)
Date: 2005-09-01 17:29
Message:
Logged In: YES
user_id=1338323
Here's an even more minimal snippet of code that produces
the error. Nothing but a logger and a thread. No need for
twisted anything. Ignore the previous example.
Does this code do something to abuse the logging facility?
--
Comment By: Lenny G. Arbage (alengarbage)
Date: 2005-09-01 11:04
Message:
Logged In: YES
user_id=1338323
file attached
--
Comment By: Lenny G. Arbage (alengarbage)
Date: 2005-09-01 11:04
Message:
Logged In: YES
user_id=1338323
file attached
--
Comment By: Alen Peacock (alenlpeacock)
Date: 2005-09-01 11:00
Message:
Logged In: YES
user_id=1239721
I'm attaching a minimal program that demonstrates the
behavior. You'll need twisted installed to run it. I've
tested on python 2.4.1 and 2.4.14, both produce the error.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-09-01 07:54
Message:
Logged In: YES
user_id=80475
It looks to me like you've created a race condition that
became evident only when switching Python versions.
Assigning to Vijay so he can give advice on the best way to
code this (most likely by moving resource competing calls to
the main thread).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1277903&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-761452 ] HTMLParser chokes on my.yahoo.com output
Bugs item #761452, was opened at 2003-06-26 21:11 Message generated for change (Comment added) made by tmick You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=761452&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.2.3 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Robert Walsh (rjwalsh) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: HTMLParser chokes on my.yahoo.com output Initial Comment: The HTML parser chokes on the output produced by http://my.yahoo.com/. The problem appears to be that the HTML Yahoo is producing contains stuff like this:
