Python argparse behavior differs depending on launch mode (Windows) - python

This is a excerpt of my test-argparse.py piece of software:
from __future__ import print_function
import argparse
import sys
def manage_command_line():
parser = argparse.ArgumentParser(description='Simple Description')
parser.add_argument('code', type=str, help='Project code')
return parser.parse_args()
args = manage_command_line()
print(args)
print(sys.version)
When called as a parameter of the interpreter (result is correct and expected):
c:\Python27\python.exe test-argparse.py KB130
Namespace(code='KB130')
2.7.12 (v2.7.12:d33e0cf91556, Jun 27 2016, 15:24:40) [MSC v.1500 64 bit (AMD64)]
However if call it directly, relying in windows file association, the result is completely different:
C:\Users\PGO\Documents\docauto>test-argparse.py KB130
usage: test-argparse.py [-h] code
test-argparse.py: error: too few arguments
The definition of Windows file group association and the redirection is standard and as described in Python 2.7.14 manual (chapter 3.3.4):
C:\Users\PGO\Documents\docauto>assoc .py
.py=Python.File
C:\Users\PGO\Documents\docauto>ftype Python.File
Python.File="C:\Python27\python.exe" "%1" %*
C:\Users\PGO\Documents\docauto>
And consistent with my system paths, although my Python version is 2.7.12 and not 2.7.14, which probably makes no difference at all.
Question: Is there a way for obtaning a consistent result in both cases? I would like a consistent behavior of the application independent of the way it is executed.

This is what I get:
C:\Users>ftype Python.File
Python.File="C:\Windows\py.exe" "%L" %*
Both cases work for me correctly. I have Python 3.6, that could explain the difference in executable name.

Related

How to use shebang in windows for Python?

Code
#! C:\Python310\python.exe
import os
import sys
print(f"PY_PYTHON={os.getenv('PY_PYTHON')}")
print(f"{sys.version=}")
print(f"Shebang : '{open(__file__).read().splitlines()[0]}'")
cmd = 'py -0p'
print(cmd)
os.system(cmd)
cmd = f'file {__file__}'
print(cmd)
os.system(cmd)
Output:
λ py t9.py
PY_PYTHON=None
sys.version='3.11.0a7 (main, Apr 5 2022, 21:27:39) [MSC v.1929 64 bit (AMD64)]'
Shebang : '#! C:\Python310\python.exe'
py -0p
-V:3.11 * C:\Python311\python.exe
-V:3.10 C:\Python310\python.exe
-V:3.9 C:\Users\smart\AppData\Local\Programs\Python\Python39\python.exe
file C:\Users\smart\Desktop\budhubot\budhubot\t9.py
C:\Users\smart\Desktop\budhubot\budhubot\t9.py: a C:\Python310\python.exe script, ASCII text executable, with CRLF line terminator
Tried forward slash too.
Edit:
Without space
Shebangs aren't a Windows thing.
On Windows, it must rely on a third-party software: bash, cygwin, python launcher, etc. So you'll find most information about its support in these third-party softwares' documentation.
But first thing, I would try to remove the space between #! and the interpreter's full path. Shebang and interpreter aren't separated by a space usually.
#!C:\Python310\python.exe
Add py.ini file in the py.exe location.
[commands]
py311="C:\Python311\python.exe"6
py310="C:\Python310\python.exe"6
py39="C:\Users\smart\AppData\Local\Programs\Python\Python39\python.exe"6
Note the last char (use any); Without this, pylauncher not works. (2nd outptut). Probably a bug. Repo
Edit:
Shebangs are not working with py -u

How does the Python interpreter know what distribution it is in? [duplicate]

