Re: [Python-Dev] ConfigParser mangles keys with special chars
* Florian Bruhin m...@the-compiler.org [2014-04-25 16:22:06 +0200]: I noticed configparser does behave in a surprising way when a key has a special meaning in ini-format. I've now submitted an issue here: http://bugs.python.org/issue21498 Florian -- () ascii ribbon campaign - stop html mailwww.asciiribbon.org /\ www.the-compiler.org | I love long mails http://email.is-not-s.ms/ Blessed are the forgetful: for they get the better even of their blunders. -- Nietzsche pgp8OOQCUnDP_.pgp Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python process creation overhead
On 5/12/2014 8:43 PM, Nick Coghlan wrote: On 13 May 2014 10:19, dw+python-...@hmmz.org wrote: On Mon, May 12, 2014 at 04:22:52PM -0700, Gregory Szorc wrote: Why can't Python start as quickly as Perl or Ruby? On my heavily abused Core 2 Macbook with 9 .pth files, 2.7 drops from 81ms startup to 20ms by specifying -S, which disables site.py. Oblitering the .pth files immediately knocks 10ms off regular startup. I guess the question isn't why Python is slower than perl, but what aspects of site.py could be cached, reimplemented, or stripped out entirely. I'd personally love to see .pth support removed. The startup code is currently underspecified and underdocumented, and quite fragile as a result. It represents 20+ years of organic growth without any systematic refactoring to simplify and streamline things. That's what PEP 432 aims to address, and is something I now expect to have time to get back to for Python 3.5. And yes, one thing those changes should enable is the creation of system Python runtimes on Linux that initialise faster than the current implementation. This is terrific news and something I greatly anticipate taking advantage of! But the great many of us still on 2.7 likely won't see a benefit, correct? How insane would it be for people to do things like pass -S in the shebang and manually implement the parts of site.py that are actually needed? ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python process creation overhead
Gregory Szorc writes: But the great many of us still on 2.7 likely won't see a benefit, correct? How insane would it be for people to do things like pass -S in the shebang and manually implement the parts of site.py that are actually needed? Well, since it probably won't work wink/ That is to say, site.py typically provides different facilities to different programs -- that's why some parts of it show up as unneeded. So you need to carefully analyze *each* *subprocess* that you propose to invoke with -S and determine which parts of site.py it needs. In most cases I suspect you would better look at alternatives that avoid invoking a subprocess per task, but instead maintains a pool of worker processes (or threads). You might even be able to save network traffic or IPC by caching replies to common requests in the worker processes, which may save more per task than process invocation. Even where -S makes sense, I would suggest invoking python -S explicitly from the parent process rather than munging the shebang in the children. (You do need to be careful to audit changes in the child programs to be sure they aren't changed in ways that change site.py requirements. Putting -S in the shebang may help catch such problems early.) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
