[issue45901] store app file type ignores command-line arguments

[Steve Dower]

Change by Steve Dower :


--
assignee:  -> steve.dower
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45901] store app file type ignores command-line arguments

[Steve Dower]

Steve Dower  added the comment:


New changeset 133fb267f437f9bd568738d0e0e59e574fc82b02 by Miss Islington (bot) 
in branch '3.9':
bpo-45901: Fixes argument passing when invoking .py files directly through the 
Store package (GH-29799)
https://github.com/python/cpython/commit/133fb267f437f9bd568738d0e0e59e574fc82b02


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45901] store app file type ignores command-line arguments

[miss-islington]

miss-islington  added the comment:


New changeset 3dcbe01dc5236fb77d8c0133fb7e6bdd0754768a by Miss Islington (bot) 
in branch '3.10':
bpo-45901: Fixes argument passing when invoking .py files directly through the 
Store package (GH-29799)
https://github.com/python/cpython/commit/3dcbe01dc5236fb77d8c0133fb7e6bdd0754768a


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45901] store app file type ignores command-line arguments

[miss-islington]

Change by miss-islington :


--
pull_requests: +28040
pull_request: https://github.com/python/cpython/pull/29808

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45901] store app file type ignores command-line arguments

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 5.0 -> 6.0
pull_requests: +28039
pull_request: https://github.com/python/cpython/pull/29807

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45901] store app file type ignores command-line arguments

[Steve Dower]

Steve Dower  added the comment:


New changeset 4841e694ee1686f8c933ddfcb8c854915867ce17 by Steve Dower in branch 
'main':
bpo-45901: Fixes argument passing when invoking .py files directly through the 
Store package (GH-29799)
https://github.com/python/cpython/commit/4841e694ee1686f8c933ddfcb8c854915867ce17


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45901] store app file type ignores command-line arguments

[Steve Dower]

Steve Dower  added the comment:

For future reference, in case someone stumbles over this issue, here's how I 
tested this change:

* set $env:IncludeUWP="true"
* did a regular PCbuild/build.bat
* generated a Store layout with "./python.bat PC/layout --preset-appx --copy 
./out"
* mock-installed it with "Add-AppxPackage -Register ./out/appxmanifest.xml"
* used "Default Programs" to change my default to the new installed Python 3.11
* put "import sys; print(sys.argv); input()" into test.py
* ran "test.py arg1 arg2" and inspected the output

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45901] store app file type ignores command-line arguments

[Steve Dower]

Change by Steve Dower :


--
keywords: +patch
pull_requests: +28034
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/29799

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45901] store app file type ignores command-line arguments

[Eryk Sun]

New submission from Eryk Sun :

The file association for the store app uses '"%1"' for the command-line 
parameters. This ignores the rest of the command-line arguments, i.e. '%*'. In 
PC/layout/support/appxmanifest.py, the add_application() calls that add the 
"Python" and "PythonW" applications should be changed to use the parameters 
string '"%1" %*' in the file types.

--
components: Installation, Windows
messages: 407029
nosy: eryksun, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: store app file type ignores command-line arguments
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

___
Python tracker 
<https://bugs.python.org/issue45901>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23427] Add sys.orig_argv: original command line arguments passed to the Python executable

[STINNER Victor]

STINNER Victor  added the comment:

I added sys.orig_argv to the master branch (future Python 3.10).

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23427] Add sys.orig_argv: original command line arguments passed to the Python executable

[STINNER Victor]

STINNER Victor  added the comment:


New changeset dd8a93e23b5c4f9290e1cea6183d97eb9b5e61c0 by Victor Stinner in 
branch 'master':
bpo-23427: Add sys.orig_argv attribute (GH-20729)
https://github.com/python/cpython/commit/dd8a93e23b5c4f9290e1cea6183d97eb9b5e61c0


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23427] Add sys.orig_argv: original command line arguments passed to the Python executable

[STINNER Victor]

STINNER Victor  added the comment:

The setproctitle project uses Py_GetArgcArgv() and would benefit of 
PyConfig.orig_argv, see:

* https://bugs.python.org/issue15577#msg370965
* https://github.com/dvarrazzo/py-setproctitle/issues/8

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23427] Add sys.orig_argv: original command line arguments passed to the Python executable

[STINNER Victor]

Change by STINNER Victor :


--
versions: +Python 3.10 -Python 3.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23427] Add sys.orig_argv: original command line arguments passed to the Python executable

[STINNER Victor]

Change by STINNER Victor :


--
title: Python should expose command when invoked with -c -> Add sys.orig_argv: 
original command line arguments passed to the Python executable

___
Python tracker 
<https://bugs.python.org/issue23427>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29857] Provide `sys.executable_argv` for host application's command line arguments

[STINNER Victor]

STINNER Victor  added the comment:

I mark this issue as a duplicate of bpo-23427 which has patch and is older.

--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Python should expose command when invoked with -c

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36825] Make TestCase aware of the command line arguments given to TestProgram

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Since test modules can already be run in parallel, #37873 does not seem 
relevant here.  (And I agree with the intent of that.)

I would be reluctant to add a mechanism with no current use, so I would not 
apply absent a decision to add one.

--
nosy: +ezio.melotti, michael.foord, rbcollins

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36825] Make TestCase aware of the command line arguments given to TestProgram

[Rémi Lapeyre]

Rémi Lapeyre  added the comment:

Bumping this issue as issue 37873 that wants to add a new -j argument to 
unittest got some attention lately.

This PR makes the Test Cases aware of the command line arguments given to 
unittest.main() and is needed to add the --pdb argument proposed in issue 18765 
to run pdb.post_mortem() when an exception occurs during a test.

Both this issue and #18765 would be very useful to augment unittest.

--
nosy: +gregory.p.smith, terry.reedy
versions: +Python 3.9 -Python 3.8

___
Python tracker 
<https://bugs.python.org/issue36825>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25631] Segmentation fault with invalid Unicode command-line arguments in embedded Python

[STINNER Victor]

STINNER Victor  added the comment:

This bug has been fixed in the implementation of the PEP 587.

$ gcc x.c -l python3.8 $(pkg-config python-3.8 --cflags --libs) -o x
$ ./x
Fatal Python error: pyinit_main: can't finish initializing sys
ValueError: character U+11 is not in range [U+; U+10]

Current thread 0x7fd23364e6c0 (most recent call first):

=> it doesn't crash anymore, but write a error message and exit.

--
nosy: +vstinner
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions: +Python 3.8, Python 3.9 -Python 3.4, Python 3.5, Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5680] Simulate command-line arguments for program run in IDLE

