[ python-Feature Requests-1432694 ] Implement preemptive threads in Python
Feature Requests item #1432694, was opened at 2006-02-16 10:11 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=1432694&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: Threads Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andrey Petrov (darkprokoba) Assigned to: Nobody/Anonymous (nobody) Summary: Implement preemptive threads in Python Initial Comment: Cooperative threads have their uses but I find the lack of real native pre-emptive threads a major issue in a 21-st century language. We should consider the inertia of programmers from C++/Java/.NET background. They are used to and experienced in solving certain kind of problems with pre-emptive threads, and it's just too plain inconvenient to step back and try to cope with cooperative threads. The idea behind Python is that programming should not be a pain, right? This applies especially to GUI programs, where threads are used to perform time-consuming work in order to avoid the GUI from freezing (was I surprised the first time I tried this in Python!) Just look at some of the modern Python GUI applications, found in some recent Linux distributions. 99% of Fedora's configuration tools suffer extreme usability issues caused by their single-threadedness. I hate using yumex because the GUI is basically frozen for the half minute it takes to reload all repos I have configured on my machine!!! I know there might be a way to alleviate this particual class of problems by more careful cooperative thread programing... but I believe we need a more straightforward solution (i.e. preemptive threads) and not workarounds. I apologize if this issue has already been raised before. Cheers, darkprokoba -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1432694&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1432343 ] Description of file-object read() method is wrong.
Bugs item #1432343, was opened at 2006-02-15 18:49 Message generated for change (Comment added) made by yohell You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1432343&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: None Status: Open Resolution: None Priority: 5 Submitted By: Grant Edwards (grante) Assigned to: Nobody/Anonymous (nobody) Summary: Description of file-object read() method is wrong. Initial Comment: There are two errors in the documentation of the file object's read() method found at http://www.python.org/doc/current/lib/bltin-file-objects.html#l2h-242 Suggested changes (unindented) are shown below interspersed with the current text with insertions noted by a '+' in the first column: Read at most size bytes from the file (less if the read hits EOF before obtaining size bytes). If the size argument is negative or omitted, read all data until EOF is reached. + Under some circumstances (e.g. system call aborted by + a signal) read() called with a negative or absent size + argument may return data before EOF is reached (even in + blocking mode). The bytes are returned as a string object. An empty string is returned when EOF is encountered immediately. (For certain files, like ttys, it makes sense to continue reading after an EOF is hit.) The last sentence above (the parenthetical one) is false for Linux/Unix. Once you hit EOF on a tty, it will return EOF forever until it's closed and re-opened. If the above sentence is true for other OSes, I suggest it be so qualified -- otherwise it should just be deleted. Note that this method may call the underlying C function fread() more than once in an effort to acquire as close to size bytes as possible. Also note that when in non-blocking mode, less data than what was requested may be returned, even if no size parameter was given. -- Comment By: YoHell (yohell) Date: 2006-02-16 12:17 Message: Logged In: YES user_id=1008220 Well spoken! However I'm not sure I quite follow you here: > The last sentence above (the parenthetical one) is false > for Linux/Unix. Once you hit EOF on a tty, it will return > EOF forever until it's closed and re-opened. A quote from Donn Cave in a discussion on comp.lang.python: """ They were probably thinking of the way the UNIX tty driver delivers an EOF on D, after which of course you can continue to read data from the same tty. """ This is also true for the Linux tty (afaik), so under those circumstances it may really make sense to continue reading past EOF. example: - #!/usr/bin/python import sys while True: s = sys.stdin.read() print s - Pressing Ctrl-D while providing input to sys.stdin via the keyboard will cause sys.stdin.read() to return, and you will still be able to keep reading from sys.stdin without closing and reopening it explicitly. But then again I might have missed something. /Joel Hedlund -- Comment By: Grant Edwards (grante) Date: 2006-02-15 18:51 Message: Logged In: YES user_id=61937 Well, that didn't work very well. I really hate these web interfaces. I've attached the suggested changes as a text file. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1432343&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1293741 ] doctest runner cannot handle non-ascii characters
Bugs item #1293741, was opened at 2005-09-17 13:41 Message generated for change (Comment added) made by bjoti You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1293741&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.4 Status: Open Resolution: None Priority: 5 Submitted By: GRISEL (ogrisel) Assigned to: Tim Peters (tim_one) Summary: doctest runner cannot handle non-ascii characters Initial Comment: The doctest module fails when the expected result string has non-ascii charcaters even if the # -*- coding: XXX -*- line is properly set. The enclosed code sample produce the following error: Traceback (most recent call last): File "test_iso-8859-15.py", line 41, in ? _test() File "test_iso-8859-15.py", line 26, in _test tried, failed = runner.run(t) File "/usr/lib/python2.4/doctest.py", line 1376, in run return self.__run(test, compileflags, out) File "/usr/lib/python2.4/doctest.py", line 1259, in __run if check(example.want, got, self.optionflags): File "/usr/lib/python2.4/doctest.py", line 1475, in check_output if got == want: UnicodeDecodeError: 'ascii' codec can't decode byte 0xe9 in position 8: ordinal not in range(128) -- Comment By: Bjorn Tillenius (bjoti) Date: 2006-02-16 12:41 Message: Logged In: YES user_id=1032069 I'm quite sure that you can use non-ASCII characters in your doctest, given that it's a unicode string. So if you make your docstring a unicode string, it should work. That is: u"""Docstring containing non-ASCII characters. ... """ -- Comment By: GRISEL (ogrisel) Date: 2005-09-18 12:25 Message: Logged In: YES user_id=795041 Unfortunateny that patch does not fix my problem. The patch at bug #1080727 fixes the problem for doctests written in external reST files (testfile and DocFileTest functions). My problem is related to internal docstring encoding (testmod for instance). However, Bjorn Tillenius says: """ 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. """ So according to him, docstrings' doctests with non-ascii characters should work by default. So maybe my system setup is somewhat broken. Could somebody please confirm/infirm this by running the attached sample script on his system? My system config: [EMAIL PROTECTED] (on linux) python 2.4.1 with: sys.getdefaultencoding() == 'ascii' and locale.getpreferredencoding() == 'ISO-8859-15' $ file test_iso-8859-15.py test_iso-8859-15.py: ISO-8859 English text -- Comment By: Tim Peters (tim_one) Date: 2005-09-17 19:42 Message: Logged In: YES user_id=31435 Please try the patch at http://www.python.org/sf/1080727 and report back on whether it solves your problem (attaching comments to the patch report would be most useful). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1293741&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1432838 ] optparse docs double-dash confusion
Bugs item #1432838, was opened at 2006-02-16 12:28 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=1432838&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: None Status: Open Resolution: None Priority: 5 Submitted By: John Veness (pelago) Assigned to: Nobody/Anonymous (nobody) Summary: optparse docs double-dash confusion Initial Comment: Page http://docs.python.org/lib/optparse-terminology.html says: The GNU project introduced "-" followed by a series of hyphen-separated words, e.g. "-file" or "-dry-run". but should say: The GNU project introduced "--" followed by a series of hyphen-separated words, e.g. "--file" or "--dry-run". Also at the bottom of that page: "-v" and "-report" are both options. should be: "-v" and "--report" are both options. It looks in general that there is a documentation rendering problem when double-dash appears in quotes. Other double-dash items on that page are ok, when not in quotes. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1432838&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1432343 ] Description of file-object read() method is wrong.
Bugs item #1432343, was opened at 2006-02-15 17:49 Message generated for change (Comment added) made by grante You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1432343&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: None Status: Open Resolution: None Priority: 5 Submitted By: Grant Edwards (grante) Assigned to: Nobody/Anonymous (nobody) Summary: Description of file-object read() method is wrong. Initial Comment: There are two errors in the documentation of the file object's read() method found at http://www.python.org/doc/current/lib/bltin-file-objects.html#l2h-242 Suggested changes (unindented) are shown below interspersed with the current text with insertions noted by a '+' in the first column: Read at most size bytes from the file (less if the read hits EOF before obtaining size bytes). If the size argument is negative or omitted, read all data until EOF is reached. + Under some circumstances (e.g. system call aborted by + a signal) read() called with a negative or absent size + argument may return data before EOF is reached (even in + blocking mode). The bytes are returned as a string object. An empty string is returned when EOF is encountered immediately. (For certain files, like ttys, it makes sense to continue reading after an EOF is hit.) The last sentence above (the parenthetical one) is false for Linux/Unix. Once you hit EOF on a tty, it will return EOF forever until it's closed and re-opened. If the above sentence is true for other OSes, I suggest it be so qualified -- otherwise it should just be deleted. Note that this method may call the underlying C function fread() more than once in an effort to acquire as close to size bytes as possible. Also note that when in non-blocking mode, less data than what was requested may be returned, even if no size parameter was given. -- >Comment By: Grant Edwards (grante) Date: 2006-02-16 13:08 Message: Logged In: YES user_id=61937 My bad. You're right about the Ctrl-D case. The code I was looking that caused a permanent EOF was when the master end of a pty was closed. I think. Anyway, Ctrl-D doesn't cause a permanent EOF condition and you can read more data afterwards. -- Comment By: YoHell (yohell) Date: 2006-02-16 11:17 Message: Logged In: YES user_id=1008220 Well spoken! However I'm not sure I quite follow you here: > The last sentence above (the parenthetical one) is false > for Linux/Unix. Once you hit EOF on a tty, it will return > EOF forever until it's closed and re-opened. A quote from Donn Cave in a discussion on comp.lang.python: """ They were probably thinking of the way the UNIX tty driver delivers an EOF on D, after which of course you can continue to read data from the same tty. """ This is also true for the Linux tty (afaik), so under those circumstances it may really make sense to continue reading past EOF. example: - #!/usr/bin/python import sys while True: s = sys.stdin.read() print s - Pressing Ctrl-D while providing input to sys.stdin via the keyboard will cause sys.stdin.read() to return, and you will still be able to keep reading from sys.stdin without closing and reopening it explicitly. But then again I might have missed something. /Joel Hedlund -- Comment By: Grant Edwards (grante) Date: 2006-02-15 17:51 Message: Logged In: YES user_id=61937 Well, that didn't work very well. I really hate these web interfaces. I've attached the suggested changes as a text file. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1432343&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-1432694 ] Implement preemptive threads in Python
Feature Requests item #1432694, was opened at 2006-02-16 08:11
Message generated for change (Comment added) made by mwh
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1432694&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: Threads
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Andrey Petrov (darkprokoba)
>Assigned to: Michael Hudson (mwh)
Summary: Implement preemptive threads in Python
Initial Comment:
Cooperative threads have their uses but I find the lack
of real native pre-emptive threads a major issue in a
21-st century language.
We should consider the inertia of programmers from
C++/Java/.NET background. They are used to and
experienced in solving certain kind of problems with
pre-emptive threads, and it's just too plain
inconvenient to step back and try to cope with
cooperative threads.
The idea behind Python is that programming should not
be a pain, right?
This applies especially to GUI programs, where threads
are used to perform time-consuming work in order to
avoid the GUI from freezing (was I surprised the first
time I tried this in Python!)
Just look at some of the modern Python GUI
applications, found in some recent Linux distributions.
99% of Fedora's configuration tools suffer extreme
usability issues caused by their single-threadedness. I
hate using yumex because the GUI is basically frozen
for the half minute it takes to reload all repos I have
configured on my machine!!! I know there might be a way
to alleviate this particual class of problems by more
careful cooperative thread programing... but I believe
we need a more straightforward solution (i.e.
preemptive threads) and not workarounds.
I apologize if this issue has already been raised before.
Cheers,
darkprokoba
--
>Comment By: Michael Hudson (mwh)
Date: 2006-02-16 14:14
Message:
Logged In: YES
user_id=6656
We _have_ preemptive threads in Python ("import threading"). Suggest you
report a real problem.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1432694&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
