[Python-Dev] Re: On the migration from master to main

[Stefano Borini]

On Tue, 23 Mar 2021 at 21:39, Python Steering Council
 wrote:
> This isn’t just about ‘master’ being rooted in slavery.

No it's not and I am shocked that such ignorance would exist to believe that.




-- 
Kind regards,

Stefano Borini
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/LNUIPXM7S5SK7VMGVHYROTLJTNIR62LM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Steering Council reply regarding conduct (was Re: Steering Council update for February)

[Brian Herman]

Maybe we can change the discussion to something more productive like the
python module system or anything else?
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/NIV227PNKJSZ5VVGUGPVBBFU7YTTLPGK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] New public C API functions must not steal references or return borrowed references

[Victor Stinner]

Hi,

A new Include/README.rst file was just added to document the 3 C API
provided by CPython:

* Include/: Limited C API
* Include/cpython/: CPython implementation details
* Include/internal/: The internal API

I would like to note that *new* public C API functions must no longer
steal references or return borrowed references.

Don't worry, there is no plan to deprecate or remove existing
functions which do that, like PyModule_AddObject() (streal a
reference) or PyDict_GetItem() (return a borrowed reference). The
policy is only to *add* new functions.

IMO for the *internal* C API, it's fine to continue doing that for
best performances.

Moreover, the limited C API must not expose "implementation details".
For example, structure members must not be accessed directly, because
most structures are excluded from the limited C API. A function call
hiding implementation details is usually better.

Here is a copy of the current Include/README.rst file:

The Python C API


The C API is divided into three sections:

1. ``Include/``
2. ``Include/cpython/``
3. ``Include/internal/``


Include: Limited API


``Include/``, excluding the ``cpython`` and ``internal`` subdirectories,
contains the public Limited API (Application Programming Interface).
The Limited API is a subset of the C API, designed to guarantee ABI
stability across Python 3 versions, and is defined in :pep:`384`.

Guidelines for expanding the Limited API:

- Functions *must not* steal references
- Functions *must not* return borrowed references
- Functions returning references *must* return a strong reference
- Macros should not expose implementation details
- Please start a public discussion before expanding the API
- Functions or macros with a ``_Py`` prefix do not belong in ``Include/``.

It is possible to add a function or macro to the Limited API from a
given Python version.  For example, to add a function to the Limited API
from Python 3.10 and onwards, wrap it with
``#if !defined(Py_LIMITED_API) || Py_LIMITED_API+0 >= 0x030A``.


Include/cpython: CPython implementation details
===

``Include/cpython/`` contains the public API that is excluded from the
Limited API and the Stable ABI.

Guidelines for expanding the public API:

- Functions *must not* steal references
- Functions *must not* return borrowed references
- Functions returning references *must* return a strong reference


Include/internal: The internal API
==


With PyAPI_FUNC or PyAPI_DATA
-

Functions or structures in ``Include/internal/`` defined with
``PyAPI_FUNC`` or ``PyAPI_DATA`` are internal functions which are
exposed only for specific use cases like debuggers and profilers.


With the extern keyword
---

Functions in ``Include/internal/`` defined with the ``extern`` keyword
*must not and can not* be used outside the CPython code base.  Only
built-in stdlib extensions (built with the ``Py_BUILD_CORE_BUILTIN``
macro defined) can use such functions.

When in doubt, new internal C functions should be defined in
``Include/internal`` using the ``extern`` keyword.

Victor
-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/QKFDGIAFPZJZE22GJ5OOMXOWQGFEDSU5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: New public C API functions must not steal references or return borrowed references

[Guido van Rossum]

I’m glad there is more clarity here. And thanks to Erlend Egeberg Aasland
for championing the PR!

—Guido

On Thu, Mar 25, 2021 at 09:30 Victor Stinner  wrote:

