[Python-Dev] Re: PEP 611 -- why limit coroutines and classes?

Antoine Pitrou wrote: > 1M concurrent database transactions? Does that sound reasonable at > all? Your database administrator probably won't like you. I agree that 1M concurrent transactions would not be reasonable for the vast majority of database configurations, I didn't mean to specifically i

[Python-Dev] Re: PEP 611 -- why limit coroutines and classes?

Andrew Svetlov wrote: > > Not sure how that works? Each client has an accepted socket, which is > > bound to a local port number, and there are 65536 TCP port numbers > > available. Unless you're using 15+ coroutines per client, you probably > > won't reach 1M coroutines that way. > > I'm sorry,

[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] PEP 611 - saturating reference counts

as an aside in the portion of PEP 611 proposing a limit to the number of classes, the proposal also mentioned reducing the size of the reference count field to achieve part of its object size savings. one of the mechanisms proposed was to implement a "saturating" reference count, though it woul

[Python-Dev] Re: Python 3.8 error?

Hi all, Sorry for the noise, I was wrong, and I retract. I was somehow mislead and hunted a phantom. Best - Chris On 10.12.19 00:29, Christian Tismer wrote: > On 09.12.19 23:26, Nick Coghlan wrote: >> >> >> On Tue., 10 Dec. 2019, 5:17 am MRAB, > > wrote: >> >>

[Python-Dev] Re: PEP 611 -- why limit coroutines and classes?

On Wed, Dec 11, 2019 at 11:52 PM Antoine Pitrou wrote: > > On Mon, 9 Dec 2019 21:42:36 -0500 > Kyle Stanley wrote: > > > > > There's also a practical use case for having a large number of coroutine > > objects, such as for asynchronously: > > > > 1) Handling a large number of concurrent clients o

[Python-Dev] Re: PEP 611 -- why limit coroutines and classes?

On Thu, Dec 12, 2019 at 8:46 AM Antoine Pitrou wrote: > > 1) Handling a large number of concurrent clients on a continuously running > > web server that receives a significant amount of traffic. > > Not sure how that works? Each client has an accepted socket, which is > bound to a local port numb

[Python-Dev] Re: PEP 611 -- why limit coroutines and classes?

On Mon, 9 Dec 2019 21:42:36 -0500 Kyle Stanley wrote: > > (b) Why limit coroutines? It's just another Python object and has no > operating resources associated with it. Perhaps your definition of > coroutine is different, and you are thinking of OS threads? > > This was my primary concern with

[Python-Dev] Re: PEP 611: The one million limit.

On Fri, 6 Dec 2019 15:19:48 -0800 "Gregory P. Smith" wrote: > I'd prefer it if we stayed on topic here... +1. Please take rants about 30-year old CPU designs elsewhere (for example Hacker News, Twitter, Facebook, etc.). Regards Antoine. ___ Python-D

[Python-Dev] Re: PEP 611: The one million limit.

On Fri, 6 Dec 2019 13:54:13 + Rhodri James wrote: > Apologies again for commenting in the wrong place. > > On 05/12/2019 16:38, Mark Shannon wrote: > > > Memory access is usually a limiting factor in the performance of > > modern CPUs. Better packing of data structures enhances locality and

[Python-Dev] Re: PEP proposal to limit various aspects of a Python program to one million.

On Tue, 10 Dec 2019 00:59:09 + Oscar Benjamin wrote: > > > Note that changing pytest to output fewer lines won't work as we will > > just hit the bytecode limit instead. > > I'm not sure. I think that pytest should have some kind of limit on > what it produces in this situation. Agreed. I

[Python-Dev] Re: [python-committers] [RELEASE] Python 3.8.1rc1 is now available for testing

Jason R. Coombs wrote: > I think I missed the announcement of the cutoff date for 3.8.1; I was hoping > to get > some bug fixes in for > importlib.metadata.https://github.com/python/cpython/pull/17568 > These aren’t crucial bugfixes, but it would be nice not to have them linger > for months. Ju

