[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

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

> I also would suggest for PEP 611 that any limits are discoverable (maybe in sys) so it can be used by other implementations like Jython. I agree, I think that sys would likely be the most reasonable place to read these limits from. Also, it seems like a good location for setting of the limits,

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

> This logic doesn't seem much different than would be for coroutines... Just need to wait for larger systems... > With 100k threads started we're only using 8G memory, there are plenty of systems today with more than 80G of RAM Well, either way, I think it's still a solid argument against

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

On Mon, Dec 9, 2019, 18:48 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 the

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

> (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 the proposed PEP. At the moment, it's rather trivial to create one

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

I was thinking the same thing. We should distinguish limits with respect to the codegen process, which seem reasonable, vs runtime. Classes and coroutines are objects, and like objects in general, the program should have the option of filling its heap with any arbitrary objects. (Whether wise or

[Python-Dev] Re: Travis CI for backports not working.

On 12/9/2019 7:33 PM, Brett Cannon wrote: Victor Stinner wrote: In that case, would you mind to make Travis CI mandatory again? Done! It is again working fine on 3.8 and 3.7. -- Terry Jan Reedy ___ Python-Dev mailing list -- python-dev@python.org

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

As PEP 611 reads to me, there is a lack of clarity as to whether you are proposing a Python-the-language limit or a CPython-the-implementation limit. I think your intent is the latter, but if so please be very clear about that in the abstract, title, and motivation. The Other implementations

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

On Tue, 10 Dec 2019 at 00:00, Steven D'Aprano wrote: > > On Sat, Dec 07, 2019 at 07:37:58PM +, Oscar Benjamin wrote: > > > I recently hit on a situation that created a one million line code file: > > https://github.com/pytest-dev/pytest/issues/4406#issuecomment-439629715 > > > > The original

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

On Mon, 9 Dec 2019 at 14:10, Mark Shannon wrote: > On 07/12/2019 7:37 pm, Oscar Benjamin wrote: > > On Sat, 7 Dec 2019 at 06:29, Steven D'Aprano wrote: > >> > >> A million seems reasonable for lines of source code, if we're prepared > >> to tell people using machine generated code to split their

[Python-Dev] Re: Travis CI for backports not working.

Victor Stinner wrote: > In that case, would you mind to make Travis CI mandatory again? Done! > Victor > Le ven. 6 déc. 2019 à 19:10, Brett Cannon br...@python.org a écrit : > > > > Victor Stinner wrote: > > Hello, > > Le mar. 26 nov. 2019 à 20:40, Brett Cannon br...@python.org a écrit : > > I

[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: PEP proposal to limit various aspects of a Python program to one million.

On Sat, Dec 07, 2019 at 07:37:58PM +, Oscar Benjamin wrote: > I recently hit on a situation that created a one million line code file: > https://github.com/pytest-dev/pytest/issues/4406#issuecomment-439629715 > > The original file (which is included in SymPy) has 3000 lines > averaging 500

[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

[Python-Dev] Re: Python 3.8 error?

On 09.12.19 23:26, Nick Coghlan wrote: > > > On Tue., 10 Dec. 2019, 5:17 am MRAB, > wrote: > > On 2019-12-09 18:22, Christian Tismer wrote: > > > > > > Hi Nick, > > > > after staring long at the code, I fount something funny in > >

[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

[Python-Dev] Re: Python 3.8 error?

On Tue., 10 Dec. 2019, 5:17 am MRAB, wrote: > On 2019-12-09 18:22, Christian Tismer wrote: > > > > > > Hi Nick, > > > > after staring long at the code, I fount something funny in > > typeobject.c #286 ff: > > > > > > static void > > type_mro_modified(PyTypeObject *type, PyObject *bases) { > >

[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

[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

[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

[Python-Dev] Re: Python 3.8 error?

On 2019-12-09 18:22, Christian Tismer wrote: On 08.12.19 09:49, Nick Coghlan wrote: On Fri., 6 Dec. 2019, 3:31 am Christian Tismer, mailto:tis...@stackless.com>> wrote: Hi guys, during the last few weeks I have been struggling quite much in order to make PySide run with Python 3.8

[Python-Dev] Python 3.8 error? (was: Python 3.8 problem with PySide)

On 08.12.19 09:49, Nick Coghlan wrote: > On Fri., 6 Dec. 2019, 3:31 am Christian Tismer, > wrote: > > Hi guys, > > during the last few weeks I have been struggling quite much > in order to make PySide run with Python 3.8 at all. > > The expected

[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

[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?

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

I want to question two specific limits. (a) Limiting the number of classes, in order to potentially save space in object headers, sounds like a big C API change, and I think it's better to lift this idea out of PEP 611 and debate the and cons separately. (b) Why limit coroutines? It's just

[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

[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

[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

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

Hi everyone, Thanks again for all your comments on PEP 611. 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. Also, when asking for

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

Hi Oscar, Thanks for the feedback. On 07/12/2019 7:37 pm, Oscar Benjamin wrote: On Sat, 7 Dec 2019 at 06:29, Steven D'Aprano wrote: A million seems reasonable for lines of source code, if we're prepared to tell people using machine generated code to split their humongous .py files into

[Python-Dev] Re: Handling cross-distro variations when running autoreconf?

- Original Message - > From: "Nick Coghlan" > To: "python-dev" > Sent: Sunday, December 8, 2019 2:58:24 PM > Subject: [Python-Dev] Handling cross-distro variations when running > autoreconf? > > Hi folks, > > While reviewing https://github.com/python/cpython/pull/17303/files, I >

[Python-Dev] Re: Handling cross-distro variations when running autoreconf?

FYI the Fedora package always re-generate the configure script as part of the package build ;-) https://src.fedoraproject.org/rpms/python3/blob/master/f/python3.spec#_639 """ %build # Regenerate the configure script and pyconfig.h.in autoconf autoheader (...) """ It's part of Fedora packaging

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

One aspect of scripting is being able to throw something together to create a correct solution to an immediate problem. If the proprietary software that you script around takes over 300 Gigs to lay out a CPU and delays are hugely expensive, then I don't want to waste time on optimisations to get