19.11.17 04:17, Nick Coghlan пише:
1. Breaking calling Py_DecodeLocale() before calling Py_Initialize()
is a compatibility break with the API implied by our own usage
examples, and we'll need to revert the breakage for 3.7, and ensure at
least one release's worth of DeprecationWarning before requ
On 19 November 2017 at 17:22, Nick Coghlan wrote:
> I've updated the PEP to try to make the explanation of the historical
> rationale more accurate:
> https://github.com/python/peps/commit/30daada7867dd7f0e008545c7fd98612282ec602
With these changes, I think the version now live at
https://www.pyt
On 13 November 2017 at 01:45, Guido van Rossum wrote:
> On Sun, Nov 12, 2017 at 1:24 AM, Nick Coghlan wrote:
>>
>> In Python 2.7 and Python 3.2, the default warning filters were updated to
>> hide
>> DeprecationWarning by default, such that deprecation warnings in
>> development
>> tools that wer
On 18 November 2017 at 11:22, Victor Stinner wrote:
> Hi,
>
> I noticed that Python not only hides DeprecationWarning, but also
> PendingDeprecationWarning and ImportWarning by default. While I
> understand why we decided to hide these warnings to users for a Python
> compiled in release mode, why
On 19 November 2017 at 01:45, Serhiy Storchaka wrote:
> 18.11.17 16:17, Nick Coghlan пише:
>>
>> On 18 November 2017 at 10:01, Victor Stinner
>> wrote:
>>>
>>> I'm writing this email to ask if this change is an issue or not to
>>> embedded Python and the Python C API. Is it still possible to call
Le 18 nov. 2017 10:44, "Serhiy Storchaka" a écrit :
The simplest way to do this:
#define PyTuple_GET_ITEM PyTuple_GetItem
This will not add new names to ABI. Such defines can be added in a separate
header file included for compatibility.
It is exactly what I am proposing :-)
Victor
_
On Nov 17, 2017, at 20:22, Victor Stinner wrote:
>
> Or maybe we should start adding new modes like -X
> all-warnings-except-PendingDeprecationWarning, -X
> I-really-really-love-warnings and -X warnings-hater, as Barry
> proposed?
Well, if I can’t convince you about a `-X the-flufls-gonna-gitcha
+1 from me as well.
On Sat, Nov 18, 2017, 02:36 Serhiy Storchaka, wrote:
> 18.11.17 03:22, Victor Stinner пише:
> > I noticed that Python not only hides DeprecationWarning, but also
> > PendingDeprecationWarning and ImportWarning by default. While I
> > understand why we decided to hide these wa
18.11.17 16:17, Nick Coghlan пише:
On 18 November 2017 at 10:01, Victor Stinner wrote:
I'm writing this email to ask if this change is an issue or not to
embedded Python and the Python C API. Is it still possible to call
"all" functions of the C API before calling Py_Initialize()?
It isn't te
On 18 November 2017 at 10:01, Victor Stinner wrote:
> I'm writing this email to ask if this change is an issue or not to
> embedded Python and the Python C API. Is it still possible to call
> "all" functions of the C API before calling Py_Initialize()?
It isn't technically permitted to call any o
Your email didn't compile. The compiler says that it's a naming conflict,
but actually I think you forgot a semicolon! (Don't worry, it happens to
all of us, whether we be happy or not :-)
--Koos
On Sat, Nov 18, 2017 at 3:05 AM, Victor Stinner
wrote:
> Hi,
>
> tl; dr I propose to extend the ex
On 18 November 2017 at 23:50, Nick Coghlan wrote:
> On 18 November 2017 at 11:05, Victor Stinner wrote:
>> Hi,
>>
>> tl; dr I propose to extend the existing "stable API" to make it almost
>> as complete as the current API. For example, add back
>> PyTuple_GET_ITEM() to be stable API, but it becom
On 18 November 2017 at 11:05, Victor Stinner wrote:
> Hi,
>
> tl; dr I propose to extend the existing "stable API" to make it almost
> as complete as the current API. For example, add back
> PyTuple_GET_ITEM() to be stable API, but it becomes a function call
> rather than a macro. The final questi
On Sat, 18 Nov 2017 01:01:47 +0100
Victor Stinner wrote:
>
> Maybe, the minimum change is to expose _PyRuntime_Initialize() in the
> public C API?
+1. Also a symmetric PyRuntime_Finalize() function (even if it's a
no-op currently).
Regards
Antoine.
__
On Sat, 18 Nov 2017 10:13:36 +0100
Victor Stinner wrote:
>
> Anyway, the PyTuple_GET_ITEM() will remain a macro in the default API for
> Python 3.7.
>
> See also my blog post which explains why the fact that it is a macro
> prevents us from optimizing it, like having specialized compact tuple fo
I agree with Serhiy. It doesn't make sense to add PyTuple_GET_ITEM to
the stable ABI. People who want to benefit from the stable ABI should
use PyTuple_GetItem. That's not very complicated.
Regards
Antoine.
On Sat, 18 Nov 2017 11:42:36 +0200
Serhiy Storchaka wrote:
> 18.11.17 11:13, Victo
Hi Christian,
On Fri, 17 Nov 2017 10:15:24 +0100
Christian Tismer wrote:
>
> Example:
> One of my tests emits warnings when a certain condition is
> met. Instead of reporting the error immediately, it uses
> warnings, and at the end of the test, an error is produced
> if there were warnings.
I
18.11.17 11:13, Victor Stinner пише:
The idea behind adding PyTuple_GET_ITEM() is to be able to compile C
extensions using it, without having to modify the code.
The simplest way to do this:
#define PyTuple_GET_ITEM PyTuple_GetItem
This will not add new names to ABI. Such defines can be added
Thanks a lot!
Good to know.
Ciao -- Chris
On 17.11.17 16:44, Brett Cannon wrote:
> Tests are not isolated from the warnings system, so things will leak
> out. Your best option is to use the context manager in the warnings
> module to temporarily make all warnings raise exceptions and test for
> t
Le 18 nov. 2017 08:32, "Serhiy Storchaka" a écrit :
Making PyTuple_GET_ITEM() a function will destroy the half of the benefit.
And this will make the ABI larger.
Sorry if I wasn't explicit about it: my idea of changing the API has an
obvious impact on performance. That's why the first step on t
20 matches
Mail list logo
