Re: [Python-Dev] Procedure for adding new public C API
Thanks Serhiy, I missed adding PyThread_tss_* to Doc/data/refcounts.dat. I opened a PR to fix it. https://github.com/python/cpython/pull/7038 Regards, Masayuki 2018-05-21 21:41 GMT+09:00 Serhiy Storchaka: > Please don't forgot to perform the following steps when add a new public > C API: > > * Document it in Doc/c-api/. > > * Add an entry in the What's New document. > > * Add it in Doc/data/refcounts.dat. > > * Add it in PC/python3.def. > > If you want to include it in the limited API, wrap its declaration with: > >#if !defined(Py_LIMITED_API) || Py_LIMITED_API+0 >= 0x0308 >#endif > > (use the correct Python version of introducing a feature in the comparison) > > If you don't want to include it in the limited API, wrap its declaration > with: > >#ifndef Py_LIMITED_API >#endif > > You are free of adding private C API, but its name should start with _Py > or _PY and its declaration should be wrapped with: > >#ifndef Py_LIMITED_API >#endif > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ma3yuki. > 8mamo10%40gmail.com > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] My fork lacks a 3.7 branch - can I create it somehow?
On Tue, May 22, 2018 at 10:45 AM, Skip Montanarowrote: >> Create it from upstream? Yep! Try this: > >> git checkout -b 3.7 upstream/3.7 >> git push -u origin 3.7 > > Thanks, Chris! Didn't have to chug for too long either, just a few seconds. > > S Perfect! I'm used to doing this sort of thing with long histories that need to be synchronized, so there can be minutes of uploading. But I guess here "3.7" is very close to "master", so there's not as much to sync. Even easier! :) ChrisA ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] My fork lacks a 3.7 branch - can I create it somehow?
> Create it from upstream? Yep! Try this: > git checkout -b 3.7 upstream/3.7 > git push -u origin 3.7 Thanks, Chris! Didn't have to chug for too long either, just a few seconds. S ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] My fork lacks a 3.7 branch - can I create it somehow?
On Tue, May 22, 2018 at 10:07 AM, Skip Montanarowrote: > My GitHub fork of the cpython repo was made awhile ago, before a 3.7 branch > was created. I have no remotes/origin/3.7. Is there some way to create it > from remotes/upstream/3.7? I asked on GitHub's help forums. The only > recommendation was to to delete my fork and recreate it. That seemed kind > of drastic, and I will do it if that's really the only way, but this seems > like functionality Git and/or GitHub probably supports. > Create it from upstream? Yep! Try this: git checkout -b 3.7 upstream/3.7 git push -u origin 3.7 That'll probably have to chug-chug-chug to push all that content up to GitHub; AFAIK they don't have any optimization for "this commit already exists in another fork of this repository", so you'll have to upload everything as if it's completely new. But other than that, it should be quick and easy. ChrisA ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "make test" routinely fails to terminate
me> On the 3.7 branch, "make test" routinely fails to terminate. Antoine> Can you try to rebuild Python? Use "make distclean" if that helps. Thanks, Antoine. That solved the termination problem. I still have problems with test_asyncio failing, but I can live with that for now. If "make distclean" is required, I suspect there is a missing/incorrect/incomplete Make dependency somewhere. I suppose "make distclean" is cheap enough that I should do it whenever I switch branches. Skip ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] My fork lacks a 3.7 branch - can I create it somehow?
My GitHub fork of the cpython repo was made awhile ago, before a 3.7 branch was created. I have no remotes/origin/3.7. Is there some way to create it from remotes/upstream/3.7? I asked on GitHub's help forums. The only recommendation was to to delete my fork and recreate it. That seemed kind of drastic, and I will do it if that's really the only way, but this seems like functionality Git and/or GitHub probably supports. Thx, Skip ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Procedure for adding new public C API
On 21 May 2018 at 14:42, Serhiy Storchakawrote: >> Is it even acceptable to add a symbol into the limited ABI? I thought >> the idea was that if I linked with python3.dll, my code would work >> with any version of Python 3? By introducing new symbols, code linked >> with the python3.dll shipped with (say) Python 3.8 would fail to run >> if executed with the python3.dll from Python 3.5. > > The limited API is versioned. If you use only Python 3.5 API (define > Py_LIMITED_API to 0x0305), the built code will be expected to work on > 3.5 and later. In theory. Thanks, I'd missed that point (I need to go and check my build process, in that case :-)). Paul ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Procedure for adding new public C API
21.05.18 16:27, Paul Moore пише: On 21 May 2018 at 13:41, Serhiy Storchakawrote: * Add it in PC/python3.def. I thought python3.def should only contain symbols in the limited ABI (it defines the API of python3.dll, doesn't it?) Thank you for correction. Yes, and only for Windows. New API implemented as macros shouldn't be included here, but if it uses some new functions, they should be included. If you want to include it in the limited API, wrap its declaration with: #if !defined(Py_LIMITED_API) || Py_LIMITED_API+0 >= 0x0308 #endif (use the correct Python version of introducing a feature in the comparison) If you don't want to include it in the limited API, wrap its declaration with: #ifndef Py_LIMITED_API #endif Is it even acceptable to add a symbol into the limited ABI? I thought the idea was that if I linked with python3.dll, my code would work with any version of Python 3? By introducing new symbols, code linked with the python3.dll shipped with (say) Python 3.8 would fail to run if executed with the python3.dll from Python 3.5. The limited API is versioned. If you use only Python 3.5 API (define Py_LIMITED_API to 0x0305), the built code will be expected to work on 3.5 and later. In theory. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Procedure for adding new public C API
On 21 May 2018 at 13:41, Serhiy Storchakawrote: > Please don't forgot to perform the following steps when add a new public C > API: > > * Document it in Doc/c-api/. > > * Add an entry in the What's New document. > > * Add it in Doc/data/refcounts.dat. > > * Add it in PC/python3.def. I thought python3.def should only contain symbols in the limited ABI (it defines the API of python3.dll, doesn't it?) > If you want to include it in the limited API, wrap its declaration with: > >#if !defined(Py_LIMITED_API) || Py_LIMITED_API+0 >= 0x0308 >#endif > > (use the correct Python version of introducing a feature in the comparison) > > If you don't want to include it in the limited API, wrap its declaration > with: > >#ifndef Py_LIMITED_API >#endif Is it even acceptable to add a symbol into the limited ABI? I thought the idea was that if I linked with python3.dll, my code would work with any version of Python 3? By introducing new symbols, code linked with the python3.dll shipped with (say) Python 3.8 would fail to run if executed with the python3.dll from Python 3.5. I have code that links with python3.dll, which is expected to run with any version of Python 3, so this isn't theoretical. (I'm not 100% sure whether, if I build with a Python 3.5 version of the headers, my code will link with a python3.dll with extra symbols - but even if that's the case, requiring cross-version binaries to be built with the oldest version of Python that they support seems restrictive at best. > You are free of adding private C API, but its name should start with _Py or > _PY and its declaration should be wrapped with: > >#ifndef Py_LIMITED_API >#endif Paul ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Procedure for adding new public C API
On May 21, 2018, at 08:41, Serhiy Storchakawrote: > Please don't forgot to perform the following steps when add a new public C > API: > [...] Perhaps this should be added to the Python Developer's Guide? -- Ned Deily n...@python.org -- [] ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Procedure for adding new public C API
Please don't forgot to perform the following steps when add a new public C API: * Document it in Doc/c-api/. * Add an entry in the What's New document. * Add it in Doc/data/refcounts.dat. * Add it in PC/python3.def. If you want to include it in the limited API, wrap its declaration with: #if !defined(Py_LIMITED_API) || Py_LIMITED_API+0 >= 0x0308 #endif (use the correct Python version of introducing a feature in the comparison) If you don't want to include it in the limited API, wrap its declaration with: #ifndef Py_LIMITED_API #endif You are free of adding private C API, but its name should start with _Py or _PY and its declaration should be wrapped with: #ifndef Py_LIMITED_API #endif ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com