The following error should be triggered for Python scripts which start with `#!/usr/bin/env python3` as in Python 3 UTF-8 is assumed and encoding preamble is no longer obligatory.
File "*****.py", line 23 SyntaxError: Non-ASCII character '\x**' in file process.py on line **, but no encoding declared; see http://python.org/dev/peps/pep-0263/ for details
------------------ (program exited with code: 1) Press return to continue
Reported for version `built on or after Sep 23 2016` or according to dpkg version `1.28-2` on Unutu Yakkety.
How the script is executed depends on the configured build command, and by default it calls `python` (not `python3` nor simply the script, in case it isn't executable). If you mean to use Python3, you can alter the build command either to call python3, or to call the script itself but then you need to make sure it's executable.
It is executable and normally I run it from the command line. Hence, I expected the _run_ to work like that.
You can use an execute command like ```shell sh -c 'if [ -x "%f" ]; then exec "./%f"; else exec python "%f"; fi' ``` Or even safer, checking it has a shebang that looks good: ```shell sh -c 'if test -x "%f" && head -n1 "%f" | grep -q "^#!.*python"; then exec "./%f"; else exec python "%f"; fi' ``` Or just trusting the shebang, if any: ```shell sh -c 'exec $(head -n1 "%f" | grep -Po "(?<=^#!).*$" || echo python) "%f"' ``` --- Geany will probably not try to read the shebang by default, because a user could select another filetype and reasonably expect his choice to be followed. We could possibly consider executing the file directly if it's executable, but it can also lead to unexpected results if that file is mistakenly marked as executable (like on some non-POSIX file systems). For now, IMO the best solution is for you to either make your own Python filetype run Python3, or use a conditional run command like I mentioned above.
For now, IMO the best solution is for you to either make your own Python filetype run Python3, or use a conditional run command like I mentioned above.
Or even simpler, just change the Execute build command to `"./%f"`, that's why they're configurable :)
Or even simpler, just change the Execute build command to `"./%f"`
Sure, only downside is that a non-executable script won't run at all :)
The script is executable, as mentioned above
In this case it is, but changing the Python build command will apply to all Python files. I'm just saying :)
Yeah, in general customizing the filetype default command or having the `python` binary in path point to the correct interpreter would be more robust.
If there were separate Python and Python3 filetypes we could have different commands, assuming they can be detected right. Otherwise the user needs to configure it as @codebrainz says.
"Somebody" could create a Python3 custom filetype with a regex to extract the filetype.
This is a test for Python3 (and Python (2)): http://pastebin.com/Hq2M5QhM The output is:
Is Python (2) and not Python 3: /tmp/nep2.py 1 /tmp/ndp2.py 1 /tmp/sep2.py 1 /tmp/sdp2.py 1 /tmp/nep3.py 0 /tmp/ndp3.py 0 /tmp/sep3.py 0 /tmp/sdp3.py 0 Is Python (3) and not Python (2): /tmp/nep2.py 0 /tmp/ndp2.py 0 /tmp/sep2.py 0 /tmp/sdp2.py 0 /tmp/nep3.py 1 /tmp/ndp3.py 1 /tmp/sep3.py 1 /tmp/sdp3.py 1
I would like to suggest two implementations. The first is that Python 3 is automatically recognised with a mechanism similar to as describer above. The second is that the user can set in Preferences what the default is. Now the default is Python (2) but I know many organisation which are allow to develop only in Python 3. For people there it would be very practical and time saving that they can change the default.
I am aware that all sorts of dynamic execute commands can be set, but many users, especially with single file applications, simply open the IDE and expect it to run out of the box and do not investigate further if it doesn't work. This can be a showstopper for new and/or inexperienced users.
I don't know, this is basically a systematic issue, not confined to Python. Most of the default commands are "wrong" in certain environments. It indeed does trip up new users but the alternative is to start bundling compilers/interpreters for all languages so we know which ones to call, or to add some kind of smart detection code to sniff out usable tools on a given platform, for every filetype.
Most of the default commands are "wrong" in certain environments.
Yeah, and most are wrong in windows as well.
or to add some kind of smart detection code to sniff out usable tools on a given platform, for every filetype.
So long as its external, like the @b4n shell stuff, then the default command could get more complex, just needs a PR by the users of the language. Preferably a PR to put the default stuff in a file, not hard coded in Geany, but thats another issue.
Closing due to age and no improvement PRs forthcoming. Feel free to re-open.
Closed #1298.
github-comments@lists.geany.org