Message298265
| Author |
scoder |
| Recipients |
Tim.Graham, rhettinger, scoder, serhiy.storchaka, skrah, vstinner |
| Date |
2017年07月13日.06:28:22 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1499927302.99.0.51198417121.issue29464@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
> Are all uses of internal CPython details optional?
Well, what classifies as a "CPython detail" sometimes just becomes clear when other implementations don't have it. ;-)
But yes, the C code that Cython generates selects alternative implementations based on some more or less generic C defines, e.g. CYTHON_COMPILING_IN_CPYTHON or CYTHON_USE_PYLONG_INTERNALS or CYTHON_ASSUME_SAFE_MACROS. We enable them based on the Python implementation and even users can disable them at need. Well, and then there are obviously tons of PY_VERSION_HEX specific special cases, such as this one.
> I would disable them by default for alpha versions of CPython.
I don't see why. We track the CPython development via travis-CI and alpha versions make us aware of changes that we need to incorporate (or sometimes fight against ;-) ). These internals very rarely change across CPython releases (e.g. the PyLong type didn't really change since 3.0/2.7.0), and this one is really an exception. Excluding alpha versions would probably reduce our response time to these changes. |
|