[issue1276] LookupError: unknown encoding: X-MAC-JAPANESE
John Smith <[EMAIL PROTECTED]> added the comment: Confirmed now I can build Python on Mac OS X with Japanese locale. I tested the followings. Python 2.6b3+ trunk:66060 Python 3.0b3+ py3k:66060 Thank you very much. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1276> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1706039] Added clearerr() to clear EOF state
John Smith added the comment: What's in a name? :p Done, anyway. _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1706039> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1706039] Added clearerr() to clear EOF state
John Smith <[EMAIL PROTECTED]> added the comment: Hi, when will this patch be checkedin? -- versions: +Python 2.5.3, Python 2.6, Python 3.0 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1706039> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1706039] Added clearerr() to clear EOF state
John Smith added the comment: Sorry for inconvenience caused with the patch. I should've got more reviews before asking it checked in. I verified eof2.diff-applied-python gets "Bus error" and Scott Dial's fileobject.diff fixes this. (Test was on 9.6.0 Darwin Kernel Version 9.6.0) ___ Python tracker <http://bugs.python.org/issue1706039> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39724] IDLE threading + stdout/stdin observed blocking behavior
New submission from John Smith : preamble: I am aware that I am not the first to encounter this issue but neither I could identify a preexisting ticket which fully matches nor is the commonly recommended "solution" (stay away from IDLE) satisfying. environment: win10, python 3.7 (tested with 32 and 64 bit version) description: If the attached script is started from IDLE the "alive" only shows up once for every input, while the script output "alive" frequently if ran from the terminal with python. So there is a discrepancy between the behavior of IDLE and "plain" python, which can lead to serious "irritations". If the print is replaced with logging.info and the logging is setup to write into a file everything works as expected and equal in both environments. thoughts: the input call seems to block access to stdout(?) in "IDLE mode". I noticed that there are several topics/post regarding IDLE's stdout/in behavior but I was unabled to find a (convinient) solution besides "just quit using IDLE". It feels strange that the editor bundled with python has such a reputation and features such a deviation in behavior from "plain" python. -- assignee: terry.reedy components: IDLE messages: 362456 nosy: John Smith, terry.reedy priority: normal severity: normal status: open title: IDLE threading + stdout/stdin observed blocking behavior type: behavior versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue39724> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39724] IDLE threading + stdout/stdin observed blocking behavior
John Smith added the comment: py -m idlelib -n path output: Python 3.6.4 (v3.6.4:d48eceb, Dec 19 2017, 06:04:45) [MSC v.1900 32 bit (Intel)] on win32 Type "copyright", "credits" or "license()" for more information. No Subprocess WARNING: Running IDLE without a Subprocess is deprecated and will be removed in a later version. See Help/IDLE Help for details. >>> waiting for inputalive alive alive alive alive alive -> so its working as intended -- ___ Python tracker <https://bugs.python.org/issue39724> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39724] IDLE threading + stdout/stdin observed blocking behavior
Change by John Smith : Added file: https://bugs.python.org/file48901/IDLE_threading_issue_min_example1.py ___ Python tracker <https://bugs.python.org/issue39724> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39724] IDLE threading + stdout/stdin observed blocking behavior
John Smith added the comment: P.S. here (other computer but with same observed behavior) I have a 3.6 32bit as one can see from the output. -- ___ Python tracker <https://bugs.python.org/issue39724> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39724] IDLE threading + stdout/stdin observed blocking behavior
John Smith added the comment: Interesting finding. Just some thoughs: I have to disagree on the "the experience with input() in IDLE is more useful and less confusing, especially to beginners" part. Here are some reasons: 1. If a beginner starts with threading and expect a concurrent execution the confusion will be high if there is non in IDLE => implicitly changes of the runtime behavior siliencly enforced by an IDE can lead to misconcepts. 2. It took me (and my team) more than one hour to track a strange issue down to this IDLE related behavior - mainly because I assumed that IDLE would not change the runtime behavior of a program in that way => the deviation in behavior can even confuse experienced developers. 3. During my search I came across several reports of similar issues and most people were told to simply quit IDLE => "quirks" have impact on the reputation. Personally I like and mainly use IDLE and would like to continue with it. -- versions: -Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue39724> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40487] Unexpected exception handler behavior in Jupyter when returning task objects created with create_task
New submission from John Smith :
Hi,
I'm running the following code in a Jupyter notebook (so there is already a
running loop).
`run_coro` (non-async function) adds given coroutines to the loop with
`loop.create_task`. I want to return the task objects created by
`loop.create_task` to check for result later in the code.
Adding the task objects to a list and returning the list has the exception
handler behave differently than expected.
```
async def test1():
''' Enumerate numbers from 1 to 9'''
n = 0
while (n := n + 1) < 10:
print(f'Test 1: {n}')
await asyncio.sleep(0.3)
return 'Test 1: DONE'
async def test2():
''' Enumerate numbers starting 1, raising exception at 5'''
n = 0
while (n := n + 1) < 10:
if n == 5:
raise ValueError('Test Exception')
print(f'Test 2: {n}')
await asyncio.sleep(0.2)
def handle_exception(loop, context):
if context['exception']:
print(f'Caught exception <{context["exception"]}> while executing
{context["future"]}')
def run_coro(loop, coros):
loop.set_exception_handler(handle_exception)
tasks = deque()
for coro in coros:
task = loop.create_task(coro)
#tasks.append(task)
# ^--- if I uncomment, exc handler behaves strangely
return tasks
# ^-- BUT if I remove the "return" statement, it behaves correctly again
loop = asyncio.get_running_loop() # retrieves Jupyter's running loop
tasks = run_coro(loop, [test1(), test2()])
```
Normal (expected output):
```
Test 1: 1
Test 2: 1
Test 2: 2
Test 1: 2
Test 2: 3
Test 1: 3
Test 2: 4
Caught exception while executing :10> exception=ValueError('Test Exception')>
Test 1: 4
Test 1: 5
Test 1: 6
Test 1: 7
Test 1: 8
Test 1: 9
```
If I uncomment `tasks.append(task)` and return the list of task objects, output
is:
```
Test 1: 1
Test 2: 1
Test 2: 2
Test 1: 2
Test 2: 3
Test 1: 3
Test 2: 4
Test 1: 4
Test 1: 5
Test 1: 6
Test 1: 7
Test 1: 8
Test 1: 9
```
If I re-run the code (re-run the Jupyter cell) the exception message would
appear at the beginning of the output (as if it had been waiting in a queue
somewhere), so for some reason it seems to get eaten-up somewhere.
The code works normally again if I remove the return statement from the
`run_coro` function.
Is this expected behaviour? Am I missing something?
--
components: asyncio
messages: 367988
nosy: asvetlov, jeanmonet, yselivanov
priority: normal
severity: normal
status: open
title: Unexpected exception handler behavior in Jupyter when returning task
objects created with create_task
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue40487>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40487] Unexpected exception handler behavior in Jupyter when returning task objects created with create_task
Change by John Smith : -- type: -> behavior ___ Python tracker <https://bugs.python.org/issue40487> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40487] Unexpected exception handler behavior in Jupyter when returning task objects created with create_task
John Smith added the comment: Additional note: In a almost identical set-up, the simple fact of assigning the task object to a variable: `task = loop.create_task(coroutine())` instead of just calling: `loop.create_task(coroutine())` ...results in the same unexpected behavior in exception handling, without even attempting to return the task object. -- ___ Python tracker <https://bugs.python.org/issue40487> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
