Le 02/07/2019 à 06:35, Inada Naoki a écrit :
I wanted to discuss about only when PyAPI_FUNC() is needed,
not about which function should be public.
On Unix, PyAPI_FUNC() or extern is basically the same currently:
#define PyAPI_FUNC(RTYPE) RTYPE
#define PyAPI_DATA(RTYPE) extern RTYPE
On
On Sun, Jun 30, 2019 at 12:26 AM Nick Coghlan wrote:
>
>
> Hence Jeroen's point: if something is useful enough for Cython to want to use
> it, it makes to provide a public API for it that hides any internal
> implementation details that may not remain stable across releases.
>
I wanted to
On Fri., 14 Jun. 2019, 2:05 am Steve Dower, wrote:
> 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
On 2019-06-13 18:03, Inada Naoki wrote:
We don't provide method calling API which uses optimization same to
LOAD_METHOD. Which may be like this:
/* methname is Unicode, nargs > 0, and args[0] is self. */
PyObject_VectorCallMethod(PyObject *methname, PyObject **args,
Py_ssize_t nargs, PyObject
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 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:
*
12 matches
Mail list logo
