Le ven. 3 mai 2019 à 17:47, Jeroen Demeyer a écrit :
>
> On 2019-05-03 14:24, Victor Stinner wrote:
> > Hi Srinivas,
> >
> > I merged your obvious doc fix, thanks.
>
> Can you please do the same for
> https://github.com/python/cpython/pull/12784
This PR is modying critical code (signal). I don't
Le ven. 3 mai 2019 à 17:47, Jeroen Demeyer a écrit :
> On 2019-05-03 14:24, Victor Stinner wrote:
> > Hi Srinivas,
> >
> > I merged your obvious doc fix, thanks.
>
> Can you please do the same for
>
> https://github.com/python/cpython/pull/12784
This PR is modying critical change. I don't have th
Hi,
Le mer. 8 mai 2019 à 16:10, Mark Shannon a écrit :
> How do I redo a failed PR check?
> The appveyor failure for https://github.com/python/cpython/pull/13181
> appears to be spurious, but there is no obvious way to redo it.
First, please make sure that a test failure is known in the bug
trac
This is only "only" for dateutil in the sense that no one other than
dateutil implements tzinfo with the interface provided. If dateutil were
/not/ already implemented with a list of offsets and their indexes, I
would still propose this, and just re-write dateutil to take advantage
of it. From a cu
Hi Paul,
The change is basically an optimization. I'm uncomfortable to design
it "only" for dateutil. What if tomorrow someone has to store an
arbitrary Python object, rather than just an integer (in range [0;
254]), into a datetime for a different optimization?
Moreover, I dislike adding a *publ
On 5/9/19 5:33 PM, Jeroen Demeyer wrote:
On 2019-05-09 20:30, Petr Viktorin wrote:
The underlying C function should not need to know how to extract
"self" from the function object, or how to handle the argument
offsetting.
Those should be implementation details.
Maybe you misunderstood my prop
On 2019-05-09 20:30, Petr Viktorin wrote:
But, if you apply the robustness principle to vectorcallfunc, it
should accept empty tuples.
Sure, if the callee wants to accept empty tuples anyway, it can do that.
That's the robustness principle. But us *forcing* the callee to accept
empty tuples i
On 2019-05-09 20:30, Petr Viktorin wrote:
The underlying C function should not need to know how to extract
"self" from the function object, or how to handle the argument
offsetting.
Those should be implementation details.
Maybe you misunderstood my proposal. I want to allow both for extra
flex
On 2019-05-09 23:09, Brett Cannon wrote:
Any reason the above are all "Vectorcall" and not "VectorCall"? You seem
to potentially have that capitalization for "PyCall_MakeVectorCall" as
mentioned below which seems to be asking for typos if there's going to
be two ways to do it. :)
"PyCall_MakeVe
On 2019-05-09 20:30, Petr Viktorin wrote:
### Making things private
For Python 3.8, the public API should be private, so the API can get
some contact with the real world. I'd especially like to be able to
learn from
Cython's experience using it.
That would mean:
* _PyObject_Vectorcall
* _PyCall
On Thu, May 9, 2019 at 11:31 AM Petr Viktorin wrote:
> PEP 590 is on its way to be accepted, with some details still to be
> discussed. I've rejected PEP 580 so we can focus on one place.
>
> Here are things we discussed on GitHub but now seem to agree on:
>
> * The vectorcall function's kwname a
PEP 590 is on its way to be accepted, with some details still to be
discussed. I've rejected PEP 580 so we can focus on one place.
Here are things we discussed on GitHub but now seem to agree on:
* The vectorcall function's kwname argument can be NULL.
* Let's use `vectorcallfunc`, not `vectorcal
Hello Python Dev team!
I submitted a Bug+PR back in February and unfortunately, nobody has given
it a review yet. :/
I'm was hoping that someone could take a look and suggest changes (if
needed). I realize that there are a ton of PRs and things to review across
the board, but here's to hoping som
13 matches
Mail list logo
