Vladimir Matveev added the comment:
- introducing dedicated opcodes for each kind of awaited call is definitely an
option. In fact first implementation used it however as Dino has mentioned it
was more of a logistical issue (there were several spots that produced .pyc
files so compiler
Change by Vladimir Matveev :
--
nosy: +v2m
___
Python tracker
<https://bugs.python.org/issue46965>
___
___
Python-bugs-list mailing list
Unsubscribe:
Vladimir Matveev added the comment:
Apologies for the delay in reply: in more concrete numbers for IG codebase
enabling this optimization resulted in 0.2% CPU win.
--
___
Python tracker
<https://bugs.python.org/issue43
Vladimir Matveev added the comment:
>Currently, super() is decoupled from the core language. It is just a builtin
>that provides customized attribute lookup. This PR makes super() more tightly
>integrated with the core language, treating it as if it were a keyword and
>part of
Change by Vladimir Matveev :
--
keywords: +patch
pull_requests: +23696
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/24936
___
Python tracker
<https://bugs.python.org/issu
New submission from Vladimir Matveev :
Calling methods and lookup up attributes when receiver is `super()` has extra
cost comparing to regular attribute lookup. It mainly comes from the need to
allocate and initialize the instance of the `super` which for zero argument
case also include
Change by Vladimir Matveev :
--
pull_requests: +22267
pull_request: https://github.com/python/cpython/pull/23374
___
Python tracker
<https://bugs.python.org/issue42
Change by Vladimir Matveev :
--
keywords: +patch
pull_requests: +21817
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/22875
___
Python tracker
<https://bugs.python.org/issu
New submission from Vladimir Matveev :
`TaskWakeupMethWrapper` looks like a more limited version of `PyCFunction` so
it can be replaced with one.
Pros: remove a bunch of code, use better calling convention
Cons: now `wakeup` object will expose slightly more properties but I'm not sure
whether
Change by Vladimir Matveev :
--
type: -> performance
___
Python tracker
<https://bugs.python.org/issue42085>
___
___
Python-bugs-list mailing list
Unsubscrib
Change by Vladimir Matveev :
--
keywords: +patch
pull_requests: +21739
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/22780
___
Python tracker
<https://bugs.python.org/issu
New submission from Vladimir Matveev :
https://bugs.python.org/issue41756 has introduced PyIter_Send as a common
entrypoint for sending values however currently fast path that does not use
StopIteration exception is only available for generators/coroutines. It would
be quite nice
Change by Vladimir Matveev :
--
pull_requests: +21649
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/22677
___
Python tracker
<https://bugs.python.org/issu
Change by Vladimir Matveev :
--
pull_requests: +21639
pull_request: https://github.com/python/cpython/pull/22663
___
Python tracker
<https://bugs.python.org/issue41
Change by Vladimir Matveev :
--
pull_requests: +21473
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/22443
___
Python tracker
<https://bugs.python.org/issu
Vladimir Matveev added the comment:
No, I don't think so but I can definitely make one. A few questions first:
- having PySendResult as a result type of PyIterSend seems ok, however prefix
for each concrete value (PYGEN_*) is not aligned with the prefix of the
function itself (PyIter_
Vladimir Matveev added the comment:
Serhiy, AFAIR PyIter_Send in my PR appear only as a rename from placeholder
`Name_TBD` and it still was specific to PyGenObjects. Do you mean something
that was listed in https://bugs.python.org/msg377007
Vladimir Matveev added the comment:
Yes, it should be
--
___
Python tracker
<https://bugs.python.org/issue41756>
___
___
Python-bugs-list mailing list
Unsub
Vladimir Matveev added the comment:
Sounds like a good middleground to start: add ``PySendResult `` and
`PySendResult PyGen_Send(PyGenObject*, PyObject* PyObject**)` specific to
generators and coroutines. Subsequent changes could introduce `PySendResult
PyIter_Send(PyObject*, PyObject
Vladimir Matveev added the comment:
so to summarize:
Proposed function signature:
```
PySendResult PyIter_Send(PyObject *obj, PyObject *arg, PyObject **result);
```
For generators/coroutines function will delegate to specialized implementation
that does not raise StopIteration exception
Vladimir Matveev added the comment:
I guess `PyIter_Send` would imply that this function should work for all inputs
(like in https://bugs.python.org/msg377007) which also sounds reasonable.
--
___
Python tracker
<https://bugs.python.
Vladimir Matveev added the comment:
Also should it be specific to generators/coroutines and accept PyGenObject* or
should it try to handle multiple cases and expose the result for them in
uniform way, i.e.
```
if (PyGen_CheckExact(gen) || PyCoro_CheckExact(gen)) {
// use coroutine
Vladimir Matveev added the comment:
If I understand proposed shape of API correctly - it was not supposed to return
exception via "result" so contract for new `PyGen_Send` function is something
like:
Return value | result
Change by Vladimir Matveev :
--
keywords: +patch
pull_requests: +21255
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/22196
___
Python tracker
<https://bugs.python.org/issu
New submission from Vladimir Matveev :
Currently async functions are more expensive to use comparing to their sync
counterparts. A simple microbenchmark shows that difference could be quite
significant:
```
import time
def f(a):
if a == 0:
return 0
return f(a - 1)
async def
Change by Vladimir Matveev :
--
keywords: +patch, patch
pull_requests: +10606, 10607
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issu
Change by Vladimir Matveev :
--
keywords: +patch, patch, patch
pull_requests: +10606, 10607, 10608
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issu
Change by Vladimir Matveev :
--
keywords: +patch
pull_requests: +10606
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue35568>
___
_
Change by Vladimir Matveev :
--
nosy: +v2m
___
Python tracker
<https://bugs.python.org/issue35568>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Vladimir Matveev :
--
keywords: +patch
pull_requests: +10488
stage: needs patch -> patch review
___
Python tracker
<https://bugs.python.org/issu
Vladimir Matveev added the comment:
I can give it a try.
--
nosy: +v2m
___
Python tracker
<https://bugs.python.org/issue14094>
___
___
Python-bugs-list mailin
Change by Vladimir Matveev :
--
keywords: +patch
pull_requests: +10371
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue31446>
___
_
Change by Vladimir Matveev :
--
keywords: +patch
pull_requests: +10367
stage: needs patch -> patch review
___
Python tracker
<https://bugs.python.org/issu
Change by Vladimir Matveev :
--
keywords: +patch
pull_requests: +10365
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue35306>
___
_
Change by Vladimir Matveev :
--
nosy: +v2m
___
Python tracker
<https://bugs.python.org/issue34872>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Vladimir Matveev :
--
pull_requests: +8843
___
Python tracker
<https://bugs.python.org/issue34603>
___
___
Python-bugs-list mailing list
Unsubscribe:
Vladimir Matveev added the comment:
somewhat shortened repro that fails with the same error on master:
```
import pandas
import numpy
now = pandas.Timestamp.now()
arr = numpy.array([ ['a', now] for i in range(0, 3)])
arr.sum(0)
```
--
nosy: +v2m
Change by Vladimir Matveev :
--
keywords: +patch
pull_requests: +8690
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue34603>
___
_
Vladimir Matveev added the comment:
I think the problem is that FFI layer assumes that MSVC compiler will try to
pass any structure less than 8 bytes in registers whereis it is not always
true:
To be returned by value in RAX, user-defined types must have a length of 1, 2,
4, 8, 16, 32
Vladimir Matveev added the comment:
In this particular case looks like a crux of the problem was in the fact that
compression encodes extra fields only if either zip64 is set or length of the
field is larger than threshold but decompression always tries to decode it.
Attached PR switches
Vladimir Matveev added the comment:
To bring in analogy: C# has lock statement that allow to run a block of code
holding a mutual-exclusion lock on some object.
```
lock(o)
{
}
```
is compiled as
```
object _lock = o;
bool _lockTaken = false;
try
{
System.Threading.Monitor.Enter(_lock
Vladimir Matveev added the comment:
I can repro it with a given sample file
```
vladima-mbp $ cat test.c
#include
#include
#include
#include
#include
int main() {
struct rlimit rl;
if(getrlimit(RLIMIT_STACK, ) < 0) {
perror("getrlimit");
exit(1);
}
Change by Vladimir Matveev :
--
pull_requests: +8561
___
Python tracker
<https://bugs.python.org/issue34606>
___
___
Python-bugs-list mailing list
Unsubscribe:
Vladimir Matveev added the comment:
file URI scheme is covered by RFC8089, specifically
https://tools.ietf.org/html/rfc8089#appendix-E.3.2.
--
nosy: +v2m
___
Python tracker
<https://bugs.python.org/issue34
Vladimir Matveev added the comment:
I agree. From code in threading.Condition.wait looks like if it is interrupted
either after calling _release_save and before entering try block or in finally
block before calling _acquire_restore - it will leave the lock in non-acquired
state.
First
Vladimir Matveev added the comment:
I've tried to repro this on Mac, Windows box and Windows VM - works fine for
all cases.
--
nosy: +v2m
___
Python tracker
<https://bugs.python.org/issue34
Change by Vladimir Matveev :
--
pull_requests: +8338
___
Python tracker
<https://bugs.python.org/issue6700>
___
___
Python-bugs-list mailing list
Unsubscribe:
47 matches
Mail list logo
