Planet Python

Virtual environments are vital if you’re developing Python apps or just writing some Python scripts. They allow you to isolate different app requirements to prevent conflicts and keep your global OS environment clean.

This is super important for many reasons. The most obvious one is requirements isolation. Let’s say that you’re working on two different projects:

• Project #1 requires Python 3.6 and the “requests” package version 2.1.0.
• Project #2 requires Python 3.10 and requests 2.31.0.

You cannot install both Python 3.6 and Python 3.10 globally on your OS. You can only install one version. And the same goes for the “requests” library.

The solution is to create a virtual environment, or “venv”, for each project which will isolate it from the other environment and, most importantly isolate it from your OS global env. Each venv has its own folder that contains all the packages and libraries the project needs to run correctly including a copy of Python itself. Then you can activate “venv1” when you’re working on Project #1 or when you finally deploy it or run it as a service or a process. When it comes time to work on Project #2, you just deactivate “venv1” and activate “venv2”.
Better yet, you can have two separate terminal or IDE windows open at the same time, one for each project with its own “venv” activated.

Another great advantage of venvs is the ability to replicate the project’s environment on almost any computer regardless of its OS or currently installed packages. This eliminates the popular “well, it runs on my laptop” excuse when your code doesn’t run on other team members’ machines. Everybody can recreate the exact project’s environment on their machine using venvs and the requirements list conventionally saved in the “requirements.txt” file.

Now, the most common place that you’ll see developers put their virtualenvs is within the same directory where the project they’re developing is saved. This has some great benefits but it also has major drawbacks. I will briefly mention both the pros and cons of this approach then I will suggest a better place for your ‘venv’ folder, the one I actually do and prefer.

Benefits of creating the “venv” inside the project folder: Easier to create:

It’s easier when you create a new project to “cd” into it and create the “venv” right inside it.

Easier to activate:

It’s also easier for you to activate the venv by just running “source venv/bin/activate” from within the project folder. No need to remember where this project’s venv lives on your disk and the absolute or relative path to it.

One bundle:

When you create the venv inside the project folder, it’s always included and bundled with the project. If you copy the project, move it or send it to a team member, the venv is right there with it. No need to recreate it or “pip install” the requirements again (not sure about this last one).

IDE optimization:

Most IDE’s will discover your venv folder if it’s directly in your project’s folder. Some IDE’s will activate the venv automatically for you, while others will at least use it as the default venv without requiring you to manually set it for each project.

Drawbacks of creating the “venv” inside the project folder: Committing venv to Git is gross:

When you have your venv inside your project’s folder, you risk committing it to Git or your version control system either by accident or unknowing that it is a bad practice.

Virtual environments can contain thousands of files and their size can be in gigabytes. Committing them to Git can overload and clutter your source code repo with unnecessary files and cause confusion for anyone trying to clone and run the source code on their machine.

I can hear you saying that the venv folder should be added to the .gitignore file and thus never committed to Git. This is true but remember that the .gitignore file is not created automatically when you initialize a Git repo. You must manually create it and manually edit it to exclude the venv folder, or use a common template for Python projects. You can easily forget to do this step and won’t notice until you see the venv folder on Github. Simply adding it then to .gitignore file won’t remove it completely from Git history which makes it look unprofessional.

Making the project difficult to backup and sync:

Venvs can get huge both in size and number of files. If you’re using any system to backup your laptop or sync your home/user folder to a remote backup location such as a NAS or Nextcloud/Dropbox/Google Drive, you’ll make your life miserable by backing up your venv folders.
I know, you can set some rules to ignore venvs but believe me, I’ve tried to do so but I always forget to add newly created projects to the list of ignored files.

I often don’t notice until it’s too late. This usually comes after a backup job takes too long to complete then I discover after some digging that a venv folder is being backed up to my NAS or even worse, being uploaded to my pCloud folder.

The Solution: A better place for your virtualenvs

Virtual environments are disposable in nature. They contain packages downloaded from the internet and should not be backed up, sync’ed, copied or moved around. They also are re-producible. Using the “requirements.txt” file that’s ideally included in every Python project, you can reinstall all the content of the venv folder anywhere you have an internet connection.

With that in mind, you should not worry about loosing the venv folder or sharing the project with that folder missing. If the person you share it with has any basic Python knowledge they should be able to replicate its venv easily.

This suggests that you should create the venv in a separate folder outside the project’s folder. The question is “Where?”

Keep all your Virtualenvs in a disposable, central folder outside the project’s folder:

As the heading suggests, the ideal place for venvs is a central folder in a disposable location on your disk outside your project’s folder. This can be your “Downloads” , “var/tmp/” or even “/tmp” folder. Basically any place that any backup or sync software would NOT backup/sync by default and would automatically ignore. Most if not all backup/sync apps and systems will ignore your “Download” folder and “/var/tmp” folder. For me, it’s my Downloads folder where I keep a sub folder of all my venvs.

This guards against human error when you forget to ignore the venv folder manually. You don’t even have to think about it.
So, the venv location must be:

1. outside.
2. disposable.
3. central.
   Here’s a breakdown of why:

Why outside the project’s folder?

So that you avoid drawbacks I mentioned above:

1. Automatically ignored from Git:
   Because they live outside the Git repo, they will never get a chance to be committed or even added to the tracked files.
2. Clutter-free source code:
   You won’t commit them to Git. They won’t clutter and overload your source code with unnecessary files. As you probably know, you repo should only contain the code you write or incorporate in your project in addition to non-reproducible assets, and NOT source code for packages and libraries you download over the internet, i.e. venvs.
3. Automatically excluded from Backups and Sync:
   When you backup or sync a project, you usually wouldn’t include any outside folders in the process.

Why a disposable folder?

Simply put, venvs can be reproduced anytime. No need to back them up as you would your personal documents and valuable source code and assets.

So, having them in a disposable location, like the Downloads folder is ideal. You don’t have to worry about excluding them from backups or sync. They’re excluded by default.

Why central location for all venvs?

There are several advantages you will gain by having all your venvs in one central folder on your disk:

Easily exclude them from backup and sync:

There are many consequences for backing up venv folders or sync’ing them to the cloud.

Most backup and sync software have a way of listing the files/folders you want to exclude. This varies between those systems. Some have an option in the GUI where you specify the list, some require you to include a hidden file with a specific name (like .nobackup in the case of Borg) in every folder you want to exclude. And some simply require that you type out “–exclude {folder name}” in the command that triggers the backup like it’s the case with rsync.

Whatever the case may be, you must do it manually for every folder. However, by having all your venvs under one, and only one, folder, you only have to do this exclusion thing once for the parent folder and be done with it. Every child folder will inherit this and be excluded automatically.

Easily remember the path to your venvs:

If you just apply my first suggestion and create your venv outside your project’s folder, each of your projects will have a different location and you’ll find it hard to remember where each project’s venv is.

By having all your venvs under one folder like “~/Downloads/venvs/” for example, it’s very easy to link to your venv from anywhere on your system.

An Example Setup:

Finally, an ideal setup I suggest and actually have been doing for years now is as follows:

• The location I use for my venvs is:
  ~/Downloads/virtual-envs/ . That is: my home directory > Downloads > virtual-envs.
• When I start a new project, I immediately create a virtualenv for it under my central venvs folder (~/Downloads/virtual-envs/) using this command:

Python3 -m venv ~/Downloads/virtual-envs/project1

• Then I activate the venv. For a quick completion of the path, I hit “Alt +.” (that’s the Alt key and the “dot” key) to add the last argument I gave to the most recent command, which is in this case “~/Downloads/virtual-envs/project1”. So, instead of typing the path again, the activation command becomes:

source + “Alt” + “.” + /bin/activate

I even make it quicker by hitting “Tab” after /b and /a in the path so that it auto-completes “bin” and “activate” words respectively for me.

That’s it. You now have a better setup for your venvs. You don’t have to worry about adding them to the .gitignore file or excluding them from backup and sync software anymore.

Virtual environments are vital if you’re developing Python apps or just writing some Python scripts. They allow you to isolate different app requirements to prevent conflicts and keep your global OS environment clean.

This is super important for many reasons. The most obvious one is requirements isolation. Let’s say that you’re working on two different projects:

• Project #1 requires Python 3.6 and the “requests” package version 2.1.0.
• Project #2 requires Python 3.10 and requests 2.31.0.

You cannot install both Python 3.6 and Python 3.10 globally on your OS. You can only install one version. And the same goes for the “requests” library.

The solution is to create a virtual environment, or “venv”, for each project which will isolate it from the other environment and, most importantly isolate it from your OS global env. Each venv has its own folder that contains all the packages and libraries the project needs to run correctly including a copy of Python itself. Then you can activate “venv1” when you’re working on Project #1 or when you finally deploy it or run it as a service or a process. When it comes time to work on Project #2, you just deactivate “venv1” and activate “venv2”.
Better yet, you can have two separate terminal or IDE windows open at the same time, one for each project with its own “venv” activated.

Another great advantage of venvs is the ability to replicate the project’s environment on almost any computer regardless of its OS or currently installed packages. This eliminates the popular “well, it runs on my laptop” excuse when your code doesn’t run on other team members’ machines. Everybody can recreate the exact project’s environment on their machine using venvs and the requirements list conventionally saved in the “requirements.txt” file.

Now, the most common place that you’ll see developers put their virtualenvs is within the same directory where the project they’re developing is saved. This has some great benefits but it also has major drawbacks. I will briefly mention both the pros and cons of this approach then I will suggest a better place for your ‘venv’ folder, the one I actually do and prefer.

Benefits of creating the “venv” inside the project folder: Easier to create:

It’s easier when you create a new project to “cd” into it and create the “venv” right inside it.

Easier to activate:

It’s also easier for you to activate the venv by just running “source venv/bin/activate” from within the project folder. No need to remember where this project’s venv lives on your disk and the absolute or relative path to it.

One bundle:

When you create the venv inside the project folder, it’s always included and bundled with the project. If you copy the project, move it or send it to a team member, the venv is right there with it. No need to recreate it or “pip install” the requirements again (not sure about this last one).

IDE optimization:

Most IDE’s will discover your venv folder if it’s directly in your project’s folder. Some IDE’s will activate the venv automatically for you, while others will at least use it as the default venv without requiring you to manually set it for each project.

Drawbacks of creating the “venv” inside the project folder: Committing venv to Git is gross:

When you have your venv inside your project’s folder, you risk committing it to Git or your version control system either by accident or unknowing that it is a bad practice.

Virtual environments can contain thousands of files and their size can be in gigabytes. Committing them to Git can overload and clutter your source code repo with unnecessary files and cause confusion for anyone trying to clone and run the source code on their machine.

I can hear you saying that the venv folder should be added to the .gitignore file and thus never committed to Git. This is true but remember that the .gitignore file is not created automatically when you initialize a Git repo. You must manually create it and manually edit it to exclude the venv folder, or use a common template for Python projects. You can easily forget to do this step and won’t notice until you see the venv folder on Github. Simply adding it then to .gitignore file won’t remove it completely from Git history which makes it look unprofessional.

Making the project difficult to backup and sync:

Venvs can get huge both in size and number of files. If you’re using any system to backup your laptop or sync your home/user folder to a remote backup location such as a NAS or Nextcloud/Dropbox/Google Drive, you’ll make your life miserable by backing up your venv folders.
I know, you can set some rules to ignore venvs but believe me, I’ve tried to do so but I always forget to add newly created projects to the list of ignored files.

I often don’t notice until it’s too late. This usually comes after a backup job takes too long to complete then I discover after some digging that a venv folder is being backed up to my NAS or even worse, being uploaded to my pCloud folder.

The Solution: A better place for your virtualenvs

Virtual environments are disposable in nature. They contain packages downloaded from the internet and should not be backed up, sync’ed, copied or moved around. They also are re-producible. Using the “requirements.txt” file that’s ideally included in every Python project, you can reinstall all the content of the venv folder anywhere you have an internet connection.

With that in mind, you should not worry about loosing the venv folder or sharing the project with that folder missing. If the person you share it with has any basic Python knowledge they should be able to replicate its venv easily.

This suggests that you should create the venv in a separate folder outside the project’s folder. The question is “Where?”

Keep all your Virtualenvs in a disposable, central folder outside the project’s folder:

As the heading suggests, the ideal place for venvs is a central folder in a disposable location on your disk outside your project’s folder. This can be your “Downloads” , “var/tmp/” or even “/tmp” folder. Basically any place that any backup or sync software would NOT backup/sync by default and would automatically ignore. Most if not all backup/sync apps and systems will ignore your “Download” folder and “/var/tmp” folder. For me, it’s my Downloads folder where I keep a sub folder of all my venvs.

This guards against human error when you forget to ignore the venv folder manually. You don’t even have to think about it.
So, the venv location must be:

1. outside.
2. disposable.
3. central.
   Here’s a breakdown of why:

Why outside the project’s folder?

So that you avoid drawbacks I mentioned above:

1. Automatically ignored from Git:
   Because they live outside the Git repo, they will never get a chance to be committed or even added to the tracked files.
2. Clutter-free source code:
   You won’t commit them to Git. They won’t clutter and overload your source code with unnecessary files. As you probably know, you repo should only contain the code you write or incorporate in your project in addition to non-reproducible assets, and NOT source code for packages and libraries you download over the internet, i.e. venvs.
3. Automatically excluded from Backups and Sync:
   When you backup or sync a project, you usually wouldn’t include any outside folders in the process.

Why a disposable folder?

Simply put, venvs can be reproduced anytime. No need to back them up as you would your personal documents and valuable source code and assets.

So, having them in a disposable location, like the Downloads folder is ideal. You don’t have to worry about excluding them from backups or sync. They’re excluded by default.

Why central location for all venvs?

There are several advantages you will gain by having all your venvs in one central folder on your disk:

Easily exclude them from backup and sync:

There are many consequences for backing up venv folders or sync’ing them to the cloud.

Most backup and sync software have a way of listing the files/folders you want to exclude. This varies between those systems. Some have an option in the GUI where you specify the list, some require you to include a hidden file with a specific name (like .nobackup in the case of Borg) in every folder you want to exclude. And some simply require that you type out “–exclude {folder name}” in the command that triggers the backup like it’s the case with rsync.

Whatever the case may be, you must do it manually for every folder. However, by having all your venvs under one, and only one, folder, you only have to do this exclusion thing once for the parent folder and be done with it. Every child folder will inherit this and be excluded automatically.

Easily remember the path to your venvs:

If you just apply my first suggestion and create your venv outside your project’s folder, each of your projects will have a different location and you’ll find it hard to remember where each project’s venv is.

By having all your venvs under one folder like “~/Downloads/venvs/” for example, it’s very easy to link to your venv from anywhere on your system.

An Example Setup:

Finally, an ideal setup I suggest and actually have been doing for years now is as follows:

• The location I use for my venvs is:
  ~/Downloads/virtual-envs/ . That is: my home directory > Downloads > virtual-envs.
• When I start a new project, I immediately create a virtualenv for it under my central venvs folder (~/Downloads/virtual-envs/) using this command:

Python3 -m venv ~/Downloads/virtual-envs/project1

• Then I activate the venv. For a quick completion of the path, I hit “Alt +.” (that’s the Alt key and the “dot” key) to add the last argument I gave to the most recent command, which is in this case “~/Downloads/virtual-envs/project1”. So, instead of typing the path again, the activation command becomes:

source + “Alt” + “.” + /bin/activate

I even make it quicker by hitting “Tab” after /b and /a in the path so that it auto-completes “bin” and “activate” words respectively for me.

That’s it. You now have a better setup for your venvs. You don’t have to worry about adding them to the .gitignore file or excluding them from backup and sync software anymore.

PostgreSQL is a powerful open-source relational database management system. In this tutorial, we’ll explore all the steps you need to connect PostgreSQL from Python code. From setting up a PostgreSQL database to executing queries using Python, we’ll cover it all. By the end, you’ll have a solid foundation for seamlessly interacting with PostgreSQL databases in […]

The post How to Connect to PostgreSQL in Python appeared first on TechBeamers.

Hi there!

I'm happy to announce version 3.12 of reader, a Python feed reader library.

