The future of the Python ssl module

Posted Jun 4, 2016 16:00 UTC (Sat) by rahulsundaram (subscriber, #21946)
In reply to: The future of the Python ssl module by robert_s
Parent article: The future of the Python ssl module

>It's a bit late - any users of requests are already using a bundled (er..) bundle of root certs (along with a bundled copy of urllib3).

Are they though? Distributions typically unbundle these.

The future of the Python ssl module

Posted Jun 4, 2016 17:47 UTC (Sat) by flussence (guest, #85566) [Link] (6 responses)

The version in Gentoo contains quite a long list in the (confusingly-named) file /usr/lib64/python2.7/site-packages/requests/cacert.pem - its timestamp matches the source python files and not the compiled ones, so I'm assuming bundled.

The future of the Python ssl module

Posted Jun 17, 2016 17:25 UTC (Fri) by ceplm (subscriber, #41334) [Link] (5 responses)

Yes

a) urllib3 is one of the reasons why requests are evil,
b) this looks like a packaging bug

Anything else?

The future of the Python ssl module

Posted Jun 21, 2016 12:30 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (4 responses)

What's wrong with urllib3 (other than it meaning there are at least two old/crap APIs shipped in the standard library)?

The future of the Python ssl module

Posted Jun 21, 2016 15:16 UTC (Tue) by ceplm (subscriber, #41334) [Link] (3 responses)

1. arrogance of its users who cannot learn the standard API properly and so they call it "old/crap" (and who spam all stackoverflow questions about urllib2),

2. arrogance of maintainers who believe that they know better than anybody, so instead of using standard API, people should install for their five lines script three quarters of megabytes of their crap including their own root certificates.

Look, I don’t claim that the urllib2 API is the most beautiful one in the world, but IMHO the way how to fix standard library is to fix standard library not to do completely incompatible thing on the side. And from following the discussions about inclusion of python-request API in the stdlib I didn't get the impression that the Python community is at fault that it has been rejected.

The future of the Python ssl module

Posted Jun 21, 2016 17:01 UTC (Tue) by ceplm (subscriber, #41334) [Link]

I found this https://github.com/kennethreitz/requests/issues/2424 discussion illuminating.

The future of the Python ssl module

Posted Jun 22, 2016 13:40 UTC (Wed) by mathstuf (subscriber, #69389) [Link] (1 responses)

One of my problems with Python is that the standard library has lots of extraneous stuff in it these days. I feel like lots of modules exist because someone said "someone might need this" and lo, it was so. Why is something like nntplib in the standard library? The smtplib and email modules have severe API deficiencies noted elsewhere recently and they'll probably never be fixed because of backwards compatibility concerns rather than someone just being able to update a package and have these issues fixed. The standard library is also pinned to the Python release cycle which is…not fast so that improvements and new features can wait up to a year before anyone can use them. Or you're on PyPI anyways, so what does it matter that it's in the standard library then?

Granted, Python didn't start out with a good package management system (and having gone through multiple iterations, seems to have finally decided on one[1]). But that doesn't mean that Python3 couldn't have spun modules out just as easily.

I really like that requests was not put into the standard library; it would have just stagnated it and required a new requests2 to be born.

[1]Though now Anaconda exists and some folk are claiming it as the Python Package Manager to End All Package Managers. Personally, it sets up walls around itself that are too high that it isn't a redistributable solution (hard-coded absolute paths everywhere).

The future of the Python ssl module

Posted Jun 22, 2016 14:52 UTC (Wed) by ceplm (subscriber, #41334) [Link]

To some extend I do agree: certainly, there should be some periodic shaving off archeological and obsolete protocols and standards is always useful (Java still contains support for all those obsolete RPC methods, CORBA, and some non-TCP/IP communication protocols). Not sure whether all those 636 lines of nntplib are such an disaster (it was fun that I could develop https://gitlab.com/mcepl/pyg without almost any external dependency), but that is not the point I accept your point on principle.

What I think is important is to investigate further separation of API and its implementation. Java guys manage to do that splendidly and I really like that I could switch between the implementation of the ElementTree from the Python standard library and lxml quite easily (and I see, I could do the same with lxml as an alternative implementation of SAX).

So, yes, I would be all for introduction of requests API in the standard library as a thin wrapper over the current urllib even with all limitations of that.