[Python-Dev] Re: Security releases of CPython

On Fri, Feb 19, 2021 at 10:53 PM Christian Heimes wrote: > On 19/02/2021 23.22, Stestagg wrote: > > The thing that stood out from this conversation, for me, is: Releases > > are too hard, and there’s a risk of not having enough volunteers as a > > result. > > > > How hard is it to fix that? > > A

[Python-Dev] Re: Security releases of CPython

On Fri, Feb 19, 2021 at 3:10 PM Stestagg wrote: > > > On Fri, 19 Feb 2021 at 22:50, Christian Heimes > wrote: > >> On 19/02/2021 23.22, Stestagg wrote: >> > The thing that stood out from this conversation, for me, is: Releases >> > are too hard, and there’s a risk of not having enough volunteers

[Python-Dev] Re: PEP 653: Precise Semantics for Pattern Matching

On Fri, 19 Feb 2021 at 15:41, Tobias Kohn wrote: > > Hi Mark, > > Thank you for your proposal to try and have more precise semantics for > pattern matching. Of course, the proposal primarily introduces a new and > extended protocol for pattern matching, upon which the 'semantics' is then > bas

[Python-Dev] Re: PEP 653: Precise Semantics for Pattern Matching

Oscar Benjamin wrote: > Under PEP 634 in general, for any class C, a pattern C(x) matches an object > C(x, y) and there's no way for C to override that. To me that is sufficiently > unintuitive in the abstract that no example is really needed to see where > there is room for improvement. We ori

[Python-Dev] Re: PEP 653: Precise Semantics for Pattern Matching

On Fri, 19 Feb 2021 at 16:27, Tobias Kohn wrote: > > Quoting Oscar Benjamin : > > > I'm not entirely sure but I think that with PEP 653 you can implement this > > like: > > > > def __deconstruct__(obj): > > if obj.step != 1: > > return obj.start, obj.stop, obj.step > > eli

[Python-Dev] Re: Security releases of CPython

On Fri, 19 Feb 2021 at 22:50, Christian Heimes wrote: > On 19/02/2021 23.22, Stestagg wrote: > > The thing that stood out from this conversation, for me, is: Releases > > are too hard, and there’s a risk of not having enough volunteers as a > > result. > > > > How hard is it to fix that? > > Actu

[Python-Dev] Re: Security releases of CPython

On 19/02/2021 23.22, Stestagg wrote: > The thing that stood out from this conversation, for me, is: Releases > are too hard, and there’s a risk of not having enough volunteers as a > result. > > How hard is it to fix that?  Actually it's easy to fix! The PSF needs needs sufficient money to hire

[Python-Dev] Re: Security releases of CPython

The thing that stood out from this conversation, for me, is: Releases are too hard, and there’s a risk of not having enough volunteers as a result. How hard is it to fix that? Steve On Fri, 19 Feb 2021 at 22:05, Terry Reedy wrote: > On 2/19/2021 5:11 AM, Michał Górny wrote: > > On Thu, 2021-02

[Python-Dev] Re: Security releases of CPython

On 2/19/2021 5:11 AM, Michał Górny wrote: On Thu, 2021-02-11 at 23:24 -0500, Terry Reedy wrote: Releases are not just a push of a button. Make the release job too onerous, and there might not be any more volunteers. While I understand your concerns and sympathize with them, Your accusatio

[Python-Dev] Re: Clarification on the removal of generator-based coroutines in 3.10

Thanks for Mr David beazley's materials online, a beginner like me was able to understand this thread from the beginning. Rarely do i get to understand what the folks in here are rumbling about. He was also teaching compiler theory at university. Don't know if he ever contributed to CPython. Here'

[Python-Dev] Re: Clarification on the removal of generator-based coroutines in 3.10

On Thu, Feb 18, 2021 at 9:04 PM Guido van Rossum wrote: > On Thu, Feb 18, 2021 at 8:23 PM Luciano Ramalho > wrote: > >> Thanks for your reply, Guido. >> >> On Fri, Feb 19, 2021 at 12:07 AM Guido van Rossum >> wrote: >> > Reading the doc section you link to, it's pretty clear that >> `@asyncio.c

