[issue33638] condition lock not re-acquired
New submission from christof :
Hello,
I have a simple code which triggers a timeout if a task did not complete
import asyncio
async def task_timeout():
condition = asyncio.Condition()
with await condition:
try:
await asyncio.wait_for(condition.wait(), timeout=4)
except asyncio.TimeoutError as e:
print("timeout reached")
# uncomment this line to make the code work
# await asyncio.sleep(0)
f = asyncio.ensure_future(task_timeout())
loop= asyncio.get_event_loop()
loop.run_until_complete(f)
It throws an exception when leaving the scope for the condition because it
expects the lock to be acquired:
RuntimeError: Lock is not acquired.
If you uncomment the line to sleep, it will work because it will continue in
the coroutine Condition.wait and call:
yield from self.acquire() => locks.py line 355
I think this is a bug and that this behaviour is not the expected one.
--
components: asyncio
messages: 317604
nosy: asvetlov, christof, yselivanov
priority: normal
severity: normal
status: open
title: condition lock not re-acquired
type: behavior
versions: Python 3.6
___
Python tracker
<https://bugs.python.org/issue33638>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33638] condition lock not re-acquired
christof added the comment: In my previous comment, what I want to implement is not a timeout for a task to complete but more precisely a timeout triggered if the coroutine was not wake up by a notify on the condition. -- ___ Python tracker <https://bugs.python.org/issue33638> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5786] len(reversed([1,2,3])) does not work anymore in 2.6.2
Christof added the comment: A compatibility break in a minor bugfix version is never a good idea I guess. I understand the reasoning but this change may break quite a few packages (at least it broke mine). A workaround in programs is easy but for already released and deployed versions simply not possible. A change for Python 2.7 would be at least annoying too but I guess could be justified. Just my thoughts... -- ___ Python tracker <http://bugs.python.org/issue5786> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41354] filecmp.cmp documentation does not match actual code
Christof Hanke added the comment: Andrei, See https://bugs.python.org/issue42958 Someone else stumbled over this topic. Maybe you can merge these two requests? Otherwise, I'm fine with a new arg. Christof -- ___ Python tracker <https://bugs.python.org/issue41354> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42958] filecmp.cmp(shallow=True) isn't actually shallow when only mtime differs
Christof Hanke added the comment: Hi, this is also discussed in https://bugs.python.org/issue41354. Ciao, Christof -- nosy: +chanke ___ Python tracker <https://bugs.python.org/issue42958> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42958] filecmp.cmp(shallow=True) isn't actually shallow when only mtime differs
Christof Hanke added the comment: Hi Andrei, I would follow rsync. >From the man page: """ [...] -c, --checksum This changes the way rsync checks if the files have been changed and are in need of a transfer. Without this option, rsync uses a "quick check" that (by default) checks if each file’s size and time of last modification match between the sender and receiver. [...] """ so, yes you can have false positives with a shallow comparison of size + mtime only. But that's usually ok for e.g. incremental backups. Wow, the bug is that old... -- ___ Python tracker <https://bugs.python.org/issue42958> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42958] filecmp.cmp(shallow=True) isn't actually shallow when only mtime differs
Christof Hanke added the comment: Andrei, cmp is the deep-compare part of filecmp. I thought we were taking about the shallow one. Thus, - shallow like rsync "quick": size + mtime. - deep like cmp -- ___ Python tracker <https://bugs.python.org/issue42958> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41354] filecmp.cmp documentation does not match actual code
Christof Hanke added the comment: I understand that you are reluctant to change existing code. But for me as a sysadmin, the current behavior doesn't make sense for two reasons: * st.st_size is part of _sig. why would you do a deep compare if the two files have a different length ? * comparing thousands of files, a proper shallow-only compare is required, since it takes a long time to compare large files (especially when they are migrated to a tape-backend), so a silent-fallback to a deep-compare is not good. -- ___ Python tracker <https://bugs.python.org/issue41354> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41354] filecmp.cmp documentation does not match actual code
New submission from Christof Hanke : help(filecmp.cmp) says: """ cmp(f1, f2, shallow=True) Compare two files. Arguments: f1 -- First file name f2 -- Second file name shallow -- Just check stat signature (do not read the files). defaults to True. Return value: True if the files are the same, False otherwise. This function uses a cache for past comparisons and the results, with cache entries invalidated if their stat information changes. The cache may be cleared by calling clear_cache(). """ However, looking at the code, the shallow-argument is taken only into account if the signatures are the same: """ s1 = _sig(os.stat(f1)) s2 = _sig(os.stat(f2)) if s1[0] != stat.S_IFREG or s2[0] != stat.S_IFREG: return False if shallow and s1 == s2: return True if s1[1] != s2[1]: return False outcome = _cache.get((f1, f2, s1, s2)) if outcome is None: outcome = _do_cmp(f1, f2) if len(_cache) > 100: # limit the maximum size of the cache clear_cache() _cache[f1, f2, s1, s2] = outcome return outcome """ Therefore, if I call cmp with shallow=True and the stat-signatures differ, cmp actually does a "deep" compare. This "deep" compare however does not check the stat-signatures. Thus I propose follwing patch: cmp always checks the "full" signature. return True if shallow and above test passed. It does not make sense to me that when doing a "deep" compare, that only the size is compared, but not the mtime. --- filecmp.py.orig 2020-07-16 12:00:57.0 +0200 +++ filecmp.py 2020-07-16 12:00:30.0 +0200 @@ -52,10 +52,10 @@ s2 = _sig(os.stat(f2)) if s1[0] != stat.S_IFREG or s2[0] != stat.S_IFREG: return False -if shallow and s1 == s2: -return True -if s1[1] != s2[1]: +if s1 != s2: return False +if shallow: +return True outcome = _cache.get((f1, f2, s1, s2)) if outcome is None: -- components: Library (Lib) messages: 374054 nosy: chanke priority: normal severity: normal status: open title: filecmp.cmp documentation does not match actual code type: behavior ___ Python tracker <https://bugs.python.org/issue41354> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41354] filecmp.cmp documentation does not match actual code
Change by Christof Hanke : -- keywords: +patch pull_requests: +20722 stage: -> patch review pull_request: https://github.com/python/cpython/pull/21580 ___ Python tracker <https://bugs.python.org/issue41354> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26047] argparse.ArgumentError documentation wrong
New submission from Christof Hanke: On https://docs.python.org/2/library/argparse.html (and on those of the 3.6-Version) it says at the bottom: """ ArgumentParser.error(message) This method prints a usage message including the message to the standard error and terminates the program with a status code of 2. """ In fact, the returned staus code is 1. -- assignee: docs@python components: Documentation messages: 257745 nosy: Christof Hanke, docs@python priority: normal severity: normal status: open title: argparse.ArgumentError documentation wrong type: enhancement versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 ___ Python tracker <http://bugs.python.org/issue26047> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