[Python-Dev] Re: More feedback on PEP 611, please

David Mertz wrote: > On Wed, Dec 11, 2019, 6:40 AM Mark Shannon m...@hotpy.org > wrote: > > I NEVER care about memory at all... except inasmuch as it effects speed. In my admittedly idiosyncratic experience, memory is usually by far my most constrained resource. I do care about it, even if pyth

[Python-Dev] Re: More feedback on PEP 611, please

I am totally against arbitrary limits in the CPython reference implementation and in the language as a whole. -- ~Ethan~ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.pyt

[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: More feedback on PEP 611, please

On 11 Dec 2019, at 12:12, Mark Shannon wrote: Hi everyone, Thanks for all your feedback so far. Previously I asked for "more precise" feedback, which has been interpreted as evidence backed feedback. That's not what I meant. My fault for not being clearer. Your opinions without any justific

[Python-Dev] Re: More feedback on PEP 611, please

On Wed, Dec 11, 2019 at 11:12:59AM +, Mark Shannon wrote: > Another thing I would like feedback on this: > My justification for a single limit of one million across the board is > to ease memorization and learning. > Is that sufficient justification, or would differing limits be better? Why

[Python-Dev] Re: More feedback on PEP 611, please

On Wed, 11 Dec 2019 at 11:38, Mark Shannon wrote: > Your opinions without any justifications are welcome, but I need precision. > > For example, saying "I don't want any limits ever for anything" is > precise, but saying "A limit of 1 million is OK provided the performance > improvements justify i

[Python-Dev] Re: More feedback on PEP 611, please

On 11/12/2019 11:12, Mark Shannon wrote: P.S. On the subject of tradeoffs, here's a bonus question: What, in your opinion, increase in memory consumption is acceptable for a 1% improvement in speed, or vice versa? Depends on the phase of the moon, the hardware I'm trying to run on, and the pr

[Python-Dev] Re: More feedback on PEP 611, please

On Wed, Dec 11, 2019, 6:40 AM Mark Shannon wrote: > P.S. On the subject of tradeoffs, here's a bonus question: > What, in your opinion, increase in memory consumption is acceptable for a > 1% improvement in speed, or vice versa? I NEVER care about memory at all... except inasmuch as it effects

[Python-Dev] Re: More feedback on PEP 611, please

On Wed, Dec 11, 2019, 6:40 AM Mark Shannon wrote: > Another thing I would like feedback on this: > My justification for a single limit of one million across the board is to > ease memorization and learning. > Is that sufficient justification, or would differing limits be better? > Absolutely not

[Python-Dev] More feedback on PEP 611, please

Hi everyone, Thanks for all your feedback so far. Previously I asked for "more precise" feedback, which has been interpreted as evidence backed feedback. That's not what I meant. My fault for not being clearer. Your opinions without any justifications are welcome, but I need precision. For e

[Python-Dev] Re: Dropping coroutines from PEP 611.

With the removal of the coroutine limit, I think that PEP 611 will be a lot easier to consider. Personally, I've gone from -1 to +0. But, with the class limit also being rather controversial, I think the PEP would benefit significantly from backing that up with some form of analysis on memory usage

[Python-Dev] Re: Feedback on PEP 611 (so far) from the Steering Council

On 11/12/2019 12:04 am, Barry Warsaw wrote: The Python Steering Council discussed PEP 611 at today’s meeting. Here is our feedback so far: * The Steering Council reserves the right to be the BDFL-Delegate for this PEP * The PEP should clearly delineate two aspects: - A language generic

[Python-Dev] Dropping coroutines from PEP 611.

Hi all, Thanks again for all your feedback on PEP 611. So far the biggest pushback on limits has been for the number of classes, line count and coroutines. Of those, I have been convinced that a limit on the number of coroutines would the hardest to workaround. In addition the justification fo

[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