Re: [Python-Dev] PEP397 no command line options to python?
On 19 October 2011 00:18, Mark Hammond skippy.hamm...@gmail.com wrote: On 18/10/2011 8:59 PM, Sam Partington wrote: ... 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 use py interactively rather than python because I have 2.7 and 3.2 installed, and py -2 or py -3 gives me the explicit version I want without PATH hacking. If 2.7 and 3.x provided python2 and python3 executables explicitly I might not do this (I'm not at my PC right now so I can't recall if 3.x provides python3.exe as well as python.exe, there was talk of this certainly, but 2.7 definitely doesn't include python2.exe). Having said that, I don't use other command line options much, so the limitation doesn't bother me much (py -3 -m xxx would be the most likely usage I'd miss...) If the extra options really mattered to me, I could probably hack up a Powershell alias easily enough, but py -V is available and does 99% of what I need. Paul. ___ 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 19 October 2011 00:18, Mark Hammond skippy.hamm...@gmail.com wrote: 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? Yes I can but I didn't. There are many ways to skin this cat, but I chose what seemed the most straightforward way. It went wrong and I didn't expect it to. Adding -tt to the shebang line makes sense, the use of -tt depends on the content of the script (although it would require me to add -tt to thousands of shebang lines). But the addition of '-u' depends on the environment in which I want to run it. i.e. when run from a console it's unnecessary and a performance penalty, whilst when run as part of a sub-process (either from an editor or as part of a larger collection of scripts) then it's nice to avoid having the output arrive in lumps. 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. But python does NOT work. If you have multiple pythons installed and scripts that are designed to run with various versions then 'python' will use the wrong one, I had thought that this was precisely what pylauncher was meant to solve, i.e. the ability to select the correct python version based on the contents of that file. Nearly all python editors have the ability to run the current script with python. None of the editors that I know of have the ability (out of the box) to parse the shebang line and dispatch to the correct python. There is however already a tool that can do that, called pylauncher. Swap python with py and it would work in all editors. The only problem is that it does not support unbuffered output which nearly all editors will need in order to display timely output. If you don't want to support all args, how about just supporting the -u argument, which is the one I really need? My issue is currently to select the right python from 2.4, 2.5, 2.6, 2.7. But the need for a tool like this is even stronger when encouraging users to move to py 3 - on all platforms. In the absence of .py3 file extensions the shebang seems the way to go. Why would users choose to do that? : Because they are in a project using mixed python versions and they want an easy way to use the correct python from within their editor. 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. There I have to disagree. Yes, a simple replacement would not add value. But a replacement that detects the correct python but otherwise works like python adds lots of value and what is more it has value on all platforms. Shouldn't that argument have applied also for the version specifier args, because to my mind that is a less elegant feature with more baggage. (oddity of py -2 -3 for example). If you want finer control just keep using c:\PythonXX\python.exe. Incidentally it would be really really nice if the windows installer installed pythonX[.Y].exe then we could just put all the python dirs in PATH and it would just work. no need for the -X.Y flags at all. 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. Ok ok, I give up. Apparently I am the only one who wants to be able to run different versions of python based on the shebang line AND add occasional arguments to the python command line. Thanks for listening. Sam
Re: [Python-Dev] PEP397 no command line options to python?
Sam Partington sam.partington at gmail.com writes: Ok ok, I give up. Apparently I am the only one who wants to be able to run different versions of python based on the shebang line AND add occasional arguments to the python command line. It sounds as if adding arguments to the shebang line will work for all cases other than the invoke-from-editor case. (Even if you need to change thousands of shebang lines, you might be able to automate this with Python, so perhaps it's not as bad as it sounds.) For the invoke-from-editor case, that's most useful when you have a reasonably long edit-run-edit-run-... session for the script(s) being edited. If that's the case, just append -u to the shebang line at the beginning of your session, and remove it at the end, and keep using py as your editor's Python; won't that do the trick? 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
[Python-Dev] Buildbots with rpm installed
Hi, Do we have buildbots with the rpm programs installed? There is a patch I want to commit to fix a bug in distutils’ bdist_rpm; it was tested by the patch author, but I cannot verify it on my machine, so I would feel safer if our buildbot fleet would cover that. Thanks ___ 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] Buildbots with rpm installed
Éric Araujo mer...@netwok.org wrote: Do we have buildbots with the rpm programs installed? There is a patch I want to commit to fix a bug in distutils’ bdist_rpm; it was tested by the patch author, but I cannot verify it on my machine, so I would feel safer if our buildbot fleet would cover that. Yes, the Fedora bot currently fails the bdist_rpm tests: http://www.python.org/dev/buildbot/all/builders/AMD64%20Fedora%20without%20threads%203.x/builds/873/steps/test/logs/stdio Stefan Krah ___ 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
[Python-Dev] Define Tracker workflow
Does everybody feel comfortable with 'stage' and 'resultion' fields in tracker? I understand that 'stage' defines workflow and 'resolution' is status indicator, but the question is - do we really need to separate them? For example, right now when a ticket's 'status' is closed (all right - there is also a 'status' field), we mark 'stage' as 'committed/rejected'. I see the 'stage' as a workflow state and 'committed/rejected' value is confusing because further steps are actually depend on if the state is actually 'committed' or 'rejected'. stage: patch review - committed/rejected When I see a patch was rejected, I need to analyse why and propose a better one. To analyse I need to look at 'resolution' field: duplicate fixed invalid later out of date postponed rejected remind wont fix works for me The resolution will likely be 'fixed' which doesn't give any info about if the patch was actually committed or not. You need to know that there is 'rejected' status, so if the status 'is not rejected' then the patch was likely committed. Note that resolution is also a state, but for a closed issue. Let me remind the values for the state of opened issue (recorded in a 'stage' field): test needed needs patch patch review commit review committed/rejected There is a clear duplication in stage:'committed/rejected', resolution:'fixed,rejected' and status:'closed'. Now `status` can be one of: open languishing pending closed For me the only things in `status` that matter are - open and closed. Everything else is more descriptive 'state' of the issue. So I'd merge all our descriptive fields into single 'state' field that will accept the following values depending on master 'status': open: languishing pending needs test needs patch patch review commit review closed: committed duplicate fixed invalid out of date rejected wont fix works for me Renamed 'test needed' - 'needs test'. For a workflow states like 'later', 'postponed' and 'remind' are too vague, so I removed them. These are better suit to user tags (custom keywords) like 'easy' etc. Implementing this change will 1. define clear workflow to pave the road for automation and future enhancements (commit/review queue, etc.) 2. de-clutter tracker UI to free space for more useful components 3. reduce categorization overhead -- anatoly t. ___ 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] Define Tracker workflow
On Wed, Oct 19, 2011 at 14:17, anatoly techtonik techto...@gmail.com wrote: The resolution will likely be 'fixed' which doesn't give any info about if the patch was actually committed or not. If there's no commit update in the messages on the issue, you should assume it was not committed. At that point, either it wasn't actually committed (fixed), or the person forgot to tag the issue in the commit message, which they should remedy by just posting a message with the changeset ID. ___ 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): Fix closes Issue12529 - cgi.parse_header failure on double quotes and
On Thu, Oct 20, 2011 at 2:53 AM, senthil.kumaran python-check...@python.org wrote: http://hg.python.org/cpython/rev/489237756488 changeset: 72988:489237756488 branch: 2.7 parent: 72984:86e3943d0d5b user: Senthil Kumaran sent...@uthcode.com date: Thu Oct 20 00:52:24 2011 +0800 summary: Fix closes Issue12529 - cgi.parse_header failure on double quotes and semicolons. Patch by Ben Darnell and Petri Lehtinen. files: Lib/cgi.py | 2 +- Lib/test/test_cgi.py | 3 +++ 2 files changed, 4 insertions(+), 1 deletions(-) NEWS entry? (same question for the later _sre fix) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] Define Tracker workflow
On Wed, 2011-10-19 at 22:17 +0300, anatoly techtonik wrote: Does everybody feel comfortable with 'stage' and 'resultion' fields in tracker? I understand that 'stage' defines workflow and 'resolution' is status indicator, but the question is - do we really need to separate them? For example, right now when a ticket's 'status' is closed (all right - there is also a 'status' field), we mark 'stage' as 'committed/rejected'. I see the 'stage' as a workflow state and 'committed/rejected' value is confusing because further steps are actually depend on if the state is actually 'committed' or 'rejected'. stage: patch review - committed/rejected When I see a patch was rejected, I need to analyse why and propose a better one. To analyse I need to look at 'resolution' field: duplicate fixed invalid later out of date postponed rejected remind wont fix works for me The resolution will likely be 'fixed' which doesn't give any info about if the patch was actually committed or not. You need to know that there is 'rejected' status, so if the status 'is not rejected' then the patch was likely committed. Note that resolution is also a state, but for a closed issue. It's somewhat confusing to me also. For me the only things in `status` that matter are - open and closed. Everything else is more descriptive 'state' of the issue. So I'd merge all our descriptive fields into single 'state' field that will accept the following values depending on master 'status': open: languishing pending needs test needs patch patch review commit review closed: committed duplicate fixed invalid out of date rejected wont fix works for me I like the idea. But its not clear what should be set at what times. While trying not to change too much, how about the following? Status: Open Closed Stage: In progress: needs fix (More specific than the term 'patch'.) needs test needs docs needs patch (Needs a combined fix/test/docs .diff file.) needs patch review (To Accepted if OK.) languishing (To Rejected:out_of_date if no action soon.) pending Accepted: commit review committed (And Close) Rejected: (Pick one and Close.) duplicate invalid out of date won't fix cannot reproduce (instead of 'works for me') This combines the stage and resolution fields together. Currently the stage is up in the upper left of a tracker page, while the status and resolution is further down. They should at least be moved near each other. +--+--+---+ | status: | stage: |resoltution: | +--+--+---+ But it would be better if it was just... +++ | status:| stage: | +++ And just list the stages like... status: Open stage: In progress - needs docs status: Open stage: In progress - needs patch review status: Open stage: Accepted - commit review status: Closed stage: Accepted - committed status: Closed stage: Rejected - invalid It's not entirely consistent because while it's open, the stage refers to what is needed, but once it's closed, it refers to the last item done. But I think it would be fine that way. As for more detailed info, you pretty much have to read the discussion. Cheers, Ron ___ 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