[miss-islington]

miss-islington  added the comment:


New changeset 81f7899f517f18a45ab111598f9dd6d7210956a8 by Miss Islington (bot) 
in branch '3.7':
bpo-5680: IDLE: Customize running a module (GH-13763)
https://github.com/python/cpython/commit/81f7899f517f18a45ab111598f9dd6d7210956a8


--
nosy: +miss-islington

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5680] Simulate command-line arguments for program run in IDLE

[miss-islington]

miss-islington  added the comment:


New changeset ae526ee320d3feabba0aa4dffa9d52e39f8941dc by Miss Islington (bot) 
in branch '3.8':
bpo-5680: IDLE: Customize running a module (GH-13763)
https://github.com/python/cpython/commit/ae526ee320d3feabba0aa4dffa9d52e39f8941dc


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5680] Simulate command-line arguments for program run in IDLE

[Terry J. Reedy]

Terry J. Reedy  added the comment:

A more than minimal patch has been merged.  Further work will be on new issues. 
 Remaining problems not previously discussed:

1. Tab focus traversal is wrong.  This is generic to Query subclasses that add 
widgets.  See #37325.

2. When the customize box is cancelled, focus goes to the Shell, even when I 
add 'event.widget.focus_set/force()'.  When the parent of the box was the 
editor, 'self.shell.text.focus_set' did not work to shift it to the Shell text.

Does anyone else have any idea how to put the focus back on the editor after 
cancel?

--
nosy: +taleinat
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5680] Simulate command-line arguments for program run in IDLE

[miss-islington]

Change by miss-islington :


--
pull_requests: +14021
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/14184

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5680] Simulate command-line arguments for program run in IDLE

[miss-islington]

Change by miss-islington :


--
pull_requests: +14022
pull_request: https://github.com/python/cpython/pull/14185

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5680] Simulate command-line arguments for program run in IDLE

[Terry J. Reedy]

Terry J. Reedy  added the comment:


New changeset 201bc2d18b60adb05810d2a6ab396047bc527088 by Terry Jan Reedy 
(Cheryl Sabella) in branch 'master':
bpo-5680: IDLE: Customize running a module (GH-13763)
https://github.com/python/cpython/commit/201bc2d18b60adb05810d2a6ab396047bc527088


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5680] Simulate command-line arguments for program run in IDLE

[Cheryl Sabella]

Cheryl Sabella  added the comment:

I've pushed a change for a more generic dialog for a 'Run Custom' option and I 
changed the keybinding to Shift-F5.  Sorry for not doing that on the initial 
commit; I didn't fully understand the difference between what you were asking 
for and the minimal version I had committed.

For this change, I also added a 'Restart shell' checkbox to the dialog, more as 
a proof-of-concept than anything else (although I did hook it up, so it should 
be functional).  Is this the type of dialog you had in mind?

I made some comments on the PR as to some of the decisions I've run into so far 
with the design.

Thanks!

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5680] Simulate command-line arguments for program run in IDLE

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Two design issues:

1. As I said 2017-06-20, msg296499, I expect to add more alternatives to the 
standard run to this menu option and dialog.  (Cheryl, I should have pointed 
you to this post as well as the later ones.)  I want to add just one new option 
to have only 1 new key to learn.  I already cannot remember all of them and I 
expect I am not the only one.  They need to be together on one dialog so that 
uses can conveniently pick multiple options when that makes sense.  Running in 
a console with args is completely sensible.  And exclusionary logic, such as 
'Cannot supply arguments if no restart' should be easier on one dialog.

The configuration and pseudoevent names, perhaps 'run-custom', should be 
changed to reflect that now.  For the menu, I am less sure.  Perhaps 'Run 
Custom', 'Run Setup', 'Run with Alternatives', 'Alternate Runs'?

2. I am pretty sure I prefer shift-F5 for the key.  (But cannot be sure until I 
try it.)  Easier to learn I think.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5680] Simulate command-line arguments for program run in IDLE

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Thanks.  Those seem reasonable for a first pass.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5680] Simulate command-line arguments for program run in IDLE

[Cheryl Sabella]

Cheryl Sabella  added the comment:

I've added a minimal change for running a module in the editor with command 
line arguments. 

Some notes:
1. The shortcut key (F7) can be entered while on the shell window.  As of now, 
any of the Run menu shortcuts can be entered, so I didn't fix that bug as part 
of this issue.
2. I'm not saving the arguments in any way.
3. I didn't (yet) make the change to print the command line arguments in the 
shell or to add it to the status bar.
4. I didn't make a change to get the sys.argv values from startup.
5. I added a single menu entry and not a cascade of different custom run 
options.

--
stage: patch review -> needs patch

___
Python tracker 
<https://bugs.python.org/issue5680>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5680] Simulate command-line arguments for program run in IDLE

[Cheryl Sabella]

Change by Cheryl Sabella :


--
pull_requests: +13648
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/13763

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5680] Simulate command-line arguments for program run in IDLE

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Cheryl, go ahead after reading the notes above.  Use an f-string for the 
runcommand argument and remember that it is run within the pristine user 
environment.  Otherwise, let's start with minimal changes.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5680] Simulate command-line arguments for program run in IDLE

[Terry J. Reedy]

Terry J. Reedy  added the comment:

My suspicion about posix=False was wrong.

>>> shlex.split(''' 1 "'a' 'b'" ''', posix=False)
['1', '"\'a\' \'b\'"']  # len(...[1]) = 9
>>> shlex.split(''' 1 '"a" "b"' ''')
['1', '"a" "b"']  # len = 7
f:\dev\3x>py -c "import sys; print(sys.argv)" 1 "'a' 'b'"
['-c', '1', "'a' 'b'"]  # Matches 'True'

>>> shlex.split(''' 1 '"a" "b"' ''', posix=False)
['1', '\'"a" "b"\'']
>>> shlex.split(''' 1 '"a" "b"' ''')
['1', '"a" "b"']  # Similar difference
f:\dev\3x>py -c "import sys; print(sys.argv)" 1 '"a" "b"'
['-c', '1', "'a", "b'"]  # crazy inversion and 3 args, matches neither

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5680] Simulate command-line arguments for program run in IDLE

[Terry J. Reedy]

Terry J. Reedy  added the comment:

When running IDLE normally, with a subprocess, it would be possible to pass 
arguments to python itself when IDLE restarts the user process (with
shell.restart_shell()).  That would be another issue.  We would have to look at 
whether any options would disable idlelib.run and how running code supervised 
might change results.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5680] Simulate command-line arguments for program run in IDLE

