New submission from John Belmonte :
A case came up where I'd like a non-async context manager to be able to
decorate both regular and async functions. I wonder why
contextlib.ContextDecorator doesn't just support both cases.
The implementation seems straightforward, switching
John Belmonte added the comment:
PerfTimer is a reusable, non-reentrant context manager implemented as a class.
There are already use cases of ContextDecorator described in the contextlib
documentation, such as the track_entry_and_exit logger. What reason would you
have for such context
John Belmonte added the comment:
My use case is for a non-async context manager, and if we take
track_entry_and_exit as an example that's non-async as well.
The explicit approach (e.g. separate base class for decorators applied to sync
vs. async functions) doesn't seem ideal, because
John Belmonte added the comment:
I have a context manager used for timing sections of code or whole functions
(when used as a decorator). It's aware of the Trio async/await scheduler and
is able to exclude periods of time where the task is not executing. The
context manager itself
New submission from John Belmonte :
because "list.pop()"
use case: maintain large ordered list and efficiently remove min item
list.pop() is O(1) but yields the max item. There is no efficient removal of
the min item.
list is by far the fastest collection to use with insort(). W
John Belmonte added the comment:
I was caught by this again, indirectly via @contextmanager.
If I define a non-async context manager using @contextmanager, I expect the
decorator support to work on async functions. I.e. the following should be
equivalent:
```
async def foo
New submission from John Belmonte :
I would like Flag class instances to have more set-like abilities:
1. iteration, to walk through each set bit of the value
2. len corresponding to #1
3. subset operator
I may be told "implement it yourself as instance methods", or that #3 has
New submission from John Belmonte :
AsyncMock appears to be new in Python 3.8, but doc is missing info on when it
was introduced.
https://docs.python.org/3.8/library/unittest.mock.html#unittest.mock.AsyncMock
--
assignee: docs@python
components: Documentation
messages: 356290
nosy
John Belmonte added the comment:
yes, will do
--
___
Python tracker
<https://bugs.python.org/issue38753>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by John Belmonte :
--
keywords: +patch
pull_requests: +16608
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/17102
___
Python tracker
<https://bugs.python.org/issu
New submission from John Belmonte :
Please add aclosing() to contextlib, the async equivalent of closing().
It's needed to ensure deterministic call of aclose() on the resource object at
block exit.
It's been available in the async_generator module for some time. However that
module
Change by John Belmonte :
--
pull_requests: +21633
versions: +Python 3.10 -Python 3.9
pull_request: https://github.com/python/cpython/pull/21545
___
Python tracker
<https://bugs.python.org/issue40
John Belmonte added the comment:
I think https://github.com/python/cpython/pull/1 should be reverted
(considering the design issue, performance issue, and bugs), and lets have a
proper design and review.
While just reading the code, I found an existing bug in Flag. And the new
John Belmonte added the comment:
It's completely undocumented, but today I noticed that Flag.__contains__() is
actually a subset operation.
def __contains__(self, other):
...
return other._value_ & self._value_ == other._value_
It's an unfortunate departure
John Belmonte added the comment:
I agree that a bit and one-bit flag are the same.
> only 'x' was in 'xyz', not 'xy
I don't understand the comparison, because str 'a in b' tests if 'a' is a
subsequence of 'b'. It is not a subset operation ('xz' in 'xyz' is false).
I can underst
John Belmonte added the comment:
> Just a comment, (1) is analogous to str. iter('abc') gives only 'a', 'b' and
> 'c', while contains accepts '', 'ab', 'bc', and 'abc' too. At least in my
> mind, it's a pretty strong analogy.
I don't agree. The "zero" bit does n
Change by John Belmonte :
--
nosy: +jbelmonte
nosy_count: 4.0 -> 5.0
pull_requests: +21698
pull_request: https://github.com/python/cpython/pull/22734
___
Python tracker
<https://bugs.python.org/issu
Change by John Belmonte :
--
keywords: +patch
nosy: +jbelmonte
nosy_count: 9.0 -> 10.0
pull_requests: +21613
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/22640
___
Python tracker
<https://bugs.python.org/i
John Belmonte added the comment:
Part of this issue (#1) was intended to be addressed by
https://github.com/python/cpython/pull/1 which added an `__iter__`
implementation to Flag and IntFlag. (The PR did not reference this issue, and
was already merged last month.)
However that PR
John Belmonte added the comment:
Thank you heckad!
I'm in need of a decorating asynccontextmanager, and glad that an
implementation is in the works that I can copy from in the meantime.
I hope Yuri reviews the PR before long.
--
nosy: +John Belmonte
John Belmonte added the comment:
Given the lack of deterministic cleanup for iterators
(https://www.python.org/dev/peps/pep-0533/), aclosing() is the way to ensure
deterministic cleanup given any API using async iteration.
--
___
Python tracker
John Belmonte added the comment:
highlighting from PEP 533:
> Async generators cannot do cleanup at all without some mechanism for
> deterministic cleanup that people will actually use, and async generators are
> particularly likely to hold resources like file de
John Belmonte added the comment:
Adding this would be a nice compliment to aclosing(), which was already merged
for 3.10.
Otherwise, witness the ugliness of using aclosing() with an async iterable
object:
async with aclosing(foo.__aiter__()) as agen:
async for item in agen
John Belmonte added the comment:
merged for Python 3.10
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
John Belmonte added the comment:
I've opened a new PR, please review.
--
___
Python tracker
<https://bugs.python.org/issue42194>
___
___
Python-bugs-list mailin
John Belmonte added the comment:
A PR was opened over a year ago, but the author never signed CLA.
How can we proceed with this doc fix?
--
nosy: +John Belmonte
___
Python tracker
<https://bugs.python.org/issue42
Change by John Belmonte :
--
nosy: +jbelmonte
nosy_count: 6.0 -> 7.0
pull_requests: +24938
pull_request: https://github.com/python/cpython/pull/26348
___
Python tracker
<https://bugs.python.org/issu
John Belmonte added the comment:
I wonder if CONFORM could tolerate these, since it's ultimately going to
discard invalid bits. And then perhaps CONFORM is the default.
--
___
Python tracker
<https://bugs.python.org/issue44
John Belmonte added the comment:
Rather than make such masks containing unknown bits, this would be best
practice if you want to use STRICT, correct?
NPTS_ROUND = 0x0
NPTS_CEIL = 0x1
NPTS_TRUNC = 0x2
NPTS_MASK = NPTS_ROUND | NPTS_CEIL | NPTS_TRUNC
Otherwise, if your input may have unknown
John Belmonte added the comment:
> However, if the user is interfacing with other software/hardware, they may
> not have a choice on which bits make up the mask.
I think it's the same as saying "unknown bits may come on the input". An
important use case is for forward comp
John Belmonte added the comment:
> Do you agree that simply removing the unnamed member check that takes place
> at Flag creation is a good way forward?
It's uncomfortable, because then STRICT is not actually strict, and it's going
to be show raw values in str/repr.
> CONFORM -
John Belmonte added the comment:
To clarify, it's caused by these mask entries in the enum:
NPTS_MASK = 0xF
DEL_S_MASK = 0xF0
AZIS_MASK = 0xF00
Since the masks are not an aggregation of individual bits defined in the enum,
it's an error.
> I'm inclined to go with [removing the ch
John Belmonte added the comment:
> Either [...] we should lose the creation time check (not apply the
> transform), or we should still have the check (raise an error on invalid
> bits) which would still leave us in this situation.
That is only one option (which undesirable con
John Belmonte added the comment:
> bpo-40816 took the much simpler approach of introducing a separate
> contextlib.AsyncContextDecorator class
How do I apply AsyncContextDecorator to the use case of wrapping either a sync
or async function with a synchronous context m
John Belmonte added the comment:
To clarify the problem case, I believe the discrepancy is seen when raising
exceptions as follows:
exc = foo()
try:
raise exc
finally:
exc.__context__ = None
(From my understanding, Trio has valid use cases for doing this since it wants
to control
John Belmonte added the comment:
[reposting the example, with source]
example:
class MyException(Exception):
pass
@contextmanager
def my_cm():
try:
yield
except BaseException:
exc = MyException()
try:
raise exc
John Belmonte added the comment:
cc: ncoghlan for help with ExitStack exception context
--
nosy: +ncoghlan
___
Python tracker
<https://bugs.python.org/issue44
Change by John Belmonte :
--
keywords: +patch
nosy: +jbelmonte
nosy_count: 3.0 -> 4.0
pull_requests: +25637
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/27089
___
Python tracker
<https://bugs.python.org/i
John Belmonte added the comment:
demonstrating the difference for async case:
import contextlib
import trio
async def background():
assert False
async def main1():
async with trio.open_nursery() as nursery:
nursery.start_soon(background
New submission from John Belmonte :
Over at the Trio project, we have evidence that
`AsyncExitStack.enter_async_context(foo())` is not actually equivalent to
`async with foo()` regarding raised exception context.
The symptom is a very long, unhelpful tracebacks because the __context__
New submission from John Belmonte :
time.thread_time is supposed to be available on OS X 10.12 and newer.
Yet it's reported to raise ImportError on macOS Big Sur (11.2.1) on Python
3.9.2 (python.org download). (Reported by Quentin Pradet.)
It is available in other OS X Python builds
Change by John Belmonte :
--
type: -> behavior
versions: +Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issu
Change by John Belmonte :
--
pull_requests: +27078
pull_request: https://github.com/python/cpython/pull/28730
___
Python tracker
<https://bugs.python.org/issue44
Change by John Belmonte :
--
pull_requests: +27079
pull_request: https://github.com/python/cpython/pull/28731
___
Python tracker
<https://bugs.python.org/issue44
New submission from John Belmonte :
proposal: add a string formatting option to normalize negative 0 values to 0
use case: rounded display of a float that is nominally 0, where the
distraction of a flashing minus sign from minute changes around 0 is unwanted
example:
>>> '%~5.1f'
John Belmonte added the comment:
> To normalize negative 0.0 to 0.0 you can just add 0.0.
yes, I'm aware-- see "implementation" in the original post
> there is no need to change all formatting specifications
For adding 0 to work, it must be done after the rounding. That me
John Belmonte added the comment:
Here is the same proposal made for C++ `std::format`:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1496r2.pdf
It makes fair arguments for the feature's use, and explains why the problem is
hard to work around.
It was withdrawn by the author
John Belmonte added the comment:
I'll share a draft PR soon (excluding Decimal), so far it's still looking
straightforward.
> Maybe old versions would correctly ignore the new bit being set.
That's one of the benefits of using bit flags in an ABI: backward-compatible
extensibil
John Belmonte added the comment:
> For Decimal, we'd need to "own" the string formatting, taking that
> responsibility away from mpdecimal, but there are already other reasons to do
> that.
After some digging, I believe this is the background on forking pieces of
John Belmonte added the comment:
potential short-term solution for Decimal:
if negative zero option is set and sign is negative:
pre-round into a temp using mpd_qrescale()
if mpd_iszero(temp):
change sign to positive
Change by John Belmonte :
--
keywords: +patch
nosy: +jbelmonte
nosy_count: 5.0 -> 6.0
pull_requests: +28274
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/30049
___
Python tracker
<https://bugs.python.org/i
John Belmonte added the comment:
implemented float and Decimal-- PR is ready for review
--
___
Python tracker
<https://bugs.python.org/issue45995>
___
___
Pytho
John Belmonte added the comment:
> changing %-formatting doesn't seem viable
I'm concerned about treating %-formatting specially. As far as float/complex,
the logical and efficient place to put this change seems to be
PyOS_double_to_string(), which affects all three formatting opti
John Belmonte added the comment:
I see now. PyOS_double_to_string() could gain the extra flag to coerce
negative zero but, out of the three formatting methods, only format() and
f-string would use the flag.
--
___
Python tracker
<ht
John Belmonte added the comment:
PEP at https://github.com/python/peps/pull/2295
--
___
Python tracker
<https://bugs.python.org/issue45995>
___
___
Python-bug
John Belmonte added the comment:
Mark, would you give it a review this month? (PR has been marked stale.)
--
___
Python tracker
<https://bugs.python.org/issue45
John Belmonte added the comment:
Thank you Mark and Eric.
> I'll note that the paper is proposing a 'z' modifier to the sign, so I guess
> for us that would translate to: [sign[optional-z]] instead of just sign. I'd
> have to noodle through the differences between that the propo
57 matches
Mail list logo