What's new? #

Here are the highlights since reader 3.10.

Split the search index into a separate database #

The full-text search index can get almost as large as the actual data, so I've split it into a separate, attached database, which allows backing up only the main database.

(I stole this idea from One process programming notes (with Go and SQLite).)

Change tracking internal API #

To support the search index split, Storage got a change tracking API that allows search implementations to keep in sync with text content changes.

This is a first step towards search backends that aren't tightly-coupled to a storage. For example, the SQLite storage uses its FTS5 extension for search, and a PostgreSQL storage can use its own native support; the new API allows either storage to use something like Elasticsearch. (There's still no good way for search to filter/sort results without storage cooperation, so more work is needed here.)

Also, it lays some of the groundwork for searchable tag values by having tag support already built into the API.

Here's how change tracking works (long version):

• Each entry has a 16 byte random sequence that changes when its text changes.
• Sequence changes get recorded and are available through the API.
• Search update() processes pending changes and marks them as done.

While simple on the surface, this prevents a lot of potential concurrency issues that needed special handling before. For example, what if an entry changes during pre-processing, before it is added to the search index? You could use a transaction, but this may keep the database locked for too long. Also, what about search backends where you don't have transactions?

I used Hypothesis and property-based testing to validate the model, so I'm ~99% sure it is correct. A real model checker like TLA+ or Alloy may have been a better tool for it, but I don't know how to use one at this point.

Filter by entry tags #

It is now possible to filter entries by entry tags: get_entries(tags=['tag']).

I did this to see how it would look to implement the has_enclosures get_entries() argument as a plugin (it is possible, but not really worth it).

SQLite storage improvements #

As part of a bigger storage refactoring, I made a few small improvements:

• Enable write-ahead logging only once, when the database is created.
• Vacuum the main database after migrations.
• Require at least SQLite 3.18, since it was required by update_search() anyway.

Python versions #

reader 3.11 (released back in December) adds support for Python 3.12.

That's it for now. For more details, see the full changelog.

Want to contribute? Check out the docs and the roadmap.

Learned something new today? Share this with others, it really helps! PyCoder's Weekly HN Reddit linkedin Twitter

What is reader? #

reader takes care of the core functionality required by a feed reader, so you can focus on what makes yours different.

reader allows you to:

• retrieve, store, and manage Atom, RSS, and JSON feeds
• mark articles as read or important
• add arbitrary tags/metadata to feeds and articles
• filter feeds and articles
• full-text search articles
• get statistics on feed and user activity
• write plugins to extend its functionality

...all these with:

• a stable, clearly documented API
• excellent test coverage
• fully typed Python

To find out more, check out the GitHub repo and the docs, or give the tutorial a try.

Why use a feed reader library? #

Have you been unhappy with existing feed readers and wanted to make your own, but:

• never knew where to start?
• it seemed like too much work?
• you don't like writing backend code?

Are you already working with feedparser, but:

• want an easier way to store, filter, sort and search feeds and entries?
• want to get back type-annotated objects instead of dicts?
• want to restrict or deny file-system access?
• want to change the way feeds are retrieved by using Requests?
• want to also support JSON Feed?
• want to support custom information sources?

... while still supporting all the feed types feedparser does?

If you answered yes to any of the above, reader can help.

The reader philosophy #

• reader is a library
• reader is for the long term
• reader is extensible
• reader is stable (within reason)
• reader is simple to use; API matters
• reader features work well together
• reader is tested
• reader is documented
• reader has minimal dependencies

Why make your own feed reader? #

So you can:

• have full control over your data
• control what features it has or doesn't have
• decide how much you pay for it
• make sure it doesn't get closed while you're still using it
• really, it's easier than you think

Obviously, this may not be your cup of tea, but if it is, reader can help.

Awarding travel grants to community members to PyCon US and seeing how much they get out of and contribute to the event is one of the most rewarding things we do at the PSF; every year, we wish we could award more.

PyCon US 2024 received 852 travel grant requests totaling almost $1.5 million. With estimated revenue of $1.8M and conference costs of $2.1M, we didn’t have the funds to support every applicant. In round one, we offered $360K, or about 24%, of the grant requests received. This is a record number of travel grants received and offered. We know many folks hoped for a grant and were disappointed not to receive one, so we wanted to share more about the process.

Travel Grant Funding

PyCon US travel grants are funded by various sources, from PyCon US ticket sales and sponsorships, Python Core Devs, the PSF, and generous contributions from PyLadies.

In 2024, some funding sources have contracted. To date, we have not received any corporate travel grant sponsorships. Furthermore, the crunch in the tech sector’s economy is negatively affecting general conference sponsorship. Inflation in event costs and lower projected sponsorships have combined to create a significant loss for PyCon US this year. The tech sector crunch also means that corporations aren’t funding travel for both speakers and attendees, which leads to more travel grant requests, which leads to us awarding a lower percentage of travel grants.

Travel Grant Award Philosophy

PyCon US Travel Grants are intended to support our non-profit mission to promote, protect, and advance the Python programming language, and to support and facilitate the growth of a diverse and international community of Python programmers. Overall, we aim to have an event that reflects that diverse community and our diverse interests, that brings together people who will get a lot out of the event and bring benefits back to their home communities, and that is engaging and impactful from the first tutorial to the last sprint.

To those ends, a part of our budget went to funding our incredible lineup of speakers. We also considered factors such as getting representation from around the world, bringing people who have never attended PyCon US, people who are looking for work, as well as educators and conference and community organizers around the world. Even still, the bittersweet reality is there are so many wonderful people in our community that we could not award grants to everyone who applied (though we sorely wish we were able to).

Although we are a US-based conference, we strive to bring folks from around the world. In fact, 77% of our travel grant funds were offered to 54 countries outside of the US!

Since PyCon US 2022, the Travel Grant Team has used an individualized approach; we read every application more than once. Funds awarded are more likely to be used under this awards model; in fact, there were no travel grant leftovers from PyCon US 2023. Prior to 2020, the team used an algorithm-based approach that relied on randomization and sometimes left money on the table that could have been used by other applicants.

Exploring Alternatives

We decided to offer an in-person ticket to anyone within the US and an online ticket for anyone outside the US. This resulted in offers for 203 in-person tickets and 420 online tickets (which would otherwise cost $100-$400 each). We know it may be impossible to use the in-person ticket without accompanying travel funds, but we wanted to offer something even if we couldn’t award the full request. If you’d like to request an exchange for an in-person ticket to an online ticket, or vice versa, please email your request to pycon-reg@python.org.

Some questions were raised about how multiple rounds of grant allocations work. Our award emails advise folks that they may request additional funds if the round one award is insufficient. Requesting additional funds removes awardees from the round one travel grant pool and puts them into the second round. Unless we receive new corporate sponsorships or other funds, round two funds come from the funds folks don’t accept in round one.

To clarify the language in the award emails, the complimentary registrations will not be removed from anyone in round 2. That is to say, if you have been offered a complimentary ticket, that offer stands regardless of whether you request additional funds or not. Even if you put yourself into the second round, you will NOT forfeit your complimentary registration.


Find more information on the PyCon US Travel Grants FAQ. If you have feedback on our process, please send it to pycon-aid@python.org.
 

PyCon US Staff

 PS - As a final note, we’d love to continue expanding our travel grant program in the future. If you’d like to help do that, a great way is to encourage your employer or other companies you are connected with to sponsor the PSF or to let them know you notice and appreciate it if they are already a sponsor.

In this article I use the metric system, where 1 meter = 3.28 feet. I also talk about highways. Here I use the definition in British English, where highway refers to any path with a public right of access.

We are all familiar with the existence of route planners like google maps or OpenStreetMaps (OSM), that allows us to get the shortest path between two points in space. With OSM and it’s read-only API Overpass we can get very detailed information about a chosen region, including streets roads and ways, but also information like if a street is illuminated, if a bus stop has a bank or which bars are in the region. This opens the door to the possibility to not only calculate a route based on distance, but also to use other criteria like prioritizing illuminated streets or the estimated quietness, so I wrote a web application to do exactly this.

How does this app look like?

You can find the application deployed here.

To use it, first of all we have to scroll the Map to the position we want to get our way. Then we need to click the two points on the map where we want to have our start and end point. On Path Priority we can select to get the quietest path or the shortest one, where the quietness option is the default one.

After clicking on Submit a new tab opens with the calculated route.

How does this App work?

This seems very simple on the surface, but what is on the inside?

Getting the data for the desired area

To build all functionalities First of all we use Leaflet and Javascript to display the map and write the functionality for the markers.

With the markers we can get the coordinates of the desired start and end points.

Downloading the map data

The first thing we need to find a route between the two points on the map is the data of the map! With Overpass API we can query the data we need from OSM:

[out:json]; way(south, west, north, east)[highway]; (._;>;); out;

South, west, north and east stand for the coordinates limiting the area we want to download. How Overpass works would be a blog article for itself, but in this case we get all ways inside of the area bounded by the given coordinates and who contain data on highway. In addition we get a list of nodes contained in the ways. In python, we execute the query with the following (simplified) code:

import requests OVERPASS_URL = 'https://overpass-api.de/api/interpreter' OVERPASS_QUERY = ''' [out:json]; way({s},{w},{n},{e})[highway]; (._;>;); out body; ''' overpass_query = OVERPASS_QUERY.format(n=self.area_boundaries.north, s=self.area_boundaries.south, e=self.area_boundaries.east, w=self.area_boundaries.west) response = requests.get(OVERPASS_URL, params={'data': overpass_query})

I decided to enhance the boundaries of the downloaded area because following scenario could happen. Imagine we want to find a path between points 1 and 2. If we didn’t add a “margin” to the boundary marked by the points, we would only get the data inside the box on figure 2. In this case it implies that the application wouldn’t find a path between the two points, despite one existing!

By adding a margin we get the data for the way between 1 and 2, as shown in figure 3.

Parsing the data and creating the graph

Once the data is downloaded, it has to be parsed. The data contains a list of node with the latitude and longitude coordinates where they are located, and a list of way containing data for highway and a list of the node id’s forming the way.

Node1
id1
lat1, lon1Node2
id2
lat2, lon2…Way1
highway:type1
nodes: id1, id2, …Way2
highway: type2
nodes: idi, idj, ……Representation of the downloaded data

With this information we know which nodes are directly connected. For the edges we need to calculate the weight. Depending on if we want to get the shortest path or the (estimated) quietest one, we need different information in order to calculate the weight of the edges.

Calculating the distance

In order to get the shortest path, we can just take the distance between two connected nodes. Since we have the coordinates of each node, we can just use the haversine library:

from haversine import Unit, haversine # Some more code coordinates_0 = (node_0.lat, node_0.lon) coordinates_1 = (node_1.lat, node_1.lon) haversine(coordinates_0, coordinates_1, unit=Unit.METERS)

This way we don’t need to implement the formula ourselves, which is quite complicated.

Estimating the quietness

To estimate the quietness, things become more complicated. The downloaded and parsed information includes the highway. The highway tells us which kind of road we have, for example if it’s residential or a motorway. Most interestingly, OSM does not save which type a road has been officially classified but rather which type it really is.

Different types of paths will have a different amount of traffic, which results in more or less sound volume. For example, a track in the middle of a forest will be quieter than a road with 6 lanes crossing a big city. With this information we can guess that a way classified as track will be quieter than a way classified as trunk.

Using that approach alone is a good start, but it has a problem: a footpath located directly next to a road is being estimated as being as quiet as the ones located far away of roads. As we can see in the picture below, the way starting on point 1 is of the same type as on point 2. However point 1 is directly next to a secondary road while point 2 is located in the middle of a park. If we don’t take into account the surroundings, we would be classifying the edges forming both ways as being equally quiet, making the estimation very imprecise.

To solve this problem, we can take into account everything we have in a certain radius. For now I took 20 meters, which after some tests it seems to allow a better estimate than if I take 10 meters.

Calculating the path and displaying it

Once we have the weights of the edges, we can construct the graph with the help of the dijkstra library.

from dijkstra import Graph # More code graph = Graph() weight_calculator = WeightCalculator(self.path_way_priority, self.nodeId_to_nodeInfo_dict) for node_id_0, node_id_1 in self.edge_list: weight = weight_calculator.get_weight(node_id_0, node_id_1) graph.add_edge(node_id_0, node_id_1, weight) graph.add_edge(node_id_1, node_id_0, weight) return graph

The weight calculator allows us to get the weight of an edge depending on if we need to take into account the distance or the estimated quietness. For each connected node pair, we calculate the weight of the connecting edge and add those into the graph.

Later we use the following code to get our path:

from dijkstra import DijkstraSPF # More code # Use graph object from above dijkstra = DijkstraSPF(graph, init_point) # Even more code dijkstra.get_path(end_node_id)

Finally we want to display it to the user using the folium library. Folium allows us to create html files where we display a map using OSM and displaying elements on said map. On the one hand we want to get the trail coordinates, which allows us to display the calculated route. dijkstra.get_path(end_node_id) returns a list of nodes, so we can use that list to get the list coordinates (latitude, longitude) to display said trail coordinates.

map = folium.Map(location=start_node_coords, zoom_start=ZOOM_START) # etc # Returns a list of nodes forming the calculated path between the init and end node nodes_forming_path = dijkstra.get_path(end_node_id) # returns a list of tuples containing the coordinates of the nodes trail_coordinates = self.get_trail_coordinates(nodes_forming_path) folium.PolyLine(trail_coordinates).add_to(map)

With the following code we add the start and end marker:

folium.Marker(start_node_coords, popup='Start').add_to(map) folium.Marker(end_node_coords, popup='End').add_to(map)

After all this we are ready to save the map and display it to the user.

Possible improvements and enhancements

It would be an improvement to make the radius for the estimated quietness weighted. This means that objects located at for example 15 meters away from the “starting node” would be less relevant as those located 2 meters away.

This application can potentially be enhanced to offer other criteria to calculate a path. Not only does it allow to help people reduce the amount of noise one is exposed, but it can add safety by prioritizing illuminated ways. Maybe it can also be used to get a friendlier path for people with mobility issues or suffering from fatigue. What cool enhancements can you think about?

I recently gave a workshop at the Developer Open Space un-conference about GitHub Copilot and how developers can benefit from these AI assistants. I was fairly new to Copilot myself, having only tried it for a few months. But I was already impressed by its often spot-on suggestions, its understanding of context, and its rich feature set.

At the end of the course, a participant asked me an interesting question about how to approach a typical extreme value or optimization task from school mathematics. I had a gut feeling that this type of task would be challenging for an AI assistant, and it sparked a great discussion about the limitations of AI and problem-solving in general. I didn’t have time to think about it back then, but now I can dive deeper. Come along and see how it works out.

So let’s see if GitHub Copilot can be used to solve mathematical puzzles. We will see that we need to learn to recognise the signs of when AI assistants are overconfident.

The mathematical problem of finding the highest point a ladder can reach while leaning against a cube The problem

You’ll find a good description of the problem here, along with several solutions, but don’t worry, you have to deliberately click to see the solution, so there’s no risk of accidentally discovering it. As with all good problems, the statement is very simple, but there is a lot to think about: There is a cube leaning against a wall, and a ladder leaning against the same wall, but at the same time touching the cube. The question is: how far up the wall can the ladder go when it has to touch the cube, so that we can get the ladder as close to the wall as the cube will allow. Ideally I would like to find a solution for every pair of ladder and cube.

In terms of variables, we have the length \( l \) of the ladder and the side length of the cube \( d \). What we want to know is the height \( h \) from the ground to the point where the ladder touches the wall. That shouldn’t be too hard, should it? Well, try to solve it yourself!

A first attempt

Well, GitHub Copilot or AI assistants to the rescue, then! Why bother with middle school mathematics? Long forgotten or never learned! Surely we’re not going to do the hard intellectual work! The whole point of AI is to assist us, isn’t it? So let’s ask GitHub Copilot to solve this problem for us.

GitHub Copilot can be used in many different ways, but the most satisfying and natural way is to simply write a comment asking for something and wait for Copilot’s suggestions. Alternatively, you can launch an inline chat prompt, which is also a nice way to go, and for most of my workflows it doesn’t feel too disruptive when I’m already in the editor window.