[Cheryl Sabella]

Cheryl Sabella  added the comment:

I'll can work on a PR for this, unless you want to do it based on your research.

--
nosy: +cheryl.sabella

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5680] Simulate command-line arguments for program run in IDLE

[Terry J. Reedy]

Terry J. Reedy  added the comment:

3 recent 'doit' requests (2 on PR 1589) raise my priority for this issue.

When a user runs a file from an editor, IDLE simulates, as well as it can, the 
user entering 'python -i path' in a system command line shell.   Both on a 
command line and in IDLE, the program starts with sys.argv = ['path'] (at least 
on my Windows system).  This can be shown by running a file with 'import sys; 
print(sys.path)' both ways.

The request for this issue is to simulate 'python -i path a1, a2, ...'.
The program should start with sys.argv = ['path', 'a1', 'a2', '...'], with the 
argument strings being the same as they would be if entered at a command line 
on the *same system*.

I have looked at least a bit at all 4 patches and have decided to start fresh, 
using just a few existing lines.  The latest of the 4 was submitted 2 years 
ago, while I was learning to use git.

By the following September, using config-extensions was obsolete.  *If* we want 
to save a command string across sessions, a line could be added to config-main. 
 But I am dubious about this.  I expect that users will want to vary argument 
values for 1 program and need different sets of arguments for different 
programs.


I want to use a subclass of idlelib.query.Query for the query box.  No need to 
reinvent it.

I believe that argument strings should be parsed into an argument list using 
shlex.split.  No need to reinvent that either.  But I am not an expert in this 
area and the doc it rather vague.  I suspect that 'posix=False' should be used 
on Windows.  Does anyone know?  Gabriel's patch is the only one using 
shlex.split, but always with the default 'posix=True'.

Saimadhav tested his patch on Debian.  The others did not say.  A 
verified-by-human htest should be added to runscript.py, and manual test 
running 'import sys; print(sys.argv)' from an editor done on the 3 major OSes.

--
stage: patch review -> needs patch
title: Command-line arguments when running in IDLE -> Simulate command-line 
arguments for program run in IDLE
versions: +Python 3.8 -Python 3.6

___
Python tracker 
<https://bugs.python.org/issue5680>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5680] Command-line arguments when running in IDLE

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Can be bump this up in priority?  The patch has been awaiting review for a good 
while.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36825] Make TestCase aware of the command line arguments given to TestProgram

[Rémi Lapeyre]

Change by Rémi Lapeyre :


--
keywords: +patch
pull_requests: +13066
stage:  -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36825] Make TestCase aware of the command line arguments given to TestProgram

[Rémi Lapeyre]

New submission from Rémi Lapeyre :

Hi, to make unittest more extensible and for issue 18765 (having a way to run 
pdb when tests fail), I would like to make TestCase aware of the command line 
arguments given to the TestProgram so they can adapt their behavior based on 
them.

I suggested this change on python-ideas 
(https://mail.python.org/pipermail/python-ideas/2019-March/055842.html) but it 
did not get much attention.

I'm opening a PR in the hope to get more feedback and will start writing 
documentation.

Please comment if this is not appropriate or regarding anything I might have 
not thought of.

--
components: Tests
messages: 341697
nosy: remi.lapeyre
priority: normal
severity: normal
status: open
title: Make TestCase aware of the command line arguments given to TestProgram
type: enhancement
versions: Python 3.8

___
Python tracker 
<https://bugs.python.org/issue36825>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36036] Add method to get user defined command line arguments in unittest.main

[Rémi Lapeyre]

New submission from Rémi Lapeyre :

Hi, I'm working on issue 18765 (running pdb.post_mortem() on failing test 
cases) where I need to control the behavior of a TestCase based on some outside 
input.

For this issue, I want to add a new --pdb option to turn this feature on when 
enabled. As of today, it seems to me that the command line arguments given to 
the TestProgram are not accessible from the TestCase.

Would adding a new parameter to TestCase be breaking backward compatibility? If 
so, what would be a better way to access command line arguments from TestCase?



In addition to this, I have the need for another project to change the behavior 
of TestCases based on a custom command line argument. I propose to add a new 
method `getCustomArguments` that will take the parser as input so the user can 
define it's own arguments by subclassing TestProgram

What do you think about this?

--
files: 0001-WIP.patch
keywords: patch
messages: 335944
nosy: remi.lapeyre
priority: normal
severity: normal
status: open
title: Add method to get user defined command line arguments in unittest.main
Added file: https://bugs.python.org/file48154/0001-WIP.patch

___
Python tracker 
<https://bugs.python.org/issue36036>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36036] Add method to get user defined command line arguments in unittest.main

[Rémi Lapeyre]

Change by Rémi Lapeyre :


--
components: +Library (Lib)
versions: +Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5680] Command-line arguments when running in IDLE

[veganaiZe]

veganaiZe added the comment:

I've created a simple work-around for those who don't want to wait for the next 
release(s) of IDLE.  It's available on SO:

https://stackoverflow.com/a/44687632/5039027

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5680] Command-line arguments when running in IDLE

[Terry J. Reedy]

Terry J. Reedy added the comment:

Running with arguments is only one requested or possible deviation from the 
standard F5 mode.  See #19042, msg296498, for many more.  I am thinking that 
there should be one menu entry (Custom Run, Alt-F5)? that brings up a box with 
alternatives, initially defaulting to the F5 values, then persisting.

The order of execution should be a) Syntax check by compile, b) Run options, if 
requested, c) Restart Shell, if requested, d) Execute code object.

I want to start with setting sys.args, but with a mind to adding other things.  
Running without explicit saving might be next.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5680] Command-line arguments when running in IDLE

[Terry J. Reedy]

Changes by Terry J. Reedy :


--
nosy: +louielu

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5680] Command-line arguments when running in IDLE

[Terry J. Reedy]

Terry J. Reedy added the comment:

I closed #28889, with a 4th patch, in favor of this one.

Gabriel, you somehow never signed the PSF Contributor License Agreement.  Until 
you do, I will assume that anything you did is covered by the other 3 patches.

--
versions: +Python 3.7 -Python 2.7, Python 3.4, Python 3.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28889] IDLE needs the ability to pass in command-line arguments

[Terry J. Reedy]

Terry J. Reedy added the comment:

Another duplicate of #5680, which already has three patches.  I retitled the PR 
and it is now listed on #5680.

--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Command-line arguments when running in IDLE

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28889>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5680] Command-line arguments when running in IDLE

