Change by Jason Fried :
--
resolution: -> fixed
___
Python tracker
<https://bugs.python.org/issue35767>
___
___
Python-bugs-list mailing list
Unsubscrib
Change by Jason Fried :
--
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue35767>
___
___
Pyth
Jason Fried added the comment:
Its not possible to have it both ways. Also it stinks too much of trying to
guess.
The root of your issue is you want a normal MagicMock not an AsyncMock. Its the
automatic behavior of patch to pick AsyncMock vs MagicMock that is the heart of
your issue
Change by Jason Fried :
--
keywords: +patch
pull_requests: +16762
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/17269
___
Python tracker
<https://bugs.python.org/issu
Change by Jason Fried :
--
keywords: +patch
pull_requests: +16761
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/17269
___
Python tracker
<https://bugs.python.org/issu
Change by Jason Fried :
--
type: -> behavior
___
Python tracker
<https://bugs.python.org/issue38857>
___
___
Python-bugs-list mailing list
Unsubscrib
New submission from Jason Fried :
If an AsyncMock uses a side_effect that is an Iterable, if called more than
items exist its suppose to raise StopIteration according to the docs but PEP
479 says that is impossible.
My Suggestion is that we update the docs and the code to Raise
New submission from Jason Fried :
If you are trying to use AsyncMock to mock a coroutine that returns awaitable
objects, AsyncMock awaits on those objects instead of returning them as is.
Example:
mock = AsyncMock(return_value=asyncio.Future())
v = await mock() # blocks on trying
Change by Jason Fried :
--
keywords: +patch
pull_requests: +16250
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/16667
___
Python tracker
<https://bugs.python.org/issu
New submission from Jason Fried :
The standard contextmanager decorator produces a wrapper that itself can be
used as a decorator
```
@contextmanager
def some_context():
...
yield
@some_context()
def some_function():
# we are inside a with some_context() now.
...
```
When
Jason Fried added the comment:
Yeah I have to agree at this point, from a naive point of view it looks
awesome, but its just as bad as loosing gil guarantees.
On Mon, Aug 26, 2019 at 03:04 Andrew Svetlov wrote:
>
> Andrew Svetlov added the comment:
>
> The solution pro
Change by Jason Fried :
--
keywords: +patch, patch, patch
pull_requests: +11316, 11317, 11318
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issu
Change by Jason Fried :
--
keywords: +patch
pull_requests: +11316
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue35767>
___
___
Py
Change by Jason Fried :
--
keywords: +patch, patch
pull_requests: +11316, 11317
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issu
Jason Fried added the comment:
working on a pull request
--
___
Python tracker
<https://bugs.python.org/issue35767>
___
___
Python-bugs-list mailing list
Unsub
Jason Fried added the comment:
Oh this is broken in 3.7 trunk
--
___
Python tracker
<https://bugs.python.org/issue35767>
___
___
Python-bugs-list mailin
New submission from Jason Fried :
https://github.com/python/cpython/blob/3.7/Lib/unittest/loader.py#L232
fullName = '%s.%s' % (testCaseClass.__module__, testFunc.__qualname__)
Instead we should probably replace testFunc.__qualname__ with attrname
I ran into this while running a test suite
New submission from Jason Fried :
Looking at the typing Module docs in the section for ByteString
This type represents the types bytes, bytearray, and memoryview.
But collections.abc.ByteString does not have memoryview registered.
Is it because memoryview doesn't support .index
Jason Fried <m...@jasonfried.info> added the comment:
For loops not supporting this throwing NotImplmentedError from the method to
enable reentrancy seems appropriate.
"You should convert all your stack to async functions..."
That may not be practical for large code bas
New submission from Jason Fried <m...@jasonfried.info>:
In 3.9 we can remove the deprecated pattern for accepting __enter__ and
__exit__ for locks. This will free up __await__ for Condition to use for
replacing .wait() which is wart from before awaitables.
My new proposed behavior is
Change by Jason Fried <m...@jasonfried.info>:
--
keywords: +patch
pull_requests: +6584
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Jason Fried <m...@jasonfried.info> added the comment:
Removed Condition from this request, because it has an __await__ method for
supporting the the deprecated pattern
with async cond:
I'll open a different bug, for Condition behavior for 3.9 when we can remove
the deprecated p
New submission from Jason Fried <m...@jasonfried.info>:
wait is a very overloaded word in asyncio. Events and Conditions are not
consistent with the rest of asyncio.
Why don't Future and Task have wait() methods? well because they are awaitable
Some subjective reasoning:
Every tim
Change by Jason Fried <m...@jasonfried.info>:
--
keywords: +patch
pull_requests: +6540
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Change by Jason Fried <m...@jasonfried.info>:
--
nosy: +lukasz.langa
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33523>
___
_
New submission from Jason Fried <m...@jasonfried.info>:
At Facebook and Instagram we have large interconnected codebases without clear
boundaries of ownership. As we move more and more services to utilize asyncio
we are finding that once blocking (but fast) code paths, are now cropp
Changes by Jason Fried <m...@jasonfried.info>:
--
pull_requests: +1825
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30395>
___
_
Changes by Jason Fried <m...@jasonfried.info>:
--
keywords: +patch
Added file: http://bugs.python.org/file43159/copybufsize.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
New submission from Jason Fried:
The default of 16k while good for memory usage it is not well suited for all
cases. if we increased this to 4MB we saw a pretty large improvement to tar
file creation and extraction on linux servers.
For a 1gb tar file containing 1024 random files each of 10MB
Jason Fried added the comment:
I ran this on Linux ext4. I didn't see much improvement on OSX with SSD.
--
Added file: http://bugs.python.org/file43139/test.py
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
New submission from Jason Fried:
With large tar file extracts I noticed that tarfile was slower than it should
be. Seems in linux that for large files (10MB) truncate is not always a free
operation even when it should be a no-op. ex: File is already 10mb seek to end
and truncate.
I created
31 matches
Mail list logo
