Develop Reference

using #!/usr/bin/env python3 shebang with Windows

I'm trying to run a Python script from the command line as a command on Windows -- so no usage of "Python" or ".py". If my script is named "testing.py", I am attempting to make this name into a command and call "testing" from the command line.
Going through the docs it seems I need to use this shebang #!/usr/bin/env python as long as I have Python in my PATH.
https://docs.python.org/3/using/windows.html#shebang-lines
I also have the script folder in my PATH, so something like
"testing.py" is currently working from the command line.
According to the docs and this tutorial,
https://dbader.org/blog/how-to-make-command-line-commands-with-python
I should be able to evoke my Python script just by "testing" if I have the proper paths within PATH and the above shebang. However, I can't seem to get the script running withouth adding ".py".

The accepted answer by #AKX is incorrect for Windows 10 standard Python 3, certainly in the latest Windows 10 (1903) if not earlier.
(Note: I cannot speak to how this may or may not work under WSL.)
I have several versions of Python installed (2.7, 3.6, 3.7, and most recently Python 3.8b1). I've been using the #!/usr/bin/env shebang for years in my scripts for cross-platform compatibility (usually to distinguish Py2 vs Py3 scripts).
I've created a little script in a folder (C:\so_test\awtest.py):
#!/usr/bin/env python3.6
import sys
print(sys.version)
If I run this with awtest.py or just awtest I get 3.6.x reported (showing it's running with Python 3.6). If I change the shebang to refer to 3.7, I get 3.7.x reported. If I change the shebang to just #!/usr/bin/env python3 I get the latest version of Python installed (3.8).
Now, if I add that folder to my path (path=%PATH%;C:\so_test in the command window you're testing in, or in the main env vars (you will need to restart the command window if you do the latter though)), I can change to a different directory and run awtest or awtest.py and they still work and refer to the folder in the path. If I remove the script folder from the path these files are no longer found.
While I wouldn't necessarily expect this to work on Windows prior to 10 or Python 2.7, this functionality appears to be the way of things going forward.

No, Windows does not support shebang lines.
The documentation you've linked relates to the py launcher installed by Python, which can interpret various shebang lines to choose a Python version to run a script with.
setuptools is able to generate wrapper .exes for your Python scripts, but it gets a little involved and already assumes you have a package with a setup.py and so on.
Locally, if you really, really need this, you probably could add .py to the PATHEXT environment variable, so the Windows command line looks up .pys like it looks up .exes (and various others; the current modern default is .COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC). However, this will naturally not scale for distributing apps, as all of your users would need to set that too.
My recommendation is to stick with just that boring old python testing.py, really.

You can use shebang in windows by setting the path of your interpreter as the first line in the file(you will see a marker on VSCode that says 'set as interpreter ' on that line).
Using windows 10,Python version 3.9 see example:
#!C:/Users/waithira/AppData/Local/Programs/Python/Python39/python.exe
print('hello world')

if you're not going to do this often. You can still add a batch file to your path testing.bat containing the command that you need to execute your code.
#echo off
python testing.py
It's a borring workaround but it works without needing to mention the extention since windows interpret batch files the same way it interpret executables.

Ghost variable "idle" in terminal/cygwin?

I cannot figure out where, how, or why the variable "idle" has been set.
It is not in an alias
It isn't in my .bashrc file
It isn't in my PATH
It isn't a user-entered variable, because it doesn't show up when I execute this: ( set -o posix ; set ) | less
but, when I type cygstart idle somehow the program still starts. Why is this?
something that is also curious is that when I execute just idle, i.e. without the cygstart command, it attempts to execute a python file. Any ideas what might be going on?
Perhaps I am looking for suggestions about how to investigate, since I realize that there might be other problems specific to my machine.
Thanks.

Since 3.4, PSF CPython Windows installers put /Scripts in the pythonxy directory. Pip and easy-install are pre-installed in Scripts. When pip is used to install packages, associated executables are put in the corresponding /Scripts. If pythonxy is the default python installation, pythonxy/Scripts is added to the system PATH and idle.bat is added. (At least, this is what happened on my machine.) So yes, command prompt> idle should work as you describe, at least for 3.4.

It's not a variable. IDLE is the name of a Python IDE.
You can launch it either directly or through Cygwin.
cygstart can be given the name of a file or program. If you give it the name of a program, it will run it.

Correct path usage in Cygwin : Difference between `python c:\somefile.py` & `python /cygdrive/c/somefile.py`

I'm using Django 1.5 & Python 2.7 on Windows + Cygwin. The following command gives me an error in bash shell
$ python /cygdrive/c/Python27/Lib/site-packages/django/bin/django-admin.py
Error:
C:\Python27\python.exe: can't open file '/cygdrive/c/Python27/Lib/site-packages/django/bin/django-admin.py': [Errno 2] No such file or directory
However this works
$ python c:/Python27/Lib/site-packages/django/bin/django-admin.py
I've seen lots of similar questions on django-admin.py errors but none specifically about this.
So what's the difference between python c:\somefile.py & python /cygdrive/c/somefile.py in a bash shell on Cygwin

As others have noted, part of the problem here is that you're calling Windows Python from Cygwin. This is an odd thing to do, as you hit strange behaviour like this, but it can work with care.
When you call Python from Cygwin - and this is the case for both Cygwin Python and Windows Python - the path you pass will be given as-is to Python to handle. That means Python must know how to handle that kind of path. For example, if you pass the following:
C:\path\to\script.py - Windows Python knows how to handle this, while Cygwin Python is likely to get confused. That said, if you type this into a Cygwin shell, those backslashes are liable to be interpreted as escape characters, and whether they are or not depends on some relatively complicated rules. Avoid, if you're playing around in Cygwin.
'C:\path\to\script.py' - Those quotes will be stripped by Cygwin's bash shell, while stopping the backslashes being taken as escape characters, so this would work fine for calling Windows Python from Cygwin. Running from a Windows command line or similar will cause problems, though, as Windows doesn't handle single quotes.
/cygdrive/c/path/to/script.py - This is the path from the point of view of any Cygwin program, such as Cygwin Python. It works perfectly for Cygwin Python, but not at all for Windows Python.
C:/path/to/script.py - It's not very well known, but backslashes in Windows paths can be replaced with forward slashes, and any well-behaved Windows program should handle that just fine: they're explicitly allowed by Windows. In particular, Windows Python has no problem with them whatsoever, and Cygwin's bash shell won't try to be clever with the forward slashes. You can therefore use this kind of path anywhere you would call Windows Python.
$(cygpath -w /cygdrive/c/path/to/script.py) - cygpath is a Cygwin utility to convert between different path styles; called with a -w option, it converts a Cygwin path to a Windows path. The $(...) indicated that Cygwin's bash shell should replace the text with the result of running the command, so if this were given as the argument to Windows Python called from a Cygwin bash shell, Windows Python would receive a Windows path it can use.
path/to/script.py - This is a relative path, so you need to call it from a suitable directory. It's the first version that will work for both Cygwin and Windows Python, and called from both a Cygwin shell and a Windows command line.
As you can see, paths are complicated, particularly when you're using Cygwin and Windows tools together.
As a general rule, the safest thing is to stick to using one or the other if possible (so only use Cygwin Python from a Cygwin shell, and only use Windows Python from a Windows command line). If that's not possible, the next best is to use cygpath whenever you're calling a Windows program from Cygwin or the other way around - running cygpath -w /cygdrive/c/Windows will give c:\windows; running cygpath 'c:\Windows' will print /cygdrive/c/Windows.

You seem to have Python installed in C: instead of in /usr/bin/python or similar. I'm guessing you installed the Windows port of Python from python.org, and not the Cygwin python package. In this case, the python executable is not using Cygwin (it's running native) and is expecting Windows-formatted path names.
Further, your Django seems to be installed in your Windows Python install. Cygwin is probably completely out of the loop.

Well, nothing should be different:
hgs15624#ESCLT0116 ~
$ python /cygdrive/c/test.py
Hello
hgs15624#ESCLT0116 ~
$ python c:/test.py
Hello
I guess you've looked for odd permissions.
Edit: the below was just referring to a typo in the question.
The error says:
/cygdrive/c/Python27/Lib/sitepackages/django/bin/django-admin.py
Did you miss the hyphen in site-packages?

Run a python script from the prompt in windows [duplicate]

This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
How do I run a python program in the Command Prompt in Windows 7?
This is a follow-up to this question: Run a python script in windows.
How would I do the equivalent of
`$ ./checksum.py <folder>
in Windows? Note, the checksum.py file starts thus:
#!/usr/bin/env python

For me, it works just to invoke the name of the script directly, e.g. > myscript.py.

if you have python installed on your system just make sure it's in the global variables.
Then you can type in "python " eg "python myscript.py abcd".
If it's not registered at global level you have to 'cd' (ChangeDir) to the location where python is installed, then run a command "python " eg:
"C:\Programs\Python>python C:\Users\User1\Desktop\MyScript.py abcd" where "C:\Programs\Python" is the current working directory.
If you want to run linux programs and commands on windows you can try MinGW or CygWin.

One potential solution to this problem, while possibly overkill, is to install Cygwin and use its environment to run the script. Of course you can just call the python command from your Windows command line (as long as it's in your PATH, as specified in autoexec.bat) followed by ./checksum.py [folder], but if you're coming from a *nix/OS X environment, you may find Cygwin makes your life simpler. Either way.

Make sure the filename extension .py is associated with the appropriate python.exe. Similarly, .pyw should be associated with pythonw.exe (this is a version of the Python interpreter that doesn't show a terminal window, suitable for use with Python GUI scripts).
The Python for Windows installer does this, so you usually won't have to mess with it unless you have multiple Python installs on your machine. If you do need to change the association, this can be done by right-clicking a .py file, choosing Properties, and clicking the Change button next to "Opens with."
Windows ignores the shebang line, so there is no way (short of Cygwin) to have different scripts use different versions of Python by changing the shebang. You could use a different extension (e.g. .py3 for Python 3 scripts) and associate that with C:\Python31\python.exe -- but that will break the script's ability to be imported as a module (Python expects the .py extension), so use it carefully. Better practice is probably to just specify the desired python.exe directly on the command line.

Python 3.2 doesn't work with python 2.7

I already have python 2.7 (installed using activepython). I'm trying to use python 3.2 just to learn more about it so i downloaded it from python.org
python 2.7 still works perfectly, but python 3.2 gives me this error when i try to open the ide.
and then I see the send error window, if i install python 3.2 using activepython i see the same error.
I'm using windows xp pro sp3 32 bit and i had the same error on sp2... How do I fix it?
EDIT #Zuljin
This is the first time that i use dependancy walker so could you give me a hand please
this is what i see
what does that mean? I already have these files...

I saw a lot of answers here. But, I think the file that you are trying to run is not correct
C:\Python32\Pythonw.exe
is not the one you use to open idle.
Open
C:\Python32\Lib\idlelib\idle.pyw

Python 2.x and 3.x can cohabitate perfectly in win xp and win 7, either 32 or 64 bits.
If you first installed the ActiveState Python distribution, be careful when installing python-3.2.2.msi.
When you arrive to the customize python 3.2.2 screen, (un)check 'register extensions' to make the feature unavailable (that is: do not register extensions).
I have installed this way both distributions in different computers without any problem so far.
Note: Check your environment variables. Only python 2.7 should be in the path (if you installed before the two distros you could have them both in the path. Remove python 3.2 path)
Edit:
From Ankit post I realized that in fact you were trying to open IDLE, maybe.
If you follow my installation instructions when you call idle.bat from the py3.2 idlelib folder you actually get idle for python 2.7 as this is what the call find in the windows path. To be able to open idle for py3.2 in the presence of python 2.7 as the registered python, I use a .bat file modified from that in the distribution:
idle_stay.bat
#echo off
rem Working IDLE bat for Windows - Custom bat for py3k as secundary python
C:\Python32\pythonw C:\Python32\Lib\idlelib\idle.pyw %1 %2 %3 %4 %5 %6 %7 %8 %9
The name idle_stay.bat is because I put this file in the folder where the official idle.bat is (C:\Python32\Lib\idlelib\idle_stay.bat). In this way it does not get overwritten each time I unisntall and reinstall a new version of python 3

It seems to me you have associated a *.py or *.pyw file extension type to some version of python.exe and/or pythonw.exe you aren't clear about. This is often, but not exclusively done from within Microsoft's "explore.exe" File Manager (I believe in Options).
I disagree that this is a reliable method:
C:\Python32\Lib\idlelib\idle.pyw
as this method will run whichever program is assigned to the "pyw" extension. That could be:
C:\Python32\pythonw.exe
or
C:\Python26\python.exe
or whatever might have happened to your file extension association as per OS or bad PATH environment variable setting. It is better to do something like this:
C:\Python32\pythonw.exe C:\Python32\Lib\idlelib\idle.pyw
where you are explicidly telling the OS to run the python executable from a specific path and selecting a specific python script in the file/folder hiearchy.
Another thing you can try to gather info is just:
python.exe -V
which will tell you the version number.
Another thing you can do:
Open a DOS command prompt and type:
set PATH=C:\Windows;C:\Windows\system32;C:\Python32
python.exe and note the version and whether is runs.
exit()
exit
Once working debug your PATH. You can use this Python script to gather intel.
If you turned off your WinXP findfile stuff (like I have) you can use this script:
inpath.py can help shed some light.
Run this python script like this:
Drop to a DOS prompt
cd to your folder with a working python.exe version.
and type python.exe inpath.py python*
where inpath is in that same folder for this test/debug.
inpath.py will search your path for all files associated as "runable" in your OS and that is in your "PATH" with the python*.* pattern.