This article is not about how to get started with GitHub Copilot. There is plenty of material already available. You can follow the official instructions here and start with a test trial, or you can use similar services like plugins that use an OpenAI API developer key or other services like Codium. For the rest of this article, I will demonstrate my approach using GitHub Copilot in Visual Studio Code with the following extensions installed: GitHub Copilot and GitHub Copilot Chat. But the nice thing about the current landscape is, that it doesn’t really matter which tool you use, as long as you start using it. There is a lot going on at the moment and different service providers are tying to dethrone each other every day, giving us developers a wide variety of providers and tools to choose from. In my personal opinion, GitHub Copilot offers one of the best integrations with Visual Studio Code and it has a very nice update cycle that regularly delivers new and helpful features (you should not miss the official YouTube channel, which is a great source of newly available features).

Having that said, let’s see what GitHub Copilot does, if we ask it in a very simplistic way:

GitHub Copilot suggests the rest of the function definition for the given problem statement GitHub Copilot suggests the rest of the function definition for the given problem statement GitHub Copilot suggests the rest of the function definition for the given problem statement

As you can see in the screenshot, GitHub Copilot suggests a solution (hence the grey color) based on our input. The suggested solution is

def max_ladder_height(l, d): return (l**2 - d**2)**0.5

Not bad! But wait… this solution is so simple that even without having studied the problem in detail, we might start to get suspicious. And we would be right to do so, because this is a Pythagorean equation that assumes \( l^2 = h^2 + d^2 \), which basically says that the squared length of the ladder is equal to the sum of the squared height and the squared side length of the cube. But this is wrong, because the side length of the cube is not the whole distance between the ladder and the wall. This would only be the case if the ladder leaned directly against the cube, but then there would be no point of contact with the wall (and no triangle), the ladder would stand vertically like a candle! No, this equation, although stated with great confidence, is simply wrong.

If you are interested in why GitHub Copilot came up with this solution, you can try out the chat feature and give it the same prompt. Here is the first part of the answer I got back from it:

To solve this problem, we need to use the Pythagorean theorem. The highest point the ladder can reach is when the ladder is perpendicular to the ground. This is because the ladder’s length forms the hypotenuse of a right triangle, and the height is one of the sides. The maximum height is achieved when the other side (the base of the triangle) is minimized. In this case, the base of the triangle is the edge of the cube, so the maximum height is when the ladder is directly above the cube’s edge.”

Github Colpilot Chat

Alternatively, if you do not want to think too much about the suggested solution, you can ask Copilot to generate some outputs for you. This will allow you to do some basic plausibility checks yourself:

Using GitHub Copilot Completion Panel to retrieve several suggestions at once Using GitHub Copilot Completion Panel to retrieve several suggestions at once Using GitHub Copilot Completion Panel to retrieve several suggestions at once

Normally with GitHub Copilot and a prompt (comment) like this, you end up with suggestions coming in line by line. If you want Copilot to generate the whole block of code at once, there are better ways than relying on the inline suggestions. One alternative is the Completion Panel, which can be opened with Ctrl + Enter. This panel shows up to 10 different suggestions, offering a greater variety than the inline suggestions, and you can choose which suggestion you want to accept. In my case, I chose suggestion 3, which complied with my request that d be only one of two values. Funnily enough, Copilot directly lists the output of each function call as a comment in front of the call, so we don’t even need to run the code, right? Wrong, let’s see what happens in the console:

2.8284271247461903 2.23606797749979 3.872983346207417 3.4641016151377544 4.898979485566356 4.58257569495584

The output is different from the comments! What a bad behavior, Copilot, shame on you! Giving me test cases with the wrong output is not a nice way to build trust between us. But honestly, I expected as much, so let’s move on.

To make the comparison easier, let’s put the predicted and the actual outputs of the function calls side by side:

Function callSuggested outputActual outputmax_ladder_height(3,1)\( 2.828 \)\( 2.828 \)max_ladder_height(3,2)\( 2.646 \)\( 2.236 \)

Note that in the second case, the suggested output of the function call is not the actual output of the function call, something you should always be aware of when working with Copilot.

Back to the question of whether this code is actually a correct solution (which we have already concluded it is not). In the first example, a ladder of length 3 (metres, if you like) leaning against a cube of side length 1 can reach a height of 2.83. This sounds wrong. Consider that a ladder leaning against a cube with a side length of 1 metre would most likely have to be tilted a bit until it actually touches the wall, which means that it is not plausible to reach a height of 2.83 metres in this scenario.

The second example is even more problematic: A ladder of length 3 and a cube of side length 2. Let’s imagine this for a moment. You can do some drawing, but it will turn out to be completely impractical for a simple reason: the ladder must be at least twice as long as the side length of the cube, otherwise it will never reach the wall if it has to lean against the cube.

The (geometric) reason for this is that the cube divides the ladder into two segments: the upper segment, which touches the wall and the cube, and the lower segment, which touches the cube and the ground. Both of these segments are part of a rectangular triangle with the cube and either the wall or the floor. In both cases, the ladder segment is the hypotenuse, that is, the longest side of the triangle (this is easier to follow if you look at the picture below, where the problem is shown in 2D space).Since each ladder segment is part of a triangle where the side length of the cube is one of the two shorter sides of the triangle, it follows that each segment must be at least as long as the side length of the cube So, the whole ladder must be at least twice the side length of the cube.

So not only does Copilot generate code that does not solve the problem correctly, it also violates some important physical constraints, such as the ladder being at least twice the size of the cube’s side length. Of course, once we have derived this knowledge ourselves, it would be quite easy to make it part of our prompts (comments) and let Copilot fix the existing function by implementing some plausibility checks. But the main point of this case study is to show how much we can rely on Copilot without spending too much effort analysing the problem first and wasting time on prompt engineering.

Deriving a working solution

I’ve already included a link to the solution in the problem statement, but because I just love maths, and because I love self-contained articles where you can get the whole story and all the information in one go, we’re going to derive the solution by hand. However, if you don’t want to see the maths behind the problem, all you need to follow this article is the final equation we derive at the end of this section.

There are several ways to solve this problem, but one elegant way is to strip away unnecessary information and think of this as a 2D problem (see the next picture). Imagine a common Cartesian coordinate system with \( y \) and \( x \) axes. In our case, the wall represents the \( y \) axis and the floor represents the x axis. The cube is no longer a square but a simple rectangle with a side length \( d \), and the ladder becomes a straight line that touches the rectangle in a single point and intersects the axes. The point where the ladder touches the wall becomes the \( y \) intercept \( P(0, h) \). This is exactly the point we are interested in, because \( h \) gives us the height we want to know. The point where the ladder touches the floor becomes the \( x \) intercept \( P(a, 0) \). We do not yet know \( a \), but it represents the distance of the ladder from the wall so we keep this unknown variable for now. There is also a third point of interest that will be important, and that is the point where the ladder touches the cube: \( P(d, d) \).

The original problem in 2D. The ladder can be understood as a straight line intersection both the x- and y-axis.

If we look at the figure above, we can see that \( a \) is the base of a right triangle, \( h \) the height, and \( l \) is the hypotenuse. Thanks to Pythagoras, we know that \( l^2 = a^2 + h^2 \). But we don’t know \( a \) and we need another equation to get closer to a solution. We now do the “trick” (I should really avoid calling it a trick because people often fear that mathematics is all about tricks and that you can only be good at it if you know those tricks, but that is not true. It is more about trying out different perspectives and representations until the problem becomes solvable or simple enough to see a solution) and think of the ladder as a straight line intersecting the two axes. The slope of a straight line \( m \) is the ratio of how much you go up or down when you go left or right. Mathematically it is expressed as the quotient of the difference in \( y \) and the difference in \( x \), so \( m = \frac{\Delta y}{\Delta x}=\frac{y_2 – y_1}{x_2 – x_1} \). We only need to fill in two points on the line to get the slope! Lucky for us, we already have two points \( P(0, h) \) and \( P(a, 0) \):

$$ m = \frac{h – 0}{a – 0} = \frac{h}{a} $$

That’s splendid! But wait, what is \( a \)? We don’t know it, so maybe we can express it with variables that we already know? Yes we can, see the Pythagorean equation above! Thanks to

$$ a^2 = l^2 – h^2 \Rightarrow a = \sqrt{l^2-h^2} $$

we get the following final expression for the slope

$$ m = \frac{h}{a} = \frac{h}{\sqrt{l^2 – h^2}} $$

That is good because we know \( l \) and thus only have an equation with the one variable that we actually want to find out: the height \( h \). But we only have the slope of the straight line, how do we get a full equation?

Taking into consideration the full equation of a straight line \( y = mx + b \) with \( m \) being the slope and \( b \) being the y-axis intersection (which we already now, because it is exactly \( h \), so \( b=h \)), we cannot reuse the two points we already used to get the slope. Luckily, we don’t have to because we have another point \( P(d,d) \) that we can just plug in into this equation.

$$ d = \frac{h}{\sqrt{l^2 – h^2}}d + h $$

Look at the beauty of that equation! The square root can look a bit scary but it is actually quite straight forward to solve this equation for \( h \), which is the final step we have to do to solve our problem. What follows are some algebraic finger exercises to solve this equation for \( h \). This is done by isolating the square root and squaring on each side and handling a few bracket expressions. Once we have done all that, we arrive at

$$ h^4 – 2h^3 + h^2 (2d^2-l^2) + 2dl^2h – d^2l^2 = 0 $$

And that is a fourth degree polynomial equation, quite different from Copilot’s first attempt! This equation looks complex because it still contains \( l \) and \( d \) as two parameters that we can plug in, so to make this equation more tangible we could plug in \( l = 3 \) and \( d=1 \) to get the equation for the height when the ladder is 3 meters and the cube’s side length is 1 meter. This would give us

$$ h^4 – 2h^3 – 7h^2 + 18h – 9 = 0 $$

How to solve such a polynomial equation is beyond the scope of this article. In short, there is no algebraic closed solution for this particular equation, which means you have to use numerical methods to solve this equation. Good for us: That is something Copilot can do easily for us, finally!

Bringing it all together

With our newly derived knowledge about the general solution to our problem for any pair of \( (l,d) \) values, let’s ask Copilot again to solve this problem for us:

# solve the equation h^4 - 2dh^3 + h^2*(2d^2 - l^2) + 2dl^2h - d^2l^2=0 # where d is the length of the cube and l is the length of the ladder def get_highest_point(l, d): a = 1 b = -2 * d c = 2 * d**2 - l**2 e = 2 * d * l**2 f = -(d**2 * l**2) roots = np.roots([a, b, c, e, f]) max_h = max(roots) # return the roots, the number of roots, the maximum root and the distance of the ladder from the wall return roots, len(roots), max_h, (l**2 - max_h**2) ** 0.5

As you can see, I gave him as prompt the full equation and explained the meaning of both variables. And in one go with a single suggestion Copilot completed the whole function for me! The only thing I entered was def and Copilot did the rest. You can see a clear structure in the code defining first all coefficients of the polynomial.

Did you notice that Copilot started with a, b and so on, but after c continues with e and f? Actually, in the first attempt, Copilot wasn’t so clever and actually used d as the fourth coefficient, overwriting the function parameter d and thus getting the wrong result for the next coefficient e which actually is calculated by \( d^2 \cdot{} l^2 \) and here \( d \) has to be the cube’s side length and not the fourth coefficient value. I used Copilot’s inline chat functionality to ask for a simple fix and it refactored the code into the version you can see above. But again, lesson learned: Copilot is not always clever enough to avoid such simple mistakes like accidentally overwriting important function parameters.

Looking at the final solution, it is actually quite nice. Using NumPy’s np.roots (the documentation actually says there is a newer API we should use) is a great solution for this problem as the roots of the polynomial are possible solutions for \( h \) because the roots are zero points that solve this equation. Knowing that it is a fourth degree polynomial equation we already know that there can only exist up to four different solutions (when you think about it, there are infinite solutions because in the real world we can put the ladder in any angle we want, not only in four discrete positions, so the solutions to this equation are not the only possible heights the ladder can take, only the maximum is meaningful in this context), but under certain conditions, it can be less than four. However, to us only the maximum height possible is interesting, so we use max(roots) to get the maximum height of all possible heights.

You may notice the second comment inside the function saying “return the roots, the number of roots, the maximum root and the distance of the ladder from the wall”. Here I prompted Copilot to generate for me the desired output and it did so flawlessly. This function returns four things: all found solutions for \( h \), the number of found solutions, the maximum height, and the distance of the ladder from the wall, so I could picture things more easily in my head!

Let’s do a quick run for one of our test cases from the beginning:

print(get_highest_point(3, 1)) >>> (array([-2.9062796 , 2.49206604, 1.67021162, 0.74400194]), 4, 2.4920660376475325, 1.670211622520849)

For a ladder with length 3 and a cube with length 1, there are four solutions, one being physically implausible. The remaining three heights are all valid solutions, from which 2.492 is the maximum height we were looking for. The ladder is actually 1.67 away from the wall. Copilot’s suggested solution for this case was 2.828, which we knew was wrong, but only now can we assess how wrong it actually was.

Final words about Copilot

What have I learnt from this case study? Copilot is a powerful tool that works surprisingly well far more often than it fails. It increases my daily productivity by several orders of magnitude, especially with mundane, repetitive tasks such as writing tests and documentation, writing well-defined methods, fixing common bugs, and the like. It is also very helpful when doing things I have not done for a while, such as working with a lesser-known library, or testing a new library I am not yet familiar with. In both cases, it can save me a lot of time by not requiring me to read tutorials or API documentation. Instead, it can directly generate examples and code snippets that show me how to use them. Copilot also shines when it comes to very common tasks like implementing algorithms. Since problems like finding a prime number, sorting a list of numbers and so on have been solved literally hundreds of times and are available in public repositories, Copilot has seen enough examples of how to generate this code and how to generate it well. Finally, Copilot is also great for interactive workflows, where I write part of a function or refactor an existing function and let it help me finish or revise the existing code using the inline chat functionality. Because Copilot knows the context, the surrounding code, it’s suggestions can be spot on.

Yet there is a reason why GitHub Copilot always warns of the real possibility that the generated code might be wrong. Whatever wrong means. Wrong can mean many things, as we have seen. It can mean that the code does not work at all and produces some kind of runtime error. It can mean that the code does not do exactly what we want it to do. Of course, there is always the possibility that our description was ambiguous and that Copilot simply took advantage of the freedom given by the vagueness of our description. It can mean that the code does what we asked it to do, but not in the best possible way, or in a way that is unsafe or otherwise considered harmful. It can mean that the code does what we asked it to do, but the generated comments and documentation are wrong. And it is difficult to detect all these things if we are too trusting. We need to be aware of this kind of misbehaviour, and we need to develop a gut feeling about which tasks will prove easy for AI assistants, and which tasks will prove difficult. Copilot gets a lot of things right the first time, often flawlessly. And then there are times when it does not get it right, even after many attempts with different prompts and strategies, adding more and more information, details, examples and guidance.

Let’s summarise:

• Copilot (and any other AI tool) can produce working code that seems correct and reasonable at first glance, but does not provide the correct solution to a given problem when tested thoroughly.
• Copilot can create test cases for existing code, but those test cases may be wrong. Similarly, it may suggest tests for parameter combinations that are not plausible.
• Copilot (and especially more generalised models) can be very persuasive and assertive in the way it presents its solutions, so you need to be aware that it can be wrong even when it argues that it is right.
• In general, Copilot is not good at solving problems that don’t have a clear solution or a known algorithm. If you ask it to sort numbers, it will do it without breaking a sweat. But if you ask it to solve a mathematical puzzle for you, well…it tries its best. Our problem was particularly hard, when you think about it, because the solution could not be derived without finding a better representation of the problem. If you have a list of numbers, you can just start sorting them in different ways, there is no step you have to take first to understand the problem. But in the case of our ladder and cube problem, the facts about the length of the ladder and the side length of the cube are not helpful in finding the solution. We had to first transform this problem into a geometric problem and define some helper variables to be able to solve it (not to mention that we relied on several mathematical facts such as equations about rectangular triangles and straight lines).
• When generating code, Copilot can introduce errors such as overwriting existing function parameters.
• However, once we had an equation and wanted Copilot to solve it for us using any method it deemed appropriate, it could do it in a single pass on the first try. I doubt it had ever seen this exact equation before, but it drew parallels from the hundreds of similar polynomial equations found in other public code repositories.

