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

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

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

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-Dev] How to keep Signaling NaN unchanged when convert hex to single-precision float ?

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 =

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

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] Re: PEP 563 and 649: The Great Compromise

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

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

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.

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

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],

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

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

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

@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

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

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

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

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

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

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

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

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

[Python-Dev] Announcing the CPython Docs Workgroup

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-Dev] Deferral of PEP 648 - Extensible customizations of the interpreter at startup

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:

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

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.

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

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

[Python-Dev] [Release management team communication] 3.10 feature freeze is 1 week away

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:

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

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

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

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