[Python-Dev] Re: Remove module's __version__ attributes in the stdlib

[Erlend Aasland]

Actually both sqlite3.version and sqlite3.version_info, the former as a string, 
the latter as a tuple.

E

On 15 Oct 2020, at 14:45, Erlend Aasland 
mailto:erlen...@innova.no>> wrote:

FYI, sqlite3 has a pysqlite “version" attribute iso. “__version__", stemming 
from its days outside of stdlib. It has held the value “2.6.0" since commit 
f9cee22, 2010-03-05.


Erlend E. Aasland

On 14 Oct 2020, at 15:53, Serhiy Storchaka 
mailto:storch...@gmail.com>> wrote:

Some module attributes in the stdlib have attribute __version__. It
makes sense if the module is developed independently from Python, but
after inclusion in the stdlib it no longer have separate releases which
should be identified by version. New changes goes into module usually
without changing the value of __version__. Different versions of the
module for different Python version can have different features but the
same __version__.

I propose to remove __version__ in all stdlib modules. Are there any
exceptions?

Also, what do you think about other meta attributes like __author__,
__credits__, __email__, __copyright__, __about__, __date__?
___
Python-Dev mailing list -- python-dev@python.org<mailto:python-dev@python.org>
To unsubscribe send an email to 
python-dev-le...@python.org<mailto: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/KBU4EU2JULXSMUZULD5HJJWCGOMN52MK/
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/4BSUFZSQY4OSZGGCEYP67NG6IWNSP2EA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Remove module's __version__ attributes in the stdlib

[Erlend Aasland]

FYI, sqlite3 has a pysqlite “version" attribute iso. “__version__", stemming 
from its days outside of stdlib. It has held the value “2.6.0" since commit 
f9cee22, 2010-03-05.


Erlend E. Aasland

On 14 Oct 2020, at 15:53, Serhiy Storchaka 
mailto:storch...@gmail.com>> wrote:

Some module attributes in the stdlib have attribute __version__. It
makes sense if the module is developed independently from Python, but
after inclusion in the stdlib it no longer have separate releases which
should be identified by version. New changes goes into module usually
without changing the value of __version__. Different versions of the
module for different Python version can have different features but the
same __version__.

I propose to remove __version__ in all stdlib modules. Are there any
exceptions?

Also, what do you think about other meta attributes like __author__,
__credits__, __email__, __copyright__, __about__, __date__?
___
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/KBU4EU2JULXSMUZULD5HJJWCGOMN52MK/
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/DAB2TCPTLLH7ZUU2B2VRKQYN7SWUT6RN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Where is the SQLite module maintainer

[Erlend Aasland]

Hi, everyone.

I'm trying to find a reviewer for this trivial PR: 
https://github.com/python/cpython/pull/20530
(The PR fixes CheckTraceCallbackContent (in the sqlite3 test suite) for SQLite 
pre 3.7.15.)


I've given up hunting for alternative reviewers (a process I find very 
uncomfortable, since I feel I'm just bugging people who have too much to do 
with things they're not interested in), so as a last resort, I'm trying the 
mailing list:

Who can help me review code that touches the sqlite3 module code base?


I've received a lot of constructive reviews from Victor Stinner, Dong-he Na and 
Pablo Galindo on my past sqlite3 PR's; thank you so much! I still feel 
uncomfortable requesting their review, as none of them are sqlite3 module 
maintainers.



Erlend
___
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/CF4AYW4NOLLPQ5GLXDT5D3SNFIKKFGXR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Where is the SQLite module maintainer

[Erlend Aasland]

> On 5 Jan 2021, at 09:08, Serhiy Storchaka  wrote:
> 27.12.20 22:20, Erlend Aasland пише:
>> Who can help me review code that touches the sqlite3 module code base?
> 
> I fixed many bugs in sqlite3 and did reviews, so I have some experience,
> although I am not an expert. I payed less attention to it since Berker
> Peksag took its maintenance, so my attention was not needed. But seems
> he is not very active now (I hope it is temporary). You can request my
> review. My reaction may be not instant because last weeks I am very busy
> with curses and tkinter.
> 

Thanks, Serhiy, and thank you very much for reviewing most of my recent PR's. I 
highly appreciate that. It looks like Berker Peksag is back again, so for now, 
I'll ping him for reviews.


Erlend
___
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/7XPDY54J2TDBFJECXPPJIJIEYWNJPA4B/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Where is the SQLite module maintainer

[Erlend Aasland]

On 27 Dec 2020, at 22:38, Christian Heimes 
mailto:christ...@python.org>> wrote:
On 27/12/2020 21.20, Erlend Aasland wrote:
[…]
Who can help me review code that touches the sqlite3 module code base?