Side note: And what about ChatGPT?

If you are familiar with Copilot, you mayknow that it is based on OpenAI’s Codex model. OpenAI states, that “OpenAI Codex is most capable in Python, but it is also proficient in over a dozen languages including JavaScript, Go, Perl, PHP, Ruby, Swift and TypeScript, and even Shell.” Basically, it is a fine-tuned foundational Large Language Model (LLM) that excels at generating code. The astute reader may object that Copilot is simply the wrong model for such a task for precisely this reason. And they might be right about that. So I decided to ask ChatGPT the same question: Can you tell me how to solve this maths problem (without the code generation)?

I will not include any more screenshots of my attempts here, you can see the chat history via this link (very nice feature of ChatGPT!). As you can see, at no point was ChatGPT able to derive at the same equation as we did. However, each solution it presented was well explained and well argued. So, basically, we can see some of the same problems we already noticed with GitHub Copilot.

There are other LLMs I could have tried, such as more powerful ones like GPT-4 or fine-tuned ones like MetaMath-Mistral-7B. It has become a sport to find the best fine-tuned model for the task at hand, and it makes sense to spend time fine-tuning for a specific problem. But the point of this article was to learn about the inherent limitations of models and AI assistants like GitHub Copilot, and when to be cautious about the answers you get and the code you generate. There’s always a better tool for the job, but the truth is that we don’t usually use all the tools available to us. Humans are creatures of habit and like to follow the path of least resistance. We try to do as much as we can with one tool, and are happy if that tool works well for almost any task we throw at it. In this respect, GitHub Copilot has many strengths, but we should never let our guard down and always remember that these tools are assistants, not experts that replace us humans.

The following text is in German, since we're announcing a Python sprint in Düsseldorf, Germany.

Ankündigung

Python Meeting Herbst Sprint 2024 in
Düsseldorf

Samstag, 09.03.2024, 10:00-18:00 Uhr
Sonntag, 10.03.2024. 10:00-18:00 Uhr

Eviden / Atos Information Technology GmbH, Am Seestern 1, 40547 Düsseldorf

Informationen Das Python Meeting Düsseldorf (PyDDF) veranstaltet mit freundlicher Unterstützung von Eviden Deutschland ein Python Sprint Wochenende.

Der Sprint findet am Wochenende 09./10.03.2024 in der Eviden / Atos Niederlassung, Am Seestern 1, in Düsseldorf statt.

• Sprint Ort in Google Maps
  

Folgende Themengebiete sind als Anregung bereits angedacht:

• Data Apps mit Taipy bauen
• XML Parser Bindings für Rust:QuickXML
• Extraktion & Visualisierung von Wissensgraphen aus unstrukturietem Text mit Hilfe eines lokalen LLMs

Natürlich können die Teilnehmenden weitere Themen vorschlagen und umsetzen.

Anmeldung, Kosten und weitere Infos

Alles weitere und die Anmeldung findet Ihr auf der Meetup Sprint Seite:

• Python Spring Sprint & Hackathon in Düsseldorf
  

WICHTIG: Ohne Anmeldung können wir den Gebäudezugang nicht vorbereiten. Eine spontane Anmeldung am Sprint Tag wird daher vermutlich nicht funktionieren.

Teilnehmer sollten sich zudem in der PyDDF Telegram Gruppe registrieren, da wir uns dort koordinieren:

• PyDDF Telegram Gruppe

Über das Python Meeting Düsseldorf

Das Python Meeting Düsseldorf ist eine regelmäßige Veranstaltung in Düsseldorf, die sich an Python-Begeisterte aus der Region wendet.

Einen guten Überblick über die Vorträge bietet unser PyDDF YouTube-Kanal, auf dem wir Videos der Vorträge nach den Meetings veröffentlichen.

Veranstaltet wird das Meeting von der eGenix.com GmbH, Langenfeld, in Zusammenarbeit mit Clark Consulting & Research, Düsseldorf.

Viel Spaß !

Marc-André Lemburg, eGenix.com

In this episode, we completed the final features needed to get the site open for others to sign up. This included some dynamic limiting of the number of people allowed to sign up. We also had to add the template styling for the login page.

In a previous post, I explained the differences between conda, Anaconda, and Miniconda.

I said that you can use conda to manage virtual environments:

If you’re not familiar with virtual environments, they allow you to maintain isolated environments with different packages and versions of those packages.

In this post, I’m going to explain the benefits of virtual environments and how to use virtual environments in conda.

Let’s go! 👇

Why use virtual environments?

A virtual environment is like a “workspace” where you can install a set of packages with specific versions. Each environment is isolated from all other environments, and also isolated from the base environment. (The base environment is created when you install conda.)

So, why use virtual environments at all?

• Different packages can have conflicting requirements for their dependencies, meaning installing one may cause the other to stop working.
• If you put them in separate environments instead, you can switch between the environments as needed, and both will continue to work.

Thus by using environments, you won’t breaking existing projects when you install, update, or remove packages, since each project can have its own environment.

You can also delete environments once you’re done with them, and if you run into problems with an environment, it’s easy to start a new one!

Six commands you need to know

conda environments have a lot of complexity, but there are actually only six commands you need to learn in order to get most of the benefits:

1️⃣ conda create -n myenv jupyter pandas matplotlib scikit-learn

This tells conda to:

• Create an environment named myenv (or whatever name you choose)
• Install jupyter, pandas, matplotlib, and scikit-learn in myenv (or whatever packages you need installed)
• Install all of their dependencies in myenv
• Choose the latest version of every one of those packages (as long as it works with every other package being installed)

That last point is a mouthful, but it basically means that conda will try to avoid any conflicts between package dependencies.

Note: conda stores all of your environments in one location on your computer, so it doesn’t matter what directory you are in when you create an environment.

2️⃣ conda activate myenv

This activates the myenv environment, such that you are now working in the myenv “workspace”.

In other words:

• If you now type python or jupyter lab (for example), you’ll be running the Python or JupyterLab that is installed in myenv.
• If you then type import pandas, you’ll be importing the pandas that’s installed in myenv.

Note: Activating an environment does not change your working directory.

3️⃣ conda list

This lists all of the packages that are installed in the active environment (along with their version numbers). If you followed my commands above, you’ll see python, jupyter, pandas, matplotlib, scikit-learn, and all of their dependencies.

4️⃣ conda env list

This lists all of the conda environments on your system, with an asterisk (*) next to the active environment.

5️⃣ conda deactivate

This exits the active environment, which will usually take you back to the “base” environment (which was created by Anaconda or Miniconda during installation).

6️⃣ conda env remove -n myenv

This permanently deletes the myenv environment. You can’t delete the active environment, so you have to deactivate myenv (or activate a different environment) first.

Going further

If you want to learn more about conda environments, check out this section of conda’s user guide:

🔗 Managing environments

If you want a broader view of conda and its capabilities, check out this section:

🔗 Common tasks

Or, share your question in the comments below and I’m happy to help! 👇

You’ve likely interacted with large language models (LLMs), like the ones behind OpenAI’s ChatGPT, and experienced their remarkable ability to answer questions, summarize documents, write code, and much more. While LLMs are remarkable by themselves, with a little programming knowledge, you can leverage libraries like LangChain to create your own LLM-powered chatbots that can do just about anything.

In an enterprise setting, one of the most popular ways to create an LLM-powered chatbot is through retrieval-augmented generation (RAG). When you design a RAG system, you use a retrieval model to retrieve relevant information, usually from a database or corpus, and provide this retrieved information to an LLM to generate contextually relevant responses.

In this tutorial, you’ll step into the shoes of an AI engineer working for a large hospital system. You’ll build a RAG chatbot in LangChain that uses Neo4j to retrieve data about the patients, patient experiences, hospital locations, visits, insurance payers, and physicians in your hospital system.

In this tutorial, you’ll learn how to:

• Use LangChain to build custom chatbots
• Design a chatbot using your understanding of the business requirements and hospital system data
• Work with graph databases
• Set up a Neo4j AuraDB instance
• Build a RAG chatbot that retrieves both structured and unstructured data from Neo4j
• Deploy your chatbot with FastAPI and Streamlit

Click the link below to download the complete source code and data for this project:

Get Your Code: Click here to download the free source code for your LangChain chatbot.

Demo: An LLM RAG Chatbot With LangChain and Neo4j

By the end of this tutorial, you’ll have a REST API that serves your LangChain chatbot. You’ll also have a Streamlit app that provides a nice chat interface to interact with your API:

Under the hood, the Streamlit app sends your messages to the chatbot API, and the chatbot generates and sends a response back to the Streamlit app, which displays it to the user.

You’ll get an in-depth overview of the data that your chatbot has access to later, but if you’re anxious to test it out, you can ask questions similar to the examples given in the sidebar:

Example questions can be found in the sidebar.

You’ll learn how to tackle each step, from understanding the business requirements and data to building the Streamlit app. There’s a lot to unpack in this tutorial, but don’t feel overwhelmed. You’ll get some background on each concept introduced, along with links to external sources that will deepen your understanding. Now, it’s time to dive in!

Prerequisites

This tutorial is best suited for intermediate Python developers who want to get hands-on experience creating custom chatbots. Aside from intermediate Python knowledge, you’ll benefit from having a high-level understanding of the following concepts and technologies:

• Large language models (LLMs) and prompt engineering
• Text embeddings and vector databases
• Graph databases and Neo4j
• The OpenAI developer ecosystem
• REST APIs and FastAPI
• Asynchronous programming
• Docker and Docker Compose

Nothing listed above is a hard prerequisite, so don’t worry if you don’t feel knowledgeable in any of them. You’ll be introduced to each concept and technology along the way. Besides, there’s no better way to learn these prerequisites than to implement them yourself in this tutorial.

Next up, you’ll get a brief project overview and begin learning about LangChain.

Project Overview

Throughout this tutorial, you’ll create a few directories that make up your final chatbot. Here’s a breakdown of each directory:

• langchain_intro/ will help you get familiar with LangChain and equip you with the tools that you need to build the chatbot you saw in the demo, and it won’t be included in your final chatbot. You’ll cover this in Step 1.

• data/ has the raw hospital system data stored as CSV files. You’ll explore this data in Step 2. In Step 3, you’ll move this data into a Neo4j database that your chatbot will query to answer questions.

• hospital_neo4j_etl/ contains a script that loads the raw data from data/ into your Neo4j database. You have to run this before building your chatbot, and you’ll learn everything you need to know about setting up a Neo4j instance in Step 3.

• chatbot_api/ is your FastAPI app that serves your chatbot as a REST endpoint, and it’s the core deliverable of this project. The chatbot_api/src/agents/ and chatbot_api/src/chains/ subdirectories contain the LangChain objects that comprise your chatbot. You’ll learn what agents and chains are later, but for now, just know that your chatbot is actually a LangChain agent composed of chains and functions.

• tests/ includes two scripts that test how fast your chatbot can answer a series of questions. This will give you a feel for how much time you save by making asynchronous requests to LLM providers like OpenAI.

• chatbot_frontend/ is your Streamlit app that interacts with the chatbot endpoint in chatbot_api/. This is the UI that you saw in the demo, and you’ll build this in Step 5.

All the environment variables needed to build and run your chatbot will be stored in a .env file. You’ll deploy the code in hospital_neo4j_etl/, chatbot_api, and chatbot_frontend as Docker containers that’ll be orchestrated with Docker Compose. If you want to experiment with the chatbot before going through the rest of this tutorial, then you can download the materials and follow the instructions in the README file to get things running:

Get Your Code: Click here to download the free source code for your LangChain chatbot.

With the project overview and prerequisites behind you, you’re ready to get started with the first step—getting familiar with LangChain.

Read the full article at https://realpython.com/build-llm-rag-chatbot-with-langchain/ »

[ Improve Your Python With 🐍 Python Tricks 💌 – Get a short & sweet Python Trick delivered to your inbox every couple of days. >> Click here to learn more and see examples ]

I had an interesting question from a reader of my PySide6 book, about how to handle dragging and dropping of widgets in a container showing the dragged widget as it is moved.

I'm interested in managing movement of a QWidget with mouse in a container. I've implemented the application with drag & drop, exchanging the position of buttons, but I want to show the motion of QPushButton, like what you see in Qt Designer. Dragging a widget should show the widget itself, not just the mouse pointer.

First, we'll implement the simple case which drags widgets without showing anything extra. Then we can extend it to answer the question. By the end of this quick tutorial we'll have a generic drag drop implementation which looks like the following.

Table of Contents

• Drag & Drop Widgets
• Visual Drag & Drop
• Generic Drag & Drop Container
• Adding a Visual Drop Target

Drag & Drop Widgets

We'll start with a simple application which creates a window using QWidget and places a series of QPushButton widgets into it.

You can substitute QPushButton for any other widget you like, e.g. QLabel. Any widget can have drag behavior implemented on it, although some input widgets will not work well as we capture the mouse events for the drag.

python from PySide6.QtWidgets import QApplication, QHBoxLayout, QPushButton, QWidget class Window(QWidget): def __init__(self): super().__init__() self.blayout = QHBoxLayout() for l in ["A", "B", "C", "D"]: btn = QPushButton(l) self.blayout.addWidget(btn) self.setLayout(self.blayout) app = QApplication([]) w = Window() w.show() app.exec()

If you run this you should see something like this.

The series of QPushButton widgets in a horizontal layout.

Here we're creating a window, but the Window widget is subclassed from QWidget, meaning you can add this widget to any other layout. See later for an example of a generic object sorting widget.

QPushButton objects aren't usually draggable, so to handle the mouse movements and initiate a drag we need to implement a subclass. We can add the following to the top of the file.

python from PySide6.QtCore import QMimeData, Qt from PySide6.QtGui import QDrag from PySide6.QtWidgets import QApplication, QHBoxLayout, QPushButton, QWidget class DragButton(QPushButton): def mouseMoveEvent(self, e): if e.buttons() == Qt.MouseButton.LeftButton: drag = QDrag(self) mime = QMimeData() drag.setMimeData(mime) drag.exec(Qt.DropAction.MoveAction)

We implement a mouseMoveEvent which accepts the single e parameter of the event. We check to see if the left mouse button is pressed on this event -- as it would be when dragging -- and then initiate a drag. To start a drag, we create a QDrag object, passing in self to give us access later to the widget that was dragged. We also must pass in mime data. This is used for including information about what is dragged, particularly for passing data between applications. However, as here, it is fine to leave this empty.

Finally, we initiate a drag by calling drag.exec_(Qt.MoveAction). As with dialogs exec_() starts a new event loop, blocking the main loop until the drag is complete. The parameter Qt.MoveAction tells the drag handler what type of operation is happening, so it can show the appropriate icon tip to the user.

You can update the main window code to use our new DragButton class as follows.

python class Window(QWidget): def __init__(self): super().__init__() self.setAcceptDrops(True) self.blayout = QHBoxLayout() for l in ["A", "B", "C", "D"]: btn = DragButton(l) self.blayout.addWidget(btn) self.setLayout(self.blayout) def dragEnterEvent(self, e): e.accept()

If you run the code now, you can drag the buttons, but you'll notice the drag is forbidden.

Dragging of the widget starts but is forbidden.

What's happening? The mouse movement is being detected by our DragButton object and the drag started, but the main window does not accept drag & drop.

To fix this we need to enable drops on the window and implement dragEnterEvent to actually accept them.

python class Window(QWidget): def __init__(self): super().__init__() self.setAcceptDrops(True) self.blayout = QHBoxLayout() for l in ["A", "B", "C", "D"]: btn = DragButton(l) self.blayout.addWidget(btn) self.setLayout(self.blayout) def dragEnterEvent(self, e): e.accept()

If you run this now, you'll see the drag is now accepted and you see the move icon. This indicates that the drag has started and been accepted by the window we're dragging onto. The icon shown is determined by the action we pass when calling drag.exec_().

