For context, the script is called path_test.py and as of right now it is meant to simply print the path of the current working directory it is called in. The path to this script is:
C:\Users\ian\my_scripts\py_scripts\path_test.py
From what I have read, the script is not being associated with the interpreter for python. I used the python.org installer when I installed python, and my python folders are properly in PATH. PATHEXT also has .PY in it yet path_test is not recognized.
Why is this the case? Is there a way to get the command lines to work without this line? I have read that the shebang line wont necessarily work in all cases depending on the OS or how the user has installed python.
Since you apparently have a fairly new setup, you might prefer to try working with Windows Subsystem for Linux (WSL). However, I would recommend that you first make sure that you can do what you want directly in DOS.
This tells DOS (indirectly through Git Bash) where to look for programs (which could include the Python interpreter itself). It has nothing to do with running your code as a script. Of course, Git Bash allows you to treat the script as its own executable. But, while there are advantages to doing that, setting PATH is still probably not what you actually want.
I understand this, invoking python path_test.py in its own directory does work as intended, however this was not my concern. What I want to achieve is the ability to invoke path_test.py anywhere I want (that is why i was showing what happens when I try to call it from another folder, ex. Documents).
So if PYTHONPATH is where it is looking to import modules, my script is not a module, so I can see now how that does not belong. Python is already in my system PATH, and if that is the default search spot should I just get rid of PYTHONPATH?
You also mentioned the run environment and the back/forward slashes. I have re-tested $ python C:/Users/ian/my_scripts/py_scripts/path_test.py in Documents, and with the forward slashes it works properly outputting the correct path to Documents.
From the brief searches I have done the closest thing I would have is Command prompt which is related to MS-DOS. Do you have any recommendations on which of these I should be favouring for testing my scripts?
Note carefully that this system means the Python file gets to choose the interpreter. It can specify an exact path to a specific Python executable, or it can ask /usr/bin/env to find one (using the same logic that the shell does when you write python my_file.py etc.).
I thought it was compatibility layers all the way down? Did they seriously re-implement all of that dos-like logic, including all the weird quirks of the original design like the magic filenames (NUL, CON etc.)?
Not true. You can setup to execute scripts aromatically as well.
For example on Windows .exe, .bat and .cmd files are executable by default. When python is installed .py files are added as executable files.
I simply put an alias (shortcut) on my desktop and then use that to store and access my scripts. But I agree that the default location is really bad - almost worse than Windows, where it is also hidden - and that the user should have some control over where they can put their scripts. I assume that once the script editor for Mac is available, some options in this direction will come with it.
In computing, the term script refers to a text file containing a logical sequence of orders that you can run to accomplish a specific task. These orders are typically expressed in a scripting language, which is a programming language that allows you to manipulate, customize, and automate tasks.
In this command, the > symbol tells the shell to redirect the output of your command to the output.txt file, rather than to the standard system output, your screen. This process is commonly known as redirection, and it works on both Windows and Unix-like systems, such as Linux and macOS.
The first approach is less portable because not all Unix systems place the Python interpreter in the same directory. In contrast, the second approach is safer and more portable. It invokes the env command to find out where the interpreter lives.
Wow! That was a long road! However, the effort was worth it. Now when you create a Python script to automate tasks in a Unix operating system, you know how to make it executable and run it from your command line.
Python is a high-level programming language with a clean and readable syntax. Python and its wide ecosystem of packages and libraries can boost your productivity in a variety of fields. The name Python also refers to a piece of software called the interpreter, which is the program that allows you to run Python code.
The interpreter is a layer of software that works between your program and your computer hardware to get your code running. Depending on the Python implementation that you use, the interpreter can be a program written in:
Whatever interpreter you use, the code that you write will run in this program. Therefore, the first condition to be able to run scripts and code is to have the interpreter correctly installed on your operating system.
Alternatively, interactive mode is when you launch the interpreter and use it as a platform to run code that you type in directly. This mode is pretty useful for learning Python as well as for developing, testing, and debugging your applications.
Note: The standard REPL also has a secondary prompt that consists of three periods (...). This prompt appears when you add indented lines to a compound statement, such as conditionals, function and class definitions, and loops.
When you import a module from another module, script, or interactive session, what really happens is that Python loads its contents for later access and use. The interesting point is that the import statement runs any executable code in the imported module.
The execution of scripts through a double click has several limitations and depends on many factors, such as the operating system, the file manager, execution permissions, and file associations. Still, you can consider this alternative a viable option for production-ready scripts and programs.
Leodanis is an industrial engineer who loves Python and software development. He's a self-taught Python developer with 6+ years of experience. He's an avid technical writer with a growing number of articles published on Real Python and other sites.
If your Python script is a little more complex then you might be looking to host on a dedicated server and make a call to it from Bubble. Something like PythonAnywhere allows you to simply to host your code and you would make an API call to it from Bubble, once you have setup an endpoint in your Python script.
Follow up - my Pythonanywhere Flask app console seems to need a restart every week or so, as it appears to stop running. If you have experience, do Pythonanywhere apps have bad uptime, or am I just using it incorrectly?
CSV uploads have too many limitations right now in Bubble, so I offload that to python. A user uploads a CSV file, which I send off to python. Python parses the headers and evaluates the data, and then returns to Bubble the column headers. I take those column headers and allow the user to map those fields, to Bubble fields. This is done so the user does not have to provide a CSV with exact matches in the header row.
I use python for a number of things. For instance, I have a discord bot written in python which interacts with bubble as the frontend experience and allows me to create a more holistic experience for users.
I want to grab some numbers saved in my Bubble database, use some python code (or any other way you can suggest) to perform some if/or logic and calculations on the numbers. The output would then be a number that I want to save back into my database.
We are working on making the Python-Java integration layer extensible, so that you can dynamically load more JAR files than just ImgLib2 (e.g., ImageJ Ops). But this is not yet working. Big announcement when it does.
yes you have to add it as external libraries in the pythonpath (see the 3rd point of the link I mentioned in my first reply), you can also add other apis from other Fiji plugins and setting the plugins.dir (see point 4 of the same link)
This will ensure that the python the user expects to be used will be the one that runs the script. This is especially important if the user is using virtualenv to have a specific version of python in a given environment.
I always ran my scripts on windows by double-clicking them. However after I reinstalled my python versions this is not happenning. My python installations are on C:\Python27 and C:\Python33. PATH has C:\Python27\ in it. If I try to run a script from cmd, it works ok. But when I double-click any .py file nothing happens.
I was having the same issue. The code works in the IDLE but not on double click. I ran the script through the command prompt and it gave me an error that the IDLE didn't find. Windows didn't like the ascii characters I was printing. I removed them and the script started to work on double click again.
I have some python scripts that I would like to use in my flow. I've seen that it is possible to load scripts in libraries and import them in python recipes, but I was wondering if there is a way to directly use them inside my flow, without having to write a python recipe.
As far as the library developed doesn't require any change from the input dataset (a schema change, a new column), and don't change the output format, then the Python "Code Recipe", after importing and using the library to transform the data, won't require any more changes in a regular basis, and you can make all the development in a git repository that you then checkout at the "libraries" section of your project. This means that we seldomly touch the flow again, and whenever you update the "libraries" the new algorithms will be applied automatically.
ff7609af8f