Re: [Python-Dev] PEP397 no command line options to python?
On 17 October 2011 15:20, Vinay Sajip vinay_sa...@yahoo.co.uk wrote: Sam Partington sam.partington at gmail.com writes: That sounds like an explanation of why it hasn't been implemented before, not an explanation of why it should continue that way. From a desire to keep the launcher as simple as possible, and to minimise the need to synchronise the launcher with command line parameter changes in future versions of Python. As simple as possible yes... but no simpler. I think having pylauncher behave so differently in the two cases of : py -u test.py py test.py Is very unexpected. And to do so silently, without warning will cause real headaches_ for users, *especially* since py -h lists -u as one of the options, it does not say 'here are the python options but you must call PythonXX/python.exe to use them'. [headaches : it did for me as I ended up with a broken build of my app due to different parts of my app built for different pythons.] To fix this the launcher doesn't need to track all python command line options, only those that take two args. I don't really see that it will be such a maintenance burden to have the launcher track any new ones. Python has only two such options after 20 years of development. As for complexity it's less than 10 lines of C. In any case, I think that expectation is not complete. In my case it was my editor that inserted the '-u' on my behalf. Or why might I not set the default action for .py files to be py -tt %1, or py -3 %1. Why deny any of the arguments to a pylauncher user? Don't forget that customised commands allow Python to be invoked from shebang lines with fair flexibility. That's a cool feature which I'd not really read up on, but that requires a global configuration file change, it's not doable on a per usage basis. Don't worry about separating them for now, assuming that it's fairly easy to figure out which bit is which :-) It wasn't hard to do and I see you've applied the patch already, thanks for the fast turn around! Sam PS Sorry, I replied off-list again! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP397 no command line options to python?
From a desire to keep the launcher as simple as possible, and to minimise the need to synchronise the launcher with command line parameter changes in future versions of Python. As simple as possible yes... but no simpler. I think having pylauncher behave so differently in the two cases of : py -u test.py py test.py Is very unexpected. And to do so silently, without warning will cause It's only unexpected if you don't read the PEP. From there: The launcher may offer some conveniences for Python developers working interactively - for example, starting the launcher with no command-line arguments will launch the default Python with no command-line arguments. Further, command-line arguments will be supported to allow a specific Python version to be launched interactively - however, these conveniences must not detract from the primary purpose of launching scripts and must be easy to avoid if desired. real headaches_ for users, *especially* since py -h lists -u as one of the options, it does not say 'here are the python options but you must call PythonXX/python.exe to use them'. Well, it's easy enough to make that clearer in the help output of py.exe :-) [headaches : it did for me as I ended up with a broken build of my app due to different parts of my app built for different pythons.] Why does the need arise to invoke py.exe in a build system? Why not just reference the Python executable you want directly? To fix this the launcher doesn't need to track all python command line options, only those that take two args. I don't really see that it will be such a maintenance burden to have the launcher track any new ones. Python has only two such options after 20 years of development. As for complexity it's less than 10 lines of C. Plus tests, presumably ... let's see 'em :-) That's a cool feature which I'd not really read up on, but that requires a global configuration file change, it's not doable on a per usage basis. Per usage = interactively, which is more of a by-the-by feature for the launcher, the main purpose being to bring shebang-line functionality to Windows. Regards, Vinay Sajip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Disabling cyclic GC in timeit module
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ... If you are only measuring json encoding of a few select pieces of data then it's a microbenchmark. If you are measuring the whole application (or a significant part of it) then I'm not sure timeit is the right tool for that. Regards Antoine. When you're measuring how much time it takes to encode json, this is a microbenchmark and yet the time that timeit gives you is misleading, because it'll take different amount of time in your application. I guess my proposition would be to not disable gc by default and disable it when requested, but well, I guess I'll give up given the strong push against it. Cheers, fijal True, but it is also heavily dependent on how much other data your application has in memory at the time. If your application has 1M objects in memory and then goes to encode/decode a JSON string when the gc kicks in, it will take a lot longer because of all the stuff that isn't JSON related. I don't think it can be suggested that timeit should grow a flag for put garbage into memory, and then run this microbenchmark with gc enabled.. If you really want to know how fast something is in your application, you sort of have to do the timing in your application, at scale and at load. John =:- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6dLwMACgkQJdeBCYSNAAOzzACfXpP16589Mu7W8ls9KddacF+g ozwAnRz5ciPg950qcV2uzyTKl1R21+6t =hGgf -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP397 no command line options to python?
On 18 October 2011 08:10, Vinay Sajip vinay_sa...@yahoo.co.uk wrote: Is very unexpected. And to do so silently, without warning will cause It's only unexpected if you don't read the PEP. From there: The launcher may offer some conveniences for Python developers working interactively - for example, starting the launcher with no command-line arguments will launch the default Python with no command-line arguments. Further, command-line arguments will be supported to allow a specific Python version to be launched interactively - however, these conveniences must not detract from the primary purpose of launching scripts and must be easy to avoid if desired. I read the PEP, but didn't spot that subtelty.I wonder how many other people will read the PEP, or just think Oh, I can just replace python with py and have it figure out the python to call. real headaches_ for users, *especially* since py -h lists -u as one of the options, it does not say 'here are the python options but you must call PythonXX/python.exe to use them'. Well, it's easy enough to make that clearer in the help output of py.exe :-) Indeed, I would say that if nothing else then that should be done [headaches : it did for me as I ended up with a broken build of my app due to different parts of my app built for different pythons.] Why does the need arise to invoke py.exe in a build system? Why not just reference the Python executable you want directly? That's rather OT here, but briefly as I can. We have transitioned our devel branch to py 2.7. Our stable branches are to remain py 2.6. The build system (also written in python) starts lots of sub build commands, (various SCons, make, bash and python). I added shebangs to all files as appropriate for devel/stable branch, and initially I changed the python build targets from python -utt build.py to ./build.py and I lost the -utt functionality which I could live with. But on some of the windows machines the default action of python files was to open an editor with the build.py. So I changed it to py -utt build.py. Everything seemed fine initially until tests started to fail which ensued some head scratching. I actually didn't figure out what was going on until I noticed that SCiTe was also calling the wrong python because it also had py -utt to run python scripts. Incidentally, one of my colleagues also discovered the same issue in his eclipse pydev setup. I also notice that Editra also does python -u by default, and I can imagine lots of users swapping python with py. I am well aware that is is by no means a perfect system and I am working at making it more bulletproof, but as usual there are time constraints etc. We will also go through the whole thing again when wxPython supports python 3. Hopefully I will have solved all these issues by then :-) To fix this the launcher doesn't need to track all python command line options, only those that take two args. I don't really see that it will be such a maintenance burden to have the launcher track any new ones. Python has only two such options after 20 years of development. As for complexity it's less than 10 lines of C. Plus tests, presumably ... let's see 'em :-) That's a cool feature which I'd not really read up on, but that requires a global configuration file change, it's not doable on a per usage basis. Per usage = interactively, which is more of a by-the-by feature for the launcher, the main purpose being to bring shebang-line functionality to Windows. Fair enough. I can see that I am asking more of pylauncher than the unix shebang parser does. But it seems to so nearly do it correctly that I was surprised that it didn't do what I had assumed it did do. I find this usage of it so useful in fact that irrespective of whether the PEP takes on my suggestions I will be using the patched one, and I will be writing a unix pylauncher to do the same. Would it not be an idea to have new installations of python actually install pylauncher as 'python' which then forwards onto the correct 'pythonX.X'. It would possibly help resolve the whole question of Does python invoke python2 or python3 issue. The patch should be attached. It is of course 20% C and 80% python tests :-) Sam add_arg_skipping.patch Description: Binary data ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (2.7): Fixes #10860: Handle empty port after port delimiter in httplib
Hi, diff --git a/Misc/NEWS b/Misc/NEWS --- a/Misc/NEWS +++ b/Misc/NEWS @@ -54,6 +54,9 @@ the following case: sys.stdin.read() stopped with CTRL+d (end of file), raw_input() interrupted by CTRL+c. +- Issue #10860: httplib now correctly handles an empty port after port + delimiter in URLs. + - dict_proxy objects now display their contents rather than just the class name. Looks like your entry went into the Interpreter Core section instead of Library. BTW, I don’t understand “3.x version will come as a separate patch” in your commit message; isn’t that the case for all patches? They’re changesets with no relationship at all from Mercurial’s viewpoint, and often their contents are also different. Cheers ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (2.7): Fixes #10860: Handle empty port after port delimiter in httplib
On Tue, Oct 18, 2011 at 11:23 PM, Éric Araujo mer...@netwok.org wrote: Looks like your entry went into the Interpreter Core section instead of Library. That should be corrected. BTW, I don’t understand “3.x version will come as a separate patch” in I think, he meant in a separate commit. :) Senthil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP397 no command line options to python?
On 18/10/2011 8:59 PM, Sam Partington wrote: ... I added shebangs to all files as appropriate for devel/stable branch, and initially I changed the python build targets from python -utt build.py to ./build.py and I lost the -utt functionality which I could live with. Can't you just put the -utt options in the shebang line of build.py? But on some of the windows machines the default action of python files was to open an editor with the build.py. So I changed it to py -utt build.py. Everything seemed fine initially until tests started to fail which ensued some head scratching. I actually didn't figure out what was going on until I noticed that SCiTe was also calling the wrong python because it also had py -utt to run python scripts. Incidentally, one of my colleagues also discovered the same issue in his eclipse pydev setup. I also notice that Editra also does python -u by default, and I can imagine lots of users swapping python with py. Why would users choose to do that? Using python presumably already works for them, so what benefit do they get? If the main advantage is they can now use shebang lines, then the specific options the script wants can be expressed in that line. I wonder if we just need to make it clear that py.exe is not designed to simply be a replacement for python.exe - a simple replacement adds no value. It is designed to bring shebang processing to Python on Windows and the shebang line is where these args should live. If you want finer control over things, just keep using python.exe. Also, seeing it is much easier to add a feature later than to remove it, we should err on the side of not adding the feature until it is clear that many people want it and ensure we aren't creating other inconsistencies or issues when we do. If it turns out to be true that even with clear documentation people come to the same conclusion as you (ie, that py.exe supports arguments the same way as python.exe) we still have the option of adding it. Cheers, Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