> Hi,
>
> A new Include/README.rst file was just added to document the 3 C API
> provided by CPython:
>
> * Include/: Limited C API
> * Include/cpython/: CPython implementation details
> * Include/internal/: The internal API
>
> I would like to note that *new* public C API functions must no longer
> steal references or return borrowed references.
>
> Don't worry, there is no plan to deprecate or remove existing
> functions which do that, like PyModule_AddObject() (streal a
> reference) or PyDict_GetItem() (return a borrowed reference). The
> policy is only to *add* new functions.
>
> IMO for the *internal* C API, it's fine to continue doing that for
> best performances.
>
> Moreover, the limited C API must not expose "implementation details".
> For example, structure members must not be accessed directly, because
> most structures are excluded from the limited C API. A function call
> hiding implementation details is usually better.
>
> Here is a copy of the current Include/README.rst file:
>
> The Python C API
> 
>
> The C API is divided into three sections:
>
> 1. ``Include/``
> 2. ``Include/cpython/``
> 3. ``Include/internal/``
>
>
> Include: Limited API
> 
>
> ``Include/``, excluding the ``cpython`` and ``internal`` subdirectories,
> contains the public Limited API (Application Programming Interface).
> The Limited API is a subset of the C API, designed to guarantee ABI
> stability across Python 3 versions, and is defined in :pep:`384`.
>
> Guidelines for expanding the Limited API:
>
> - Functions *must not* steal references
> - Functions *must not* return borrowed references
> - Functions returning references *must* return a strong reference
> - Macros should not expose implementation details
> - Please start a public discussion before expanding the API
> - Functions or macros with a ``_Py`` prefix do not belong in ``Include/``.
>
> It is possible to add a function or macro to the Limited API from a
> given Python version.  For example, to add a function to the Limited API
> from Python 3.10 and onwards, wrap it with
> ``#if !defined(Py_LIMITED_API) || Py_LIMITED_API+0 >= 0x030A``.
>
>
> Include/cpython: CPython implementation details
> ===
>
> ``Include/cpython/`` contains the public API that is excluded from the
> Limited API and the Stable ABI.
>
> Guidelines for expanding the public API:
>
> - Functions *must not* steal references
> - Functions *must not* return borrowed references
> - Functions returning references *must* return a strong reference
>
>
> Include/internal: The internal API
> ==
>
>
> With PyAPI_FUNC or PyAPI_DATA
> -
>
> Functions or structures in ``Include/internal/`` defined with
> ``PyAPI_FUNC`` or ``PyAPI_DATA`` are internal functions which are
> exposed only for specific use cases like debuggers and profilers.
>
>
> With the extern keyword
> ---
>
> Functions in ``Include/internal/`` defined with the ``extern`` keyword
> *must not and can not* be used outside the CPython code base.  Only
> built-in stdlib extensions (built with the ``Py_BUILD_CORE_BUILTIN``
> macro defined) can use such functions.
>
> When in doubt, new internal C functions should be defined in
> ``Include/internal`` using the ``extern`` keyword.
>
> Victor
> --
> Night gathers, and now my watch begins. It shall not end until my death.
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/QKFDGIAFPZJZE22GJ5OOMXOWQGFEDSU5/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-- 
--Guido (mobile)
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/6TEXVP6C3AVEUMWH3LIRA36W2MZO4T57/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: How about using modern C++ in development of CPython ?

[Ivan Pozdeev via Python-Dev]

On 24.03.2021 19:58, Antoine Pitrou wrote:

On Wed, 24 Mar 2021 19:45:49 +0300
Ivan Pozdeev via Python-Dev  wrote:

How does C++ fare in binary compatibility? Last time I checked it out (about 10 
years ago), there was completely none, every compiler's ABI
was a black box without any guarantees whatsoever.
For any software that's going to dynamically link and exchange binary types 
with other independently produced software, that's a deal breaker.

That depends if you use C++ internally or expose C++ bits in the public
API.
If you only use C++ internally, binary compatibility is presumably less
of an issue.


Python produces and accepts its internal types in API calls and allows extension modules to derive from them -- so it cannot "only use C++ 
internally" if those are going to become C++ types. (And if not, the point of using C++ is unclear.)



Regards

Antoine.


