[Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST]

[Chris Angelico]

On Mon, Apr 26, 2021 at 2:27 PM Nathaniel Smith  wrote:
> Yeah, you've understood correctly, and you see why I wrote "both the
> current proposal and the alternative have very complex implications
> and downsides" :-)
>
> [chomp lots of very helpful summarizing]

Gotcha, thanks!

ChrisA
___
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/LCQLKVQMBLHFX74WQD3Z5BIMYT5ARQFP/
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] [Release management team communication] 3.10 feature freeze is 1 week away

[Pablo Galindo Salgado]

Hi everyone,

This is the last friendly reminder from the release management team that
Python 3.10 feature freeze is a week away (Monday, 3 May 2021).

Some important things to have in mind:

* We have some release blockers that must be resolved before the release is
done:

https://bugs.python.org/issue43908
https://bugs.python.org/issue43933
https://bugs.python.org/issue43916

If you want to help making sure that the release is on time, help us
resolving those blockers. You can also search the issues in
https://bugs.python.org/issue?@template=search&status=1 with the
"release-blocker" priority.

* Please, don't wait until the last moment (Sunday) to merge PRs into
master. This is because if many changes accumulate into a time window and
problems are detected, is much more difficult to locate the problematic
changes among the rest. If there are any problems with your commits, you
also would have the risk of having your changes reverted to unblock the
release without any time window to merge them again before feature freeze.

Please, also be aware of the following:

* No new features or improvements should be merged after the feature
freeze. From the devguide (https://devguide.python.org/devcycle/#beta) :

> After a first beta release is published, no new features are accepted.
Only bug fixes and improvements to documentation and tests can now be
committed.
> This is when core developers should concentrate on the task of fixing
regressions and other new issues filed by users who have downloaded the
alpha and beta releases.
> Being in beta can be viewed much like being in RC but without the extra
overhead of needing commit reviews.

* If your change involves some platform-specific behaviour or has a
non-trivial amount of C code, make sure you run the buildbots
in your Pull Request by using the "test-with-buildbots" label (
https://discuss.python.org/t/now-you-can-test-a-pr-with-the-buildbots-before-merging/2966
).
Alternatively you could check the buildbots post-merge in the buildbot
server:
https://buildbot.python.org/all/#/builders?tags=%2B3.x&tags=%2Bstable
This is very important because if problems are detected at the time of the
release, the release management team may have to revert
the changes and therefore those will not be included in Python 3.10.

* The master branch will be renamed to main (check our previous
communication about how this will be done and how you should
proceed
https://mail.python.org/archives/list/python-dev@python.org/thread/QWW7KGBW5UH2N5FOZOFXQBQPYELWQM3O/
)

If you have any questions or concerns, please contact me as soon as
possible.

Regards from sunny London,
Pablo Galindo Salgado
___
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/V7V5JHKZCJVE2GTI5NFEP3PNKOLH35VL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

[Baptiste Carvello]

Hi,

sorry for being late to the party, but I may not be the only one wondering…

Le 14/04/2021 à 20:56, Barry Warsaw a écrit :
> 
> I’d forgotten that this PEP was in Deferred state.  I think it should be 
> rejected and I plan on making that change.  importlib.metadata is a much 
> better approach to programmatically determining package versions.
> 
> https://docs.python.org/3/library/importlib.metadata.html#distribution-versions

This is indeed the correct approach, thanks for letting me learn this.

However, I unsuccessfully searched for the canonical way to look up the
distribution name based on either a module name or an imported module
object. Is there one?

Looks like it could be computed based on information in
"*.egg-info/installed-files.txt", but it's far from trivial. Is
"installed-files.txt" even guaranteed to exist for all distributions?

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

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

[Guido van Rossum]

One thing we could do would be to prioritize setting the IMMUTABLE flag on
the most "public" modules of the list. Of these, I would think array.array
and the three classes in _sre to be the most important.

On Mon, Apr 26, 2021 at 3:34 AM Erlend Aasland  wrote:

> 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/
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

[Python-Dev] Deferral of PEP 648 - Extensible customizations of the interpreter at startup

[Barry Warsaw]

Hi Mario,

The Python Steering Council today decided that we will defer consideration of 
PEP 648 to Python 3.11.  On March 30, 2021 we sent the following feedback to 
you via python-dev, which began a discussion thread:

https://mail.python.org/archives/list/python-dev@python.org/message/OGYZZZ4A54RI24YEKZEPPLWU4WPRLJPE/

We on the SC extend our thanks again for the PEP, and encourage you to continue 
to work on this PEP for pronouncement in Python 3.11.

Cheers,
-Barry
(on behalf of the Python Steering Council)



signature.asc
Description: Message signed with OpenPGP
___
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/Z3QKDAZARNM5KRTIKRE5AOWCC2DI2AOW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Announcing the CPython Docs Workgroup

[Mariatta]

Thanks to everyone for your patience as we worked to get the Docs Workgroup
off the ground.

As you may have remembered, Carol Willing and Ned Batchelder brought
forward the topic of CPython Documentation

at last year's Python Language Summit.

The topic has been further discussed at last year's virtual Python core
dev's sprint, and Carol has worked on the Docs WG charter
.
Please see the group charter doc linked above to understand the purpose,
goals, group values, and guidelines of the Docs WG.

We've been working to move the Docs Workgroup forward. We'll share more
details at next month's Python Language Summit. For now, here's some high
level information:

   - The initial workgroup members are: Carol, Mariatta, Ned Batchelder,
   and Julien Palard. Additionally, the Python Steering Council are permanent
   members of the WG.
   - Work on this group will be organized on the python/docs-community
   GitHub repository. The charter information and meeting notes will be posted
   there.
   - The Documentation category on Discourse
    will be the
   main communication channel between the WG and the wider Python community
   - We will scheduling monthly meetings for the team to meet
   - We’re still working on the logistics on taking in new members to the
   group. We’ll keep you updated!

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

[Python-Dev] Existing asyncio features scheduled for removal in Python 3.9 and 3.10

[Illia Volochii]

Hi everyone,

There are a couple of uncompleted asyncio feature removals scheduled
for 3.9 and 3.10 releases.
It will be great if we either complete them or reschedule before the
3.10 feature freeze. There are two stale pull requests related to
this.

Removal of @asyncio.coroutine in version 3.10 deprecated since version 3.8
Documentation: 
https://docs.python.org/3.10/library/asyncio-task.html#asyncio.coroutine
Issue deprecating the decorator: https://bugs.python.org/issue36921
Issue for the removal: https://bugs.python.org/issue43216
There is no pull request yet, mainly because of an unclarified
question regarding types.coroutine in 36921.

Prohibiting non-ThreadPoolExecutor in loop.set_default_executor
Warning scheduling the prohibiting in version 3.9:
https://github.com/python/cpython/blob/425434dadc30d96dc1c0c628f954f9b6f5edd2c9/Lib/asyncio/base_events.py#L816-L821
Issue: https://bugs.python.org/issue43234
Stale pull request: https://github.com/python/cpython/pull/24540

Prohibiting previously deprecated operations on asyncio.trsock.TransportSocket
Warning scheduling the prohibiting in version 3.9:
https://github.com/python/cpython/blob/425434dadc30d96dc1c0c628f954f9b6f5edd2c9/Lib/asyncio/trsock.py#L20-L24
Issue: https://bugs.python.org/issue43232
Stale pull request: https://github.com/python/cpython/pull/24538

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

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

[Brett Cannon]

On Mon, Apr 26, 2021 at 9:37 AM Baptiste Carvello <
devel2...@baptiste-carvello.net> wrote:

> Hi,
>
> sorry for being late to the party, but I may not be the only one wondering…
>
> Le 14/04/2021 à 20:56, Barry Warsaw a écrit :
> >
> > I’d forgotten that this PEP was in Deferred state.  I think it should be
> rejected and I plan on making that change.  importlib.metadata is a much
> better approach to programmatically determining package versions.
> >
> >
> https://docs.python.org/3/library/importlib.metadata.html#distribution-versions
>
> This is indeed the correct approach, thanks for letting me learn this.
>
> However, I unsuccessfully searched for the canonical way to look up the
> distribution name based on either a module name or an imported module
> object. Is there one?
>

If you mean how to tie a module back to its name on PyPI, you should be
able to look up the "Name" in the project's metadata:
https://docs.python.org/3/library/importlib.metadata.html#distribution-metadata
.

-Brett


>
> Looks like it could be computed based on information in
> "*.egg-info/installed-files.txt", but it's far from trivial. Is
> "installed-files.txt" even guaranteed to exist for all distributions?
>
> Cheers,
> Baptiste
> ___
> 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/SVQ777EGE56OIWHIKPCURGPXGMUJ7HCY/
> 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/OMHAJ7WU7TVM6WWQHYPI3AYGORCKUNAK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Existing asyncio features scheduled for removal in Python 3.9 and 3.10

[Luciano Ramalho]

I don't understand how it's possible to "Deprecate @coroutine for sake
of async def" when native coroutines ultimately depend on a generator
to be driven by the event loop.

What am I missing?

Perhaps in asyncio the generator magic is now written in C, but as
Nathaniel J. Smith points out, Trio and Curio both use Python
generators at their cores.

Cheers,

Luciano

On Mon, Apr 26, 2021 at 5:55 PM Illia Volochii  wrote:
>
> Hi everyone,
>
> There are a couple of uncompleted asyncio feature removals scheduled
> for 3.9 and 3.10 releases.
> It will be great if we either complete them or reschedule before the
> 3.10 feature freeze. There are two stale pull requests related to
> this.
>
> Removal of @asyncio.coroutine in version 3.10 deprecated since version 3.8
> Documentation: 
> https://docs.python.org/3.10/library/asyncio-task.html#asyncio.coroutine
> Issue deprecating the decorator: https://bugs.python.org/issue36921
> Issue for the removal: https://bugs.python.org/issue43216
> There is no pull request yet, mainly because of an unclarified
> question regarding types.coroutine in 36921.
>
> Prohibiting non-ThreadPoolExecutor in loop.set_default_executor
> Warning scheduling the prohibiting in version 3.9:
> https://github.com/python/cpython/blob/425434dadc30d96dc1c0c628f954f9b6f5edd2c9/Lib/asyncio/base_events.py#L816-L821
> Issue: https://bugs.python.org/issue43234
> Stale pull request: https://github.com/python/cpython/pull/24540
>
> Prohibiting previously deprecated operations on asyncio.trsock.TransportSocket
> Warning scheduling the prohibiting in version 3.9:
> https://github.com/python/cpython/blob/425434dadc30d96dc1c0c628f954f9b6f5edd2c9/Lib/asyncio/trsock.py#L20-L24
> Issue: https://bugs.python.org/issue43232
> Stale pull request: https://github.com/python/cpython/pull/24538
>
> Thanks,
> Illia
> ___
> 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/PLSLFTJXY2JUIRGJARBER4SRUWDXX2AQ/
> Code of Conduct: http://python.org/psf/codeofconduct/



-- 
Luciano Ramalho
|  Author of Fluent Python (O'Reilly, 2015)
| http://shop.oreilly.com/product/0636920032519.do
|  Technical Principal at ThoughtWorks
|  Twitter: @ramalhoorg
___
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/L3Y4TWVWYE3PD3O5BQIW35LYE55EBTCU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Deprecate Py_TRASHCAN_SAFE_BEGIN/END in 3.10?

[Irit Katriel via Python-Dev]

Re https://bugs.python.org/issue40608.

I think it will be an act of kindness to
deprecate Py_TRASHCAN_SAFE_BEGIN/END in 3.10 and tell people to use
Py_TRASHCAN_BEGIN/END
instead.

TL;DR: There was a change in 3.8 that introduced the latter while leaving
the former for backwards compatibility, but also inadvertently breaking
them. This is not an easy bug to deal with in the wild, we found it because
we have a unit test in our codebase referencing https://
bugs.python.org/issue16602.  A deprecation note pointing to the new macros
would have made it easier.

Is there any reason not to deprecate the old macros?

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

[Python-Dev] Re: Existing asyncio features scheduled for removal in Python 3.9 and 3.10

[Nathaniel Smith]

@asyncio.coroutine and @types.coroutine are different beasts.
@asyncio.coroutine is the deprecated one; @types.coroutine is
lower-level and not deprecated.

On Mon, Apr 26, 2021 at 2:48 PM Luciano Ramalho  wrote:
>
> I don't understand how it's possible to "Deprecate @coroutine for sake
> of async def" when native coroutines ultimately depend on a generator
> to be driven by the event loop.
>
> What am I missing?
>
> Perhaps in asyncio the generator magic is now written in C, but as
> Nathaniel J. Smith points out, Trio and Curio both use Python
> generators at their cores.
>
> Cheers,
>
> Luciano
>
> On Mon, Apr 26, 2021 at 5:55 PM Illia Volochii  
> wrote:
> >
> > Hi everyone,
> >
> > There are a couple of uncompleted asyncio feature removals scheduled
> > for 3.9 and 3.10 releases.
> > It will be great if we either complete them or reschedule before the
> > 3.10 feature freeze. There are two stale pull requests related to
> > this.
> >
> > Removal of @asyncio.coroutine in version 3.10 deprecated since version 3.8
> > Documentation: 
> > https://docs.python.org/3.10/library/asyncio-task.html#asyncio.coroutine
> > Issue deprecating the decorator: https://bugs.python.org/issue36921
> > Issue for the removal: https://bugs.python.org/issue43216
> > There is no pull request yet, mainly because of an unclarified
> > question regarding types.coroutine in 36921.
> >
> > Prohibiting non-ThreadPoolExecutor in loop.set_default_executor
> > Warning scheduling the prohibiting in version 3.9:
> > https://github.com/python/cpython/blob/425434dadc30d96dc1c0c628f954f9b6f5edd2c9/Lib/asyncio/base_events.py#L816-L821
> > Issue: https://bugs.python.org/issue43234
> > Stale pull request: https://github.com/python/cpython/pull/24540
> >
> > Prohibiting previously deprecated operations on 
> > asyncio.trsock.TransportSocket
> > Warning scheduling the prohibiting in version 3.9:
> > https://github.com/python/cpython/blob/425434dadc30d96dc1c0c628f954f9b6f5edd2c9/Lib/asyncio/trsock.py#L20-L24
> > Issue: https://bugs.python.org/issue43232
> > Stale pull request: https://github.com/python/cpython/pull/24538
> >
> > Thanks,
> > Illia
> > ___
> > 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/PLSLFTJXY2JUIRGJARBER4SRUWDXX2AQ/
> > Code of Conduct: http://python.org/psf/codeofconduct/
>
>
>
> --
> Luciano Ramalho
> |  Author of Fluent Python (O'Reilly, 2015)
> | http://shop.oreilly.com/product/0636920032519.do
> |  Technical Principal at ThoughtWorks
> |  Twitter: @ramalhoorg
> ___
> 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/L3Y4TWVWYE3PD3O5BQIW35LYE55EBTCU/
> Code of Conduct: http://python.org/psf/codeofconduct/



-- 
Nathaniel J. Smith -- https://vorpus.org
___
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/V6OZH6YFUOV5XPXKRWRBKRKFDJXTJQR3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

[Stestagg]

On Mon, Apr 26, 2021 at 10:31 PM Brett Cannon  wrote:

>
>
> On Mon, Apr 26, 2021 at 9:37 AM Baptiste Carvello <
> devel2...@baptiste-carvello.net> wrote:
>
>> Hi,
>>
>> sorry for being late to the party, but I may not be the only one
>> wondering…
>>
>> Le 14/04/2021 à 20:56, Barry Warsaw a écrit :
>> >
>> > I’d forgotten that this PEP was in Deferred state.  I think it should
>> be rejected and I plan on making that change.  importlib.metadata is a much
>> better approach to programmatically determining package versions.
>> >
>> >
>> https://docs.python.org/3/library/importlib.metadata.html#distribution-versions
>>
>> This is indeed the correct approach, thanks for letting me learn this.
>>
>> However, I unsuccessfully searched for the canonical way to look up the
>> distribution name based on either a module name or an imported module
>> object. Is there one?
>>
>
> If you mean how to tie a module back to its name on PyPI, you should be
> able to look up the "Name" in the project's metadata:
> https://docs.python.org/3/library/importlib.metadata.html#distribution-metadata
> .
>
>
The missing bit here, for me, is how do you map a module back to it's
project (distribution)?

For example:

```
>>> import bs4
>>> bs4.__version__
'4.9.1'
>>> importlib.metadata.metadata('bs4')
PackageNotFoundError: bs4
```

This is because the distribution calls itself 'beautifulsoup4' instead.

The same goes for another package: `umap`, for which the distribution is
called `umap-learn`


This is the best I could come up with from reading the docs:

import bs4  #<- This is the module we want the version of

import importlib
import sys
from itertools import chain
from pathlib import Path

loaders = sys.meta_path

target_path = Path(bs4.__file__)

distros = list(chain(*(finder.find_distributions() for finder in
loaders if hasattr(finder, 'find_distributions'
distros_files = chain(*(f for f in (d.files for d in distros)))
distro_files = [(d, d.locate_file(f)) for d in distros if d.files for f
in d.files]
matching = [d for d, f in distro_files if f == target_path]

for match in matching:
print("Found Version:", match.version)

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

[Python-Dev] Re: Existing asyncio features scheduled for removal in Python 3.9 and 3.10

[Luciano Ramalho]

On Mon, Apr 26, 2021 at 7:04 PM Nathaniel Smith  wrote:
>
> @asyncio.coroutine and @types.coroutine are different beasts.
> @asyncio.coroutine is the deprecated one; @types.coroutine is
> lower-level and not deprecated.

According to @Guido van Rossum in this message of Feb. 19, 2021 [1],
@types.coroutine was not deprecated "due to an oversight"

[1] 
https://mail.python.org/archives/list/python-dev@python.org/message/CEQQLON7A5D64V7VAPH7OCTULG2HZPHQ/

Relevant quote from GvR:

"""
It looks like types.coroutine will remain (it does not contain code to
warn about deprecation like asyncio.coroutine does), but I don't think
it is required to end a chain of coroutines -- it may have been an
oversight that we did not start deprecating it. (But in any case it
won't be supported by asyncio.)
"""

At that time, Guido presented an explanation about why asyncio can
live without it. I thought it made sense to me at the time, but now I
realize I did not understand the solution that involves a trampoline.
It's OK, I am not looking for another explanation at this time.

I was confused and concerned that this could affect Curio and Trio.

Sorry for the noise.

Cheers,

Luciano


On Mon, Apr 26, 2021 at 7:04 PM Nathaniel Smith  wrote:
>
> @asyncio.coroutine and @types.coroutine are different beasts.
> @asyncio.coroutine is the deprecated one; @types.coroutine is
> lower-level and not deprecated.
>
> On Mon, Apr 26, 2021 at 2:48 PM Luciano Ramalho  wrote:
> >
> > I don't understand how it's possible to "Deprecate @coroutine for sake
> > of async def" when native coroutines ultimately depend on a generator
> > to be driven by the event loop.
> >
> > What am I missing?
> >
> > Perhaps in asyncio the generator magic is now written in C, but as
> > Nathaniel J. Smith points out, Trio and Curio both use Python
> > generators at their cores.
> >
> > Cheers,
> >
> > Luciano
> >
> > On Mon, Apr 26, 2021 at 5:55 PM Illia Volochii  
> > wrote:
> > >
> > > Hi everyone,
> > >
> > > There are a couple of uncompleted asyncio feature removals scheduled
> > > for 3.9 and 3.10 releases.
> > > It will be great if we either complete them or reschedule before the
> > > 3.10 feature freeze. There are two stale pull requests related to
> > > this.
> > >
> > > Removal of @asyncio.coroutine in version 3.10 deprecated since version 3.8
> > > Documentation: 
> > > https://docs.python.org/3.10/library/asyncio-task.html#asyncio.coroutine
> > > Issue deprecating the decorator: https://bugs.python.org/issue36921
> > > Issue for the removal: https://bugs.python.org/issue43216
> > > There is no pull request yet, mainly because of an unclarified
> > > question regarding types.coroutine in 36921.
> > >
> > > Prohibiting non-ThreadPoolExecutor in loop.set_default_executor
> > > Warning scheduling the prohibiting in version 3.9:
> > > https://github.com/python/cpython/blob/425434dadc30d96dc1c0c628f954f9b6f5edd2c9/Lib/asyncio/base_events.py#L816-L821
> > > Issue: https://bugs.python.org/issue43234
> > > Stale pull request: https://github.com/python/cpython/pull/24540
> > >
> > > Prohibiting previously deprecated operations on 
> > > asyncio.trsock.TransportSocket
> > > Warning scheduling the prohibiting in version 3.9:
> > > https://github.com/python/cpython/blob/425434dadc30d96dc1c0c628f954f9b6f5edd2c9/Lib/asyncio/trsock.py#L20-L24
> > > Issue: https://bugs.python.org/issue43232
> > > Stale pull request: https://github.com/python/cpython/pull/24538
> > >
> > > Thanks,
> > > Illia
> > > ___
> > > 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/PLSLFTJXY2JUIRGJARBER4SRUWDXX2AQ/
> > > Code of Conduct: http://python.org/psf/codeofconduct/
> >
> >
> >
> > --
> > Luciano Ramalho
> > |  Author of Fluent Python (O'Reilly, 2015)
> > | http://shop.oreilly.com/product/0636920032519.do
> > |  Technical Principal at ThoughtWorks
> > |  Twitter: @ramalhoorg
> > ___
> > 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/L3Y4TWVWYE3PD3O5BQIW35LYE55EBTCU/
> > Code of Conduct: http://python.org/psf/codeofconduct/
>
>
>
> --
> Nathaniel J. Smith -- https://vorpus.org



-- 
Luciano Ramalho
|  Author of Fluent Python (O'Reilly, 2015)
| http://shop.oreilly.com/product/0636920032519.do
|  Technical Principal at ThoughtWorks
|  Twitter: @ramalhoorg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3

[Python-Dev] Re: str() vs format(): trivia question

[Ethan Furman]

On 4/20/21 2:11 PM, MRAB wrote:
> On 2021-04-20 20:42, Ethan Furman wrote:

>> The deprecation period will give that user, and others like them, time to 
add their own Enum base classes with the
>> `__format__` method they desire.
>
> Couldn't the format accept 'd' if they want an int, i.e. f"{Color.RED:d}"?


Yes, in fact.  And that even works now.  Thanks!

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

[Python-Dev] Re: PEP 563 and 649: The Great Compromise

[Carl Meyer]

On Sun, Apr 25, 2021 at 10:30 AM Brett Cannon  wrote:
> I know I would be curious, especially if backwards compatibility can be 
> solved reasonably (for those that haven't lived this, deferred execution 
> historically messes up code relying on import side-effects and trackbacks are 
> weird as they occur at access time instead of at the import statement).

I had been assuming that due to backward compatibility and performance
of `LOAD_GLOBAL`, this would need to be a new form of import,
syntactically distinguished. But the performance and some of the
compatibility concerns could be alleviated by making all imports
deferred by default, and then resolving any not-yet-resolved imports
at the end of module execution. This is perhaps even better for the
non-typing case, since it would generally fix most import cycle
problems in Python. (It would be sort of equivalent to moving all
imports that aren't needed for module execution to the end of the
module, which is another ugly but effective workaround for cycles.) It
would have the downside that type-only imports which will never be
needed at runtime at all will still be imported, even if
`__annotations__` are never accessed.

I think it's still problematic for backward compatibility with import
side effects, though, so if we did this at the very least it would
have to be behind a `__future__` import.

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

[Python-Dev] bz2.BZ2File doesn't support name?

[roy]

I was surprised recently to discover that BZ2File (at least in 3.7) doesn't 
have a name attribute.  Is there some fundamental reason name couldn't be 
supported, or is it just a bug that it wasn't implemented?
___
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/N3Q7AN5ISRGKS76GT4YSJX2SV6BNQIWM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] How to keep Signaling NaN unchanged when convert hex to single-precision float ?

[Huang, Yang]

Hi,

Code snippet 1 and 2 convert an hex to float, but the SNaN is changed to QNaN 
automatically. It follows IEEE 754 behavior.
While Code snippet 3 converts an hex to double, and  the SNaN keeps.
Is there any solution to keep SNaN float unchanged in Code snippet 1 and 2?


  1.  >>> i = int('7f81', 16)
>>> cp = pointer(c_uint32(i))
>>> fp = cast(cp, POINTER(c_float))
>>> print(fp.contents.value) # nan
>>> print(struct.pack(">f", fp.contents.value).hex())
7fc1


  1.  >>> f = struct.unpack('!f', bytes.fromhex('7f81'))[0]

>>> f  # nan

>>> hex(struct.unpack('>> i = int('7FF1', 16)

>>> cp = pointer(c_uint64(i))

>>> fp = cast(cp, POINTER(c_double))

>>> print(fp.contents.value)

nan

>>> print(struct.pack(">d", fp.contents.value).hex())

7ff1

Thank you in advance!

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

[Python-Dev] Re: bz2.BZ2File doesn't support name?

[Paul Bryan]

I think one of the issues is that BZ2File accepts the filename as a
name or as a file-like object!

I don't see why it couldn't be enhanced to provide the filename though
(by pulling it from the fp). Meanwhile, the ugly way to get the
filename from a BZ2File object:

pbryan@dynamo:~$ python3
Python 3.9.3 (default, Apr  8 2021, 23:35:02) 
[GCC 10.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import bz2
>>> f = bz2.BZ2File("test.bz2")
>>> f._fp.name
'test.bz2'
>>> 

Paul


On Tue, 2021-04-27 at 04:04 +, r...@panix.com wrote:
> I was surprised recently to discover that BZ2File (at least in 3.7)
> doesn't have a name attribute.  Is there some fundamental reason name
> couldn't be supported, or is it just a bug that it wasn't
> implemented?
> ___
> 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/N3Q7AN5ISRGKS76GT4YSJX2SV6BNQIWM/
> 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/S4KSWVFLM5JEZCI3OFWJSEKR3JUJL6XL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: bz2.BZ2File doesn't support name?

[Senthil Kumaran]

There is an open bug report https://bugs.python.org/issue24258

I guess it was overlooked. It could be a good task for someone interested.
Please add me as a reviewer if you submit a patch, I can help review and
move it forward.

On Mon, Apr 26, 2021 at 9:22 PM  wrote:

> I was surprised recently to discover that BZ2File (at least in 3.7)
> doesn't have a name attribute.  Is there some fundamental reason name
> couldn't be supported, or is it just a bug that it wasn't implemented?
> ___
> 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/N3Q7AN5ISRGKS76GT4YSJX2SV6BNQIWM/
> 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/NCGH6EYRIDFANEAWDQ3KVE6LFXNS4ROV/
Code of Conduct: http://python.org/psf/codeofconduct/