Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Welcome to Software Development on Codidact!

Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.

Post History

66%
+2 −0
Q&A How can I start my Python code, from the code itself?

Mac/Linux In this environment, Python scripts can be given a shebang line that tells the operating system that the file is a script, and what interpreter (i.e., Python) to use for it. Because # st...

posted 5mo ago by Karl Knechtel‭  ·  edited 5mo ago by Karl Knechtel‭

Answer
#2: Post edited by user avatar Karl Knechtel‭ · 2024-06-24T17:26:26Z (5 months ago)
Emphasize common failure mode and include a reference link
  • ## Mac/Linux
  • In this environment, Python scripts can be given a [shebang](https://en.wikipedia.org/wiki/Shebang_(Unix)) line that tells the operating system that the file is a script, and what interpreter (i.e., Python) to use for it. Because `#` starts a comment in Python, Python itself doesn't need any special handling for this - it's just ignored anyway. Of course, the file also needs to be marked as executable (`chmod +x`).
  • Keep in mind that without a shebang, the operating system will typically try to treat the script as a *shell* script, which will fail completely (probably with many errors). The operating system doesn't care about a `.py` extension on the file name - only the shebang matters.
  • It's common to use something like `#!/usr/bin/env python`, to allow the operating system to find Python. But sometimes it's necessary to give the path to a specific Python to make the script work properly.
  • It's also common for such scripts to name the file *without* a `.py` extension (so just `myscript`), and to *not* use a `if __name__ == '__main__':` guard. That's because a script like this will normally *only* be used as a script and *should not* ever be `import`ed from somewhere else - so it's completely unnecessary and inelegant to add those things.
  • <details><summary>Complete example</summary>
  • How the script is named, and the permissions:
  • ```lang-none
  • $ ls
  • myscript
  • $ stat -c '%A' myscript
  • -rwxrwxr-x
  • ```
  • What's in it:
  • ```python
  • $ cat myscript
  • #!/usr/bin/env python
  • def my_function():
  • print("Test")
  • my_function()
  • ```
  • How we run it, and what happens:
  • ```lang-none
  • $ ./myscript
  • Test
  • ```
  • </details>
  • ## Windows
  • Windows doesn't care about shebangs generally, and doesn't have a concept of executable text files. However, it does have a concept of file associations - so we can tell Windows to use Python (via a specific path to `python`, perhaps something like<br>`C:\Program Files\Python 3.12\python.exe`) to open any file with a `.py` file name extension when it's double-clicked.
  • But better yet, we can tell it to use [the Python Launcher for Windows](https://docs.python.org/3/using/windows.html#python-launcher-for-windows). There's only one of these even if you install multiple versions of Python, and it's in a single, consistent place -<br>`C:\Windows\py.exe` (assuming Python was installed "for all users"). More importantly, this `py` program *tries to read and understand shebang lines* - simply write the script *as if* it would run on a Mac or Linux system, and let `py` do the rest.
  • </details>
  • ## Mac/Linux
  • In this environment, Python scripts can be given a [shebang](https://en.wikipedia.org/wiki/Shebang_(Unix)) line that tells the operating system that the file is a script, and what interpreter (i.e., Python) to use for it. Because `#` starts a comment in Python, Python itself doesn't need any special handling for this - it's just ignored anyway. Of course, the file also needs to be marked as executable (`chmod +x`).
  • <section class="notice is-warning">
  • Keep in mind that without a shebang, the operating system will typically try to treat the script as a *shell* script, which will fail completely ([probably with many errors](https://stackoverflow.com/questions/22275350)). The operating system doesn't care about a `.py` extension on the file name - only the shebang matters.
  • </section>
  • It's common to use something like `#!/usr/bin/env python`, to allow the operating system to find Python. But sometimes it's necessary to give the path to a specific Python to make the script work properly.
  • It's also common for such scripts to name the file *without* a `.py` extension (so just `myscript`), and to *not* use a `if __name__ == '__main__':` guard. That's because a script like this will normally *only* be used as a script and *should not* ever be `import`ed from somewhere else - so it's completely unnecessary and inelegant to add those things.
  • <details><summary>Complete example</summary>
  • How the script is named, and the permissions:
  • ```lang-none
  • $ ls
  • myscript
  • $ stat -c '%A' myscript
  • -rwxrwxr-x
  • ```
  • What's in it:
  • ```python
  • $ cat myscript
  • #!/usr/bin/env python
  • def my_function():
  • print("Test")
  • my_function()
  • ```
  • How we run it, and what happens:
  • ```lang-none
  • $ ./myscript
  • Test
  • ```
  • </details>
  • ## Windows
  • Windows doesn't care about shebangs generally, and doesn't have a concept of executable text files. However, it does have a concept of file associations - so we can tell Windows to use Python (via a specific path to `python`, perhaps something like<br>`C:\Program Files\Python 3.12\python.exe`) to open any file with a `.py` file name extension when it's double-clicked.
  • But better yet, we can tell it to use [the Python Launcher for Windows](https://docs.python.org/3/using/windows.html#python-launcher-for-windows). There's only one of these even if you install multiple versions of Python, and it's in a single, consistent place -<br>`C:\Windows\py.exe` (assuming Python was installed "for all users"). More importantly, this `py` program *tries to read and understand shebang lines* - simply write the script *as if* it would run on a Mac or Linux system, and let `py` do the rest.
  • </details>
#1: Initial revision by user avatar Karl Knechtel‭ · 2024-06-14T10:08:02Z (5 months ago)
## Mac/Linux

In this environment, Python scripts can be given a [shebang](https://en.wikipedia.org/wiki/Shebang_(Unix)) line that tells the operating system that the file is a script, and what interpreter (i.e., Python) to use for it. Because `#` starts a comment in Python, Python itself doesn't need any special handling for this - it's just ignored anyway. Of course, the file also needs to be marked as executable (`chmod +x`).

Keep in mind that without a shebang, the operating system will typically try to treat the script as a *shell* script, which will fail completely (probably with many errors). The operating system doesn't care about a `.py` extension on the file name - only the shebang matters.

It's common to use something like `#!/usr/bin/env python`, to allow the operating system to find Python. But sometimes it's necessary to give the path to a specific Python to make the script work properly.

It's also common for such scripts to name the file *without* a `.py` extension (so just `myscript`), and to *not* use a `if __name__ == '__main__':` guard. That's because a script like this will normally *only* be used as a script and *should not* ever be `import`ed from somewhere else - so it's completely unnecessary and inelegant to add those things.

<details><summary>Complete example</summary>

How the script is named, and the permissions:
```lang-none
$ ls
myscript
$ stat -c '%A' myscript 
-rwxrwxr-x
```
What's in it:
```python
$ cat myscript 
#!/usr/bin/env python

def my_function():
    print("Test")

my_function()
```
How we run it, and what happens:
```lang-none
$ ./myscript 
Test
```
</details>

## Windows

Windows doesn't care about shebangs generally, and doesn't have a concept of executable text files. However, it does have a concept of file associations - so we can tell Windows to use Python (via a specific path to `python`, perhaps something like<br>`C:\Program Files\Python 3.12\python.exe`) to open any file with a `.py` file name extension when it's double-clicked.

But better yet, we can tell it to use [the Python Launcher for Windows](https://docs.python.org/3/using/windows.html#python-launcher-for-windows). There's only one of these even if you install multiple versions of Python, and it's in a single, consistent place -<br>`C:\Windows\py.exe` (assuming Python was installed "for all users"). More importantly, this `py` program *tries to read and understand shebang lines* - simply write the script *as if* it would run on a Mac or Linux system, and let `py` do the rest.
</details>