___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/GHYWBZY56CTPBOOQRVXCOXTO2EUHUZ3Z/
Code of Conduct: http://python.org/psf/codeofconduct/


--
Regards,
Ivan

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/7JIYJGSEL6RZM4FPNRSD3TMABO7YHT3D/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: How about using modern C++ in development of CPython ?

[Antoine Pitrou]

On Thu, 25 Mar 2021 20:22:55 +0300
Ivan Pozdeev via Python-Dev  wrote:
> On 24.03.2021 19:58, Antoine Pitrou wrote:
> > On Wed, 24 Mar 2021 19:45:49 +0300
> > Ivan Pozdeev via Python-Dev  wrote:  
> >> How does C++ fare in binary compatibility? Last time I checked it out 
> >> (about 10 years ago), there was completely none, every compiler's ABI
> >> was a black box without any guarantees whatsoever.
> >> For any software that's going to dynamically link and exchange binary 
> >> types with other independently produced software, that's a deal breaker.  
> > That depends if you use C++ internally or expose C++ bits in the public
> > API.
> > If you only use C++ internally, binary compatibility is presumably less
> > of an issue.  
> 
> Python produces and accepts its internal types in API calls and allows 
> extension modules to derive from them -- so it cannot "only use C++ 
> internally" if those are going to become C++ types. (And if not, the point of 
> using C++ is unclear.)

You can use C++ without exposing C++ types in the API.  For example,
C++ templates could improve the maintainability of the generic
"stringlib" routines that are currently based on C macros.  Another
example is using RAII in function bodies to help cleanup owned
references.

Regards

Antoine.


___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/F7WX4SB4DV2GQJU2SXGXYLS7F3QJU3Q4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: How about using modern C++ in development of CPython ?

[Christian Heimes]

On 25/03/2021 18.39, Antoine Pitrou wrote:
> On Thu, 25 Mar 2021 20:22:55 +0300
> Ivan Pozdeev via Python-Dev  wrote:
>> On 24.03.2021 19:58, Antoine Pitrou wrote:
>>> On Wed, 24 Mar 2021 19:45:49 +0300
>>> Ivan Pozdeev via Python-Dev  wrote:  
 How does C++ fare in binary compatibility? Last time I checked it out 
 (about 10 years ago), there was completely none, every compiler's ABI
 was a black box without any guarantees whatsoever.
 For any software that's going to dynamically link and exchange binary 
 types with other independently produced software, that's a deal breaker.  
>>> That depends if you use C++ internally or expose C++ bits in the public
>>> API.
>>> If you only use C++ internally, binary compatibility is presumably less
>>> of an issue.  
>>
>> Python produces and accepts its internal types in API calls and allows 
>> extension modules to derive from them -- so it cannot "only use C++ 
>> internally" if those are going to become C++ types. (And if not, the point 
>> of using C++ is unclear.)
> 
> You can use C++ without exposing C++ types in the API.  For example,
> C++ templates could improve the maintainability of the generic
> "stringlib" routines that are currently based on C macros.  Another
> example is using RAII in function bodies to help cleanup owned
> references.

C has ways to handle cleanup and ownership better -- at least some
compilers do. For example gcc has
__attribute__(cleanup(cleanup_function)) for automatic cleanup on scope
boundaries. If I recall correctly it works something like this:

void
Py_auto_decref(PyObject **o)
{
if (!o || !*o)
return;

Py_DECREF(*o);
*o = NULL;
}


PyObject *
func(PyObject self)
{
PyObject *spam  __attribute__((cleanup(Py_auto_decref)));
...
Py_RETURN_NONE;
// spam gets automatically decrefed
}

It's too bad that the feature is not universally available in C99.

Christian

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/JGONDY5TRVTSCRMDUPPQH6OMEOAQ37Y2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: New public C API functions must not steal references or return borrowed references

[Mark Shannon]

Hi Victor,

I'm with you 100% on not returning borrowed references, doing so is just 
plain dangerous.


However, is a blanket ban on stealing references the right thing?