[Python-Dev] Re: Security releases of CPython

On Fri, Feb 19, 2021 at 2:16 AM Michał Górny wrote: > On Thu, 2021-02-11 at 23:24 -0500, Terry Reedy wrote: > > On 2/11/2021 3:23 PM, Michał Górny wrote: > > > Hello, > > > > > > I'm the primary maintainer of CPython packages in Gentoo. I would like > > > to discuss possible improvement to the re

[Python-Dev] Re: PEP 653: Precise Semantics for Pattern Matching

Hi Mark, Quoting Mark Shannon : Hi Tobias, [...] But they are not referenced in PEP 634. I shouldn't have to trawl the internet to find the rejected ideas section. https://dl.acm.org/doi/10.1145/3426422.3426983 That paper describes a `__match__` method, which is absent from PEP 634. W

[Python-Dev] Re: PEP 653: Precise Semantics for Pattern Matching

Hi Tobias, On 19/02/2021 5:57 pm, Tobias Kohn wrote: > Hi Mark, > > Quoting Mark Shannon mailto:m...@hotpy.org>>: > >> [...] >> >> If you had published these "more complicated, powerful protocols", you >> might be able to claim that this is a "rehash". >> But you didn't. >> > I would say that the

[Python-Dev] Re: Python 0.9.1

> In conversation with Dan, I have fixed my conda package (but overwritten the same version). I needed to add this to the build: > > # sudo apt-get install gcc-multilib > CC='gcc -m32' make python Thanks. That fixes it for me as well. I never even looked at intobject.c, since it compiled out of t

[Python-Dev] Summary of Python tracker Issues

ACTIVITY SUMMARY (2021-02-12 - 2021-02-19) Python tracker at https://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open7428 (+13) closed 47578 (+49) total 55006 (+62) Open issues wi

[Python-Dev] Re: PEP 653: Precise Semantics for Pattern Matching

Hi Mark, Quoting Mark Shannon : [...] If you had published these "more complicated, powerful protocols", you might be able to claim that this is a "rehash". But you didn't.   I would say that these ideas have been quite prominently published: https://www.python.org/dev/peps/pep-0622/#cus

[Python-Dev] Re: Python 0.9.1

In conversation with Dan, I have fixed my conda package (but overwritten the same version). I needed to add this to the build: # sudo apt-get install gcc-multilib CC='gcc -m32' make python I don't have 32-bit headers by default anymore on my distro. With that change, I can run: % conda install

[Python-Dev] Re: PEP 653: Precise Semantics for Pattern Matching

Hi Brandt, On 18/02/2021 5:32 pm, Brandt Bucher wrote: Thanks for taking the time to work on this, Mark. Overall, I'm skeptical of this proposal. It seems like it takes a lot of "simple" things and makes them quite complex, and takes many "static" things and makes them quite dynamic. I feel t

[Python-Dev] Re: PEP 653: Precise Semantics for Pattern Matching

Hi, I wish I'd read this before replaying your last email On 18/02/2021 6:49 pm, Brandt Bucher wrote: Brandt Bucher wrote: For a pattern with no positional subpatterns, such as like `C()` or `C(x=x, y=y, z=z)`: ... It also appears that we lose a lot of expressive "idioms" by requiring `__

[Python-Dev] Re: PEP 597 bikeshedding: envvar / option name.

As long as we don't encounter sys.flags.pen_is_mightier type of cases, I guess it'll be OK. :-) On Fri, 2021-02-19 at 12:08 +0100, Victor Stinner wrote: > Environment variable names with underscore would be more readable, > but > IMO consistency with all existing names matters more: > https://docs

[Python-Dev] [RELEASE] Python 3.9.2 and 3.8.8 are now available

Convinced of the wonders of free two-day deliveries, I’m pleased to present you Python 3.9.2 and 3.8.8. Get them from: https://www.python.org/downloads/release/python-392/ https://www.python.org/downloads/release/python-388/