[Louie Lu (old)]

Changes by Louie Lu (old) :


--
pull_requests: +2353

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5680] Command-line arguments when running in IDLE

[veganaiZe]

Changes by veganaiZe :


--
nosy: +veganaiZe

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28889] IDLE needs the ability to pass in command-line arguments

[Louie Lu]

Louie Lu added the comment:

This PR will add the short-key to F7, when using editor. It will prompt up a 
dialog and user can input the command-line arguments then run the code.

--
nosy: +louielu

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28889>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28889] IDLE needs the ability to pass in command-line arguments

[Louie Lu]

Changes by Louie Lu :


--
pull_requests: +1682

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Python Command Line Arguments

[breamoreboy]

On Saturday, April 15, 2017 at 6:45:51 PM UTC+1, Grant Edwards wrote:
> On 2017-04-14, Bernd Nawothnig wrote:
> 
> > He should switch to argparse in any case because getopt is no longer
> > supported and does only receive bugfixes.
> 
> In my book, "receiving bug fixes" means it's still supported.
> 
> --
> Grant

Just to reinforce what I said before, optparse is deprecated, not getopt.

Kindest regards.

Mark Lawrence.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python Command Line Arguments

[breamoreboy]

On Friday, April 14, 2017 at 2:44:09 PM UTC+1, Bernd Nawothnig wrote:
> On 2017-04-13, Jason Friedman wrote:
> >> I have this code which I got from https://www.tutorialspoint.
> >> com/python/python_command_line_arguments.htm The example works fine but
> >> when I modify it to what I need, it only half works. The problem is the
> >> try/except. If you don't specify an input/output, they are blank at the end
> >> but it shouldn't be.
> >>
> >> import getopt
> >> import sys
> >
> > I am guessing you are wanting to parse command-line arguments rather than
> > particularly wanting to use the getopt module.
> > If I am correct you might want to spend your time instead learning the
> > argparse module:
> > https://docs.python.org/3/library/argparse.html
> > https://docs.python.org/3/howto/argparse.html
> 
> He should switch to argparse in any case because getopt is no longer
> supported and does only receive bugfixes.
> 
> Bernd
> 
> -- 
> Die Antisemiten vergeben es den Juden nicht, dass die Juden ‘Geist’
> haben – und Geld. Die Antisemiten – ein Name der
> ‘Schlechtweggekommenenen’ [Friedrich Nietzsche]

optparse is deprecated, not getopt.

Kindest regards.

Mark Lawrence.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python Command Line Arguments

[Grant Edwards]

On 2017-04-14, Bernd Nawothnig  wrote:

> He should switch to argparse in any case because getopt is no longer
> supported and does only receive bugfixes.

In my book, "receiving bug fixes" means it's still supported.

--
Grant

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python Command Line Arguments

[Bernd Nawothnig]

On 2017-04-13, Jason Friedman wrote:
>> I have this code which I got from https://www.tutorialspoint.
>> com/python/python_command_line_arguments.htm The example works fine but
>> when I modify it to what I need, it only half works. The problem is the
>> try/except. If you don't specify an input/output, they are blank at the end
>> but it shouldn't be.
>>
>> import getopt
>> import sys
>
> I am guessing you are wanting to parse command-line arguments rather than
> particularly wanting to use the getopt module.
> If I am correct you might want to spend your time instead learning the
> argparse module:
> https://docs.python.org/3/library/argparse.html
> https://docs.python.org/3/howto/argparse.html

He should switch to argparse in any case because getopt is no longer
supported and does only receive bugfixes.




Bernd

-- 
Die Antisemiten vergeben es den Juden nicht, dass die Juden ‘Geist’
haben – und Geld. Die Antisemiten – ein Name der
‘Schlechtweggekommenenen’ [Friedrich Nietzsche]
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python Command Line Arguments

[ian . stegner]

On Thursday, April 13, 2017 at 12:38:48 PM UTC+10, MRAB wrote:
> On 2017-04-13 02:59, ian.steg...@gmail.com wrote:
> > I have this code which I got from 
> > https://www.tutorialspoint.com/python/python_command_line_arguments.htm The 
> > example works fine but when I modify it to what I need, it only half works. 
> > The problem is the try/except. If you don't specify an input/output, they 
> > are blank at the end but it shouldn't be.
> > 
> > 
> > import getopt
> > import sys
> > 
> > def main(argv):
> > inputfile = ''
> > outputfile = ''
> > try:
> >opts, args = getopt.getopt(argv,"hi:o:",["ifile=","ofile="])
> > except getopt.GetoptError:
> >inputfile = 'Input'
> >outputfile = 'Output'
> > if inputfile == '':
> >for opt, arg in opts:
> >   if opt == '-h':
> >  print ('Usage: Encrypt.py -i  -o ')
> >  sys.exit()
> >   elif opt in ("-i", "--ifile"):
> >  inputfile = arg
> >   elif opt in ("-o", "--ofile"):
> >  outputfile = arg
> > else:
> >''
> > 
> > print 'In: ' + inputfile
> > print 'Out: ' + outputfile
> > 
> > if __name__ == "__main__":
> > main(sys.argv[1:])
> > 
> You'll get the GetoptError exception if an option that requires an 
> argument doesn't have one. That's not the same as omitting the option 
> entirely.
> 
> For example:
> 
>  # No -i option.
>  foo
> 
>  # Option -i present but without its required argument.
>  foo -i

WOW. Thanks for that.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python Command Line Arguments

[MRAB]

On 2017-04-13 02:59, ian.steg...@gmail.com wrote:

I have this code which I got from 
https://www.tutorialspoint.com/python/python_command_line_arguments.htm The 
example works fine but when I modify it to what I need, it only half works. The 
problem is the try/except. If you don't specify an input/output, they are blank 
at the end but it shouldn't be.


import getopt
import sys

def main(argv):
inputfile = ''
outputfile = ''
try:
   opts, args = getopt.getopt(argv,"hi:o:",["ifile=","ofile="])
except getopt.GetoptError:
   inputfile = 'Input'
   outputfile = 'Output'
if inputfile == '':
   for opt, arg in opts:
  if opt == '-h':
 print ('Usage: Encrypt.py -i  -o ')
 sys.exit()
  elif opt in ("-i", "--ifile"):
 inputfile = arg
  elif opt in ("-o", "--ofile"):
 outputfile = arg
else:
   ''

print 'In: ' + inputfile
print 'Out: ' + outputfile

if __name__ == "__main__":
main(sys.argv[1:])