Dragging of the widget starts and is accepted, showing a move icon.

Releasing the mouse button during a drag drop operation triggers a dropEvent on the widget you're currently hovering the mouse over (if it is configured to accept drops). In our case that's the window. To handle the move we need to implement the code to do this in our dropEvent method.

The drop event contains the position the mouse was at when the button was released & the drop triggered. We can use this to determine where to move the widget to.

To determine where to place the widget, we iterate over all the widgets in the layout, until we find one who's x position is greater than that of the mouse pointer. If so then when insert the widget directly to the left of this widget and exit the loop.

If we get to the end of the loop without finding a match, we must be dropping past the end of the existing items, so we increment n one further (in the else: block below).

python def dropEvent(self, e): pos = e.position() widget = e.source() self.blayout.removeWidget(widget) for n in range(self.blayout.count()): # Get the widget at each index in turn. w = self.blayout.itemAt(n).widget() if pos.x() < w.x(): # We didn't drag past this widget. # insert to the left of it. break else: # We aren't on the left hand side of any widget, # so we're at the end. Increment 1 to insert after. n += 1 self.blayout.insertWidget(n, widget) e.accept()

The effect of this is that if you drag 1 pixel past the start of another widget the drop will happen to the right of it, which is a bit confusing. To fix this we can adjust the cut off to use the middle of the widget using if pos.x() < w.x() + w.size().width() // 2: -- that is x + half of the width.

python def dropEvent(self, e): pos = e.position() widget = e.source() self.blayout.removeWidget(widget) for n in range(self.blayout.count()): # Get the widget at each index in turn. w = self.blayout.itemAt(n).widget() if pos.x() < w.x() + w.size().width() // 2: # We didn't drag past this widget. # insert to the left of it. break else: # We aren't on the left hand side of any widget, # so we're at the end. Increment 1 to insert after. n += 1 self.blayout.insertWidget(n, widget) e.accept()

The complete working drag-drop code is shown below.

python from PySide6.QtCore import QMimeData, Qt from PySide6.QtGui import QDrag from PySide6.QtWidgets import QApplication, QHBoxLayout, QPushButton, QWidget class DragButton(QPushButton): def mouseMoveEvent(self, e): if e.buttons() == Qt.MouseButton.LeftButton: drag = QDrag(self) mime = QMimeData() drag.setMimeData(mime) drag.exec(Qt.DropAction.MoveAction) class Window(QWidget): def __init__(self): super().__init__() self.setAcceptDrops(True) self.blayout = QHBoxLayout() for l in ["A", "B", "C", "D"]: btn = DragButton(l) self.blayout.addWidget(btn) self.setLayout(self.blayout) def dragEnterEvent(self, e): e.accept() def dropEvent(self, e): pos = e.position() widget = e.source() self.blayout.removeWidget(widget) for n in range(self.blayout.count()): # Get the widget at each index in turn. w = self.blayout.itemAt(n).widget() if pos.x() < w.x() + w.size().width() // 2: # We didn't drag past this widget. # insert to the left of it. break else: # We aren't on the left hand side of any widget, # so we're at the end. Increment 1 to insert after. n += 1 self.blayout.insertWidget(n, widget) e.accept() app = QApplication([]) w = Window() w.show() app.exec() Visual Drag & Drop

We now have a working drag & drop implementation. Next we'll move onto improving the UX by showing the drag visually. First we'll add support for showing the button being dragged next to the mouse point as it is dragged. That way the user knows exactly what it is they are dragging.

Qt's QDrag handler natively provides a mechanism for showing dragged objects which we can use. We can update our DragButton class to pass a pixmap image to QDrag and this will be displayed under the mouse pointer as the drag occurs. To show the widget, we just need to get a QPixmap of the widget we're dragging.

python from PySide6.QtCore import QMimeData, Qt from PySide6.QtGui import QDrag from PySide6.QtWidgets import QApplication, QHBoxLayout, QPushButton, QWidget class DragButton(QPushButton): def mouseMoveEvent(self, e): if e.buttons() == Qt.MouseButton.LeftButton: drag = QDrag(self) mime = QMimeData() drag.setMimeData(mime) drag.exec(Qt.DropAction.MoveAction)

To create the pixmap we create a QPixmap object passing in the size of the widget this event is fired on with self.size(). This creates an empty pixmap which we can then pass into self.render to render -- or draw -- the current widget onto it. That's it. Then we set the resulting pixmap on the drag object.

If you run the code with this modification you'll see something like the following --

Dragging of the widget showing the dragged widget.

Generic Drag & Drop Container

We now have a working drag and drop behavior implemented on our window. We can take this a step further and implement a generic drag drop widget which allows us to sort arbitrary objects. In the code below we've created a new widget DragWidget which can be added to any window.

You can add items -- instances of DragItem -- which you want to be sorted, as well as setting data on them. When items are re-ordered the new order is emitted as a signal orderChanged.

python from PySide6.QtCore import QMimeData, Qt, Signal from PySide6.QtGui import QDrag, QPixmap from PySide6.QtWidgets import ( QApplication, QHBoxLayout, QLabel, QMainWindow, QVBoxLayout, QWidget, ) class DragItem(QLabel): def __init__(self, *args, **kwargs): super().__init__(*args, **kwargs) self.setContentsMargins(25, 5, 25, 5) self.setAlignment(Qt.AlignmentFlag.AlignCenter) self.setStyleSheet("border: 1px solid black;") # Store data separately from display label, but use label for default. self.data = self.text() def set_data(self, data): self.data = data def mouseMoveEvent(self, e): if e.buttons() == Qt.MouseButton.LeftButton: drag = QDrag(self) mime = QMimeData() drag.setMimeData(mime) pixmap = QPixmap(self.size()) self.render(pixmap) drag.setPixmap(pixmap) drag.exec(Qt.DropAction.MoveAction) class DragWidget(QWidget): """ Generic list sorting handler. """ orderChanged = Signal(list) def __init__(self, *args, orientation=Qt.Orientation.Vertical, **kwargs): super().__init__() self.setAcceptDrops(True) # Store the orientation for drag checks later. self.orientation = orientation if self.orientation == Qt.Orientation.Vertical: self.blayout = QVBoxLayout() else: self.blayout = QHBoxLayout() self.setLayout(self.blayout) def dragEnterEvent(self, e): e.accept() def dropEvent(self, e): pos = e.position() widget = e.source() self.blayout.removeWidget(widget) for n in range(self.blayout.count()): # Get the widget at each index in turn. w = self.blayout.itemAt(n).widget() if self.orientation == Qt.Orientation.Vertical: # Drag drop vertically. drop_here = pos.y() < w.y() + w.size().height() // 2 else: # Drag drop horizontally. drop_here = pos.x() < w.x() + w.size().width() // 2 if drop_here: break else: # We aren't on the left hand/upper side of any widget, # so we're at the end. Increment 1 to insert after. n += 1 self.blayout.insertWidget(n, widget) self.orderChanged.emit(self.get_item_data()) e.accept() def add_item(self, item): self.blayout.addWidget(item) def get_item_data(self): data = [] for n in range(self.blayout.count()): # Get the widget at each index in turn. w = self.blayout.itemAt(n).widget() data.append(w.data) return data class MainWindow(QMainWindow): def __init__(self): super().__init__() self.drag = DragWidget(orientation=Qt.Orientation.Vertical) for n, l in enumerate(["A", "B", "C", "D"]): item = DragItem(l) item.set_data(n) # Store the data. self.drag.add_item(item) # Print out the changed order. self.drag.orderChanged.connect(print) container = QWidget() layout = QVBoxLayout() layout.addStretch(1) layout.addWidget(self.drag) layout.addStretch(1) container.setLayout(layout) self.setCentralWidget(container) app = QApplication([]) w = MainWindow() w.show() app.exec()

Generic drag-drop sorting in horizontal orientation.

You'll notice that when creating the item, you can set the label by passing it in as a parameter (just like for a normal QLabel which we've subclassed from). But you can also set a data value, which is the internal value of this item -- this is what will be emitted when the order changes, or if you call get_item_data yourself. This separates the visual representation from what is actually being sorted, meaning you can use this to sort anything not just strings.

In the example above we're passing in the enumerated index as the data, so dragging will output (via the print connected to orderChanged) something like:

python [1, 0, 2, 3] [1, 2, 0, 3] [1, 0, 2, 3] [1, 2, 0, 3]

If you remove the item.set_data(n) you'll see the labels emitted on changes.

python ['B', 'A', 'C', 'D'] ['B', 'C', 'A', 'D']

We've also implemented orientation onto the DragWidget using the Qt built in flags Qt.Orientation.Vertical or Qt.Orientation.Horizontal. This setting this allows you sort items either vertically or horizontally -- the calculations are handled for both directions.

Generic drag-drop sorting in vertical orientation.

Adding a Visual Drop Target

If you experiment with the drag-drop tool above you'll notice that it doesn't feel completely intuitive. When dragging you don't know where an item will be inserted until you drop it. If it ends up in the wrong place, you'll then need to pick it up and re-drop it again, using guesswork to get it right.

With a bit of practice you can get the hang of it, but it would be nicer to make the behavior immediately obvious for users. Many drag-drop interfaces solve this problem by showing a preview of where the item will be dropped while dragging -- either by showing the item in the place where it will be dropped, or showing some kind of placeholder.

In this final section we'll implement this type of drag and drop preview indicator.

The first step is to define our target indicator. This is just another label, which in our example is empty, with custom styles applied to make it have a solid "shadow" like background. This makes it obviously different to the items in the list, so it stands out as something distinct.

python from PySide6.QtCore import QMimeData, Qt, Signal from PySide6.QtGui import QDrag, QPixmap from PySide6.QtWidgets import ( QApplication, QHBoxLayout, QLabel, QMainWindow, QVBoxLayout, QWidget, ) class DragTargetIndicator(QLabel): def __init__(self, parent=None): super().__init__(parent) self.setContentsMargins(25, 5, 25, 5) self.setStyleSheet( "QLabel { background-color: #ccc; border: 1px solid black; }" )

We've copied the contents margins from the items in the list. If you change your list items, remember to also update the indicator dimensions to match.

The drag item is unchanged, but we need to implement some additional behavior on our DragWidget to add the target, control showing and moving it.

First we'll add the drag target indicator to the layout on our DragWidget. This is hidden to begin with, but will be shown during the drag.

python class DragWidget(QWidget): """ Generic list sorting handler. """ orderChanged = Signal(list) def __init__(self, *args, orientation=Qt.Orientation.Vertical, **kwargs): super().__init__() self.setAcceptDrops(True) # Store the orientation for drag checks later. self.orientation = orientation if self.orientation == Qt.Orientation.Vertical: self.blayout = QVBoxLayout() else: self.blayout = QHBoxLayout() # Add the drag target indicator. This is invisible by default, # we show it and move it around while the drag is active. self._drag_target_indicator = DragTargetIndicator() self.blayout.addWidget(self._drag_target_indicator) self._drag_target_indicator.hide() self.setLayout(self.blayout)

Next we modify the DragWidget.dragMoveEvent to show the drag target indicator. We show it by inserting it into the layout and then calling .show -- inserting a widget which is already in a layout will move it. We also hide the original item which is being dragged.

In the earlier examples we determined the position on drop by removing the widget being dragged, and then iterating over what is left. Because we now need to calculate the drop location before the drop, we take a different approach.

If we wanted to do it the same way, we'd need to remove the item on drag start, hold onto it and implement re-inserting at it's old position on drag fail. That's a lot of work.

Instead, the dragged item is left in place and hidden during move.

python def dragMoveEvent(self, e): # Find the correct location of the drop target, so we can move it there. index = self._find_drop_location(e) if index is not None: # Inserting moves the item if its alreaady in the layout. self.blayout.insertWidget(index, self._drag_target_indicator) # Hide the item being dragged. e.source().hide() # Show the target. self._drag_target_indicator.show() e.accept()

The method self._find_drop_location finds the index where the drag target will be shown (or the item dropped when the mouse released). We'll implement that next.

The calculation of the drop location follows the same pattern as before. We iterate over the items in the layout and calculate whether our mouse drop location is to the left of each widget. If it isn't to the left of any widget, we drop on the far right.

python def _find_drop_location(self, e): pos = e.position() spacing = self.blayout.spacing() / 2 for n in range(self.blayout.count()): # Get the widget at each index in turn. w = self.blayout.itemAt(n).widget() if self.orientation == Qt.Orientation.Vertical: # Drag drop vertically. drop_here = ( pos.y() >= w.y() - spacing and pos.y() <= w.y() + w.size().height() + spacing ) else: # Drag drop horizontally. drop_here = ( pos.x() >= w.x() - spacing and pos.x() <= w.x() + w.size().width() + spacing ) if drop_here: # Drop over this target. break return n

The drop location n is returned for use in the dragMoveEvent to place the drop target indicator.

Next wee need to update the get_item_data handler to ignore the drop target indicator. To do this we check w against self._drag_target_indicator and skip if it is the same. With this change the method will work as expected.

python def get_item_data(self): data = [] for n in range(self.blayout.count()): # Get the widget at each index in turn. w = self.blayout.itemAt(n).widget() if w != self._drag_target_indicator: # The target indicator has no data. data.append(w.data) return data

If you run the code a this point the drag behavior will work as expected. But if you drag the widget outside of the window and drop you'll notice a problem: the target indicator will stay in place, but dropping the item won't drop the item in that position (the drop will be cancelled).

To fix that we need to implement a dragLeaveEvent which hides the indicator.

python def dragLeaveEvent(self, e): self._drag_target_indicator.hide() e.accept()

With those changes, the drag-drop behavior should be working as intended. The complete code is shown below.

python from PySide6.QtCore import QMimeData, Qt, Signal from PySide6.QtGui import QDrag, QPixmap from PySide6.QtWidgets import ( QApplication, QHBoxLayout, QLabel, QMainWindow, QVBoxLayout, QWidget, ) class DragTargetIndicator(QLabel): def __init__(self, parent=None): super().__init__(parent) self.setContentsMargins(25, 5, 25, 5) self.setStyleSheet( "QLabel { background-color: #ccc; border: 1px solid black; }" ) class DragItem(QLabel): def __init__(self, *args, **kwargs): super().__init__(*args, **kwargs) self.setContentsMargins(25, 5, 25, 5) self.setAlignment(Qt.AlignmentFlag.AlignCenter) self.setStyleSheet("border: 1px solid black;") # Store data separately from display label, but use label for default. self.data = self.text() def set_data(self, data): self.data = data def mouseMoveEvent(self, e): if e.buttons() == Qt.MouseButton.LeftButton: drag = QDrag(self) mime = QMimeData() drag.setMimeData(mime) pixmap = QPixmap(self.size()) self.render(pixmap) drag.setPixmap(pixmap) drag.exec(Qt.DropAction.MoveAction) class DragWidget(QWidget): """ Generic list sorting handler. """ orderChanged = Signal(list) def __init__(self, *args, orientation=Qt.Orientation.Vertical, **kwargs): super().__init__() self.setAcceptDrops(True) # Store the orientation for drag checks later. self.orientation = orientation if self.orientation == Qt.Orientation.Vertical: self.blayout = QVBoxLayout() else: self.blayout = QHBoxLayout() # Add the drag target indicator. This is invisible by default, # we show it and move it around while the drag is active. self._drag_target_indicator = DragTargetIndicator() self.blayout.addWidget(self._drag_target_indicator) self._drag_target_indicator.hide() self.setLayout(self.blayout) def dragEnterEvent(self, e): e.accept() def dragLeaveEvent(self, e): self._drag_target_indicator.hide() e.accept() def dragMoveEvent(self, e): # Find the correct location of the drop target, so we can move it there. index = self._find_drop_location(e) if index is not None: # Inserting moves the item if its alreaady in the layout. self.blayout.insertWidget(index, self._drag_target_indicator) # Hide the item being dragged. e.source().hide() # Show the target. self._drag_target_indicator.show() e.accept() def dropEvent(self, e): widget = e.source() # Use drop target location for destination, then remove it. self._drag_target_indicator.hide() index = self.blayout.indexOf(self._drag_target_indicator) if index is not None: self.blayout.insertWidget(index, widget) self.orderChanged.emit(self.get_item_data()) widget.show() self.blayout.activate() e.accept() def _find_drop_location(self, e): pos = e.position() spacing = self.blayout.spacing() / 2 for n in range(self.blayout.count()): # Get the widget at each index in turn. w = self.blayout.itemAt(n).widget() if self.orientation == Qt.Orientation.Vertical: # Drag drop vertically. drop_here = ( pos.y() >= w.y() - spacing and pos.y() <= w.y() + w.size().height() + spacing ) else: # Drag drop horizontally. drop_here = ( pos.x() >= w.x() - spacing and pos.x() <= w.x() + w.size().width() + spacing ) if drop_here: # Drop over this target. break return n def add_item(self, item): self.blayout.addWidget(item) def get_item_data(self): data = [] for n in range(self.blayout.count()): # Get the widget at each index in turn. w = self.blayout.itemAt(n).widget() if w != self._drag_target_indicator: # The target indicator has no data. data.append(w.data) return data class MainWindow(QMainWindow): def __init__(self): super().__init__() self.drag = DragWidget(orientation=Qt.Orientation.Vertical) for n, l in enumerate(["A", "B", "C", "D"]): item = DragItem(l) item.set_data(n) # Store the data. self.drag.add_item(item) # Print out the changed order. self.drag.orderChanged.connect(print) container = QWidget() layout = QVBoxLayout() layout.addStretch(1) layout.addWidget(self.drag) layout.addStretch(1) container.setLayout(layout) self.setCentralWidget(container) app = QApplication([]) w = MainWindow() w.show() app.exec()