Maybe the problem is the term "stealing".
The caller is transferring the reference to the callee.
In some circumstances it can make a lot of sense to do so, since the 
caller has probably finished with the reference and the callee needs a 
new one.


Cheers,
Mark.


On 25/03/2021 4:27 pm, Victor Stinner wrote:

Hi,

A new Include/README.rst file was just added to document the 3 C API
provided by CPython:

* Include/: Limited C API
* Include/cpython/: CPython implementation details
* Include/internal/: The internal API

I would like to note that *new* public C API functions must no longer
steal references or return borrowed references.

Don't worry, there is no plan to deprecate or remove existing
functions which do that, like PyModule_AddObject() (streal a
reference) or PyDict_GetItem() (return a borrowed reference). The
policy is only to *add* new functions.

IMO for the *internal* C API, it's fine to continue doing that for
best performances.

Moreover, the limited C API must not expose "implementation details".
For example, structure members must not be accessed directly, because
most structures are excluded from the limited C API. A function call
hiding implementation details is usually better.

Here is a copy of the current Include/README.rst file:

The Python C API


The C API is divided into three sections:

1. ``Include/``
2. ``Include/cpython/``
3. ``Include/internal/``


Include: Limited API


``Include/``, excluding the ``cpython`` and ``internal`` subdirectories,
contains the public Limited API (Application Programming Interface).
The Limited API is a subset of the C API, designed to guarantee ABI
stability across Python 3 versions, and is defined in :pep:`384`.

Guidelines for expanding the Limited API:

- Functions *must not* steal references
- Functions *must not* return borrowed references
- Functions returning references *must* return a strong reference
- Macros should not expose implementation details
- Please start a public discussion before expanding the API
- Functions or macros with a ``_Py`` prefix do not belong in ``Include/``.

It is possible to add a function or macro to the Limited API from a
given Python version.  For example, to add a function to the Limited API
from Python 3.10 and onwards, wrap it with
``#if !defined(Py_LIMITED_API) || Py_LIMITED_API+0 >= 0x030A``.


Include/cpython: CPython implementation details
===

``Include/cpython/`` contains the public API that is excluded from the
Limited API and the Stable ABI.

Guidelines for expanding the public API:

- Functions *must not* steal references
- Functions *must not* return borrowed references
- Functions returning references *must* return a strong reference


Include/internal: The internal API
==


With PyAPI_FUNC or PyAPI_DATA
-

Functions or structures in ``Include/internal/`` defined with
``PyAPI_FUNC`` or ``PyAPI_DATA`` are internal functions which are
exposed only for specific use cases like debuggers and profilers.


With the extern keyword
---

Functions in ``Include/internal/`` defined with the ``extern`` keyword
*must not and can not* be used outside the CPython code base.  Only
built-in stdlib extensions (built with the ``Py_BUILD_CORE_BUILTIN``
macro defined) can use such functions.

When in doubt, new internal C functions should be defined in
``Include/internal`` using the ``extern`` keyword.

Victor


___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/5UURMDSQUGSNZEUDUSQNHWRZIUKDIZJH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Alternative syntax for Python's lambda

[Dan Stromberg]

I posted this to LWN, and thought I'd share it here too:

I'm opposed to terse-ifying lambda in Python.

Lambda is rarely useful in Python - you're almost always better off using a
generator expression, a list comprehension, or something from the operator
module.

And lambdas tend to give rise to the software development equivalent of a
runon sentence.

Naming a function in those rare cases that you genuinely need something
custom really isn't the end of the world, and is more readable anyway.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/KZ66M7T4E6BO3ZO4FNC4RWC3LSE6CQG5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Alternative syntax for Python's lambda

[Ethan Furman]

On 3/25/21 1:06 PM, Dan Stromberg wrote:


I posted this to LWN, and thought I'd share it here too:


This post is nearly completely devoid of context -- could you post a link, or 
what you are responding to, or something?

--
~Ethan~
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/4BVRW67UU6KQCDER4FMRTZ4WUMBDTNGJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: New public C API functions must not steal references or return borrowed references

