On Fri, Nov 2, 2018 at 1:02 PM Victor Stinner wrote:
>
> Le ven. 2 nov. 2018 à 18:32, Neil Schemenauer a
> écrit :
> > A simple approach would be to introduce something like
> > Python-internal.h. If you are a Python internal unit, you can
> > include both Python.h and Python-internal.h. We
Le ven. 2 nov. 2018 à 18:32, Neil Schemenauer a écrit :
> A simple approach would be to introduce something like
> Python-internal.h. If you are a Python internal unit, you can
> include both Python.h and Python-internal.h. We could, over time,
> split Python-iternal.h into smaller modular
On 2018-10-28, Benjamin Peterson wrote:
> I don't think more or less API should be magically included based
> on whether Py_BUILD_CORE is defined or not.
I agree.
> If we want to have private headers, we should include them where
> needed and not install them. Really, Py_BUILD_CORE should go
Le jeu. 1 nov. 2018 à 16:38, Steve Dower a écrit :
> I assume the redundancy was there to handle the naming collision
> problem, but a better way to do that is to have only header files that
> users should ever use in "include/", and put the rest inside
> "include/python/" and "include/internal/"
I assume the redundancy was there to handle the naming collision
problem, but a better way to do that is to have only header files that
users should ever use in "include/", and put the rest inside
"include/python/" and "include/internal/" (and if possible, we don't
distribute the internal
I pushed many changes. I moved most of the Py_BUILD_CORE code out of
Include/ header files.
Le jeu. 1 nov. 2018 à 02:35, Eric Snow a écrit :
> On the one hand dropping redundancy in the filename is fine. On the other
> having the names mirror the public header files is valuable.
Current
On the one hand dropping redundancy in the filename is fine. On the other
having the names mirror the public header files is valuable. How about
leaving the base names alone and change the directory to "pyinternal"?
-eric
On Wed, Oct 31, 2018, 17:36 Victor Stinner Ok, thanks. I decided to
Ok, thanks. I decided to remove the redundant "py", so I renamed
"pystate.h" to "pycore_state.h" (single "py", instead of
"pycore_pystate.h", double "py py").
I updated my PR:
https://github.com/python/cpython/pull/10263
* Rename Include/internal/ header files:
* pyatomic.h -> pycore_atomic.h
B
On Wed, Oct 31, 2018 at 4:28 PM Victor Stinner wrote:
>
> Le mer. 31 oct. 2018 à 22:19, Eric Snow a écrit
> :
> > > Maybe we can keep "Include/internal/" directory name, but add
> > > "pycore_" rather than "internal_" to header filenames?
> >
> > this sounds good to me. thanks for chasing
Le mer. 31 oct. 2018 à 22:19, Eric Snow a écrit :
> > Maybe we can keep "Include/internal/" directory name, but add
> > "pycore_" rather than "internal_" to header filenames?
>
> this sounds good to me. thanks for chasing this down.
What do you prefer?
(A Include/internal/internal_pystate.h
On Wed, Oct 31, 2018 at 2:05 PM Victor Stinner wrote:
>
> Le mer. 31 oct. 2018 à 20:40, Eric Snow a écrit
> :
> > On Mon, Oct 29, 2018 at 6:39 AM Victor Stinner wrote:
> > > Le lun. 29 oct. 2018 à 06:32, Benjamin Peterson a
> > > écrit :
> > > > How does the current Include/internal/
On Wed, Oct 31, 2018 at 1:57 PM Victor Stinner wrote:
>
> Ok, I proposed to rename internal header files, add an "internal_"
> prefix, to avoid this issue:
> https://github.com/python/cpython/pull/10263
>
> My PR also adds Include/internal/ to search paths of header files.
>
> Extract of the
Le mer. 31 oct. 2018 à 20:40, Eric Snow a écrit :
> On Mon, Oct 29, 2018 at 6:39 AM Victor Stinner wrote:
> > Le lun. 29 oct. 2018 à 06:32, Benjamin Peterson a
> > écrit :
> > > How does the current Include/internal/ directory fail at accomplishing
> > > your goal?
> >
> > Hum, let me
Ok, I proposed to rename internal header files, add an "internal_"
prefix, to avoid this issue:
https://github.com/python/cpython/pull/10263
My PR also adds Include/internal/ to search paths of header files.
Extract of the change:
diff --git a/Include/internal/pystate.h
On Mon, Oct 29, 2018 at 6:39 AM Victor Stinner wrote:
> Le lun. 29 oct. 2018 à 06:32, Benjamin Peterson a écrit
> :
> > How does the current Include/internal/ directory fail at accomplishing your
> > goal?
>
> Hum, let me understand how I came into this issue. I tried to convert
>
Le mer. 31 oct. 2018 à 19:22, Eric Snow a écrit :
> > I propose a practical solution for that: Include/*.h files would only
> > be be public API.
>
> As we've already discussed, I'm entirely in favor of this. :) In
> fact, I was thinking along those same lines when I originally created
>
On Sun, Oct 28, 2018 at 10:20 AM Victor Stinner wrote:
> Python C API has no strict separation between the 3 levels of API:
>
> * core: Py_BUILD_CORE define
> * stable: Py_LIMITED_API define (it has a value)
> * regular: no define
>
> IMHO the current design of header files is done backward: by
Le mar. 30 oct. 2018 à 02:59, Benjamin Peterson a écrit :
> > To me, it seems wrong that a function or macro defined in
> > Include/objimpl.h requires an explicit #include "internal/pystate.h".
> > objimpl.h should be self-sufficient.
>
> I agree. I would say nothing in Include/*.h should be
On Mon, Oct 29, 2018, at 05:38, Victor Stinner wrote:
> Le lun. 29 oct. 2018 à 06:32, Benjamin Peterson a écrit
> :
> > > My overall approach is to make sure that we don't leak functions by
> > > mistakes into the public API or into the stable API anymore. For
> > > example, if a function is
My short comment: +1
My longer comment: for someone who is not trying to be caught up in "internals"
I find it extremely difficult to work with the "default" approach described
below - trying to mentally understand, and remember what those macros mean/do
as I got "bug-hunting".
Ultimately,
Le lun. 29 oct. 2018 à 06:32, Benjamin Peterson a écrit :
> > My overall approach is to make sure that we don't leak functions by
> > mistakes into the public API or into the stable API anymore. For
> > example, if a function is really for the core, put it in pycore/. It
> > will be more explicit
On Sun, Oct 28, 2018, at 14:30, Victor Stinner wrote:
> Le dim. 28 oct. 2018 à 21:50, Benjamin Peterson a écrit
> :
> > I don't think more or less API should be magically included based on
> > whether Py_BUILD_CORE is defined or not. If we want to have private
> > headers, we should include
Le dim. 28 oct. 2018 à 21:50, Benjamin Peterson a écrit :
> I don't think more or less API should be magically included based on whether
> Py_BUILD_CORE is defined or not. If we want to have private headers, we
> should include them where needed and not install them. Really, Py_BUILD_CORE
>
On Sun, Oct 28, 2018, at 09:20, Victor Stinner wrote:
> Hi,
>
> Python C API has no strict separation between the 3 levels of API:
>
> * core: Py_BUILD_CORE define
> * stable: Py_LIMITED_API define (it has a value)
> * regular: no define
>
> IMHO the current design of header files is done
Oh, I forgot to add a reference to the bugs.python.org issue and my
pull request!
* https://bugs.python.org/issue35081
* https://github.com/python/cpython/pull/10143
My PR more or less implements the first milestone of my plan
(Py_BUILD_CORE): it creates Include/pycore/.
Victor
Le dim. 28 oct.
Hi,
Python C API has no strict separation between the 3 levels of API:
* core: Py_BUILD_CORE define
* stable: Py_LIMITED_API define (it has a value)
* regular: no define
IMHO the current design of header files is done backward: by default,
everything is public. To exclude an API from core or
26 matches
Mail list logo
