[Python-Dev] Re: Emit a SyntaxWarning for unhashables literals in hashable dependant literals.

On Fri, Dec 13, 2019, at 02:20, mental na via Python-Dev wrote: > Guido van Rossum wrote: > > This is most definitely a language issue, not just a CPython issue -- the > > rules around hashability and (im)mutability are due to the language > > definition, not the whim of an implementer. > > I was

[Python-Dev] Re: Emit a SyntaxWarning for unhashables literals in hashable dependant literals.

Guido van Rossum wrote: > This is most definitely a language issue, not just a CPython issue -- the > rules around hashability and (im)mutability are due to the language > definition, not the whim of an implementer. I was not aware of this, I assumed it was a implementation issue because I knew

[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: Travis CI for backports not working.

> I.e. if someone breaks some test, is Travis-CI the only thing that keeps the breakage from landing on master? We still have Azure Pipelines as a mandatory check for PRs before they can be merged to master, which includes a few additional platforms and hasn't had any recent issues (AFAIK). I

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

Does Travis-CI serve any purpose for us still? I.e. if someone breaks some test, is Travis-CI the only thing that keeps the breakage from landing on master? On Thu, Dec 12, 2019 at 5:46 PM Kyle Stanley wrote: > Victor Stinner wrote: > > What is the issue? Can someone please open a bug report at

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

Victor Stinner wrote: > What is the issue? Can someone please open a bug report at https://bugs.python.org/ so I can try to investigate? >From my understanding, it looks to be pyenv related and not something we can fix on our end, at least based on the build logs:

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

What is the issue? Can someone please open a bug report at https://bugs.python.org/ so I can try to investigate? Victor Le ven. 13 déc. 2019 à 02:05, Brett Cannon a écrit : > > This is failing again, so I had to switch off Travis from being a requirement > (again). > > I'm not not going to

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

This is failing again, so I had to switch off Travis from being a requirement (again). I'm not not going to flip it back on until Travis has been stable for a month as I don't like being the blocker on stuff when I can help it. And if Travis isn't stable in a month then we might need to start

[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

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

On Thu, Dec 12, 2019 at 7:05 PM Kyle Stanley wrote: > 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 >

[Python-Dev] Re: Emit a SyntaxWarning for unhashables literals in hashable dependant literals.

This is most definitely a language issue, not just a CPython issue -- the rules around hashability and (im)mutability are due to the language definition, not the whim of an implementer. A tool like mypy will catch this for you. As to the desirability of adding a syntax warning for such

[Python-Dev] Emit a SyntaxWarning for unhashables literals in hashable dependant literals.

I'm not sure if this is the right place to bring this up, python-ideas seemed like language issues and python-dev seemed like CPython issues. There are several unhashable builtin types present in CPython, as of today the ones I've noticed are: lists, dicts, sets, and bytearrays. Two of these

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

On Thu, 12 Dec 2019 11:43:58 + Rhodri James wrote: > On 11/12/2019 21:35, Antoine Pitrou wrote: > > In any case, this will have to be judged on benchmark numbers, once > > Mark (or someone else) massages the interpreter to experiment with > > those runtime memory footprint reductions. > >

[Python-Dev] Re: Python 3.8 error?

Pardon, I meant "there is no Python 3.8 version, yet". And this is wrong, the MacOS pip install shows PyQt5-5.13.2-5.13.2-cp35.cp36.cp37.cp38-abi3-macosx_10_6_intel.whl So probably we have some bad oversight, somewhere. Cheers -- Chris On 12.12.19 13:48, Christian Tismer wrote: > On

[Python-Dev] Re: Python 3.8 error?

On 12.12.19 13:04, Petr Viktorin wrote: > I'm quite interested in the rest of the story here. PySide is probably > the biggest open-source user of the limited API, so IMO it is relevant > to this list. BTW., the Python 3.8 change to type refcounting is already breaking the Limited API a bit,

[Python-Dev] Re: Python 3.8 error?

On 12.12.19 13:04, Petr Viktorin wrote: > I'm quite interested in the rest of the story here. PySide is probably > the biggest open-source user of the limited API, so IMO it is relevant > to this list. I guess that PyQt5 is a similar huge user, and it may be that they have the same problem,

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

On 11/12/2019 21:35, Antoine Pitrou wrote: In any case, this will have to be judged on benchmark numbers, once Mark (or someone else) massages the interpreter to experiment with those runtime memory footprint reductions. This I absolutely agree with. Without evidence we're just waving our

[Python-Dev] Re: Python 3.8 error?

I'm quite interested in the rest of the story here. PySide is probably the biggest open-source user of the limited API, so IMO it is relevant to this list. On 2019-12-11 23:48, Christian Tismer wrote: Hi all, Sorry for the noise, I was wrong, and I retract. I was somehow mislead and hunted a

[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

[Python-Dev] Re: Why limit coroutines?

On 2019-12-11 22:45, Antoine Pitrou wrote: 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?

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

On Wed., 11 Dec. 2019, 9:16 pm Mark Shannon, wrote: > > > 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 > >

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

On Thu, 12 Dec 2019 00:56:41 -0500 Kyle Stanley wrote: > > IMO, the max > number of concurrent transactions that the a database system can handle at > once is a very clear application of Moore's Law. I'm not quite sure that's the case. I think in reality Moore's Law has also helped databases

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

On Wed, 11 Dec 2019 23:17:48 -0500 Kyle Stanley wrote: > > TL;DR: It's definitely possible to have more than one client per TCP port. Thanks for correcting me. Not sure why, but I appear to make that mistake once every couple years. > I'm have no idea what the > realistic maximum limit of