02:59 <Atque> mgorny: Start a data science company, make $1trillion dollars and bankroll pypy?

03:00 <Atque> pypy is really good for lots of things. The dream would be having the latest cpython version's features and a drop in replacement, but that's unlikely to happens resourcewise I imagine.

03:03 <Corbin> It's a matter of politics, not just resources. That said, if the desire is to just see one particular feature in PyPy, it might be possible for an individual to contribute that feature on their own.

03:04 <Atque> Corbin: Is there pushback on some features?

03:08 <Corbin> Atque: No, PyPy welcomes contributions. The source of problems is that CPython and PyPy are distinct; features proposed and popular within the CPython community don't always come with a plan for how non-CPython systems will implement them.

03:16 <Atque> Yeah, makes sense. So there's no overall body setting the development of python variants (CPython, PyPy, Jython, IronPython etc.)?

03:17 <Corbin> No. Depending on who you ask and how you measure, my prior estimate is that around 98% of the Python ecosystem uses CPython exclusively. We are on the edges of a monoculture.

06:44 <mattip> ctismer: I opened an issue about the warnings on NumPy 1.22+

06:44 <mattip> https://foss.heptapod.net/pypy/pypy/-/issues/3658

07:05 <ctismer> mattip: Thank you! That could explain other problems as well.

10:53 <ctismer> mattip: Can you please elaborate? `isinstance(ndarray.__class_getitem__, types.MethodType)` does not compute for me.

11:00 <mattip> you need to be using numpy 1.22 and higher and pypy 3.8 or higher

11:07 <ctismer> >>>> isinstance(numpy.ndarray(3).__class_getitem__, types.MethodType)

11:07 <ctismer> mattip: Ah, you need to use an instance to get this. This works:

11:07 <ctismer> True

11:57 <cfbolz> I don't see how that could be False, honestly

12:06 <mattip> in CPython type(numpy.ndarray.__class_getitem__).mro() is [<class 'builtin_function_or_method'>, <class 'object'>]

12:07 <mattip> in PyPy it is [<class 'method'>, <class 'object'>]

12:07 <cfbolz> yes, but we don't have builtin_function_or_method as a type

12:08 <mattip> well, we need to differentiate between cpyext class methods and python ones, since

12:09 <mattip> you can write to __doc__ on python methods, but not on cpyext ones

12:11 <ctismer> mattip: This case does not apply to my problems, directly. But it shows again that methods are sometimes treated wrong. Example:

12:11 <ctismer> mattip: https://www.irccloud.com/pastebin/mz3Fjwka/problem

12:13 <ctismer> cfbolz: We need something that determines a builtin method, somehow.

12:15 <mattip> "builtin" is a deceptive name, but yeah

12:34 <ctismer> I have this ugly patch for PyPy since quite some time:

12:35 <ctismer> cfbolz https://www.irccloud.com/pastebin/HnmXd1TI/method_patch

12:36 <ctismer> but this is maybe not the only needed patch. There might be other things that need patching as well.

12:38 <ctismer> the isinstance is for instance not yet covered 😃

13:59 <mattip> it seems we have more things to do before the release of py3.9, like pep573

14:42 <cfbolz> mattip: ah, ouch, is pep 573 a lot of work?

14:43 <mattip> the bit I committed on the branch is enough to get cython tests to pass, but it would be nice to do the rest too

14:44 <mattip> the CI running at https://github.com/pypy/binary-testing/actions is helpful

14:44 <mattip> to see what is broken

14:50 <cfbolz> mattip: cool that it helps

20:33 <exarkun> Anyone know about pypy 3.8 support in cibuildwheel? It seems to be missing?

20:38 <mattip> exarkun: update 2.3.0

20:38 <mattip> https://cibuildwheel.readthedocs.io/en/stable/changelog/#v230

20:39 <exarkun> I'm using 2.3.1

20:40 <exarkun> Bah. I put "pp38-" instead of "pp38-*" in the config.

22:23 <mgorny> just submitted a PR fixing cherrypy

22:23 <mgorny> turned out the test suite was failing and then crashing pytest... because upstream neglected to close files