On Thu, 13 Jun 2019 22:05:01 +0900
Inada Naoki wrote:
>
> Currently, many private APIs uses `PyAPI_FUNC()`.
It's easier to use PyAPI_FUNC() everywhere than forget it in some
places and then bother Windows users.
Private APIs are sometimes used in third-party modules if they want
access to
On Thu, 13 Jun 2019 02:07:54 +0200
Victor Stinner wrote:
>
> For PyCodeOptions: does it contain posonlyargcount? If not, how do you
> pass posonlyargcount. I'm not sure if you plan to handle the backward
> compatibility.
The idiom to use it could be:
PyCodeOptions opts = PyCodeOptions_INIT;
//
There were some easy issues assigned to me, that were set aside for the
mentored sprint.
They can be worked on by new contributors during the Euro Python sprint.
ᐧ
On Thu, Jun 13, 2019 at 9:37 AM Steve Dower wrote:
> Hi all
>
> Just letting everyone know that I signed up any core devs who are
Hi all
Just letting everyone know that I signed up any core devs who are going
to be at EuroPython to run sprints :) (including myself, since I'll be
there)
Like PyCon US, the sprints at EuroPython will attract many first-time
contributors, so it will be helpful to have as many people who
On Fri, Jun 14, 2019 at 12:29 AM Jeroen Demeyer wrote:
>
>
> I think that the opposite is true actually: the reason that people
> access internals is because there is no public API doing what they want.
> Having more public API should *reduce* the need for accessing internals.
>
> For example,
On 13Jun2019 0816, Jeroen Demeyer wrote:
On 2019-06-13 17:11, Steve Dower wrote:
The cost of that convenience is that
we can never optimise internals because they are now public API.
I think that the opposite is true actually: the reason that people
access internals is because there is no
On 2019-06-13 17:11, Steve Dower wrote:
The cost of that convenience is that
we can never optimise internals because they are now public API.
I think that the opposite is true actually: the reason that people
access internals is because there is no public API doing what they want.
Having
On 13Jun2019 0643, Jeroen Demeyer wrote:
On 2019-06-13 15:36, Victor Stinner wrote:
The main risk is that people start to use it
If people use it, it should be taken as a sign that the function is
useful and deserves to be public API.
If it's useful, then someone can write a justification
On Thu, Jun 13, 2019 at 10:37 PM Victor Stinner wrote:
>
> Python 3.8 now has a better separation between "private" and "internal"
> APIs:
>
> * private are "_Py" symbols which are exported in the python DLL: they
> should not be used, but can be used techically
>
> * internal are symbols defined
On 2019-06-13 15:36, Victor Stinner wrote:
The main risk is that people start to use it
If people use it, it should be taken as a sign that the function is
useful and deserves to be public API.
___
Python-Dev mailing list -- python-dev@python.org
Hi,
Le 13/06/2019 à 15:05, Inada Naoki a écrit :
Some functions in cpython are private. These APIs
are called from only python executable or DLL.
They are not called even from extension modules in stdlib.
Python 3.8 now has a better separation between "private" and "internal"
APIs:
*
Hi, all.
Some functions in cpython are private. These APIs
are called from only python executable or DLL.
They are not called even from extension modules in stdlib.
In this time, I want to keep _PyObject_GetMethod private.
https://github.com/python/cpython/pull/14015#discussion_r293351734
As
On 2019-06-13 14:21, Victor Stinner wrote:
We may deprecate it and document that VECTORCALL should be
preferred.
Not really. Vectorcall and METH_FASTCALL solve different problems on
different levels.
METH_FASTCALL is used specifically in PythonMethodDef, in other words
for instances of
Hi Jeroen,
My initial plan was to hide it to ensure that nobody uses it, wait until
the code and the API is battle-tested, and then propose a public API. I
was a good idea to not make it public in the first place, since Python
3.7 modified FASTCALL deeply to not include keyword parameters by
Le 16/05/2019 à 23:12, Pablo Galindo Salgado a écrit :
> I propose to remove the current parser module and expose pgen2 as a
> standard library module.
As a first step, I created https://bugs.python.org/issue37268 to propose
to deprecate the parser module already in Python 3.8.
Victor
Hello,
has the time come to document METH_FASTCALL? This was introduced in
Python 3.6 for positional arguments only and extended in Python 3.7 to
support also keyword arguments. No changes have been made since then.
The vectorcall protocol (PEP 590) uses a calling convention based on
16 matches
Mail list logo