You'll get the GetoptError exception if an option that requires an 
argument doesn't have one. That's not the same as omitting the option 
entirely.


For example:

# No -i option.
foo

# Option -i present but without its required argument.
foo -i
--
https://mail.python.org/mailman/listinfo/python-list

Re: Python Command Line Arguments

[Jason Friedman]

>
> I have this code which I got from https://www.tutorialspoint.
> com/python/python_command_line_arguments.htm The example works fine but
> when I modify it to what I need, it only half works. The problem is the
> try/except. If you don't specify an input/output, they are blank at the end
> but it shouldn't be.
>
> import getopt
> import sys
>

Hello Ian,
I am guessing you are wanting to parse command-line arguments rather than
particularly wanting to use the getopt module.
If I am correct you might want to spend your time instead learning the
argparse module:
https://docs.python.org/3/library/argparse.html
https://docs.python.org/3/howto/argparse.html
-- 
https://mail.python.org/mailman/listinfo/python-list

Python Command Line Arguments

[ian . stegner]

I have this code which I got from 
https://www.tutorialspoint.com/python/python_command_line_arguments.htm The 
example works fine but when I modify it to what I need, it only half works. The 
problem is the try/except. If you don't specify an input/output, they are blank 
at the end but it shouldn't be.


import getopt
import sys

def main(argv):
   inputfile = ''
   outputfile = ''
   try:
  opts, args = getopt.getopt(argv,"hi:o:",["ifile=","ofile="])
   except getopt.GetoptError:
  inputfile = 'Input'
  outputfile = 'Output'
   if inputfile == '':
  for opt, arg in opts:
 if opt == '-h':
print ('Usage: Encrypt.py -i  -o ')
sys.exit()
 elif opt in ("-i", "--ifile"):
inputfile = arg
 elif opt in ("-o", "--ofile"):
outputfile = arg
   else:
  ''

   print 'In: ' + inputfile
   print 'Out: ' + outputfile

if __name__ == "__main__":
   main(sys.argv[1:])
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue26919] on Android python fails to decode/encode command line arguments

[Donald Stufft]

Changes by Donald Stufft :


--
pull_requests: +937

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29857] Provide `sys.executable_argv` for host application's command line arguments

[Nick Coghlan]

Nick Coghlan added the comment:

OK, I've changed the proposed attribute name to be `sys.executable_argv`, with 
the rationale being that it's "argv as originally seen by sys.executable, 
rather than by Python's __main__ module"

As part of documenting this, both it and the `argv` documentation can make it 
clear that they may be entirely absent if the host application doesn't set them.

--
title: Provide `sys._raw_argv` for host application's command line arguments -> 
Provide `sys.executable_argv` for host application's command line arguments

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29857>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29857] Provide `sys._raw_argv` for host application's command line arguments

[STINNER Victor]

STINNER Victor added the comment:

> If the embedding application doesn't call PySys_SetArgv or PySys_SetArgvEx, 
> then there is no `argv` attribute defined in the sys module (I wasn't 
> actually sure what happened in that case, so I went and checked the code).

Ok, so just don't define sys._raw_argv in that case. But it doesn't seem enough 
to me to justify to make the attribute private.

https://docs.python.org/dev/library/sys.html#sys.getallocatedblocks can be seen 
as an implementation detail.The method name has no underscore prefix, but a 
simple fallback: return 0 if the feature is is not implemented.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29857] Provide `sys._raw_argv` for host application's command line arguments

[Nick Coghlan]

Nick Coghlan added the comment:

If the embedding application doesn't call PySys_SetArgv or PySys_SetArgvEx, 
then there is no `argv` attribute defined in the sys module (I wasn't actually 
sure what happened in that case, so I went and checked the code).

For the reference CLI, the relevant call happens in Py_Main() after all the 
interpreter level arguments have been processed.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29857] Provide `sys._raw_argv` for host application's command line arguments

[STINNER Victor]

STINNER Victor added the comment:

> For example, if Py_Main() is never called (for CPython), it would still be 
> None,

What is the content of sys.argv in that case? Can't we use the same value for 
sys._raw_argv?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29857] Provide `sys._raw_argv` for host application's command line arguments

[Nick Coghlan]

Nick Coghlan added the comment:

@Steven This is an implementation detail in the same sense that sys._getframe() 
is: it's not something that's actually going to make sense in all contexts. For 
example, if Py_Main() is never called (for CPython), it would still be None, 
and other implementations may not define it at all. And even when it's set for 
CPython, the exact details of what it contains are going to be at least 
somewhat platform dependent.

@Barry On Windows we define `mainw` rather than `main`, so it's the UTF-16-LE 
encoded text that is the "raw" form. That means the "raw" here refers to 
"before the Python interpreter CLI processing" - the normalization step to get 
the command line to wchar_t regardless of platform isn't going to be skipped 
(since the interpreter runtime itself never even sees the raw bytes in Python 
3).

One option would be to use a longer name like `sys._executable_argv`, since in 
the typical case, `sys.executable` and `sys._executable_argv[0]` will be the 
same.

@Victor It wouldn't be exactly the same as Py_GetArgcArgv, as I'd propose 
making a pristine copy *before* Py_Main() mutates anything - we do some 
in-place editing of entries while figuring out what "sys.argv[0]" should look 
like at the Python level.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29857] Provide `sys._raw_argv` for host application's command line arguments

[STINNER Victor]

STINNER Victor added the comment:

There is already an existing public C API get retrieve original program 
arguments *as text*:

/* Make the *original* argc/argv available to other modules.
   This is rare, but it is needed by the secureware extension. */

void
Py_GetArgcArgv(int *argc, wchar_t ***argv)
{
*argc = orig_argc;
*argv = orig_argv;
}

Are you talking about exposing these arguments at the Python level?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29857] Provide `sys._raw_argv` for host application's command line arguments

[STINNER Victor]

STINNER Victor added the comment:

> Well, "raw args" implies minimal or no processing,

Ok, so call it "original", sys.orig_arv, in that case ;-)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29857] Provide `sys._raw_argv` for host application's command line arguments

[Barry A. Warsaw]

Barry A. Warsaw added the comment:

On Mar 21, 2017, at 11:47 AM, STINNER Victor wrote:

>No, text please. Text is just more convenient in Python, and it's trivial to
>retrieve original bytes:
>
>raw_args_bytes = [os.fsencode(arg) for arg in sys._raw_args]