as far as I know we don't have an active module owner and maintainer any
more.

What about Berker Peksag? He's at least listed as a code owner in 
.github/CODEOWNERS, but I rarely see him engaged in sqlite3 matters on GitHub 
and bpo. The last time I remember him discussing sqlite3 matters was seven 
months ago. (Just an observation; not critisism.)

Gerhard Häring, the original author of pysqlite, is still listed
as expert. But he hasn't been active in many years. I haven't seen him
in quite some time, too.

I think it's been five or so years since he last participated on bpo.

How about you put your name in the expert index instead of him? :)

Thanks for your confidence, but I'm far from an expert :)


Erlend
___
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/RCD2WC2IKYIGA4USOALE3GZ455LT7U4P/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Where is the SQLite module maintainer

[Erlend Aasland]

> On 4 Jan 2021, at 17:34, Steve Dower  wrote:
> On 12/28/2020 11:32 AM, Erlend Aasland wrote:
>>> On 27 Dec 2020, at 22:38, Christian Heimes >> <mailto:christ...@python.org>> wrote:
>>> How about you put your name in the expert index instead of him? :)
>> Thanks for your confidence, but I'm far from an expert :)
> Neither is anyone else :)
> 
> I'm not looking to start any mentoring right now, but if someone else is and 
> you're interested, it should be easy to get you connected. I am more than 
> happy to endorse you as a good candidate for becoming our SQLite expert.
> 

Thanks, I really appreciate that. I'm willing to invest the time needed if 
someone's interested in mentoring me.


Erlend
___
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/PRMT36E5WJUREBJVKYHMZQVTKZDQ4QYF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Where is the SQLite module maintainer

[Erlend Aasland]

> On 4 Jan 2021, at 18:24, Guido van Rossum  wrote:
> 
> OTOH if you just want to have the PR merged I can do that -- it seems 
> unobjectionable.

I'm eager to get it merged, so I'll appreciate it if you could help with that.


Erlend
___
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/EIZNTM5ZH5H6DTYG63SC4MVRAJH7HBJC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] List of stdlib types that have been converted to heap types

[Erlend Aasland]

Ref. https://bugs.python.org/issue43908, I've compiled a list of types that 
have been converted to heap types. I've posted it on Discourse for readability:
https://discuss.python.org/t/list-of-built-in-types-converted-to-heap-types/8403


Note: for now, I didn't bother to trace PyType_Spec variable names to complete 
type names. Hope it's not too much of a problem.


Erlend



Here's the plain text version:

0b858cdd5d 2021-01-04 Modules/cjkcodecs/multibytecodec.c
- multibytecodec_spec
- encoder_spec
- decoder_spec
- reader_spec
- writer_spec

c8a87addb1 2021-01-04 Modules/pyexpat.c
- _xml_parse_type_spec

75bf107c62 2021-01-02 Modules/arraymodule.c
- array_spec
- arrayiter_spec

dd39123970 2020-12-29 Modules/_functoolsmodule.c
- partial_type_spec
- keyobject_type_spec
- lru_list_elem_type_spec
- lru_cache_type_spec

6104013838 2020-12-18 Modules/_threadmodule.c
- lock_type_spec
- rlock_type_spec
- local_dummy_type_spec
- local_type_spec

a6109ef68d 2020-11-20 Modules/_sre.c
- pattern_spec
- match_spec
- scanner_spec

5c36da78d7 2020-11-20 Modules/_ssl.c
- PySSLSocket_spec
- PySSLContext_spec
- PySSLMemoryBIO_spec
- PySSLSession_spec

01c6aa43dc 2020-11-07 Modules/_queuemodule.c
- simplequeue_spec

74b4eda98b 2020-11-03 Modules/mmapmodule.c
- mmap_object_spec

c8c4200b65 2020-10-26 Modules/unicodedata.c
- ucd_type_spec

256e54acdb 2020-10-01 Modules/_sqlite
- connection_spec
- cursor_spec

9031bd4fa4 2020-10-01 Modules/_sqlite
- row_spec
- stmt_spec

cb6db8b6ae 2020-09-29 Modules/_sqlite
- type_spec (PrepareProtocolType)

a937ab45d6 2020-09-27 Modules/_sqlite
- node_spec
- cache_spec

83de110dce 2020-09-23 Modules/_lsprof.c
- _lsprof_profiler_type_spec

52a2df135c 2020-09-08 Modules/sha256module.c
- sha224_type_spec
- sha256_type_spec

2aabc3200b 2020-09-07 Modules/overlapped.c
- overlapped_type_spec