[Erlend Aasland]

Glad to help! Thank you Guido, Antoine, Serhiy, and Victor for your insights 
and scrutinising :)

E

On 25 Mar 2021, at 18:15, Guido van Rossum 
mailto:gu...@python.org>> wrote:

I’m glad there is more clarity here. And thanks to Erlend Egeberg Aasland for 
championing the PR!

—Guido

On Thu, Mar 25, 2021 at 09:30 Victor Stinner 
mailto:vstin...@python.org>> wrote:
Hi,

A new Include/README.rst file was just added to document the 3 C API
provided by CPython:

* Include/: Limited C API
* Include/cpython/: CPython implementation details
* Include/internal/: The internal API

I would like to note that *new* public C API functions must no longer
steal references or return borrowed references.

Don't worry, there is no plan to deprecate or remove existing
functions which do that, like PyModule_AddObject() (streal a
reference) or PyDict_GetItem() (return a borrowed reference). The
policy is only to *add* new functions.

IMO for the *internal* C API, it's fine to continue doing that for
best performances.

Moreover, the limited C API must not expose "implementation details".
For example, structure members must not be accessed directly, because
most structures are excluded from the limited C API. A function call
hiding implementation details is usually better.

Here is a copy of the current Include/README.rst file:

The Python C API


The C API is divided into three sections:

1. ``Include/``
2. ``Include/cpython/``
3. ``Include/internal/``


Include: Limited API


``Include/``, excluding the ``cpython`` and ``internal`` subdirectories,
contains the public Limited API (Application Programming Interface).
The Limited API is a subset of the C API, designed to guarantee ABI
stability across Python 3 versions, and is defined in :pep:`384`.

Guidelines for expanding the Limited API:

- Functions *must not* steal references
- Functions *must not* return borrowed references
- Functions returning references *must* return a strong reference
- Macros should not expose implementation details
- Please start a public discussion before expanding the API
- Functions or macros with a ``_Py`` prefix do not belong in ``Include/``.

It is possible to add a function or macro to the Limited API from a
given Python version.  For example, to add a function to the Limited API
from Python 3.10 and onwards, wrap it with
``#if !defined(Py_LIMITED_API) || Py_LIMITED_API+0 >= 0x030A``.


Include/cpython: CPython implementation details
===

``Include/cpython/`` contains the public API that is excluded from the
Limited API and the Stable ABI.

Guidelines for expanding the public API:

- Functions *must not* steal references
- Functions *must not* return borrowed references
- Functions returning references *must* return a strong reference


Include/internal: The internal API
==


With PyAPI_FUNC or PyAPI_DATA
-

Functions or structures in ``Include/internal/`` defined with
``PyAPI_FUNC`` or ``PyAPI_DATA`` are internal functions which are
exposed only for specific use cases like debuggers and profilers.


With the extern keyword
---

Functions in ``Include/internal/`` defined with the ``extern`` keyword
*must not and can not* be used outside the CPython code base.  Only
built-in stdlib extensions (built with the ``Py_BUILD_CORE_BUILTIN``
macro defined) can use such functions.

When in doubt, new internal C functions should be defined in
``Include/internal`` using the ``extern`` keyword.

Victor
--
Night gathers, and now my watch begins. It shall not end until my death.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to 
python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/QKFDGIAFPZJZE22GJ5OOMXOWQGFEDSU5/
Code of Conduct: http://python.org/psf/codeofconduct/
--
--Guido (mobile)
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to 
python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/6TEXVP6C3AVEUMWH3LIRA36W2MZO4T57/
Code of Conduct: http://python.org/psf/codeofconduct/

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/DXXEGSXDPUNRPNV3MYGEWZTLPBQB6UVI/
Code of Conduct: http://python.org/psf/codeofconduc

[Python-Dev] OpenSSL 1.1.1k CVE fixes

[Christian Heimes]

Hi,

OpenSSL released 1.1.1k today with two high severity CVEs,
https://www.openssl.org/news/vulnerabilities.html