[Python-Dev] Re: PEP 653: Precise Semantics for Pattern Matching

Hi Oscar, Quoting Oscar Benjamin : Yes, thanks Mark. I'm not sure I've fully understood the PEP yet but I can see some parts that I definitely like. [...] As I have just noted in my response to Mark, the aspect with the "deconstructor" (or `__match__` protocol as we called it) is defini

[Python-Dev] Re: Clarification on the removal of generator-based coroutines in 3.10

I think that for this functionality (force the event loop to run), the trampoline just needs to define a function that returns a magic value and special-case that. The helper then becomes def __sleep0(): await The magic object may have to be something with an __await__() method. On Fri, Feb

[Python-Dev] Re: PEP 653: Precise Semantics for Pattern Matching

Hi Mark, Thank you for your proposal to try and have more precise semantics for pattern matching.  Of course, the proposal primarily introduces a new and extended protocol for pattern matching, upon which the 'semantics' is then based.  I think it is important to recognise and discuss your

[Python-Dev] Re: PEP 597 bikeshedding: envvar / option name.

Environment variable names with underscore would be more readable, but IMO consistency with all existing names matters more: https://docs.python.org/dev/using/cmdline.html#environment-variables So I prefer PYTHONWARNDEFAULTENCODING env var and sys.flags.warn_default_encoding attribute names. Vict

[Python-Dev] Re: Security releases of CPython

On Thu, 2021-02-11 at 23:24 -0500, Terry Reedy wrote: > On 2/11/2021 3:23 PM, Michał Górny wrote: > > Hello, > > > > I'm the primary maintainer of CPython packages in Gentoo. I would like > > to discuss possible improvement to the release process in order to > > accelerate releasing security fixes

[Python-Dev] Re: Security releases of CPython

On Tue, 2021-02-16 at 00:53 +0100, Victor Stinner wrote: > Hi Michał, > > I created https://python-security.readthedocs.io/ website to track > known Python vulnerabilities to help me checking if fixes are > backported to all supported Python branches. I'm maintaing this list > manually, it's far f

[Python-Dev] Re: Clarification on the removal of generator-based coroutines in 3.10

Hello, On Fri, 19 Feb 2021 06:29:35 -0300 Luciano Ramalho wrote: > On Fri, Feb 19, 2021 at 4:08 AM Guido van Rossum > wrote: > > Can you try this? > > > > async def __sleep(self): > > await None > > That didn't work*, but this does: > > async def __sleep(): > return None > > Was th

[Python-Dev] Re: Clarification on the removal of generator-based coroutines in 3.10

On Fri, Feb 19, 2021 at 6:29 AM Luciano Ramalho wrote: > async def __sleep(): > return None Sorry, I meant to write: async def __sleep0(): return None Since the idea is to replace the generator-based coroutine `__sleep0` in tasks.py [1] with a native coroutine. [1] https://github.com/

[Python-Dev] Re: Clarification on the removal of generator-based coroutines in 3.10

On Fri, Feb 19, 2021 at 4:08 AM Guido van Rossum wrote: > Can you try this? > > async def __sleep(self): > await None That didn't work*, but this does: async def __sleep(): return None Was that the idea? (*) TypeError: object NoneType can't be used in 'await' expression > > On Thu, Fe

[Python-Dev] Re: PEP 597 bikeshedding: envvar / option name.

On Mon, Feb 15, 2021 at 3:00 PM Paul Bryan wrote: > > Let the bikeshedding begin. How about with the underscores in place? More > readable to my eyes. > I agree with you. Although it is not consistent with existing many option names, it is much more readable. Ivan, Victor, what do you think? ab

[Python-Dev] Re: Clarification on the removal of generator-based coroutines in 3.10

On Fri, Feb 19, 2021 at 4:08 AM Guido van Rossum wrote: > Can you try this? > > async def __sleep(self): > await None Perhaps you meant this? async def __sleep0(): await None Either way, `await None` raises "TypeError: object NoneType can't be used in 'await' expression". Maybe I mis