63f102fe07 2020-09-06 Modules/md5module.c Modules/sha1module.c 
Modules/sha512module.c
- md5_type_spec
- sha1_type_spec
- sha512_sha384_type_spec
- sha512_sha512_type_spec

31967fd8d0 2020-08-27 Modules/_operator.c
- itemgetter_type_spec
- attrgetter_type_spec
- methodcaller_type_spec

e087f7cd43 2020-08-13 Modules/_winapi.c
- winapi_overlapped_type_spec

1937edd376 2020-06-23 Modules/_lzmamodule.c
- lzma_compressor_type_spec
- lzma_decompressor_type_spec

ec68918795 2020-06-20 Modules/_bz2module.c
- bz2_compressor_type_spec
- bz2_decompressor_type_spec

c4862e333a 2020-06-17 Modules/_gdbmmodule.c
- gdbmtype_spec

bf69a8f99f 2020-06-16 Modules/_dbmmodule.c
- dbmtype_spec

d5b3f6b7f9 2020-05-16 Modules/_hashopenssl.c
- EVPXOFtype_spec

53e4c91725 2020-03-30 Modules/_abc.c
- _abc_data_type_spec

33f15a16d4 2020-03-27 Modules/_json.c
- PyScannerType_spec
- PyEncoderType_spec

b3966639d2 2019-11-05 Modules/posixmodule.c
- DirEntryType_spec
- ScandirIteratorType_spec

df69e75edc 2019-09-25 Modules/_hashopenssl.c
- EVPtype_spec

f919054e53 2019-09-14 Modules/selectmodule.c
- devpoll_Type_spec
- kqueue_event_Type_spec
- poll_Type_spec
- pyEpoll_Type_spec
- kqueue_queue_Type_spec

04f0bbfbed 2019-09-13 Modules/_randommodule.c
- Random_Type_spec

ac46eb4ad6 2019-09-11 Python/Python-ast.c
- AST_type_spec
- AST_type_spec

a1ffad0719 2019-09-10 Modules/zlibmodule.c
- Comptype_spec
- Decomptype_spec

4f384af067 2019-09-10 Modules/_struct.c
- unpackiter_type_spec
- PyStructType_spec

11dc6c311d 2012-10-14 Modules/_tkinter.c
- PyTclObject_Type_spec
- Tktt_Type_spec
- Tkapp_Type_spec

3b36fb1f53 2012-06-22 Modules/_ssl.c
- sslerror_type_spec

bc07cb883e 2012-06-14 Modules/_curses_panel.c
- PyCursesPanel_Type_spec


___
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/QP2ZTALWWHP6ILIE45MHQC5KNEI2WWZZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Signature discrepancies between documentation and implementation

[Erlend Aasland]

Hi all,

What's the recommended approach with issues like 
https://bugs.python.org/issue43094? Change the docs or the implementation? I 
did a quick search on bpo, but could not find similar past issues.



Erlend
___
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/3NPQMMWIDSP5DEBV5LAQ3Y7JUIUN4PFE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Signature discrepancies between documentation and implementation

[Erlend Aasland]

Hi Victor, and thanks for you reply.

> On 9 Feb 2021, at 11:46, Victor Stinner  wrote:
> If there are applications relying on the parameter name, it's better
> to trust the Python implementation, rather than the documentation.

I feared that answer :)

> It would be better to make these parameters positional only in the
> first place, but now it's too late for such backward incompatible
> change :-(

Unfortunately, yes.


Erlend
___
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/7XJMO335TVWAUZWXLOH6272E5K5FJL7N/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Signature discrepancies between documentation and implementation

[Erlend Aasland]

> On 10 Feb 2021, at 01:28, Petr Viktorin  wrote:
> 
> On 2/9/21 9:15 PM, Serhiy Storchaka wrote:
>> 09.02.21 12:22, Erlend Aasland пише:
>>> What's the recommended approach with issues like 
>>> https://bugs.python.org/issue43094? Change the docs or the implementation? 
>>> I did a quick search on bpo, but could not find similar past issues.
>> If the documentation and the C implemented function contradict about
>> parameter name, we are free to treat the parameter as positional-only.
>> User cannot pass the argument as keyword because the documented name
>> does not work, and the real name is not exposed to the user.
> 
> It is. Python will correct you if you try to use the documented name:

Correct. However, I suspect that most users use positional arguments with these 
functions (since this is the first (?) report of the inconsistency) so I guess 
it's ok, in this case, to make the arguments positional only and normalise the 
argument naming.


Erlend
___
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/4U3IYJE5ZAXJQWHPXCQZC2K4OYDZWVFE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Signature discrepancies between documentation and implementation

[Erlend Aasland]

Thanks, Jakub.

E

> On 9 Feb 2021, at 19:42, Jakub Stasiak  wrote:
> 
> To provide some context as you looked for issues on bpo: in the two I was 
> involved in[1][2] the resolution was to update the documenttion to reflect 
> the actual situation.
> 
> Best,
> Jakub
> 
> [1] https://bugs.python.org/issue42230
> [2] https://bugs.python.org/issue38580
> 
___
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/UJJ7CKQ6QYYVLBCUJPT4TUSTYTWFADDT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Where and how can I contribute?

[Erlend Aasland]

Hi, Marco! I'd suggest taking a look at the issues that are marked as "Easy 
Tasks" on http://bugs.python.org. Not all of them are trivial, though (there 
may not be consensus on how to solve the issue), but you should be able to find 
something to work on there :)