The ssl module is not affected by CVE-2021-3450 in its default
configuration. Python does not set X509_V_FLAG_X509_STRICT on
SSLContext. Only applications that that use ssl.VERIFY_X509_STRICT
verify flag are affected.

It looks like Python's ssl module is vulnerable to CVE-2021-3449. The
crash does not affect pip, requests, or any other client-side socket.
Only server-side SSL/TLS sockets are vulnerable (ssl.PROTOCOL_TLS_SERVER
and server_side=True).


I haven't had time to reproduce and verify any of the CVE bugs yet. That
means I'm not entirely sure how the CVEs affect CPython. I strongly
recommend that you update OpenSSL through your vendor and restart your
services. If you cannot update OpenSSL (e.g. for Python.org installers),
then you can apply workarounds:


To disable X509_V_FLAG_X509_STRICT flag either remove any lines that set
the flag or unset the flag with:

ctx.verify_flags &= ~ssl.VERIFY_X509_STRICT

(That's bitwise AND and unary bitwise invert operator)


To work around CVE-2021-3449 either set disable TLS 1.0, 1,1, and 1.2 with

ctx.minimum_version = ssl.TLSVersion.TLSv1_3

or disable renegotiation with

ctx.options |= ssl.OP_NO_RENEGOTIATION

NOTE: Renegotiation is required for TLS 1.2 rekeying, optional TLS
client cert authention with TLS 1.2 and possible other features. TLS 1.3
is not supported by older clients and servers.


Christian

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/2GULUR43MNEW3IJM44LS5ZY2TOUANPNT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Alternative syntax for Python's lambda

[Dan Stromberg]

Please see https://lwn.net/Articles/847960/

:)

On Thu, Mar 25, 2021 at 2:34 PM Ethan Furman  wrote:

> On 3/25/21 1:06 PM, Dan Stromberg wrote:
> >
> > I posted this to LWN, and thought I'd share it here too:
>
> This post is nearly completely devoid of context -- could you post a link,
> or what you are responding to, or something?
>
> --
> ~Ethan~
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/4BVRW67UU6KQCDER4FMRTZ4WUMBDTNGJ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/3PBF272BZAWWF7XWP3O2PQ25VT4Y5HOO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: New public C API functions must not steal references or return borrowed references

[Gregory P. Smith]

On Thu, Mar 25, 2021 at 11:58 AM Mark Shannon  wrote:

> Hi Victor,
>
> I'm with you 100% on not returning borrowed references, doing so is just
> plain dangerous.
>
> However, is a blanket ban on stealing references the right thing?
>
> Maybe the problem is the term "stealing".
> The caller is transferring the reference to the callee.
> In some circumstances it can make a lot of sense to do so, since the
> caller has probably finished with the reference and the callee needs a
> new one.
>
> Cheers,
> Mark.
>

When was the last time a non-internal API that transferred references added?

I suggest keeping the restriction on new APIs in place until we actually
find a situation where we think we "need" one outside of Include/internal/
to help force the discussion as to why that needs to be public.

-gps