If you run this example on macOS you may notice that the widget drag preview (the QPixmap created on DragItem) is a bit blurry. On high-resolution screens you need to set the device pixel ratio and scale up the pixmap when you create it. Below is a modified DragItem class which does this.

Update DragItem to support high resolution screens.

python class DragItem(QLabel): def __init__(self, *args, **kwargs): super().__init__(*args, **kwargs) self.setContentsMargins(25, 5, 25, 5) self.setAlignment(Qt.AlignmentFlag.AlignCenter) self.setStyleSheet("border: 1px solid black;") # Store data separately from display label, but use label for default. self.data = self.text() def set_data(self, data): self.data = data def mouseMoveEvent(self, e): if e.buttons() == Qt.MouseButton.LeftButton: drag = QDrag(self) mime = QMimeData() drag.setMimeData(mime) # Render at x2 pixel ratio to avoid blur on Retina screens. pixmap = QPixmap(self.size().width() * 2, self.size().height() * 2) pixmap.setDevicePixelRatio(2) self.render(pixmap) drag.setPixmap(pixmap) drag.exec(Qt.DropAction.MoveAction)

That's it! We've created a generic drag-drop handled which can be added to any projects where you need to be able to reposition items within a list. You should feel free to experiment with the styling of the drag items and targets as this won't affect the behavior.

#619 – MARCH 5, 2024
View in Browser »

Duck Typing in Python: Writing Flexible and Decoupled Code

In this tutorial, you’ll learn about duck typing in Python. It’s a typing system based on objects’ behaviors rather than on inheritance. By taking advantage of duck typing, you can create flexible and decoupled sets of Python classes that you can use together or individually.
REAL PYTHON

Using IPython Jupyter Magic Commands

“IPython Jupyter Magic commands (e.g. lines in notebook cells starting with % or %%) can decorate a notebook cell, or line, to modify its behavior.” This article shows you how to define them and where they can be useful.
STEFAN KRAWCZYK

Posit Connect - Make Deployment the Easiest Part of Your Data Science Workflow

Data scientists use Posit Connect to securely share insights. Automate time-consuming tasks & distribute custom-built tools & solutions across teams. Publish data apps, docs, notebooks, & dashboards. Deploy models as APIs, & configure reports to run & get distributed on a custom schedule →
POSIT sponsor

Monkeying Around With Python: A Guide to Monkey Patching

Monkey patching is the practice of modifying live code. This article shows you how its done and why and when to use the practice.
KARISHMA SHUKLA

DjangoCon US Call for Proposals

DJANGOCON

White House Recommends Use of Python

PYTHON SOFTWARE FOUNDATION

JupyterLab 4.1 and Notebook 7.1 Released

JUPYTER

Articles & Tutorials Requests Maintainer Reflects on the Project After a Decade

One of the oldest active maintainers of the popular requests libraries reflects on the project’s good and bad parts over the last several years. He posits things that would improve the project and maintenance thereof. He also talks about what’s holding the project back right now. Associated Hacker News discussion.
IAN STAPLETON CORDASCO • Shared by nah

Improve the Architecture of Your Python Using import-linter

For large Python projects, managing dependency relationships between modules can be challenging. Using import-linter, this task can be made easier. This article provides a simple introduction to the import-linter tool and presents 6 practical ways to fix inappropriate dependencies.
PIGLEI • Shared by piglei

We’re Building the Future of Humanity Using Python No Other Language Will Give You Better Results

Today, you can build AI & data apps using only Python! This open-source Python end-to-end app builder helps you with it. Similar to Steamlit but designed to build production-ready apps, it offers some differences: scales as more users hit the app, can work with huge datasets, and is multi-user →
TAIPY sponsor

How to Read User Input From the Keyboard in Python

Reading user input from the keyboard is a valuable skill for a Python programmer, and you can create interactive and advanced programs that run on the terminal. In this tutorial, you’ll learn how to create robust user input programs, integrating error handling and multiple entries.
REAL PYTHON

Tracing System Calls in Python

This article shows you how to trace the system calls made when you run your Python program. It includes how you can use the Perfetto trace viewer to visualize the interactions.
MATT STUCHLIK

The Most Important Python News in 2023

Vita has put together a site using data from the PyCoder’s newsletter. The site itself is built using Python tools. If you missed something in 2023, you might find it here.
VITA MIDORI • Shared by Vita Midori

Django Login, Logout, Signup, Password Change and Reset

Learn how to implement a complete user authentication system in Django from scratch, consisting of login, logout, signup, password change, and password reset.
WILL VINCENT • Shared by Will Vincent

Why Python’s Integer Division Floors

This article on the Python History blog talks about why the decision was made to have integer division use floors, instead of truncation like C.
GUIDO VAN ROSSUM

Falsehoods Junior Developers Believe About Becoming Senior

This opinion piece by Vadim discusses how newer developers perceive what it means to be a senior developer, and how they’re often wrong.
VADIM KRAVCENKO

What’s in a Name?

An article about names in Python, and why they’re not the same as objects. The article discusses reference counts and namespaces.
STEPHEN GRUPPETTA • Shared by Stephen Gruppetta

Reduce, Reuse, Recycle: McDonald’s Reusable Workflows

This post on McDonald’s technology blog talks about how they take advantage of reusable workflows with GitHub Actions.
MICHAEL GORELIK

Popular git Config Options

This post covers some of the more popular options you can use when configuring git, and why you might choose them.
JULIA EVANS

Projects & Code logot: Test Whether Your Code Is Logging Correctly

GITHUB.COM/ETIANEN

hypofuzz: Adaptive Fuzzing of Hypothesis Tests

GITHUB.COM/ZAC-HD

cantok: Implementation of the “Cancellation Token” Pattern

GITHUB.COM/POMPONCHIK • Shared by Evgeniy Blinov

xonsh: Python-Powered, Cross-Platform, Unix-Gazing Shell

GITHUB.COM/XONSH

django-queryhunter: Find Your Expensive Queries

GITHUB.COM/PAULGILMARTIN • Shared by Paul

Events Eclipse Insights: How AI Is Transforming Solar Astronomy

March 5, 2024
MEETUP.COM • Shared by Laura Stephens

Weekly Real Python Office Hours Q&A (Virtual)

March 6, 2024
REALPYTHON.COM

Canberra Python Meetup

March 7, 2024
MEETUP.COM

Sydney Python User Group (SyPy)

March 7, 2024
SYPY.ORG

PyCon Pakistan 2024

March 9 to March 11, 2024
PYCON.PK

Django Girls CDO Workshop 2024

March 9 to March 10, 2024
DJANGOGIRLS.ORG

PyCon SK 2024

March 15 to March 18, 2024
PYCON.SK

Happy Pythoning!
This was PyCoder’s Weekly Issue #619.
View in Browser »

[ Subscribe to 🐍 PyCoder’s Weekly 💌 – Get the best Python news, articles, and tutorials delivered to your inbox once a week >> Click here to learn more ]

You’ve built a shiny Django app and want to release it to the public, but you’re worried about time-intensive tasks that are part of your app’s workflow. You don’t want your users to have a negative experience navigating your app. You can integrate Celery to help with that.

Celery is a distributed task queue for UNIX systems. It allows you to offload work from your Python app. Once you integrate Celery into your app, you can send time-intensive tasks to Celery’s task queue. That way, your web app can continue to respond quickly to users while Celery completes expensive operations asynchronously in the background.

In this video course, you’ll learn how to:

• Recognize effective use cases for Celery
• Differentiate between Celery beat and Celery workers
• Integrate Celery and Redis in a Django project
• Set up asynchronous tasks that run independently of your Django app
• Refactor Django code to run a task with Celery instead

[ Improve Your Python With 🐍 Python Tricks 💌 – Get a short & sweet Python Trick delivered to your inbox every couple of days. >> Click here to learn more and see examples ]

As an open-source container orchestration platform that automates deployment, scaling, and load balancing, Kubernetes offers unparalleled resilience and flexibility in the management of your Django applications.

Whether you’re launching a small-scale project or managing a complex application, Kubernetes provides a robust environment to enhance your Django application, ensuring it’s ready to meet the demands of modern web development.

By automating the deployment, scaling, and operation of containerized applications, Kubernetes (or K8s) provides numerous benefits for organizations in the fast-paced tech industry.

Whether you’re a Django developer looking to enhance your deployment skills or a Kubernetes enthusiast eager to explore Django integration, this guide has something for everyone.

The introduction to this tutorial explores the symbiotic relationship between Django and Kubernetes, enabling you to seamlessly containerize your web application, distribute workloads across clusters, and ensure high availability.

Django

The Django framework, a high-level Python web framework, stands as a beacon of efficiency and simplicity in the world of web development. Born out of the need to create rapid, robust, and maintainable web applications, Django has become a go-to choice for developers and organizations.

At its core, Django embraces the “batteries-included” philosophy, offering an extensive array of built-in tools, libraries, and conventions that facilitate the development process. It simplifies complex tasks like URL routing, database integration, and user authentication, allowing developers to focus on building their applications.

One of Django’s foremost benefits is its adherence to the “Don’t repeat yourself” (DRY) principle, reducing redundancy and enhancing code maintainability. It also follows the model-view-controller (MVC) architectural pattern, making applications structured and easy to manage.

Django also prioritizes security, making it less prone to common web vulnerabilities. It includes features like cross-site scripting (XSS) and cross-site request forgery (CSRF) protection out of the box. Offering a potent combination of speed, simplicity, and security, Django is an ideal choice for developers looking to create robust, feature-rich web applications with minimal effort.

Container orchestrators

Container orchestrators are essential tools for managing and automating the deployment, scaling, and operation of containerized applications. There are several container orchestrators available on the market, the most popular of which include:

1. Kubernetes, the top open-source container orchestration platform, offers a robust and adaptable environment for handling containerized applications. It automates tasks such as scaling, load balancing, and container health checks, with a broad extension ecosystem.

2. Docker Swarm is a container orchestration solution provided by Docker. Designed to be simple to set up and use, it’s a good choice for smaller applications or organizations already using Docker as it uses the same command-line interface and API as Docker.

3. OpenShift is an enterprise Kubernetes platform developed by Red Hat. It adds developer and operational tools on top of Kubernetes, simplifying the deployment and management of containerized applications.

4. Nomad, developed by HashiCorp, is a lightweight and user-friendly orchestrator capable of managing containers and non-containerized applications.

5. Apache Mesos is an open-source distributed system kernel, and DC/OS (data center operating system) is an enterprise-grade platform built on Mesos. DC/OS extends Mesos with additional features for managing and scaling containerized applications.

Software teams primarily work with managed platforms offered by well-known cloud providers such as AWS, Google Cloud Platform, and Azure. These cloud providers offer services like Amazon EKS, Google GKE, and Azure AKS, all of which are managed Kubernetes solutions. These services streamline the setup, expansion, and administration of Kubernetes clusters and seamlessly integrate with the respective cloud environments, ensuring efficient container orchestration and application deployment.

Creating a Django Application in PyCharm

In this tutorial, we’ll start by generating a minimal Django application. We’ll then containerize the application and, in the final step, deploy it to a local Kubernetes cluster using Docker Desktop.

If you’re new to working with the Django framework but are eager to create a Django application from scratch, read this blog post.

You can access the source code used in this tutorial here.

Let’s begin by creating a new Django application in PyCharm.

To create your project, launch PyCharm and click New Project. If PyCharm is already running, select File | New Project from the main menu.

Furnish essential details such as project name, location, and interpreter type, utilizing either venv or a custom environment.

Then, click Create.

PyCharm will do the heavy lifting by setting up your project and creating the virtual environment.

Gunicorn

Once the project has been created, install Gunicorn – a popular Python web server gateway interface (WSGI) HTTP server. A pre-fork worker model web server used to serve Python web applications, Gunicorn is often used in combination with web frameworks like Django, Flask, and others to deploy web applications and make them accessible over the internet.

The Python Packages tool window provides the quickest and easiest way to preview and install packages for the currently selected Python interpreter.

You can open the tool window via View | Tool Windows | Python Packages.

Psycopg 2

Psycopg 2 is a Python library used to connect to and interact with PostgreSQL databases. It provides a Python interface for working with PostgreSQL, one of the most popular open-source relational database management systems. Psycopg 2 allows Python developers to perform various database operations, such as inserting, updating, and retrieving data, as well as executing SQL queries, and managing database connections from within Python programs.

Before installing psycopg2, you need to install the system-level dependencies, brew install libpq for macOS, and apt-get install libpq-dev for Linux.

Reference: postgresql.org/docs/16/libpq.html

libpq is the client library for PostgreSQL. It’s a C library that provides the necessary functionality for client applications to connect to, interact with, and manage PostgreSQL database servers. 

After completing the particular modifications, update the section within settings.py related to DATABASES.

Always make sure to pass your secret credentials through environment variables.

STATIC_ROOT

In Django, STATIC_ROOT is a configuration setting used to specify the absolute file system path where collected static files will be stored when you run the collectstatic management command. Static files typically include CSS, JavaScript, images, and other assets used by your web application. The STATIC_ROOT setting is an essential part of serving static files in a production environment.

Set an environment variable for STATIC_ROOT at line 127. This variable will point to a file path that leads to a Kubernetes persistent volume. I’ll explain later how to configure this setup.

To collect static files, run the following command:

python manage.py collectstatic

This command will gather the static files and place them in the STATIC_ROOT directory. You can then serve these assets directly through an NGINX or Apache web server – a more efficient approach for production environments.

Dockerfile

A Dockerfile is a straightforward textual document containing directives for constructing Docker images.

1. FROM python:3.11: This line specifies the base image for the Docker image using the official Python 3.11 image from Docker Hub. The application will be built and run on top of this base image, which already has Python pre-installed.

2. ENV PYTHONUNBUFFERED 1: This line sets an environment variable PYTHONUNBUFFERED to 1. It’s often recommended to set this environment variable when running Python within Docker containers to ensure that Python doesn’t buffer the output. This helps in getting real-time logs and debugging information from the application.

3. WORKDIR /app: This line sets the working directory within the Docker container to /app. All subsequent commands will be executed in this directory.

4. COPY . /app: This line copies the contents of the current directory (the directory where the Dockerfile is located) to the /app directory within the container. This includes your application code and any files needed for the Docker image.

5. RUN pip install -r requirements.txt: This line runs the pip install command to install the Python dependencies listed in a requirements.txt file located in the /app directory. This is a common practice for Python applications as it allows you to manage the application’s dependencies.

