[Python-Dev] Timing for removing legacy Unicode APIs deprecated by PEP 393 (original) (raw)
INADA Naoki songofacandy at gmail.com
Thu Apr 19 02:39:21 EDT 2018
- Previous message (by thread): [Python-Dev] Timing for removing legacy Unicode APIs deprecated by PEP 393
- Next message (by thread): [Python-Dev] [RELEASE] Python 2.7.15 release candidate 1
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
I suppose that many users will start porting to Python 3 only in 2020, after 2.7 EOL. After that time we shouldn't support compatibility with 2.7 and can start emitting deprecation warnings at runtime. After 1 or 2 releases after that we can make corresponding public API always failing and remove private API and data fields.
Python 3.8 is planned to be released at 2019-10-20. It's just before 2.7 EOL. My current thought is:
In 3.8, we make sure deprecated API emits warning (compile time if possible, runtime for others).
If the deprecation is adopted smoothly, drop them in 3.9 (Mid 2021). Otherwise, removal is postponed to 3.10 (Late 2023).
There are other functions which expect that data is aligned to sizeof(long) or 8 bytes. Siphash hashing is special because it is called not just for strings and bytes, but for memoryview, which doesn't guarantee any alignment.
Oh, I'm sad about hear that...
Note that after removing the wchart* field the gap will not gone, because the size of the structure should be a multiple of the alignment of the first field (which is a pointer).
Of course, we need hack for packing.
-- INADA Naoki <songofacandy at gmail.com>
- Previous message (by thread): [Python-Dev] Timing for removing legacy Unicode APIs deprecated by PEP 393
- Next message (by thread): [Python-Dev] [RELEASE] Python 2.7.15 release candidate 1
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]