[Python-Dev] Re: Please be more precise when commenting on PEP 611.

On 12/13/19 12:27 AM, Steven D'Aprano wrote: > On Wed, Dec 11, 2019 at 10:30:15PM -0500, Richard Damon wrote: > >> I will way that in my many years of >> programming experience I can't think of any great cases where a language >> as part of the language definition limited to 'size' of a program to

[Python-Dev] Re: Please be more precise when commenting on PEP 611.

On Wed, Dec 11, 2019 at 10:30:15PM -0500, Richard Damon wrote: > I will way that in my many years of > programming experience I can't think of any great cases where a language > as part of the language definition limited to 'size' of a program to > good effect, Good thing that's not what the PEP

[Python-Dev] Re: Please be more precise when commenting on PEP 611.

On Thu., 12 Dec. 2019, 10:03 pm Mark Shannon, wrote: > > Explicit limits are much easier to test. Does code outside the limit > fail in the expected fashion and code just under the limit work correctly? > > What I want, is to allow more efficient use of resources without > inconveniently low or u

[Python-Dev] Re: Please be more precise when commenting on PEP 611.

On 11/12/2019 3:56 pm, Guido van Rossum wrote: On Wed, Dec 11, 2019 at 2:14 AM Mark Shannon > wrote: If the status quo were the result of considered decision, then it would of course need considerable justification. If, as is the case here, the status quo is

[Python-Dev] Re: Please be more precise when commenting on PEP 611.

I've been restraining myself from commenting in this threads, as I don't know enough details of the implementation of Python to make reasoned arguments on how much such limits would help in the efficiency for running a Python program.  I will way that in my many years of programming experience I ca

[Python-Dev] Re: Please be more precise when commenting on PEP 611.

On Wed, Dec 11, 2019 at 2:14 AM Mark Shannon wrote: > > If the status quo were the result of considered decision, then it would > of course need considerable justification. > If, as is the case here, the status quo is a result of historical > accident and/or implementation details, then I think a

[Python-Dev] Re: Please be more precise when commenting on PEP 611.

On 10/12/2019 7:24 am, Kyle Stanley wrote: Chris Angelico wrote: > We have people who believe that a bit > mask will slow things down, others who claim that improved cache > locality will speed things up, and Mark asks us to please justify our > objections with numbers. But surely it's up

[Python-Dev] Re: Please be more precise when commenting on PEP 611.

On 09/12/2019 10:29 pm, Gregory P. Smith wrote: My overall problem with the PEP and a reason I'd reject it by default it that it is asking to pre-emptively impose limits on things, some of which we believe would cause problems to existing long running applications (limiting the total number o

[Python-Dev] Re: Please be more precise when commenting on PEP 611.

On 10/12/2019 00:01, Chris Angelico wrote: Exactly. Yes, I know that I massively oversimplified things in that post. But you nonetheless acknowledge here that we are*still* quite lacking in any actual evidence. We have people who believe that a bit mask will slow things down, others who claim th

[Python-Dev] Re: Please be more precise when commenting on PEP 611.

Chris Angelico wrote: > We have people who believe that a bit > mask will slow things down, others who claim that improved cache > locality will speed things up, and Mark asks us to please justify our > objections with numbers. But surely it's up to Mark to show numbers > first? +1. While it would

[Python-Dev] Re: Please be more precise when commenting on PEP 611.

On Tue, Dec 10, 2019 at 10:51 AM Steven D'Aprano wrote: > > On Mon, Dec 09, 2019 at 02:12:37PM -0800, Nathaniel Smith wrote: > > > > On 09/12/2019 2:15 pm, Chris Angelico wrote: > > > You: "We should limit things. Stuff will be faster." > > > Others: "Really? Because bit masking is work. It'll be

[Python-Dev] Re: Please be more precise when commenting on PEP 611.

On Mon, Dec 09, 2019 at 02:12:37PM -0800, Nathaniel Smith wrote: > > > On 09/12/2019 2:15 pm, Chris Angelico wrote: > > You: "We should limit things. Stuff will be faster." > > Others: "Really? Because bit masking is work. It'll be slower." I'm not an expert, but the impression I've got from vario

[Python-Dev] Re: Please be more precise when commenting on PEP 611.

My overall problem with the PEP and a reason I'd reject it by default it that it is asking to pre-emptively impose limits on things, some of which we believe would cause problems to existing long running applications (limiting the total number of types for example), without having actually demonstr

[Python-Dev] Re: Please be more precise when commenting on PEP 611.

> > On 09/12/2019 2:15 pm, Chris Angelico wrote: > You: "We should limit things. Stuff will be faster." > Others: "Really? Because bit masking is work. It'll be slower." > You: "Maybe we limit it somewhere else, whatever. It'll be faster." > Others: "Will it? How much faster?" > You: "It'll be fast

[Python-Dev] Re: Please be more precise when commenting on PEP 611.

Mark wrote, in reply to me: > On 09/12/2019 3:01 pm, Paddy McCarthy wrote: > > "Bear in mind that the costs of higher limits are paid by everyone, but > > the benefits are gained by few." > > > > Is there some evidence for the above statement? One of the issues with C > > programming is the need f

[Python-Dev] Re: Please be more precise when commenting on PEP 611.

I think a much more sensible approach than mandating a limit because "who knows, it might speed something up" would be finding the speedup first. Probably that means one limit at a time too. E.g. maybe some patch imposes the 1 million LOC limit and demonstrates a repeatable benchmark improvement b

[Python-Dev] Re: Please be more precise when commenting on PEP 611.

On Tue, Dec 10, 2019 at 4:56 AM Mark Shannon wrote: > > > On 09/12/2019 2:15 pm, Chris Angelico wrote: > > On Tue, Dec 10, 2019 at 1:09 AM Mark Shannon wrote: > >> Bear in mind that the costs of higher limits are paid by everyone, but > >> the benefits are gained by few. > > > > Can we get some s

[Python-Dev] Re: Please be more precise when commenting on PEP 611.

On 09/12/2019 2:15 pm, Chris Angelico wrote: On Tue, Dec 10, 2019 at 1:09 AM Mark Shannon wrote: Bear in mind that the costs of higher limits are paid by everyone, but the benefits are gained by few. Can we get some stats on what the costs of higher limits (or having no limit at all) is? Or

[Python-Dev] Re: Please be more precise when commenting on PEP 611.

On 09/12/2019 14:05, Mark Shannon wrote: I would like to ask a favour; please be more specific in your comments. Ideally state which part of the PEP you are disagreeing with and why you disagree with the relevant part of the rationale/motivation. This is rather hard to do when I don't think y

[Python-Dev] Re: Please be more precise when commenting on PEP 611.

Also, I've pointed at two of those limits that worry me some - namely number of classes and number of co-routines, and had not seen so far any feedback even whether they actually make sense. A simple data analysis tasks that create a co-routine per row, and submit those for workers with more than

[Python-Dev] Re: Please be more precise when commenting on PEP 611.

I have not seen any benchmarks supporting the claim that proposed limits would ACTUALLY have any positive performance effect. While some of the claims of performance gain are *plausible*, I also would not be very surprised if some of them caused performance loss. For example, requiring bit masking

[Python-Dev] Re: Please be more precise when commenting on PEP 611.

On Tue, Dec 10, 2019 at 1:09 AM Mark Shannon wrote: > Bear in mind that the costs of higher limits are paid by everyone, but > the benefits are gained by few. Can we get some stats on what the costs of higher limits (or having no limit at all) is? Or, putting it the other way: Since CPython curre