Well, "raw args" implies minimal or no processing, so bytes would make the
most sense.  It doesn't bother me that it's inconvenient; this won't be an oft
used API and the conversion to strings should be just as easy.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29857] Provide `sys._raw_argv` for host application's command line arguments

[STINNER Victor]

STINNER Victor added the comment:

> As bytes?

No, text please. Text is just more convenient in Python, and it's trivial to 
retrieve original bytes:

raw_args_bytes = [os.fsencode(arg) for arg in sys._raw_args]

--
nosy: +haypo

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29857] Provide `sys._raw_argv` for host application's command line arguments

[Steven D'Aprano]

Steven D'Aprano added the comment:

Why is the name flagged as a private implementation detail? I.e. a single 
leading underscore. I'd be reluctant to rely on this in production code, given 
how strong the _private convention is.

Suggest just `sys.raw_args` instead.

--
nosy: +steven.daprano

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29857] Provide `sys._raw_argv` for host application's command line arguments

[Nick Coghlan]

Nick Coghlan added the comment:

For CPython, I was thinking of having it be "whatever gets passed to Py_Main", 
and that accepts wchar_t in Py3 [1], so on *Nix systems, the command line has 
already been decoded with [2] by the time it runs.

[1] https://docs.python.org/3/c-api/veryhigh.html#c.Py_Main
[2] https://docs.python.org/3/c-api/sys.html#c.Py_DecodeLocale

In the case of Windows, the wchar_t array is received straight from the OS as 
UTF-16-LE.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29857] Provide `sys._raw_argv` for host application's command line arguments

[Barry A. Warsaw]

Barry A. Warsaw added the comment:

As bytes?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29857] Provide `sys._raw_argv` for host application's command line arguments

[Barry A. Warsaw]

Changes by Barry A. Warsaw :


--
nosy: +barry

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29857] Provide `sys._raw_argv` for host application's command line arguments

[Jakub Wilk]

Changes by Jakub Wilk :


--
nosy: +jwilk

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29857] Provide `sys._raw_argv` for host application's command line arguments

[Nick Coghlan]

New submission from Nick Coghlan:

Issue 14208 was ultimately resolved through an import system specific solution, 
with PEP 451 making the module name passed to `python -m` available as 
`__main__.__spec__.name`.

However, there are other situations where it may be useful to offer an 
implementation-dependent attribute in the `sys` module that provides access to 
a copy of the host application's raw `argv` details, rather than the filtered 
`sys.argv` details that are left after the host application's command line 
processing has been completed.

In the case of CPython, where `sys.argv` represents the arguments to the Python 
level __main__ function, `sys._raw_argv` would be a copy of the argv argument 
to the C level main() or wmain() function (as appropriate for the platform).

--
messages: 289873
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Provide `sys._raw_argv` for host application's command line arguments
type: enhancement

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29857>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26919] on Android python fails to decode/encode command line arguments

[Xavier de Gaye]

Changes by Xavier de Gaye :


--
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26919] on Android python fails to decode/encode command line arguments

[Xavier de Gaye]

Xavier de Gaye added the comment:

Forgot the issue number in the commit message for the default branch, the 
corresponding changeset is 80a041d39c20.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26919] on Android python fails to decode/encode command line arguments

[Roundup Robot]

Roundup Robot added the comment:

New changeset e5360d413ce4 by Xavier de Gaye in branch '3.6':
Issue #26919: On Android, operating system data is now always encoded/decoded
https://hg.python.org/cpython/rev/e5360d413ce4

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26919] on Android python fails to decode/encode command line arguments

[Xavier de Gaye]

Xavier de Gaye added the comment:

The patch fixes also the following errors in test_warnings:

==
FAIL: test_nonascii (test.test_warnings.CEnvironmentVariableTests)
--
Traceback (most recent call last):
  File 
"/sdcard/org.bitbucket.pyona/lib/python3.7/test/test_warnings/__init__.py", 
line 1072, in test_nonascii
"['ignore:Deprecaci\xf3nWarning']".encode('utf-8'))
AssertionError: b"['ignore:Deprecaci\\udcc3\\udcb3nWarning']" != 
b"['ignore:Deprecaci\xc3\xb3nWarning']"

==
FAIL: test_nonascii (test.test_warnings.PyEnvironmentVariableTests)
--
Traceback (most recent call last):
  File 
"/sdcard/org.bitbucket.pyona/lib/python3.7/test/test_warnings/__init__.py", 
line 1072, in test_nonascii
"['ignore:Deprecaci\xf3nWarning']".encode('utf-8'))
AssertionError: b"['ignore:Deprecaci\\udcc3\\udcb3nWarning']" != 
b"['ignore:Deprecaci\xc3\xb3nWarning']"

--

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28889] IDLE needs the ability to pass in command-line arguments

[Raymond Hettinger]

New submission from Raymond Hettinger:

[--- Feature request posted on behalf of Balakrishnan Sakthidharan ---]

IDLE lets you run scripts with F5.

What is needs is an F6 that opens a dialog box and asks for command-line 
arguments.  This will help develop and test command line scripts in the IDE.

  F6 -q5 -v=8 somefile.txt

--
assignee: terry.reedy
components: IDLE
messages: 282567
nosy: rhettinger, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE needs the ability to pass in command-line arguments
type: enhancement
versions: Python 3.7

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28889>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26919] on Android python fails to decode/encode command line arguments

[Xavier de Gaye]

Changes by Xavier de Gaye <xdeg...@gmail.com>:


--
title: android: test_cmd_line fails -> on Android python fails to decode/encode 
command line arguments

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26919>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23665] Provide IDLE menu option to set command-line arguments

[Matej Cepl]

Changes by Matej Cepl :


--
nosy: +mcepl

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5680] Command-line arguments when running in IDLE

[Matej Cepl]

Changes by Matej Cepl :


--
nosy: +mcepl

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5680] Command-line arguments when running in IDLE

[Terry J. Reedy]

Terry J. Reedy added the comment:

Today on SO: 
https://stackoverflow.com/questions/33866724/read-data-from-file-idle.  Person 
writing script to open a file given on command line asks 'How to test from 
IDLE?' He found PyCharm, but I would like to add a better answer than the 
workaround I gave above.  It does not have to be either perfect or necessarily 
permanent.  There are two subissues.  

1) Get a command line from the user.  1a. What dialog?  1b. Retain it for as 
least the current session?  Same for all editors? Specific to file?

2) Use the command line.  2a. parse with shlex or custom parser. 2b integrate 
in ScriptBinding.py when starting user code so code sees arguments in sys.argv.

Looking *briefly* at the patches:

M.B.: Get command line with new extension module argumentDialog.py. Parse with 
re.findall(arg_regex).  Modifies ScriptBinding, including the deletin of a 
condition for setting user sys.argv.

G.G.: Get command line with tkSimpleDialog._QueryString. Split with shlex.  
Reuses MB's ScriptBinding patch.

S.H.: Get command line with custom dialog. Use custom parser. Add new tests.

My inclination is to start as simple as possible.  Use a message box to get a 
single string (no error checking is needed).  Set for specific file only, not 
all.  The setting could be added to status bar.  Parse with shlex.  Question: 
is basic command line parsing system specific?  Does MAC stick with unix/posix 
rules?  Should shlex.split use non-posix mode on Windows?

--
assignee: asvetlov -> terry.reedy
nosy: +markroseman
type: behavior -> enhancement
versions: +Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5680] Command-line arguments when running in IDLE

[Terry J. Reedy]

Terry J. Reedy added the comment:

When  file is run with command line args, it might be nice to add an additional 
separator line with the line entered.  That way, if someone ran a series of 
experiments with different command lines, they would have the command line and 
output together as documentation that can be saved.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25631] Segmentation fault with invalid Unicode command-line arguments in embedded Python

[Eryk Sun]

Eryk Sun added the comment:

The interpreter isn't initialized, so calling PyErr_Format in a release build 
segfaults when it tries to dereference a NULL PyThreadState. OTOH, a debug 
build should call PyThreadState_Get, which in this case calls Py_FatalError and 
aborts the process. Unfortunately 3.5.0+ debug builds don't call 
PyThreadState_Get due to the fix for issue 25150.

> the possibility of other exceptions being raised early in the 
> initialization sequence remains a potential problem.

PEP 432 proposes a pre-initialization phase that sets a valid Python thread 
state.

--
nosy: +eryksun, ncoghlan

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25631] Segmentation fault with invalid Unicode command-line arguments in embedded Python

[Itai Bar-Natan]

New submission from Itai Bar-Natan:

The following embedded application, which calls Py_Main with a "-W X" argument 
where X is not a valid Unicode string, returns a segmentation fault:

```
#include "Python.h"

main() {
wchar_t *invalid_str;
invalid_str = malloc(2*sizeof(wchar_t));
invalid_str[0] = 0x11;
invalid_str[1] = 0;
wchar_t *argv[4] = {L"embedded-python", L"-W", invalid_str, NULL};

Py_Main(3, argv);
}
```

This segmentation fault is present in Python 3.4, 3.5, and the latest 
development branch I downloaded, but is not present in Python 3.2. This program 
is obviously invalid and it may be reasonable to emit a fatal error in this 
situation, but it should not give a segmentation fault.

I believe the issue is that this codes leads to exception being thrown before 
exceptions are initialized, and more specifically, a call to 
PyExceptionClass_Check() within PyErr_Object() reads a NULL pointer. I haven't 
tested this but I expect that this problem would not appear when calling Python 
directly since Python sanitizes the command line arguments from main(). 
Nonetheless even here the possibility of other exceptions being raised early in 
the initialization sequence remains a potential problem.

--
components: Interpreter Core
messages: 254703
nosy: itaibn
priority: normal
severity: normal
status: open
title: Segmentation fault with invalid Unicode command-line arguments in 
embedded Python
type: crash
versions: Python 3.4, Python 3.5, Python 3.6

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25631>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25219] Update doc for Idle command line arguments.

[Terry J. Reedy]

Changes by Terry J. Reedy :


--
assignee:  -> terry.reedy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25219] Update doc for Idle command line arguments.

[Terry J. Reedy]

Changes by Terry J. Reedy <tjre...@udel.edu>:


--
title: Update doc for Idle command line argument. -> Update doc for Idle 
command line arguments.

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25219>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5680] Command-line arguments when running in IDLE

[Terry J. Reedy]

Terry J. Reedy added the comment:

Pending application of a patch, the following will work to only add args to 
sys.argv when running from an Idle editor.

import sys
# ...
if __name__ == '__main__':
if 'idlelib.PyShell' in sys.modules:
sys.argv.extend(('a', '-2'))  # add your argments here.
print(sys.argv)  # in use, parse sys.argv after extending it
# ['C:\\Programs\\python34\\tem.py', 'a', '-2']

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5680
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5680] Command-line arguments when running in IDLE

[Wolfgang Maier]

Changes by Wolfgang Maier wolfgang.ma...@biologie.uni-freiburg.de:


--
nosy: +wolma

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5680
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5680] Command-line arguments when running in IDLE

[Terry J. Reedy]

Terry J. Reedy added the comment:

I closed #23665 in favor of this one.  Raymond's take: msg238108

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5680
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23665] Provide IDLE menu option to set command-line arguments

[Terry J. Reedy]

Terry J. Reedy added the comment:

#5680 has 3 different patches. I have not reviewed them yet.  I will link to 
Raymond's message there.

--
nosy: +terry.reedy
resolution:  - duplicate
stage: needs patch - resolved
status: open - closed
superseder:  - Command-line arguments when running in IDLE

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23665
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5680] Command-line arguments when running in IDLE

[Raymond Hettinger]

Raymond Hettinger added the comment:

Here's my comment from the duplicate tracker item:
--

A number of IDEs support menu options to set the execution environment for 
programs under development and testing.  In particular, it would be nice if 
IDLE let the user set command line arguments to be passed into sys.argv when 
running a script by pressing F5.

Here are some existing implementations for reference:
* Wing-IDE: https://wingware.com/doc/intro/tutorial-debugging-launch
* Visual Studio: https://www.youtube.com/watch?v=IgbQCRHKV-Y
* PyCharm: 
https://www.jetbrains.com/pycharm/help/run-debug-configuration-python.html

This feature will help users interactively develop and test command-line tools 
while retaining all the nice features of the IDE.   I would personally find it 
useful when teaching students about how sys.argv works.

I suggest adding an option under the Run menu for Set Command Line arguments.  
It would trigger a dialog box that lets a user set a string such as 
somefile.txt -r 10.  The user string would be run through shlex to break it 
into separate fields.  When F5 is pressed, the sys.argv list would be 
repopulated to include the script name and the lexed arguments.

A little more elaborate option is to add a Run menu entry for Set Execution 
Enviroment that let's the user 1) set the command-line  2) specify the start-up 
directory (using os.chdir), 3) and edit the environment variables (from 
os.environ) or at least be able to set PYTHONPATH.

--
nosy: +rhettinger

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5680
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23665] Provide IDLE menu option to set command-line arguments

