Package Control has patched these two module issues for a while, but I figured I'd give some details for those that are interested:
Sublime Text 2 on Windows has an error when importing select. It isn't that Jon didn't include select, but rather there seems to be an issue importing the select.pyd from the folder that sublime_text.exe is located in, with Python 2.6. In fact, Python 2.6 on Windows has all sorts of issues that Jon burned a lot of time trying to work around. For instance, Python 2.6 can't add sys.path entries for folders with non-ascii characters. This led to a hacky work-around where Sublime Text chdirs into each package folder and loads the Python from ".\". Package Control solves the select import by shipping the select.pyd files, but placing them in a package folder and then adding that folder to sys.path.
For Linux, Python creates a _ssl.so shared library shim that links with the system's version of OpenSSL. The downside is that different distros have different versions of OpenSSL - 0.9.x and 1.x.x. This is further compounded by the fact that Fedora has their own specially numbered version of libssl (libssl-10 instead of libssl-1.0.0). So, by distributing a compiled version of Python, there isn't a way to ship the _ssl module for Python that will actually consistently work. Jon seems to have decided to focus his energy on other issues. Package Control patches this issue also. Actually, my SFTP package was the first to patch the issue, but I spent the time to make in generally available to all packages with Package Control 3.0.
So there are two options to deal with _ssl. Jon could try to ship OpenSSL with Sublime Text, thus entering the world of being responsible for patching OpenSSL, and dealing with dynamic linking issues and all that jazz. It gets kind of gross dealing with rpath and all kinds of other work to get the shared lib to look in the current folder first rather than loading the, possibly incorrect, system version of libssl. I've gone down that path before with a project and it was not a fun time. On a side note, Sublime Text on Windows unfortunately does ship OpenSSL, so the version available to Sublime Text plugins can be out-of-date. I've been working on a cross-platform crypto library for Python that uses the OS crypto facilities, which could be a solution for this in the future.
The other option is to rely on the system version of OpenSSL, but provide _ssl.so shims for each of the different major versions of OpenSSL for each architecture. Then ssl.py would have to be patched to try each of the shims until one of them loaded properly. The upside here is that the distro is responsible for updates to OpenSSL. This general approach is what Package Control does, however I don't patch ssl.py. Instead Package Control adds a custom package that is listed alphabetically first, and thus loaded by Sublime Text first. This custom package tries importing each of the shims until it finds one that works with the version of OpenSSL on the system. If you are morbidly curious, you can see the code and shims at https://github.com/codexns/sublime-ssl-linux.
The end result of all of this is that for the majority of ST users, these issues are likely solved. Package Control 3.0 automatically installs these fixes, and provides mechanisms for package developers to share other compiled Python modules. Older versions of Package Control have been EOLed, and thus it is possible for package developers to rely on users having these patches in place.
Sublime Text 2 on Windows has an error when importing select. It isn't that Jon didn't include select, but rather there seems to be an issue importing the select.pyd from the folder that sublime_text.exe is located in, with Python 2.6. In fact, Python 2.6 on Windows has all sorts of issues that Jon burned a lot of time trying to work around. For instance, Python 2.6 can't add sys.path entries for folders with non-ascii characters. This led to a hacky work-around where Sublime Text chdirs into each package folder and loads the Python from ".\". Package Control solves the select import by shipping the select.pyd files, but placing them in a package folder and then adding that folder to sys.path.
For Linux, Python creates a _ssl.so shared library shim that links with the system's version of OpenSSL. The downside is that different distros have different versions of OpenSSL - 0.9.x and 1.x.x. This is further compounded by the fact that Fedora has their own specially numbered version of libssl (libssl-10 instead of libssl-1.0.0). So, by distributing a compiled version of Python, there isn't a way to ship the _ssl module for Python that will actually consistently work. Jon seems to have decided to focus his energy on other issues. Package Control patches this issue also. Actually, my SFTP package was the first to patch the issue, but I spent the time to make in generally available to all packages with Package Control 3.0.
So there are two options to deal with _ssl. Jon could try to ship OpenSSL with Sublime Text, thus entering the world of being responsible for patching OpenSSL, and dealing with dynamic linking issues and all that jazz. It gets kind of gross dealing with rpath and all kinds of other work to get the shared lib to look in the current folder first rather than loading the, possibly incorrect, system version of libssl. I've gone down that path before with a project and it was not a fun time. On a side note, Sublime Text on Windows unfortunately does ship OpenSSL, so the version available to Sublime Text plugins can be out-of-date. I've been working on a cross-platform crypto library for Python that uses the OS crypto facilities, which could be a solution for this in the future.
The other option is to rely on the system version of OpenSSL, but provide _ssl.so shims for each of the different major versions of OpenSSL for each architecture. Then ssl.py would have to be patched to try each of the shims until one of them loaded properly. The upside here is that the distro is responsible for updates to OpenSSL. This general approach is what Package Control does, however I don't patch ssl.py. Instead Package Control adds a custom package that is listed alphabetically first, and thus loaded by Sublime Text first. This custom package tries importing each of the shims until it finds one that works with the version of OpenSSL on the system. If you are morbidly curious, you can see the code and shims at https://github.com/codexns/sublime-ssl-linux.
The end result of all of this is that for the majority of ST users, these issues are likely solved. Package Control 3.0 automatically installs these fixes, and provides mechanisms for package developers to share other compiled Python modules. Older versions of Package Control have been EOLed, and thus it is possible for package developers to rely on users having these patches in place.