2016-12-21 2:52 GMT+01:00 Steve Dower :
> _PyBytes_DecodeEscape
> _PyDebug_PrintTotalRefs
> _PyThreadState_Current
> _PyTrash_thread_deposit_object
> _PyTrash_thread_destroy_chain
> _PyUnicode_DecodeUnicodeEscape
> _Py_AddToAllObjects
> _Py_ForgetReference
> _Py_GetRefTotal
> _Py_HashSecret_Initial
On 21.12.16 11:50, Victor Stinner wrote:
2016-12-21 2:52 GMT+01:00 Steve Dower :
_PyBytes_DecodeEscape
_PyDebug_PrintTotalRefs
_PyThreadState_Current
_PyTrash_thread_deposit_object
_PyTrash_thread_destroy_chain
_PyUnicode_DecodeUnicodeEscape
_Py_AddToAllObjects
_Py_ForgetReference
_Py_GetRefTota
2016-12-21 14:06 GMT+01:00 Serhiy Storchaka :
>> These functions are private. Would it be possible to not export them?
>
> Private functions used in public macros (like _Py_NewReference) should be
> exported.
Ah, _Py_NewReference is used in the PyObject_INIT(op, typeobj) *macro*, right.
IMO it's
Three months ago we discussed about an issue with PySlice_GetIndicesEx().
(https://mail.python.org/pipermail/python-dev/2016-August/145901.html)
The problem was that PySlice_GetIndicesEx() takes the size of the
sequence, but the size of the sequence can be changed when call custom
__index__() m
"Ok, now why should _Py_PrintReferences() function be exported?"
It probably shouldn't, but it needs an #ifndef Py_LIMITED_API check so it is
excluded from the headers (my list was automatically generated).
And ideally, private functions that are deliberately exported would have
comments, or if
On 21.12.16 17:41, Steve Dower wrote:
"Ok, now why should _Py_PrintReferences() function be exported?"
It probably shouldn't, but it needs an #ifndef Py_LIMITED_API check so
it is excluded from the headers (my list was automatically generated).
And ideally, private functions that are deliberate
On Dec 21, 2016 7:43 AM, "Steve Dower" wrote:
"Ok, now why should _Py_PrintReferences() function be exported?"
It probably shouldn't, but it needs an #ifndef Py_LIMITED_API check so it
is excluded from the headers (my list was automatically generated).
It sounds like the opt-out approach isn't
2016-12-21 17:21 GMT+01:00 Nathaniel Smith :
> It sounds like the opt-out approach isn't working very well, and maybe an
> opt-in approach should be considered instead? I recognize that the way C
> headers work makes this difficult, but it seems like something needs to
> change.
I proposed somethi
"maybe the test suite should error out if any unexpected symbols appear in the
stable ABI?"
This or on build (personally I prefer this sort of validation at build time,
but I know others would prefer to defer it).
We have a script now that can extract all the right functions, though I think
it
There's a difference between "private", "stable for 3.x" and "stable for all 3"
though. It's the third category that's getting too many functions added without
due consideration.
Top-posted from my Windows Phone
-Original Message-
From: "Victor Stinner"
Sent: 12/21/2016 8:40
To: "Na
On Wed, 21 Dec 2016 at 06:52 Serhiy Storchaka wrote:
> [SNIP]
> Let's start bikeshedding. What are your ideas about names and the order
> of arguments of two following functions?
>
> 1. Takes a slice object, returns it's start, stop and step as Py_ssize_t
> values. Can fail.
>
start, stop, step
11 matches
Mail list logo