Erlend

On 26 Mar 2021, at 11:29, Marco Sulla 
mailto:marco.sulla.pyt...@gmail.com>> wrote:

I would contribute to the project in my spare time. Can someone point
me to some easy task? I know C and the Python C API a little.
___
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/5EQWUYNGSTWGJONZCFRMK6XWXL36WCLR/
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/PRQHC42ZBDAOV3QRH7GXATYTS57DVJ23/
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: 

[Python-Dev] Re: f-strings in the grammar

[Erlend Aasland]

On 20 Sep 2021, at 13:18, Pablo Galindo Salgado 
mailto:pablog...@gmail.com>> wrote:

We are doing this work in this branch: 
https://github.com/we-like-parsers/cpython/blob/fstring-grammar

That link is broken. Assuming you mean 
https://github.com/we-like-parsers/cpython/tree/fstring-grammar?


E
___
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/W2VMLMV6OFPIG6NEL45NAOUJ3CHBIFK2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [PSA] OpenSSL 3.0 support is preliminary and experimental

[Erlend Aasland]

Is there an issue that keeps track of all the missing pieces? A "remaining 
tasks" list would be useful for involving more devs (and of course useful when 
resuming development, "now, where was I..."). A quick search on BPO revealed 
some info:

- bpo-46313: SSLObject does not raise SSLEOFError on OpenSSL 3
- bpo-40479: Port _hashlib to OpenSSL 3.0.0
- bpo-46114: OpenSSL 3.0 uses different version scheme
- bpo-38820: Make Python compatible with OpenSSL 3.0.0

Thank you for all the work you've put into this already, Christian!


Erlend

> On 9 Jan 2022, at 19:39, Christian Heimes  wrote:
> 
> Hi,
> 
> I would like to remind everybody that Python's support for OpenSSL 3.0 is 
> preliminary [1]. Python compiles with OpenSSL 3.0.0 and simple code kinda 
> works. However there are known performance regressions, missing features 
> (e.g. usedforsecurity flag), and potential bugs cause by API 
> incompatibilities.
> 
> Due to the experimental state I advise against using Python with OpenSSL 3.0 
> in production.
> 
> It may take a while until Python gains full support for the next version of 
> OpenSSL. I have shifted my personal OSS time to more fun topics like 
> performance and WASM. My work time is currently limited, too.
> 
> Christian
> 
> [1] https://docs.python.org/3/whatsnew/3.10.html#ssl
> ___
> 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/ATO4DM6QYZGLSGGDZ3TRN5X3QDD5OHOE/
> 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/ZLNVH3ZY4YC6PXKEVKS3MK6RVXXPR5SS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Steering Council reply to PEP 670 -- Convert macros to functions in the Python C API

[Erlend Aasland]

Petr, SC, thanks for your time and response! Just a quick comment:

> On 8 Feb 2022, at 11:32, Petr Viktorin  wrote:
> 
> In effect, the SC accepts the first part of the PEP, except cases where:


What status does that put the PEP in?


E

___
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/Z44YV6IXXAQ4W3HDL5UN2BR5FHYQLQ3S/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Require a C compiler supporting C99 to build Python 3.11

[Erlend Aasland]

According to the docs[^1], MSVC does _not_ support all of C99. OTOH they claim
conformance with both C11 and C17, using the /std:c11 and /std:c17 compiler
flags.


[^1]: 
https://docs.microsoft.com/en-us/cpp/build/reference/std-specify-language-standard-version?view=msvc-170

> On 8 Feb 2022, at 10:52, Petr Viktorin  wrote:
> 
> Does MSVC support all of C99? I haven't found any documentation claiming 
> that... but I'm also not familiar with MSVC.

___
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/AYZC3F73THZXNMSYWSFPXFKAUQ5NBTDO/
Code of Conduct: http://python.org/psf/codeofconduct/