6. EXPOSE 8000: This line informs Docker that the container listens on port 8000. It doesn’t actually publish the port. It’s a metadata declaration to indicate which ports the container may use.

7. CMD ["gunicorn", "django_kubernetes_tutorial.wsgi:application", "--bind", "0.0.0.0:8000"]: This line specifies the default command to run when the container starts. It uses Gunicorn to serve the Django application and binds Gunicorn to listen on all network interfaces (0.0.0.0) on port 8000 using the WSGI application defined in django_kubernetes_tutorial.wsgi:application.

DockerHub

Visit hub.docker.com and proceed to either log in or sign up on the platform.

Click on Create repository.

Next, provide the repository name and make the visibility public. If you’re working with sensitive or confidential information, set the visibility to Private.

Once the repository has been created, you need to build the docker image and then push the image to the registry.

Before executing the command, ensure that your requirements.txt file is current by running the following command:

pip freeze > requirements.txt

To construct an image, execute the following command: 

docker build -t mukulmantosh/django-kubernetes:1.0 .

docker build -t <USERNAME>/django-kubernetes:1.0 .

This command will vary depending on your specific circumstances, and you will need to utilize your personal username.

You then need to authenticate with Docker Hub to push the image to the registry.

Type the following command in the terminal:

docker login

Enter your username and password. Once they have been successfully authenticated, you can push the image by running:

docker push mukulmantosh/django-kubernetes:1.0 

docker push <USERNAME>/django-kubernetes:1.0 

Once the image has been successfully pushed, you can observe changes in Docker Hub.

If you don’t plan to push any more images to the registry, you can log out by running the following command:

docker logout

If you want to pull this image locally, visit hub.docker.com/r/mukulmantosh/django-kubernetes.

Kubernetes Configuration: Writing YAML Files

This section of the tutorial describes the deployment of applications to local Kubernetes clusters.

For this tutorial, we will be using Docker Desktop, but you could also use minkube or kind.

Namespaces

In Kubernetes, namespaces is a virtual partition within a cluster that is used to group and isolate resources and objects. It’s a way to create multiple virtual clusters within a single physical cluster. 

You can create and manage namespaces using kubectl, the Kubernetes command-line tool, or by defining them in YAML manifests when deploying resources. 

• If you’ve chosen Docker Desktop as your preferred platform for running Kubernetes, be sure to enable Kubernetes in the settings by clicking the Enable Kubernetes checkbox.

Run the following command in the terminal to create namespace:

kubectl create ns django-app

Deploying databases with K8s

To begin, let’s establish a PostgreSQL instance in our Kubernetes cluster on the local environment.

PersistentVolume

In Kubernetes, a persistent volume (PV) is a piece of storage in the cluster that an administrator has provisioned. By storing data in a way that is independent of a pod’s life cycle, PVs allow for a more decoupled and flexible management and abstraction of storage resources. This means data can persist even if the pod that uses it is deleted or rescheduled to a different node in the cluster.

Let’s create a persistent volume and name it pv.yml.

This YAML configuration defines a PersistentVolume resource named postgres-pv with a capacity of 1 gigabyte, mounted using the ReadWriteOnce access mode, and provided by a local path on the node’s file system located at /data/db. This PV can be used to provide persistent storage for pods that need access to a directory on the node’s file system and is suitable for applications like PostgreSQL or other stateful services that need persistent storage.

For production, we recommend either using cloud solutions like AWS RDS or Google CloudSQL, or use Kubernetes StatefulSets.

PersistentVolumeClaim

In Kubernetes, a PersistentVolumeClaim (PVC) is a resource object used by a pod to request a specific amount of storage with certain properties from a PV. PVCs act as a way for applications to claim storage resources without needing to know the details of the underlying storage infrastructure.

By creating and using PVCs, Kubernetes provides a way to dynamically allocate and manage storage resources for applications while abstracting the underlying storage infrastructure, making it easier to work with and manage stateful applications in containerized environments.

Let’s create a PVC and name it pvc.yml.

A PVC requests storage resources and is bound to a PV that provides the actual storage. 

This YAML configuration defines a PersistentVolumeClaim named postgres-pvc within the django-app namespace. It requests a gigabyte of storage with the ReadWriteOnce access mode, and it explicitly specifies the manual StorageClass. This PVC is intended to be bound to an existing PV with the name postgres-pv, effectively reserving that volume for use by pods within the django-app namespace that reference this PVC.

ConfigMap

In Kubernetes, a ConfigMap is an API object that is used to store configuration data in key-value pairs. ConfigMaps provides a way to decouple configuration data from the application code, making it easier to manage and update configurations without modifying and redeploying containers. They are especially useful for configuring applications, microservices, and other components within a Kubernetes cluster.

Let’s create a ConfigMap and name it cm.yml.

Although this tutorial uses ConfigMaps, for security considerations, it’s recommended to store sensitive credentials in Kubernetes Secrets or explore alternatives like Bitnami Sealed Secrets, AWS Parameter Store, or HashiCorp Vault.

Deployment

In Kubernetes, a Deployment is a resource object used to manage the deployment and scaling of applications. It’s part of the Kubernetes API group and provides a declarative way to define and manage the desired state of your application.

A Deployment is a higher-level Kubernetes resource used for managing and scaling application pods. 

This YAML configuration defines a Deployment named postgres in the django-app namespace. It deploys a single replica of a PostgreSQL database (version 16.0) with persistent storage. The database pod is labeled as app: postgresdb, and the storage is provided by a PVC named postgres-pvc. Configuration and credentials for the PostgreSQL container are provided via a ConfigMap named db-secret-credentials.

Service

In Kubernetes, a Service is a resource object used to expose a set of pods as a network service. Services enable network communication between different parts of your application running in a Kubernetes cluster and provide a stable endpoint for clients to access those parts. Services abstract the underlying network infrastructure, making it easier to connect and discover the components of your application.

This YAML configuration defines a NodePort Service named postgres-service within the django-app namespace. It exposes the PostgreSQL service running in pods labeled with “app: postgresdb” on port 5432 within the cluster. External clients can access the Service on any node’s IP address using port 30004. This Service provides a way to make the PostgreSQL database accessible from outside the Kubernetes cluster.

Creating YAML configurations for a Django application PersistentVolume

This YAML defines a PersistentVolume named staticfiles-pv with a 1 GB storage capacity, allowing multiple pods to read and write to it simultaneously. The storage is provided by a local host path located at /data/static. The Django static files will be stored at this location.

PersistentVolumeClaim

This YAML defines a PVC named staticfiles-pvc in the django-app namespace. It requests storage with a capacity of at least 1 GB from a PV with the “manual” StorageClass, and it specifies that it needs ReadWriteMany access. The claim explicitly binds to an existing PV named staticfiles-pv to satisfy its storage needs. This allows pods in the django-app namespace to use this PVC to access and use the storage provided by the associated PV.

ConfigMap

This YAML defines a ConfigMap named app-cm in the django-app namespace, and it contains various key-value pairs that store configuration data. This ConfigMap can be used by pods or other resources within the django-app namespace to access configuration settings, such as database connection information and static file paths.

Deployment

This YAML defines a Deployment named django-app-deploy in the django-app namespace. It creates one replica (pod) running a container with a specific Docker image and configuration. The pod is associated with two volumes, postgres-db-storage and staticfiles, which are backed by PVCs. The container is configured to use environment variables from a ConfigMap named app-cm and listens on port 8000. The volumes are mounted at specific paths within the container to provide access to database storage and static files. This Deployment is a common way to run a Django application using Kubernetes.

If you are interested in pulling images from a private registry, then read here. 

Service

The Service listens on port 8000 and directs incoming traffic to pods labeled with app: django-application. This is a common configuration for exposing and load-balancing web applications in a Kubernetes cluster where multiple instances of the same application are running. The Service ensures that traffic is distributed evenly among them.

NGINX

NGINX is a high-performance web and reverse proxy server known for its speed, reliability, and scalability. It efficiently handles web traffic, load balancing, and content delivery, making it a popular choice for serving websites and applications.

ConfigMap

This YAML defines a Kubernetes ConfigMap named nginx-cm in the django-app namespace, and it contains a key-value pair where the key is default.conf and the value is a multiline NGINX configuration file that proxies the request to the backend server. 

Deployment

This YAML defines a Deployment that creates and manages pods running an NGINX container with specific volumes and configurations. The Deployment ensures that one replica of this pod is always running in the django-app namespace. It also overrides the default NGINX configuration by replacing it with the nginx-cm ConfigMap.

Service

This YAML configuration creates a Kubernetes Service named nginx-service in the django-app namespace. It exposes pods with the label app:nginx on port 80 within the cluster and also makes the Service accessible on NodePort 30005 on each cluster node. This allows external traffic to reach the pods running the NGINX application via the NodePort service.

Managing batch workloads with Kubernetes jobs

In Kubernetes, a Job is a resource object that represents a single unit of work or a finite task. Jobs are designed to run tasks to completion, with a specified number of successful completions. 

Database migration

This YAML configuration defines a Kubernetes Job named django-db-migrations in the django-app namespace. The Job runs a container using a custom Docker image for Django migrations and mounts a PVC to provide storage for database-related files. If the Job fails, it can be retried up to 15 times, and it will retain its pod for 100 seconds after completion. This Job will create new tables in PostgreSQL.

Static files

This YAML configuration defines a Kubernetes Job named django-staticfiles in the django-app namespace. The Job runs a container using a custom Docker image for collecting static files for a Django application and mounts a PVC to provide storage for the static files. If the Job fails, it can be retried up to three times, and it will retain its pod for 100 seconds after completion for debugging purposes. This Job will copy the static files to the mountPath, which is /data/static.

Launching the Application

To launch the application, navigate to the k8s directory and execute the following command:

After deploying the application, use the following command to verify the status of running pods:

kubectl get pods -n django-app -w

Creating a superuser in Django

Once all your applications are up and running, create a superuser to login into the Django admin.

Run the following command to get the list of running pods:

kubectl get pods -n django-app

To get inside the container shell, run:

kubectl exec -it <POD_NAME> -n django-app -- sh

Then, run:

python manage.py createsuperuser

Once you’ve successfully created the superuser, open http://127.0.0.1:30005 in a browser. You will be directed to the default welcome page.

Then, head over to the Django admin via http://127.0.0.1:30005/admin.

Enter the username and password that you’ve just created. 

Once authenticated, you will be redirected to the Django administration page. 

If you try logging through localhost:30005/admin, you might receive a 403 Forbidden (CSRF) error.

You can resolve this in the settings.py file under CSRF_TRUSTED_ORIGINS.

CSRF_TRUSTED_ORIGINS is a setting in Django that is used to specify a list of trusted origins for cross-site request forgery (CSRF) protection. CSRF is a security vulnerability that can occur when an attacker tricks a user into unknowingly making an unwanted request to a web application. To prevent this, Django includes built-in CSRF protection.

CSRF_TRUSTED_ORIGINS allows you to define a list of origins (websites) from which CSRF-protected requests are accepted. Any request originating from an origin not included in this list will be considered potentially malicious and duly blocked.

This setting can be used to allow certain cross-origin requests to your Django application while maintaining security against CSRF attacks. It’s particularly helpful in scenarios where your application needs to interact with other web services or APIs that are hosted on different domains.

If you are using GUI tools like Kubernetes Dashboard, you can easily visualize your running pods, deployments, persistent volumes, etc.

Kubernetes Support in PyCharm 

PyCharm offers an enhanced editor and runtime support tailored for Kubernetes, bringing a host of features to streamline your Kubernetes management, including:

• Browsing cluster objects, extracting and editing their configurations, and describing them.
• Viewing events.
• Viewing and downloading pod logs.
• Attaching the pod console.
• Running shell in pods.
• Forwarding ports to a pod.
• Applying resource YAML configurations from the editor.
• Deleting resources from the cluster.
• Completion of ConfigMap and Secret entries from the cluster.
• Configuring paths to kubectl.
• Configuring custom kubeconfig files globally and per project.
• Switching contexts and namespaces.
• Using API schema (including CRD) from the active cluster to edit resource manifests.

Watch this video to learn more about working with Kubernetes in PyCharm Professional.

Try PyCharm for your Kubernetes tasks for free!

DOWNLOAD PYCHARM References

Already have a solid understanding of Kubernetes? Then, take the next step in your programming journey by exploring cloud solutions, and check out our tutorials on AWS EKS and Google Kubernetes Engine.

<strong>Topics covered in this episode:</strong><br> <ul> <li><a href="https://github.com/ajeetdsouza/zoxide"><strong>zoxide</strong></a></li> <li><a href="https://rahulpai.co.uk/smart-clis-with-typer.html"><strong>Smart CLIs with Typer</strong></a></li> <li><a href="https://twitter.com/samuel_colvin/status/1763339372361814187?s=12&t=RL7Nk7OAFSptvENxe1zIqA"><strong>Python recommended officially by the US Government</strong></a></li> <li><a href="https://www.blog.pythonlibrary.org/tag/tui/"><strong>Textual tutorials at Mouse vs Python</strong></a></li> <li><strong>Extras</strong></li> <li><strong>Joke</strong></li> </ul><a href='https://www.youtube.com/watch?v=AbCuv0wuzP0' style='font-weight: bold;'data-umami-event="Livestream-Past" data-umami-event-episode="373">Watch on YouTube</a><br> <p><strong>About the show</strong></p> <p>Sponsored by ScoutAPM: <a href="https://pythonbytes.fm/scout"><strong>pythonbytes.fm/scout</strong></a></p> <p><strong>Connect with the hosts</strong></p> <ul> <li>Michael: <a href="https://fosstodon.org/@mkennedy"><strong>@mkennedy@fosstodon.org</strong></a></li> <li>Brian: <a href="https://fosstodon.org/@brianokken"><strong>@brianokken@fosstodon.org</strong></a></li> <li>Show: <a href="https://fosstodon.org/@pythonbytes"><strong>@pythonbytes@fosstodon.org</strong></a></li> </ul> <p>Join us on YouTube at <a href="https://pythonbytes.fm/stream/live"><strong>pythonbytes.fm/live</strong></a> to be part of the audience. Usually Tuesdays at 11am PT. Older video versions available there too.</p> <p><strong>Michael #1:</strong> <a href="https://github.com/ajeetdsouza/zoxide"><strong>zoxide</strong></a></p> <ul> <li>zoxide is a smarter cd command, inspired by z and autojump.</li> <li>It remembers which directories you use most frequently, so you can "jump" to them in just a few keystrokes.</li> <li>zoxide works on all major shells and platforms.</li> </ul> <p><strong>Brian #2:</strong> <a href="https://rahulpai.co.uk/smart-clis-with-typer.html"><strong>Smart CLIs with Typer</strong></a></p> <ul> <li>Rahul Pai</li> <li>Lots of TILs here, even though I’ve been using Typer for years.</li> <li>Examples of <ul> <li>Auto-detection of arguments and types based on type hints</li> <li>Help text is a smidge clunkier</li> <li>Prompting for missing arguments </li> <li>Defaulting to an enviromental variable for missing args</li> <li>Print help if no args given</li> <li>Explicit app and subcommands with a comparison to argparse</li> <li>Reusable commands with result_callback </li> </ul></li> <li>Several topics covered in comparison with argparse</li> <li>See also <a href="https://pythontest.com/testing-argparse-apps/">Testing argparse Applications</a></li> </ul> <p><strong>Michael #3:</strong> <a href="https://twitter.com/samuel_colvin/status/1763339372361814187?s=12&t=RL7Nk7OAFSptvENxe1zIqA"><strong>Python recommended officially by the US Government</strong></a></p> <ul> <li>The US government explicitly recommends memory safe languages.</li> <li>Python is one of them</li> <li>The comparison to big tech by Samuel is interesting</li> </ul> <p><strong>Brian #4:</strong> <a href="https://www.blog.pythonlibrary.org/tag/tui/"><strong>Textual tutorials at Mouse vs Python</strong></a></p> <ul> <li>Mike Driscoll</li> <li>Most recently <a href="https://www.blog.pythonlibrary.org/2024/02/06/creating-a-modal-dialog-for-your-tuis-in-textual/">Creating a Modal Dialog For Your TUIs in Textual</a></li> <li>Textualize already has some pretty great documentation at <a href="https://textual.textualize.io">textual.textualize.io</a></li> <li>But it’s cool to see some different tutorials on it.</li> </ul> <p><strong>Extras</strong> </p> <p>Brian: </p> <ul> <li><a href="https://www.youtube.com/watch?v=_FdjW47Au30">Is UV the FUTURE of Python PACKAGING? 🐍📦</a> - Hynek <ul> <li>Nice context on how uv fits into all of the existing packaging challenges and some hope for the future.</li> </ul></li> <li>venmo feed is public by default</li> </ul> <p>Michael:</p> <ul> <li><a href="https://ngrok.com/blog-post/ngrok-python">ngrok Python SDK</a></li> <li><a href="https://talkpython.fm/episodes/show/451/djangonauts-ready-for-blast-off">Djangonauts on Talk Python</a></li> <li>Maybe <a href="https://python-bytes-static.nyc3.digitaloceanspaces.com/yellow-phone.jpg">just a new case</a> and <a href="https://support.apple.com/iphone/repair/battery-replacement">battery</a> for your phone?</li> </ul> <p><strong>Joke:</strong> <a href="https://workchronicles.com/narrator-they-did-not-in-fact-delegate-maintenance/">Ship it</a>!</p>

