kxroberto <kxrobe...@users.sourceforge.net> added the comment: >> "It doesn't happen in Python 3" >> >> Yet the cheap/unnecessary pre-imports of ssl in those other mentioned >> socket using libs (urllib (cgi!),httplib,smtplib,pop,imap...) exist >> there. socket is rarely used directly, so not much difference to Py2 >> in effect overall. > Well, by this measure, we probably have unnecessary imports all over the > place, since the general guideline is to import modules at the top-level > rather than inside functions (the reason is partly technical, to avoid > potential deadlocks with the import lock).
see e.g. issue #1046077. As said, in this case here its even about libs almost as big as the python binary itself (on many platforms). When there are only few link points, and a huge effect (->usage probabilities), late imports shall be used. Python is dynamic. The list, as posted, is short here. Grep "ssl" in Python lib. Its not reasonable to draw the big libcrypto and libssl almost always. >> Thus I'd request to not close this issue so swift. This is IHMO really >> a point to make python startup significantly faster, with a rather >> simple means. > If you are using a network library such as urllib or others you > mentioned, then startup time will surely be small compared to the time > spent sending and retrieving data over the network, no? no. This is to cheap here. I'd vote for some discipline regarding such levels of resource usage. (I often wonder why software today isn't much faster than years ago - though the nominal speed of hardware increases tremendously. package sizes grow, without appropriate growth of functionality. This is one example how the rescources are wasted too careless.) For example each cgi script (which has to respond fast and does only a small job), which does "import cgi" and a few lines; or a script which just uses e.g., urllib string format functions ... : the whole thing is drawn. > >> Also the linkage of _ssl solely against a detailed version of >> libssl/libcrypto is still questionable. > I don't know the reasons (if any). Perhaps you can open a separate issue > about that? Yet the issue of this library is here now. Why procrastinate? > >> "This is therefore a problem with the Debian package" >> >> I'm not into the Python build files. Just to ask/double-check: is that >> observed _semi_ static link selection (which is good otherwise - >> somebody must have done surprisingly lots of care) really from Debian >> or is there maybe a sort of 2nd default option bundle somewhere in >> Pythons configure? (If really not so I would go for Debian BTS.) > Well, seeing as Mageia's Python 2.7 doesn't have the problem, I really > think it must be Debian-specific: as emphasized in my sentence such reasoning alone would be sloppy. Thats why I asked. Does sb actually know, if this optimized semistatic module list is really not in Pythons configure somewhere? (The Debians would have gone rather deep into issues when they really created that fine tuning on their own. almost can't believe. If so I'd even recommend to adopt that (except _ssl.so) generally into Pythons standard configuration - at least for Linux) ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue13580> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
