We Love Python (1) - Introducing the New Python Version and Setting Up the Environment

Installing the latest version 3.13.0

Let's try installing the latest version of Python, 3.13.0, which was just released in September.
I previously wrote about the details of environment setup, but let's forget that for now and just download and install the installer this time.
★ This also assumes a Windows environment.

Select Windows installer (64bit) from here.
Run it immediately. Check "Add python exe to PATH" at the bottom and click "Install Now".

For installation, running with general user privileges is fine! (Administrator privileges are not required.)
Home users should use their own Windows Account. Corporate users should run it under their own account. (★ Please be sure to obtain permission from your workplace system administrator or supervisor before doing this.)

If you select "Install Now" with the option above, Python will be installed under your user profile (C:\Users\myaccount\ ...). It's a rather hard-to-find location, but you don't need to worry about that for now.
You can skip "Customize Installation" this time.

Once the installation is complete, sign out and sign back into Windows. This is to enable the "Add python.exe to PATH" setting from the installer.

Now you can run python from the command prompt.
Let's check the PATH from the command prompt.
The highlighted part below is the Python PATH.

You could start Python development from here, but there is one thing I definitely want to cover this time.

Creating a virtual environment

Wait, what is that all of a sudden?

Specifically, let's imagine a scenario where you are developing and shipping an application. When you create multiple applications on a single development machine by yourself, you separate the language version and libraries used for each application, and build them per application when distributing.

Generally, a partition for a development application is called a project. I think this is a familiar concept for those who work with Visual Studio, etc.
In Python, you first create a project folder and then create a virtual environment under it.

Learning by doing, let's actually create one. First, create a project folder.
Here, I will create a folder called python directly under the user profile and line up multiple projects there.
There is already a project called "test" that I created the other day.

I will add a project called "myapp" here. From here on, I will work in the command prompt.

Go to where you want to create your project, and type: mkdir myapp; cd myapp
Here, we will create a virtual environment using the venv tool included with Python.

c:\>cd users\yoshi

c:\Users\yoshi>mkdir myapp

c:\Users\yoshi>cd myapp

c:\Users\yoshi\myapp>python -m venv my_venv

When you run "python -m venv my_venv" on the 4th line, you will wait a few seconds and a virtual environment called "my_venv" will be created.
Next, let's actually try activating the virtual environment.

c:\Users\yoshi\myapp>.\my_venv\Scripts\activate

I think the prompt has changed to the display below. Now you can perform Python development under the virtual environment my_venv.

Since my_venv does not contain any external libraries other than python, we will install them as needed using the pip command (library management command). You can check what external libraries are currently installed with "pip freeze".

For now, let's install jupyter lab. It is an evolved development environment for Jupyter Notebook.

Pip told me that a new version is available, so I followed its instructions. The command is displayed in green, so I will copy and paste it.

When I run 'pip freeze', there are a lot of libraries installed. These are all libraries used by Jupyter Lab.

When I type 'jupyter lab', Jupyter Lab starts up properly.

The command prompt from earlier is doing various tasks in the background.
No wonder so many libraries are needed. It runs by launching a web server locally, after all.

I will exit Jupyter Lab for now and return to the command prompt.
It's bad manners, but I'll force quit with Ctrl-C.
↑ That's too rude, so I'll fix it.
To exit Jupyter Lab, click 'Shutdown' at the bottom of the 'File' menu.

A 'Shutdown Confirmation' pop-up will appear, so click the red 'Shutdown' button.

It has been shut down correctly.

Returning to the command prompt I launched earlier, I can see that I have exited Jupyter Lab normally.

Running 'deactivate' exits the virtual environment my_venv.

With this, the preparations for app development are almost complete. From next time, I will create a simple app in this environment.
I have zero knowledge of handling libraries from here on, so I have a feeling it will be a thorny path.

Virtual environment summary

Operating a created virtual environment on the command prompt

• Create a virtual environment: C:\project_dir> python -m venv [virtual environment name]

• Enter the virtual environment: C:\project_dir> .\[virtual_env_name]\Scripts\activate

• Exit the virtual environment: > deactivate

If you're wondering why you need the full path only when entering, I assume it's because it properly configures the PATH and other settings after executing activate. I will omit an anatomical breakdown of the mechanism.

Note that libraries must be installed for each virtual environment. Jupyter Lab is no exception. I kind of wish I could manage everything in one Jupyter Lab across virtual environments.

See you later!