In this tutorial, we will delve into the powerful combination of Pandas and Tkinter through the PandasTable library. PandasTable provides a convenient way to display and interact with pandas DataFrames in a Tkinter GUI.

Prerequisites:

1. Basic knowledge of Python and Tkinter.
2. Some Familiarity with Pandas and DataFrames.

You will also need to install the pandas and pandastable libraries. Run the following commands to do so:

pip install pandas pip install pandastable Creating Interactive Data Tables with PandasTable in Tkinter

Let’s start by importing the required libraries for our tutorial.

import tkinter as tk from pandastable import Table, TableModel import pandas as pd

Create a class for your application and initialize the main Tkinter window.

class PandasTableApp: def __init__(self, root): self.frame = tk.Frame(root) self.frame.pack(padx=10, pady=10)

Next, we need to define a DataFrame with some sample data, which we will feature in our PandasTable.

# Create a sample DataFrame data = {'Name': ['John', 'Alice', 'Bob'], 'Age': [28, 24, 22], 'City': ['New York', 'San Francisco', 'Los Angeles']} df = pd.DataFrame(data)

Now, create a PandasTable widget and display the DataFrame within the Tkinter window. Remember to call the show function, as it is responsible for visually rendering (or updating) the PandasTable.

# Create a PandasTable self.table = Table(self.frame, dataframe=df, showtoolbar=True, showstatusbar=True) self.table.show()

Tip: Don’t ever put the root window as the PandasTable object’s parent (first parameter). You must use a container type object, such as a frame as the parent.

Complete the script with the Tkinter main loop.

if __name__ == "__main__": root = tk.Tk() app = PandasTableApp(root) root.mainloop()

This gives us the following output:

You can see the Toolbar on the right which comes with a whole bunch of cool features, such as saving the table and loading it. Various mutations you can apply, deleting rows, adding rows, zoom features, even some advanced plotting features, you name it!

Modifying the PandasTable directly

Most the functions are fairly intuitive, so there is little need to explain how to use them. Instead, there is another important aspect we will focus on explaining.

As a programmer, you need to know how to modify this table internally (through code). In the previous example, we initialized the table with a dataframe, but what if we want to make modifications (e.g. load another dataframe, or add a new record).

To do so, you can access the dataframe using the table.model.df attributes. The following code defines a function which modifies the table by adding a new row:

import tkinter as tk from pandastable import Table, TableModel import pandas as pd class PandasTableApp: def __init__(self, root): self.frame = tk.Frame(root) self.frame.pack(padx=10, pady=10) # Create a sample DataFrame data = {'Name': ['John', 'Alice', 'Bob'], 'Age': [28, 24, 22], 'City': ['New York', 'San Francisco', 'Los Angeles']} self.df = pd.DataFrame(data) # Create a PandasTable self.table = Table(self.frame, dataframe=self.df, showtoolbar=True, showstatusbar=True) self.table.show() self.modify_table() def modify_table(self): new_row = {'Name': 'Eve', 'Age': 25, 'City': 'Paris'} self.df = self.df._append(new_row, ignore_index=True) self.table.model.df = self.df self.table.redraw() if __name__ == "__main__": root = tk.Tk() app = PandasTableApp(root) root.mainloop()

Note that we used the redraw function after making the changes. This function is required for the changes to visually update.

As you can see, our new row has been added:

This marks the end of the Tkinter with PandasTable tutorial. Any suggestions or contributions for CodersLegacy are more than welcome. Questions regarding the tutorial content can be asked in the comments section below.

The post Exploring Data Tables in Tkinter with PandasTable appeared first on CodersLegacy.

This tutorial dives into the world of generating random IP addresses in Python. It’ll first walk you through the concept of IP addresses and describe the two main versions (IPv4 and IPv6). After that, it’ll equip you with the knowledge and code to create your random IP address generator. Side by side, it’ll highlight potential […]

The post Generate Random IP Address (IPv4/IPv6) in Python appeared first on TechBeamers.

Hey ya &#x1F44B; hope you are having a good start to 2024 ❤️

It&aposs been a dog’s age since we last spoke. In case you don’t know the reason for our hiatus: we took Elmo’s question of “How is everybody doing?” to its core and had to face the inner truths of our existence.

Luckily, soon the days got longer and the word news got worse so we had to unlock our doors and come out to organise the bestest of conferences!

We are now pumped to get things rolling and ready to cook up an awesome experience for EuroPython 2024 &#x1F680;

&#x1F1E8;&#x1F1FF;EuroPython 2024 - Prague Congress Centre 08-14 July

We are coming back to Prague! We loved last year so much that we decided to have EuroPython 2024 at the Prague Congress Centre again between the 8th and 14th of July, 2024. To stay up to date with the latest news, please visit our website.

We also encourage you to sign up to our monthly community newsletter.

Mr. Bean knows thingsCall for Proposals &#x1F40D;

The call for proposals for EuroPython 2024 is OPEN! &#x1F389;

This year we’re aiming for a similar schedule as last year, i.e. around 120 talks, more or less 16 tutorials, posters and special events.

• Tutorials/Workshops (8-9 July): will be hands-on 180 min sessions with 40-100 participants
• Talks (10-12 July) : 30 or 45 min length presentations of specific and general interest to the European Python community (including a dedicated PyData track).

We are looking for sessions of all levels: beginner, intermediate, and advanced.

You are also welcome to submit posters! They will be printed in large formats. This is a graphical way to showcase your research, project or technology. Posters are exhibited at the conference, can be read at any time by participants, and can be discussed face-to-face with their authors during the Poster Sessions (between July 10th and 12th).

No matter your level of Python or public speaking experience, EuroPython&aposs job is to help you bring yourself to our community so we all flourish and benefit from each other&aposs experience and contribution. &#x1F3C6;

The deadline for submission is March 6th, 2024 Anywhere on Earth.

We would love to see your proposals bubbling in there. Help us make 2024 the year of another incredible EuroPython!

For more information, have a look at https://ep2024.europython.eu/cfp.

Speaker&aposs Mentorship Programme &#x1F3A4;

The Speaker&aposs Mentorship Programme is back for EuroPython 2024!

We had a call for mentees and mentors last month and it was a huge success &#x1F680;So far, we have managed to match 28 speakers to diligent mentors.

On the 26th of February, we hosted an Ask me Anything session for all the people interested in submitting a proposal. Our programme team was there and answered all the questions raised by interested speakers. We clarified information about the Call for Proposals and shared knowledge about Financial Aid, amongst other info.

If you are curious and would like to see what was discussed, the session recording can be found on YouTube at: https://youtu.be/EiCfmf6QVIA

Call for ContributorsConference Organisers &#x1F4AA;

To the wonderful humans who signed up to help organise the EuroPython Conference itself, thank you! We are late in replying to everyone and we are thankful for your patience. We got caught between dengue fevers &#x1F99F; and carnivals &#x1F38A;.

The good news is that we are now back on track and will reach out to everyone this week.

We had a lot of applications this year, so a selection process was required. But fear nothing! In case you don’t get to work with the most fun team of all time, there is always next year. &#x1F31F;

We look forward to working together to make this conference an unforgettable experience for everyone involved &#x1F4BC;✨

Speaker’s mentors &#x1F38F;

For everyone who signed up to either mentor on the Speaker’s Mentorship Programme, a HUGE thank you! This would not be possible without your collaboration and work. We are so very proud to have you around learning and sharing and strengthening the community.

We truly hope you take advantage of the opportunity and develop the skills you’re looking for. After all, we believe the best way to learn is to teach. &#x1F4DA;✨

Proposal Reviewers &#x1F4D4;

We also announced the Call for Proposal Reviewers. These awesome volunteers are the people who review the proposal’s submissions and vote on the ones which they think are more suitable for making up the conference&aposs programme.

This is very crucial work as it plays a significant part in shaping the EuroPython 2024 schedule!

A massive thank you to everyone who has filled the form to help. You will get a cucumber lollipop as a sign of our affection. &#x1F36D;

We will contact you by the end of the Call for Proposals to coordinate all the fun stuff. Please, keep an eye out for our email this month so we can start the labour. ⚒️

Fáilte Ireland Award &#x1F3C6;

The 2022 edition of the EuroPython Conference (EPC) was in Dublin, Ireland. More old news? You bet! But this time it is relevant because in November 2023, the 21st edition of the EPC was awarded a Conference Ambassador Recognition Award from Fáilte Ireland, the National Tourism Development Authority for the country.

The evening was fantastic and a delightful way to acknowledge the people and businesses who have hosted conference events on the little Emerald Island. This is our first prize. We’re feeling proud and happy and wanted to share the news! &#x1F947;

One of our members wrote more about the experience on LinkedIn.

Laís Carvalho (EuroPython) and Nicolas Laurance (Python Ireland) hold the Irish-sized whiskey glass awarded &#x1F943; from Failte IrelandEPS Board

We have a new Board for 2023-2024.

If you want to learn the names of the new board members, head over to the article on our website: https://www.europython-society.org/eps-board-2023-2024/

TL;DR: We hope to do a fine job this year and help the European Python community thrive even more!

If you want to talk to us about anything, give feedback, or ask for a partner to count the stars beside you, shoot us an email at board@europython.eu.

Upcoming Events in Europe

Here are some Python events happening in Europe in the near future.

PyCon Slovakia: March 15-17 2024

PyCon SK will happen in the wonderful city of Bratislava! The conference is organised by the civic association SPy, which focuses on the promotion and dissemination of the Python programming language and other open-source technologies and ideas.

Check out their programme here: https://2024.pycon.sk/en/speakers/index.html. More information can be found on their website: https://2024.pycon.sk/en/index.html

PyCon DE & PyData Berlin: April 22-24 2024

Immerse yourself in three days of Python and PyData excellence at our community-driven conference in the vibrant heart of Berlin. From workshops to live keynote sessions, connect with fellow enthusiasts and experts alike! Join fellow Pythonistas at the iconic BCC venue at Alexanderplatz where we actually hosted EuroPython 2014! Check out their website for more info: https://2024.pycon.de/

PyCon Italy: May 22-25 2024

PyCon Italia 2024 will happen in Florence. The birthplace of Renaissance will receive a wave of Pythonistas looking to geek out this year. The schedule is online and you can check it out at their cutely animated website ( https://2024.pycon.it/). Beginners will have a special treat by having a full day of activities on May 22nd. Starting with Workshops about Python, Data Science, and Public Speaking.

It’s time to get tickets!

GeoPython: May 27-29 2024

GeoPython 2024 will happen in Basel, Switzerland. Focused on exploring the fascinating fusion of Python programming and the boundless world of Geo, the 9th edition of GeoPython has already published a preliminary schedule (here: https://2024.geopython.net/schedule).

For more information about GeoPython 2024, you can visit their website here: https://2024.geopython.net/

Djangocon.eu: June 5-9 2024

DjangoCon Europe 2024 will happen in Vigo, Spain. Organized by Django practitioners from all levels, the 16th edition of the Conference will be hosted in the beautiful Galician city, famous for its amazing food & the Illas Atlanticas.

You can check more information about Django Con Europe at their lovely website: https://2024.djangocon.eu/

Py.Jokespip install pyjokesimport pyjokesprint(pyjokes.get_joke()) Child: Dad, why does the Sun rise in the East and set in the West? Dad: Son, it&aposs working, don&apost touch it! That&aposs all, folks! &#x1F3C1;

Thanks for reading along.

We will have a regular monthly appearance in your inbox from now on. We are happy to tailor our future editions to accommodate what you&aposd like to see here. Influence what gets to your inbox by dropping us a line at communications@europython.eu

With joy and excitement,

EuroPython 2024 Team &#x1F917;

Python has something called wildcard imports, which look like from module import *. This type of import allows you to quickly get all the objects from a module into your namespace. However, using this import on a package can be confusing because it’s not clear what you want to import: subpackages, modules, objects? Python has the __all__ variable to work around this issue.

The __all__ variable is a list of strings where each string represents the name of a variable, function, class, or module that you want to expose to wildcard imports.

In this tutorial, you’ll:

• Understand wildcard imports in Python
• Use __all__ to control the modules that you expose to wildcard imports
• Control the names that you expose in modules and packages
• Explore other use cases of the __all__ variable
• Learn some benefits and best practices of using __all__

To get the most out of this tutorial, you should be familiar with a few Python concepts, including modules and packages, and the import system.

Get Your Code: Click here to download the free sample code that shows you how to use Python’s __all__ attribute.

Importing Objects in Python

When creating a Python project or application, you’ll need a way to access code from the standard library or third-party libraries. You’ll also need to access your own code from the multiple files that may make up your project. Python’s import system is the mechanism that allows you to do this.

The import system lets you get objects in different ways. You can use:

• Explicit imports
• Wildcard imports

In the following sections, you’ll learn the basics of both strategies. You’ll learn about the different syntax that you can use in each case and the result of running an import statement.

Explicit Imports

In Python, when you need to get a specific object from a module or a particular module from a package, you can use an explicit import statement. This type of statement allows you to bring the target object to your current namespace so that you can use the object in your code.

To import a module by its name, you can use the following syntax:

Python import module [as name] Copied!

This statement allows you to import a module by its name. The module must be listed in Python’s import path, which is a list of locations where the path based finder searches when you run an import.

The part of the syntax that’s enclosed in square brackets is optional and allows you to create an alias of the imported name. This practice can help you avoid name collisions in your code.

As an example, say that you have the following module:

Python calculations.py def add(a, b): return float(a + b) def subtract(a, b): return float(a - b) def multiply(a, b): return float(a * b) def divide(a, b): return float(a / b) Copied!

This sample module provides functions that allow you to perform basic calculations. The containing module is called calculations.py. To import this module and use the functions in your code, go ahead and start a REPL session in the same directory where you saved the file.

Then run the following code:

Python >>> import calculations >>> calculations.add(2, 4) 6.0 >>> calculations.subtract(8, 4) 4.0 >>> calculations.multiply(5, 2) 10.0 >>> calculations.divide(12, 2) 6.0 Copied!

The import statement at the beginning of this code snippet brings the module name to your current namespace. To use the functions or any other object from calculations, you need to use fully qualified names with the dot notation.

Note: You can create an alias of calculations using the following syntax:

Python import calculations as calc Copied!

This practice allows you to avoid name clashes in your code. In some contexts, it’s also common practice to reduce the number of characters to type when using qualified names.

For example, if you’re familiar with libraries like NumPy and pandas, then you’ll know that it’s common to use the following imports:

Python import numpy as np import pandas as pd Copied!

Using shorter aliases when you import modules facilitates using their content by taking advantage of qualified names.

You can also use a similar syntax to import a Python package:

Read the full article at https://realpython.com/python-all-attribute/ »

[ Improve Your Python With 🐍 Python Tricks 💌 – Get a short & sweet Python Trick delivered to your inbox every couple of days. >> Click here to learn more and see examples ]