<njs>
out of curiosity: how much of a slowdown do you think we would see on CPython if we used PyPy's cffi-based ssl module instead of the current stdlib version?
<mattip>
njs: it might be easier to benchmark and make the case for sqlite3
<njs>
mattip: dealing with old versions of ssl is about 100x more painful than dealing with old versions of sqlite3 though
<njs>
maybe 1000x
<mattip>
right, but there are two issues: is a cffi-based c-extension inherintly slower, and
<mattip>
is a cryptography-based (cffi) _ssl slower
<njs>
it's really just an idle thought at this point, but with the rumblings about possibly splitting parts of the stdlib out into independently versioned packages, moving the ssl module to pypi does have some attractions
<njs>
but then you'd want the version on pypi to work beyond cpython
<mattip>
as long as it is a ensuressl type of move
<njs>
yeah, it would be that if anything
<mattip>
the issue of "what is python.org going to ship" needs to be hashed out in some meeting with the debian/redhat packager maintainers, anaconda, pypa,
<mattip>
with some representatives from big companies (Brumberg, Boeing, ...)
<mattip>
would be good to get them all in one room and reach some working big-picture axioms
<mattip>
I think your mail on discourse (which I cannot find in the web ui at discuss.python.org) lays it out well, but not sure it is reaching the right people
<njs>
and that thread is just one piece of the larger conversation
<njs>
but also I'm not really sure what business it is of anaconda or bloomberg whether it's possible to upgrade IDLE within a single python version or not?
<njs>
(IDLE and distutils will probably be the actual first test cases for generalizing ensurepip)
<mattip>
using PyPI is not unversally accepted as a good thing
<mattip>
but maybe we can sell the ensurepip approach in a way that makes corporate happy
<mattip>
and does not complicate the life of distro maintainers like debian, anaconda
<mattip>
design it from the ground up to support non-pip use cases
<njs>
(also, debian already breaks up the stdlib into separately installable pieces)
<mattip>
right, but then when someone does `pip install` it breaks, so now we are making that also break the stdlib packages
<mattip>
but I'm sure you have discussed this to death with others, so I will stop
<njs>
hmm, that's a good point
<mattip>
one last thought - I wonder if there is a way to convince distros and conda-forge to upstream their package-fix recipes
<mattip>
so pypi packages become much more like conda-forge and distro-specific ones
<mattip>
then maybe `pip install` becomes less destructive
<njs>
the main reason 'pip install' is destructive is that now you have two inconsistent sources of truth about what's installed
<njs>
pip's package database, and conda/apt/yum's package database
<njs>
and unfortunately there's no quick fix for that :-/
<mattip>
doesn't have to be quick, just agreed-upon-going-forward, but in order to do that all the right people have to be in the conversation
<mattip>
seems like PyCon packaging summit was a good start
<njs>
I've had a bunch of conversations with the conda folks about this, and I think it's fixable in their case, but so far it hasn't seemed to stick
<njs>
for apt/yum I don't think there is any solution, except maybe pip should refuse to work in that case unless you write, like --please-destroy-my-distro-package-manager
<mattip>
everyone is so involved in putting out the fires, it is hard to think big
<mattip>
without re$ource$ it is hard to imagine things changing for the better
<mattip>
and it is hard to create win-win scenarios
<njs>
well, maybe Peter's B-corp will solve it :-)
<njs>
there are a lot of win-win scenarios in packaging in general, it's just super hard to get everyone on the same page
<mattip>
:)
<mattip>
it can be 99% win-win, but the 1% who loses is going to make lots of noise
<mattip>
much easier to torpedo new things that to change legacy code
Ai9zO5AP has joined #pypy
<mattip>
but we are off topic for #pypy
jacob22_ is now known as jacob22
marvin has quit [Remote host closed the connection]
marvin_ has joined #pypy
marvin_ has quit [Remote host closed the connection]
marvin_ has joined #pypy
xcm is now known as Guest24280
Guest24280 has quit [Remote host closed the connection]
xcm has joined #pypy
antocuni has joined #pypy
dddddd has quit [Read error: Connection reset by peer]
<mattip>
test_ssl.test_options is silly, it tests the default flags for an ssl context, but the flags are very platform / os dependent
<mattip>
I am disabling it
Garen_ has quit [Ping timeout: 248 seconds]
<kenaan>
mattip default 937db12c1a36 /lib-python/2.7/test/test_ssl.py: disable flaky test
marvin_ has quit [Remote host closed the connection]
marvin has joined #pypy
Zaab1t has joined #pypy
Zaab1t has quit [Remote host closed the connection]
forgottenone has quit [Ping timeout: 268 seconds]
dddddd has quit [Read error: Connection reset by peer]
ajlawrence has joined #pypy
dddddd has joined #pypy
lritter has quit [Quit: Leaving]
mattip_ has joined #pypy
mattip has quit [Ping timeout: 272 seconds]
<ajlawrence>
mattip_: I would like to merge the winmultiprocessing branch some point today. There is still some bug in the test_multiprocessing_spawn.py where error codes from one test bleed into the next. I have looked at it a few times now and have no idea what is going on there. Is it still OK for me to merge the branch with those failures?
<ajlawrence>
I will raise an issue to capture the problem and then move onto something else before I go mad.
Tsundere_cloud has joined #pypy
Zaab1t has joined #pypy
Zaab1t has quit [Remote host closed the connection]
Kipras_ has quit [Ping timeout: 246 seconds]
lritter has joined #pypy
marvin has quit [Remote host closed the connection]
marvin_ has joined #pypy
marvin_ has quit [Remote host closed the connection]
marvin_ has joined #pypy
marvin_ has quit [Remote host closed the connection]
marvin_ has joined #pypy
marvin_ has quit [Remote host closed the connection]
forgottenone has quit [Quit: Konversation terminated!]
<mattip_>
ajlawrence: if the situation is currently that merging the branch does not make multiprocessing worse, and the tests won't hang the buildslave,
<mattip_>
then I am fine merging it.
<ajlawrence>
mattip_: It doesn't make the situation worse. Most of the tests now pass but there is a bug that I could not fix.
Zaab1t has joined #pypy
Zaab1t has quit [Remote host closed the connection]
<mattip_>
so we should merge it
<mattip_>
do you want me to?
<ajlawrence>
I merged the py3.6 branch into winmultiprocessing and am currently double checking the tests on the build machine. I will merge it if they look ok.
<ajlawrence>
Do you know why so many tests fail with "ImportError: No module named '_testcapi'"?
<mattip_>
not really. Are they failing on default as well? maybe the wrong python is being used to build the c-extension module
<ajlawrence>
It is looking for python36.lib in the wrong place. I fixed it on the winmutliprocessing branch.
<mattip_>
lib -> libs in 440feb6ea372, did that fix it now?
<mattip_>
should that get backported to default?
<ajlawrence>
Default seems ok.
<mattip_>
weird
<ajlawrence>
It seemed a bit wierd to me as well. I would have thought someone would have noticed a small bug like that and got a bit paranoid about breaking something.
<mattip_>
the next lines should "fix" it by falling back to another location for the library
<mattip_>
"# For a local translation or nightly build"
Tsundere_cloud has quit [Quit: Connection closed for inactivity]
<mattip_>
ajlawrence: there are so many failing tests, it gets lost in the noise