[Saimadhav Heblikar]

Saimadhav Heblikar added the comment:

http://bugs.python.org/issue5680

Also had submitted a patch for it. Could you post your review there? (I was 
learning the CPython style then, so excuse obvious mistakes :) )

--
nosy: +sahutd

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23665
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23665] Provide IDLE menu option to set command-line arguments

[Raymond Hettinger]

New submission from Raymond Hettinger:

A number of IDEs support menu options to set the execution environment for 
programs under development and testing.  In particular, it would be nice if 
IDLE let the user set command line arguments to be passed into sys.argv when 
running a script by pressing F5.

Here are some existing implementations for reference:
* Wing-IDE: https://wingware.com/doc/intro/tutorial-debugging-launch
* Visual Studio: https://www.youtube.com/watch?v=IgbQCRHKV-Y
* PyCharm: 
https://www.jetbrains.com/pycharm/help/run-debug-configuration-python.html

This feature will help users interactively develop and test command-line tools 
while retaining all the nice features of the IDE.   I would personally find it 
useful when teaching students about how sys.argv works.

I suggest adding an option under the Run menu for Set Command Line arguments.  
It would trigger a dialog box that lets a user set a string such as 
somefile.txt -r 10.  The user string would be run through shlex to break it 
into separate fields.  When F5 is pressed, the sys.argv list would be 
repopulated to include the script name and the lexed arguments.

A little more elaborate option is to add a Run menu entry for Set Execution 
Enviroment that let's the user 1) set the command-line  2) specify the start-up 
directory (using os.chdir), 3) and edit the environment variables (from 
os.environ) or at least be able to set PYTHONPATH.

--
components: IDLE
messages: 238108
nosy: rhettinger
priority: normal
severity: normal
stage: needs patch
status: open
title: Provide IDLE menu option to set command-line arguments
type: enhancement
versions: Python 3.5

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23665
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5680] Command-line arguments when running in IDLE

[Terry J. Reedy]

Terry J. Reedy added the comment:

I have a recent idea that there should be a separate and persistent execution 
process for each file run.  This would make it easy to persist the cmd lines 
args for a particular module.

--
versions: +Python 3.4, Python 3.5 -Python 3.1, Python 3.2

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5680
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5680] Command-line arguments when running in IDLE

[Saimadhav Heblikar]

Saimadhav Heblikar added the comment:

Submitting a patch for 3.4.

1. Allows the user to set command line arguments via a dialog box
2. Parsing - Maps the string which user entered into a list i.e. the same 
results are produced as when run via terminal/command prompt. The parsing 
methods returns a list, which is similar to the sys.argv, when you run script 
from command line.
3. Adds tests for the parsing method
4. Extends mock_idle for point 3

I am on Debian and don't have access to a windows machine. please try to run 
the tests on windows machine and see if its OK.(cmd handles arguments rather 
differently.)

Also, should we persist the command line argument that user entered across 
sessions?

--
nosy: +sahutd
Added file: http://bugs.python.org/file34568/cmd-arg.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5680
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5680] Command-line arguments when running in IDLE

[Tal Einat]

Changes by Tal Einat talei...@gmail.com:


--
nosy:  -taleinat

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5680
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5680] Command-line arguments when running in IDLE

[Mark Lawrence]

Changes by Mark Lawrence breamore...@yahoo.co.uk:


--
nosy:  -BreamoreBoy

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5680
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Determine actually given command line arguments

[Jussi Piitulainen]

Henry Leyh writes:

 But now I would also like to be able to _write_ such a config file
 FILE that can be read in a later run.  And FILE should contain only
 those arguments that were given on the command line.
 
 Say, I tell argparse to look for arguments -s|--sopt STRING,
 -i|--iopt INT, -b|--bopt [BOOL], -C CONFFILE.  Then 'prog -s bla -i
 42 -C cfile' should produce a confparser compatible cfile which
 contains
 
[my_options]
sopt = blah
iopt = 42
 
 and not 'bopt = False' (if False was the program's default for
 bopt).

Could you instead write those options that differ from the defaults?
You could parse an actual command line and an empty command line, and
work out the difference.

So 'prog -i 3' would not cause 'iopt = 3' to be written if 3 is the
default for iopt, but would that be a problem?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Determine actually given command line arguments

[Henry Leyh]

On 16.05.2013 08:08, Jussi Piitulainen wrote:

Henry Leyh writes:


But now I would also like to be able to _write_ such a config file
FILE that can be read in a later run.  And FILE should contain only
those arguments that were given on the command line.

Say, I tell argparse to look for arguments -s|--sopt STRING,
-i|--iopt INT, -b|--bopt [BOOL], -C CONFFILE.  Then 'prog -s bla -i
42 -C cfile' should produce a confparser compatible cfile which
contains

[my_options]
sopt = blah
iopt = 42

and not 'bopt = False' (if False was the program's default for
bopt).


Could you instead write those options that differ from the defaults?
You could parse an actual command line and an empty command line, and
work out the difference.

So 'prog -i 3' would not cause 'iopt = 3' to be written if 3 is the
default for iopt, but would that be a problem?


That's what the program does at the moment.  However, I'm not quite 
happy with it.  Generally, the user doesn't know what's the default and 
it would be confusing if 'prog -i 3' doesn't make 'iopt = 3' turn up in 
the file at the end.  There may also be the case when the user (for 
whatever reason) _wants_ the default in the file.


I think I will try the opposite instead: the program writes the whole 
set of options to the file.  This would produce a complete and 
consistent configuration which automatically reflects the hierarchy in 
which the options were set.  And the user can sort it out by hand if he 
wants.


Regards,
Henry

--
http://mail.python.org/mailman/listinfo/python-list

Determine actually given command line arguments

[Henry Leyh]

Hello,
I am writing a program that gets its parameters from a combination of 
config file (using configparser) and command line arguments (using 
argparse).  Now I would also like the program to be able to _write_ a 
configparser config file that contains only the parameters actually 
given on the commandline.  Is there a simple way to determine which 
command line arguments were actually given on the commandline, i.e. does 
argparse.ArgumentParser() know which of its namespace members were 
actually hit during parse_args().


I have tried giving the arguments default values and then looking for 
those having a non-default value but this is really awkward, especially 
if it comes to non-string arguments.  Also, parsing sys.argv looks 
clumsy because you have to keep track of short and long options with and 
without argument etc. i.e. all things that I got argparse for in the 
first place.


Thanks  Greetings,
Henry
--
http://mail.python.org/mailman/listinfo/python-list