On 25/03/2021 4:27 pm, Victor Stinner wrote:
> > Hi,
> >
> > A new Include/README.rst file was just added to document the 3 C API
> > provided by CPython:
> >
> > * Include/: Limited C API
> > * Include/cpython/: CPython implementation details
> > * Include/internal/: The internal API
> >
> > I would like to note that *new* public C API functions must no longer
> > steal references or return borrowed references.
> >
> > Don't worry, there is no plan to deprecate or remove existing
> > functions which do that, like PyModule_AddObject() (streal a
> > reference) or PyDict_GetItem() (return a borrowed reference). The
> > policy is only to *add* new functions.
> >
> > IMO for the *internal* C API, it's fine to continue doing that for
> > best performances.
> >
> > Moreover, the limited C API must not expose "implementation details".
> > For example, structure members must not be accessed directly, because
> > most structures are excluded from the limited C API. A function call
> > hiding implementation details is usually better.
> >
> > Here is a copy of the current Include/README.rst file:
> >
> > The Python C API
> > 
> >
> > The C API is divided into three sections:
> >
> > 1. ``Include/``
> > 2. ``Include/cpython/``
> > 3. ``Include/internal/``
> >
> >
> > Include: Limited API
> > 
> >
> > ``Include/``, excluding the ``cpython`` and ``internal`` subdirectories,
> > contains the public Limited API (Application Programming Interface).
> > The Limited API is a subset of the C API, designed to guarantee ABI
> > stability across Python 3 versions, and is defined in :pep:`384`.
> >
> > Guidelines for expanding the Limited API:
> >
> > - Functions *must not* steal references
> > - Functions *must not* return borrowed references
> > - Functions returning references *must* return a strong reference
> > - Macros should not expose implementation details
> > - Please start a public discussion before expanding the API
> > - Functions or macros with a ``_Py`` prefix do not belong in
> ``Include/``.
> >
> > It is possible to add a function or macro to the Limited API from a
> > given Python version.  For example, to add a function to the Limited API
> > from Python 3.10 and onwards, wrap it with
> > ``#if !defined(Py_LIMITED_API) || Py_LIMITED_API+0 >= 0x030A``.
> >
> >
> > Include/cpython: CPython implementation details
> > ===
> >
> > ``Include/cpython/`` contains the public API that is excluded from the
> > Limited API and the Stable ABI.
> >
> > Guidelines for expanding the public API:
> >
> > - Functions *must not* steal references
> > - Functions *must not* return borrowed references
> > - Functions returning references *must* return a strong reference
> >
> >
> > Include/internal: The internal API
> > ==
> >
> >
> > With PyAPI_FUNC or PyAPI_DATA
> > -
> >
> > Functions or structures in ``Include/internal/`` defined with
> > ``PyAPI_FUNC`` or ``PyAPI_DATA`` are internal functions which are
> > exposed only for specific use cases like debuggers and profilers.
> >
> >
> > With the extern keyword
> > ---
> >
> > Functions in ``Include/internal/`` defined with the ``extern`` keyword
> > *must not and can not* be used outside the CPython code base.  Only
> > built-in stdlib extensions (built with the ``Py_BUILD_CORE_BUILTIN``
> > macro defined) can use such functions.
> >
> > When in doubt, new internal C functions should be defined in
> > ``Include/internal`` using the ``extern`` keyword.
> >
> > Victor
> >
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/5UURMDSQUGSNZEUDUSQNHWRZIUKDIZJH/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.o

[Python-Dev] Re: New public C API functions must not steal references or return borrowed references

[Simon Cross]

On Thu, Mar 25, 2021 at 9:01 PM Mark Shannon  wrote:
> Maybe the problem is the term "stealing".
> The caller is transferring the reference to the callee.
> In some circumstances it can make a lot of sense to do so, since the
> caller has probably finished with the reference and the callee needs a
> new one.

The problem with both borrowed and stolen references is that they
implicitly expose the lifetime of the reference as part of the API.

I agree that borrowed references are worse in some sense (there is no
way to indicate that one is done with a borrowed reference at all).

Stolen references are not great though. As you mention, in theory one
can treat the stolen reference as having been DECREF'ed and never use
it again, but in practice that's hard to do. When reviewing or writing
code, one has to remember precisely which API functions steal a
reference. One can no longer reason about whether the reference
counting is correct by looking for appropriate DECREF's. It's very
hard for tools to help pick up mistakes because the reference was
freed -- just not necessarily at the right time.

Of course it is hard to avoid these kinds of problems as long as
pointers to PyObjects and reference counting are part of the API, but
let's not make it more difficult to write correct code unless there is
a really big advantage to be had by doing so.

I also don't see the rules that Victor is proposing as absolutes. More
of a "let's have a big conversation before doing this" kind of rule.

- Simon
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/CIL7IOCDAQYA6HRJTP3ZCNRGYZWPTFQW/
Code of Conduct: http://python.org/psf/codeofconduct/