How do I check which version of the Python interpreter is running my script?
This information is available in the sys.version string in the sys module:
>>> import sys
Human readable:
>>> print(sys.version) # parentheses necessary in python 3.
2.5.2 (r252:60911, Jul 31 2008, 17:28:52)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)]
For further processing, use sys.version_info or sys.hexversion:
>>> sys.version_info
(2, 5, 2, 'final', 0)
# or
>>> sys.hexversion
34014192
To ensure a script runs with a minimal version requirement of the Python interpreter add this to your code:
assert sys.version_info >= (2, 5)
This compares major and minor version information. Add micro (=0, 1, etc) and even releaselevel (='alpha','final', etc) to the tuple as you like. Note however, that it is almost always better to "duck" check if a certain feature is there, and if not, workaround (or bail out). Sometimes features go away in newer releases, being replaced by others.
From the command line (note the capital 'V'):
python -V
This is documented in 'man python'.
From IPython console
!python -V
Use platform's python_version from the stdlib:
from platform import python_version
print(python_version())
# 3.9.2
I like sys.hexversion for stuff like this.
>>> import sys
>>> sys.hexversion
33883376
>>> '%x' % sys.hexversion
'20504f0'
>>> sys.hexversion < 0x02060000
True
Your best bet is probably something like so:
>>> import sys
>>> sys.version_info
(2, 6, 4, 'final', 0)
>>> if not sys.version_info[:2] == (2, 6):
... print "Error, I need python 2.6"
... else:
... from my_module import twoPointSixCode
>>>
Additionally, you can always wrap your imports in a simple try, which should catch syntax errors. And, to #Heikki's point, this code will be compatible with much older versions of python:
>>> try:
... from my_module import twoPointSixCode
... except Exception:
... print "can't import, probably because your python is too old!"
>>>
Put something like:
#!/usr/bin/env/python
import sys
if sys.version_info<(2,6,0):
sys.stderr.write("You need python 2.6 or later to run this script\n")
exit(1)
at the top of your script.
Note that depending on what else is in your script, older versions of python than the target may not be able to even load the script, so won't get far enough to report this error. As a workaround, you can run the above in a script that imports the script with the more modern code.
Here's a short commandline version which exits straight away (handy for scripts and automated execution):
python -c "print(__import__('sys').version)"
Or just the major, minor and micro:
python -c "print(__import__('sys').version_info[:1])" # (2,)
python -c "print(__import__('sys').version_info[:2])" # (2, 7)
python -c "print(__import__('sys').version_info[:3])" # (2, 7, 6)
With six module, you can do it by:
import six
if six.PY2:
# this is python2.x
else:
# six.PY3
# this is python3.x
import sys
sys.version.split(' ')[0]
sys.version gives you what you want, just pick the first number :)
Like Seth said, the main script could check sys.version_info (but note that that didn't appear until 2.0, so if you want to support older versions you would need to check another version property of the sys module).
But you still need to take care of not using any Python language features in the file that are not available in older Python versions. For example, this is allowed in Python 2.5 and later:
try:
pass
except:
pass
finally:
pass
but won't work in older Python versions, because you could only have except OR finally match the try. So for compatibility with older Python versions you need to write:
try:
try:
pass
except:
pass
finally:
pass
Several answers already suggest how to query the current python version. To check programmatically the version requirements, I'd make use of one of the following two methods:
# Method 1: (see krawyoti's answer)
import sys
assert(sys.version_info >= (2,6))
# Method 2:
import platform
from distutils.version import StrictVersion
assert(StrictVersion(platform.python_version()) >= "2.6")
Just for fun, the following is a way of doing it on CPython 1.0-3.7b2, Pypy, Jython and Micropython. This is more of a curiosity than a way of doing it in modern code. I wrote it as part of http://stromberg.dnsalias.org/~strombrg/pythons/ , which is a script for testing a snippet of code on many versions of python at once, so you can easily get a feel for what python features are compatible with what versions of python:
via_platform = 0
check_sys = 0
via_sys_version_info = 0
via_sys_version = 0
test_sys = 0
try:
import platform
except (ImportError, NameError):
# We have no platform module - try to get the info via the sys module
check_sys = 1
if not check_sys:
if hasattr(platform, "python_version"):
via_platform = 1
else:
check_sys = 1
if check_sys:
try:
import sys
test_sys = 1
except (ImportError, NameError):
# just let via_sys_version_info and via_sys_version remain False - we have no sys module
pass
if test_sys:
if hasattr(sys, "version_info"):
via_sys_version_info = 1
elif hasattr(sys, "version"):
via_sys_version = 1
else:
# just let via_sys remain False
pass
if via_platform:
# This gives pretty good info, but is not available in older interpreters. Also, micropython has a
# platform module that does not really contain anything.
print(platform.python_version())
elif via_sys_version_info:
# This is compatible with some older interpreters, but does not give quite as much info.
print("%s.%s.%s" % sys.version_info[:3])
elif via_sys_version:
import string
# This is compatible with some older interpreters, but does not give quite as much info.
verbose_version = sys.version
version_list = string.split(verbose_version)
print(version_list[0])
else:
print("unknown")
If you want to detect pre-Python 3 and don't want to import anything...
...you can (ab)use list comprehension scoping changes and do it in a single expression:
is_python_3_or_above = (lambda x: [x for x in [False]] and None or x)(True)
from sys import version_info, api_version, version, hexversion
print(f"sys.version: {version}")
print(f"sys.api_version: {api_version}")
print(f"sys.version_info: {version_info}")
print(f"sys.hexversion: {hexversion}")
output
sys.version: 3.6.5 (v3.6.5:f59c0932b4, Mar 28 2018, 17:00:18) [MSC v.1900 64 bit (AMD64)]
sys.api_version: 1013
sys.version_info: sys.version_info(major=3, minor=6, micro=5, releaselevel='final', serial=0)
sys.hexversion: 50726384
The simplest way
Just type python in your terminal and you can see the version
as like following
desktop:~$ python
Python 2.7.6 (default, Jun 22 2015, 18:00:18)
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>
sys.version_info doesn't seem to return a tuple as of 3.7. Rather, it returns a special class, so all of the examples using tuples don't work, for me at least. Here's the output from a python console:
>>> import sys
>>> type(sys.version_info)
<class 'sys.version_info'>
I've found that using a combination of sys.version_info.major and sys.version_info.minor seems to suffice. For example,...
import sys
if sys.version_info.major > 3:
print('Upgrade to Python 3')
exit(1)
checks if you're running Python 3. You can even check for more specific versions with...
import sys
ver = sys.version_info
if ver.major > 2:
if ver.major == 3 and ver.minor <= 4:
print('Upgrade to Python 3.5')
exit(1)
can check to see if you're running at least Python 3.5.
Check Python version: python -V or python --version or apt-cache policy python
you can also run whereis python to see how many versions are installed.
To verify the Python version for commands on Windows, run the following commands in a command prompt and verify the output
c:\>python -V
Python 2.7.16
c:\>py -2 -V
Python 2.7.16
c:\>py -3 -V
Python 3.7.3
Also, To see the folder configuration for each Python version, run the following commands:
For Python 2,'py -2 -m site'
For Python 3,'py -3 -m site'
This just returns 2.7, 3.6 or 3.9
import sys
current_version = ".".join(map(str, sys.version_info[0:2]))
which is what you usually you need...
The even simpler simplest way:
In Spyder, start a new "IPython Console", then run any of your existing scripts.
Now the version can be seen in the first output printed in the console window:
"Python 3.7.3 (default, Apr 24 2019, 15:29:51)..."
To check from the command-line, in one single command, but include major, minor, micro version, releaselevel and serial, then invoke the same Python interpreter (i.e. same path) as you're using for your script:
> path/to/your/python -c "import sys; print('{}.{}.{}-{}-{}'.format(*sys.version_info))"
3.7.6-final-0
Note: .format() instead of f-strings or '.'.join() allows you to use arbitrary formatting and separator chars, e.g. to make this a greppable one-word string. I put this inside a bash utility script that reports all important versions: python, numpy, pandas, sklearn, MacOS, xcode, clang, brew, conda, anaconda, gcc/g++ etc. Useful for logging, replicability, troubleshootingm bug-reporting etc.
all answers has great insights
another way is platform.python_version_tuple()
python3 -c “import platform; print(platform.python_version_tuple())”
(‘3’, ‘6’, ‘8’)
if you want to check the python version for at least condition (e.g., python 3.9.0):
import platform
python_version_tuple = list(map(int, platform.python_version_tuple()))
if python_version_tuple >= [3, 9, 0]:
# Running at least Python 3.9.0
else:
# Running Python below 3.9.0
If you are working on linux just give command python output will be like this
Python 2.4.3 (#1, Jun 11 2009, 14:09:37)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-44)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
For windows, Go to command prompt and type this command to get the python version:
python --version
Or
python -V
A attempt using os.popen to read it in a variable:
import os
ver = os.popen('python -V').read().strip()
print(ver)

Why is my script's directory not in the Python sys.path?

Python 3.6.5
I am aware of this one: Why does my python not add current working directory to the path?
But the problem there is that he's doing something more complicated (referring to a sub-folder but executing from a main folder). The answers there are to either simplify things or to add package definitions.
And the selected answer even says: "It is the script's directory that is added"
However, my problem is really more simple: My script's directory ISN'T added.
Basically, all the tutorials on the internet say: import mymodule
When I do that, I get a name error...
My folder structure:
C:/Projects/interner
interner.py # this is the main program body
aux.py # this is the auxiliary file I would like to import into the above
I've tried both coding 'import aux' inside interner.py, and also using the interactive console:
cd c:/Projects/interner
python
import aux
To no avail (ModuleNotFoundError: No module named 'aux')
My sys.path:
['C:\\Tools\\Python\\python365\\python36.zip', 'C:\\Tools\\Python\\python365']
(both from inside the script and from interactive console)
Could you please tell me why I can't import local scripts? Is it because my sys.path is missing the PWD? If so, why is it missing it?
Edit: Doing this to help investigation:
>>> import os; print(os.listdir("."))
['aux.py', 'hw.py', 'interner.py', 'my_funcs.py']
I believe this is a Python bug, specific to the embeddable (ZIP file without an installer) Windows distribution. I’ve filed https://bugs.python.org/issue34841.
Removing the python37._pth file (presumably python36._pth in your case) from the distribution fixed it for me.
I don't know why but it seems that "" is missing from your sys.path variable, and that prevents from importing modules from current directory all right!
I can somehow reproduce your issue (eatcpu.py is in my current dir):
$ python.exe
Python 2.7.8 (default, Jun 30 2014, 16:08:48) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.path
['', 'C:\\Windows\\system32\\python27.zip', 'D:\\AppX64\\Python27\\DLLs', ... etc...]
>>> import eatcpu
works. Now in another python session:
$ python.exe
Python 2.7.8 (default, Jun 30 2014, 16:08:48) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.path.remove("")
>>> import eatcpu
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: No module named eatcpu
>>>
So the quickfix for you is to do:
import sys
sys.path.append("")
It looks like you are using the embeddable distribution of CPython rather than one of the regular installers. As described on the documentation page:
The embedded distribution is a ZIP file containing a minimal Python environment. It is intended for acting as part of another application, rather than being directly accessed by end-users.
Since you seem to be directly accessing Python rather than embedding it, you should consider using the regular (or Microsoft Store) installer (also described on the page I linked above).
Try making it explicit:
from . import aux

lxml installed, but not working on Windows

I need to validate an XML file against an XSD. To accomplish this I would like to use the lxml library. The problem is that even though I have from lxml import etree and have installed lxml to C:\Python33\Lib\site-packages\lxml\, I'm getting the error
Traceback (most recent call last):
File "C:\Users\asmithe\Documents\dev1\TestParse.py", line 3, in <module>
from lxml import etree as ET_l
ImportError: No module named lxml
Why is this and how do I fix it? I tried adding C:\Python33\Lib\site-packages\lxml\ to the PATH variable and it didn't help. I had installed lxml using PIP.
UPDATE: When I run the script through the interactive terminal (i.e. typing python in cmd) it CAN import lxml
Here is a simple script
from lxml import etree
def main():
print('hi')
if __name__ == "__main__":
main()
In cmd I do
C:\Users\dev1\Documents\test>python
Python 3.3.5 (v3.3.5:62cf4e77f785, Mar 9 2014, 10:35:05) [MSC v.1600 64 bit (AM
D64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from lxml import etree
>>>
>>> def main():
... print('hi')
...
>>>
>>> if __name__ == "__main__":
... main()
...
hi
>>> exit()
However if I try to run it
> ImportLxml.py
then I get
C:\Users\dev1\Documents\test>ImportLxml.py
Traceback (most recent call last):
File "C:\Users\dev1\Documents\XML test\TestImport.py", line 1, in <module>
from lxml import etree
ImportError: No module named lxml
Here are all of the pythonic entries in the PATH environment variable
C:\Python33\;
C:\Python33\Scripts;
C:\Python33\Lib\site-packages\lxml\
%ARCGISINSALLDIR%\arcpy;
Configure the Python Launcher for Windows to use 3.3.5 as default:
py -3
Alternately -- assuming you chose to install the Python Launcher when last installing Python -- begin your script with a shebang which the Python Launcher will recognize as requesting Python 3:
#! python3
If you decided not to install the Python Launcher for Windows when installing Python 3.3, see the install documentation for manual steps:
Associate the correct file group with .py scripts:
assoc .py=Python.File
Redirect all Python files to the new executable:
ftype Python.File=C:\Path\to\pythonw.exe "%1" %*
This can be used to configure the type for Python.File to the Python interpreter of your choice, ie. that for 3.3.5. (As a matter of good practices, Python.File should be pointed at py.exe or python.exe; the pythonw.exe example above is a direct quote from the docs, but a bad practice nonetheless).
Alternately, if you have a py.exe on disk (installed with Python 3.3) but it isn't being used, you can modify those instructions a bit:
Associate the correct file group with .py scripts:
assoc .py=Python.File
Redirect all Python files to the new executable:
ftype Python.File=C:\Path\to\py.exe "%1" %*
...again, adjusting the path to be appropriate for where you installed Python 3.3.x.

Can't popen new instance of python.exe

There’s a project where I need to use both Python 3.3 and 2.7. I am trying to launch a script under Python 2.7 but it’s not working. Here is a simple example.
first.py
import subprocess
import sys
print('Inside first.py')
print(sys.version)
subprocess.Popen(["C:\Python27\ArcGISx6410.2\Python.exe", "second.py"])
second.py
import arcpy
print 'This is second.py'
This doesn’t work and the output is
Inside first.py
3.3.5 (v3.3.5:62cf4e77f785, Mar 9 2014, 10:35:05) [MSC v.1600 64 bit (AMD64)]
File "C:\Python33\lib\site.py", line 173
file=sys.stderr)
^
SyntaxError: invalid syntax
That’s the entire stack trace. If I were to replace C:\...Python.exe with notepad.exe then it works. I’m using Liclipse on Windows 7.
UPDATE: it appears different versions of Python are run, when from the command line python first.py is 3.3 but py first.py or just first.py then 2.7 is used.
Try:
import os
subprocess.Popen(["C:\\Python27\\ArcGISx6410.2\\Python.exe", "second.py"], env=dict(os.environ, PYTHONHOME="C:\\Python27\\ArcGISx6410.2"))
Python on Windows needs a little help sometimes to figure out which version of the standard library to use.

Categories