Planet Python
Zato Blog: API Testing in Pure English
Do you have 20 minutes to learn how to test APIs in pure English, without any programming needed?
Great, the API testing tutorial is here.
Right after you complete it, you'll be able to write API tests as the one below.
Next steps:➤ Read about how to use Python to build and integrate enterprise APIs that your tests will cover
➤ Python API integration tutorial
➤ Python Integration platform as a Service (iPaaS)
➤ What is an Enterprise Service Bus (ESB)? What is SOA?
Julien Tayon: Bidirectionnal python/tk by talking to tk interpreter back and forth
But what fun is it?
It's funnier if the tcl/tk interperpreter talks back to python :D as an hommage to the 25 years awaited TK9 versions that solves a lot of unicode trouble.
Beforehand, to make sense to the code a little warning is required : this code targets only POSIX environment and loses portability because I chose to use a way that is not the « one best way » for enabling bidirectionnal talks. By using os.set_blocking(p.stdout.fileno(), False) we can have portable non blocking IO, which means this trick has been tested on linux, freeBSD and windows successfully.
First and foremost, the Popen now use p.stdout=PIPE enabling the channel on which tcl will talk. As a joke puts/gets are named from tcl/tk functions and are used in python to push/get strings from tcl.
Instead of using multithreading having one thread listen to the output and putting the events in a local queue that the main thread will consume I chose the funniest technique of setting tcl/tk output non blocking which does not work on windows. This is the fnctl part of the code.
Then, I chose not to parse the output of tcl/tk but exec it, making tcl/tk actually push python commands back to python. That's the exec part of the code.
For this I needed an excuse : so I added buttons to change minutes/hours back and forth.
That's the moment we all are gonna agree that tcl/tk that tcl/tk biggest sin is its default look. Don't worry, next part is about using themes.
Compared to the first post, changes are minimal :D This is how it should look : And here is the code, largely still below 100 sloc (by 3 lines). #!/usr/bin/env python from subprocess import Popen, PIPE from time import sleep, time, localtime # import fcntl import os # let's talk to tk/tcl directly through p.stdin p = Popen(['wish'], stdin=PIPE, stdout=PIPE) # best non portable answer on stackoverflow #fd = p.stdout.fileno() #flag = fcntl.fcntl(fd, fcntl.F_GETFL) #fcntl.fcntl(fd, fcntl.F_SETFL, flag | os.O_NONBLOCK) # ^-- this 3 lines can be replaced with this one liner --v # portable non blocking IO os.set_blocking(p.stdout.fileno(), False) def puts(s): for l in s.split("\n"): p.stdin.write((l + "\n").encode()) p.stdin.flush() def gets(): ret=p.stdout.read() p.stdout.flush() return ret WIDTH=HEIGHT=400 puts(f""" canvas .c -width {WIDTH} -height {HEIGHT} -bg white pack .c . configure -background white ttk::button .ba -command {{ puts ch-=1 }} -text << pack .ba -side left -anchor w ttk::button .bb -command {{ puts cm-=1 }} -text < pack .bb -side left -anchor w ttk::button .bc -command {{ puts ch+=1 }} -text >> pack .bc -side right -anchor e ttk::button .bd -command {{ puts cm+=1 }} -text > pack .bd -side right -anchor e """) # Constant are CAPitalized in python by convention from cmath import pi as PI, e as E ORIG=complex(WIDTH/2, HEIGHT/2) # correcting python notations j => I I = complex("j") rad_per_sec = 2.0 * PI /60.0 rad_per_min = rad_per_sec / 60 rad_per_hour = rad_per_min / 12 origin_vector_hand = WIDTH/2 * I size_of_sec_hand = .9 size_of_min_hand = .8 size_of_hour_hand = .65 rot_sec = lambda sec : -E ** (I * sec * rad_per_sec ) rot_min = lambda min : -E ** (I * min * rad_per_min ) rot_hour = lambda hour : -E ** (I * hour * rad_per_hour ) to_real = lambda c1,c2 : "%f %f %f %f" % (c1.real,c1.imag,c2.real, c2.imag) for n in range(60): direction= origin_vector_hand * rot_sec(n) start=.9 if n%5 else .85 puts(f".c create line {to_real(ORIG+start*direction,ORIG+.95*direction)}") sleep(.01) diff_offset_in_sec = (time() % (24*3600)) - \ localtime()[3]*3600 -localtime()[4] * 60.0 \ - localtime()[5] ch=cm=0 while True: # eventually parsing tcl output back = gets() # trying is more concise than checking try: back = back.decode() exec(back) except Exception as e: pass t = time() s= t%60 m = m_in_sec = t%(60 * 60) + cm * 60 h = h_in_sec = (t- diff_offset_in_sec)%(24*60*60) + ch * 3600 + cm * 60 puts(".c delete second") puts(".c delete minute") puts(".c delete hour") c0=ORIG+ -.1 * origin_vector_hand * rot_sec(s) c1=ORIG+ size_of_sec_hand * origin_vector_hand * rot_sec(s) puts( f".c create line {to_real(c0,c1)} -tag second -fill blue -smooth true") c1=ORIG+size_of_min_hand * origin_vector_hand * rot_min(m) puts(f".c create line {to_real(ORIG, c1)} -tag minute -fill green -smooth true") c1=ORIG+size_of_hour_hand * origin_vector_hand * rot_hour(h) puts(f".c create line {to_real(ORIG,c1)} -tag hour -fill red -smooth true") puts("flush stdout") sleep(.1)
Some history about this code.
I have been mentored in a physical lab where we where doing the pipe, fork, dup2 dance to tcl/tk from C to give a nice output to our simulations so we could control our instuition was right and could extract pictures for the publications. This is a trick that is almost as new as my arteries.
My mentor used to say : we are not coders, we need stuff to work fast and neither get drowned in computer complexity or endless quest for « the one best way » nor being drowned in bugs, we aim for the Keep It Simple Stupid Ways.
Hence, this is a Keep It Simple Stupid approach that I revived for the sake of seeing if it was still robust after 35 years without using it.
Well, if it's robust and it's working: it ain't stupid even if it isn't the « one best idiomatic way ». :P
Talk Python to Me: #479: Designing Effective Load Tests for Your Python App
Hugo van Kemenade: Python Core Developer Sprint 2024
🐍🏃The week before last was the annual Python Core Dev Sprint, graciously hosted by Meta in Bellevue, WA!
The idea: bring a bunch of Python core team members, triagers, and special guests to the same room for a week. It's hugely beneficial and productive, we held many in-depth discussions that just don't happen when we're all remote and async, and got to work on many different things together.
The sprint room
During the week, I reviewed 39 PRs, created 15, merged 10, updated 4, and closed 2 issues.
Monday highlightsAs release manager for Python 3.14, I discussed with Brett Cannon one of his project ideas which will come after lock files, and after the next big one.
Also as RM, discussed with Russell Keith-Magee, Ned Deily, Łukasz Langa and Thomas Wouters about including official binaries for iOS and Android, which wandered into ideas about security releases.
I did some maintenance of our PyPI projects, adding PEP 740 attestations, support for the new Python 3.13 and dropping support for the very-nearly-EOL 3.8.
Tuesday highlightsStarted investigating slow doctest on 3.13+ with Alex Waygood, who on Wednesday narrowed it down to a problem with the new incremental garbage collector, which would go on to be reverted by Friday and result in Python 3.13's Monday release to be postponed and replaced with an extra release candidate. Not ideal, but much better to discover these things before the big release.
We had a Q&A session with the Steering Council: Barry Warsaw, Emily Morehouse, Gregory P. Smith, Pablo Galindo Salgado and Thomas.
The Python Steering Council
Proofread Guido van Rossum's STAR voting proposal for electing future steering councils.
Discussed with Eric Snow his novel method for displaying many code samples in a table, using <details> disclosures to prevent the table being too wide. Looks like a good solution!
Wednesday highlightsI applied the finishing touches to PEP 2026 (Calendar versioning for Python) and Barry gave it a final review. Ready for submission!
Seth Larson, the PSF Security Developer-in-Residence, wasn't at the sprint but we discussed our plan to stop providing GPG signatures for CPython and rely on SigStore instead. Expect a PEP soon!
Also not at the sprint, I recommended PSF Infrastructure Engineer Jacob Coffee as a CPython triager. Welcome aboard!
The whole room discussed including static type annotations in CPython.
We had a Q&A session with two of the three Developers-in-Residence, Łukasz and Petr Viktorin.
Q&A with Łukasz and Petr
Discussed expanding the voter pool for Steering Council elections with Mariatta, Greg and Thomas.
Larry Hastings handed out, in return for oohs and aahs, some nice P.C.D.S. 2024 stickers he generously designed and printed up for us. Thanks!
PCDS 2024 stickers by Larry Thursday highlights
On the 26th September, at 10:26 Bellevue time (20:26 Helsinki time), I submitted PEP 2026 to the Steering Council!🤞
Brett discussed whether we should update PEP 387 to prefer 5 year deprecations instead of 2 years.
Brandt Bucher gave us all an update on the progress of the Just-in-Time (JIT) compiler ("we went from 0% slower to 0% faster!") and we discussed plans for Python 3.14.
Because I couldn't attend Thursday's Helsinki Python meetup due to being at another kind of Python meetup on the other side of the world, I gave the famous HelPy quiz to the assembled core devs. Unsurprisingly they did pretty well, but the most incorrect answer was a pleasant surprise: we've had ~400 not ~80 new contributors to Python 3.13!
Pablo performed card tricks!
Magic from Pablo
Meta took us out for a delicious dinner at a local fish restaurant. Thank you!
Friday highlightsMariatta presented ideas to Jelle Zijlstra, Petr, Russell and me about to use modern tools to create a modern, interactive tutorial.
Also during the week, continued work with Adam Turner on improving the docs.python.org build. Adam wasn't at the sprint, so tag-teamed PR reviews overnight. After much work straddling many teams, projects and repos, we've got the full HTML build loop for 13 languages × 3 versions down from over 40 hours to just under 9 hours, with more improvements coming.
Made a demo of the CPython docs using the PyData Sphinx Theme.
Along with around 25 others, I was on Łukasz and Pablo's core.py podcast.
Łukasz and Pablo in their ad-hoc podcast studio in a Meta meeting room
Itamar gave us cake for the podcast's first birthday!
cake.py. Photo by Itamar Oren. Thank you
It was a hugely productive week, big thanks to Itamar Oren and Meta for organising and hosting!
See also Mariatta's excellent blog posts, and I recommend the core.py podcast with short interviews with some 25 attendees! Łukasz and Pablo were also guests on the Changelog podcast during the sprint.
Header photo by Itamar Oren
Julien Tayon: Simpler than PySimpleGUI and python tkinter: talking directly to tcl/tk
Even though FreeSimpleGUI is a good approach to simpler tk/tcl binding in python : we can do better, especially if your linux distro split the python package and you don't have access to tkinter. I am watching you debian, splitting ALL packages and breaking them including ... tcl from tk (what a crime).
Under debian this stunt requires you to install tk : apt install tk8.6
How hard is it when tcl/tk is installed to do GUI programming in tk without tkinter?
Well, it's fairly easy, first and foremost coders are coders, they code in whatever language. If you do code in one language you can't do docker, simple sysadmin tasks (shell), compile C extensions (make syntax) or web applications (HTML + javascript). Hence, learning more than one language is part of doing python applications.
How hard is coding in tcl/tk natively?
Fairly easy: its difficulty is a little above lua, and way below perl thanks to the absence of references.
What value tcl have ?
It's still used in domain specific field such as VLSI (Very Large Scale Integration of electronic component).
So here is the plan : we are gonna do an application that do the math in python which is perfect for expressing complex math in more readable way than tcl and push all the GUI to the tk interpreter (albeit wish).
We are gonna make a simple wall clock ... and all tcl commands are injected to tcl through the puts function.
#!/usr/bin/env python from subprocess import Popen, PIPE from time import sleep, time, localtime # let's talk to tk/tcl directly through p.stdin p = Popen(['wish'], stdin=PIPE) def puts(s): for l in s.split("\n"): p.stdin.write((l + "\n").encode()) p.stdin.flush() WIDTH=HEIGHT=400 puts(f""" canvas .c -width {WIDTH} -height {HEIGHT} -bg white pack .c . configure -background "white" """) # Constant are CAPitalized in python by convention from cmath import pi as PI, e as E ORIG=complex(WIDTH/2, HEIGHT/2) # correcting python notations j => I I = complex("j") rad_per_sec = 2.0 * PI /60.0 rad_per_min = rad_per_sec / 60 rad_per_hour = rad_per_min / 12 origin_vector_hand = WIDTH/2 * I size_of_sec_hand = .9 size_of_min_hand = .8 size_of_hour_hand = .65 rot_sec = lambda sec : -E ** (I * sec * rad_per_sec ) rot_min = lambda min : -E ** (I * min * rad_per_min ) rot_hour = lambda hour : -E ** (I * hour * rad_per_hour ) to_real = lambda c1,c2 : "%f %f %f %f" % (c1.real,c1.imag,c2.real, c2.imag) for n in range(60): direction= origin_vector_hand * rot_sec(n) start=.9 if n%5 else .85 puts(f".c create line {to_real(ORIG+start*direction,ORIG+.95*direction)}") sleep(.1) diff_offset_in_sec = (time() % (24*3600)) - \ localtime()[3]*3600 -localtime()[4] * 60.0 \ - localtime()[5] while True: t = time() s= t%60 m = m_in_sec = t%(60 * 60) h = h_in_sec = (t- diff_offset_in_sec)%(24*60*60) puts(".c delete second") puts(".c delete minute") puts(".c delete hour") c0=ORIG+ -.1 * origin_vector_hand * rot_sec(s) c1=ORIG+ size_of_sec_hand * origin_vector_hand * rot_sec(s) puts( f".c create line {to_real(c0,c1)} -tag second -fill blue -smooth true") c1=ORIG+size_of_min_hand * origin_vector_hand * rot_min(m) puts(f".c create line {to_real(ORIG, c1)} -tag minute -fill green -smooth true") c1=ORIG+size_of_hour_hand * origin_vector_hand * rot_hour(h) puts(f".c create line {to_real(ORIG,c1)} -tag hour -fill red -smooth true") sleep(.1) Next time as a bonus, I'm gonna do something tkinter cannot do: bidirectional communications (REP/REQ pattern).
Mariatta: Python Core Sprint 2024: Day 5
I reviewed some issues that came to the CPython repo. There were a few interesting tickets related to the datetime module. These issues were discovered by Hypothesis, a property-based testing tool for Python. I’ve been hearing a lot about Hypothesis, but never really used it in production or at work. I watched a talk about it at PyCon US many years ago, and I even had ice cream selfie with Zac who maintains Hypothesis. Anyway, I’ve just been interested in learning more about Hypothesis and how it could solve issues not caught by other testing methods, and I think this is one of the perks of contributing to open source: getting exposed to things you don’t normally use at work, and I think it’s a great way to learn new things.
Julien Tayon: PySimpleGUI : surviving the rug pull of licence part I
The main advantage was about not having to remember in wich order to make the pack and having to do the mainloop call. It was not a revolution, just a simple, elegant evolution, hence I was still feeling in control.
However, the projet made a jerk move by relicensing in full proprietary license that requires a key to work functionnaly.
I will not discuss this since the point have been made clearly on python mailing list.
Luckily I want to raise 2 points :
- we have been numerous coders to fork the project for doing pull requests
- it higlights once more the danger of too much dependencies
If you have a working copy of the repository
Well, you can still install a past version of pysimpleGUI, but unless you can do pip install git+https://github.com/jul/PySimpleGUI#egg=pysimpleGUI
Pro: if that version suited you, your old code will work
Con: there will be no update for the bugs and it is pretty much a no-go.
Expect free alternative
One of the power of free software is the power to fork, and some coders already forked in a « free forever » version of pysimpleGUI.
One of this fork is : Free Simple GUI.
Pro: migration is as simple as : pip install FreeSimpleGUI and then in the source : - import PySimpleGUI as sg + import FreeSimpleGUI as sg
Con: a project is as useful as the capacity of the community to keep up with the job of solving issues and the strength of the community to follow up.
Migrating to tkinter
This will be covered in the week to come by translating some examples to real life migration by myself.
Since tkinter has improved a lot and his a pillar of python distribution when it is not broken by debian, it is fairly easy.
Pro: diminises the need for a dependency and empower you with the poweful concept of tk such as variables binded to a widget (an observer pattern).
Con: PySimpleGUI is a multi-target adaptor to not only tkinter but also remi (web), wx, Qt. If you were using the versatility of pysimpleGUI and its multi-platform features you really need to look at the « free forever » alternatives.
Python Engineering at Microsoft: Python in Visual Studio Code – October 2024 Release
We’re excited to announce the October 2024 release of the Python and Jupyter extensions for Visual Studio Code!
This release includes the following announcements:
- Run Python tests with coverage
- Default Python problem matcher
- Python language server mode
If you’re interested, you can check the full list of improvements in our changelogs for the Python, Jupyter and Pylance extensions.
Run Python tests with coverageYou can now run Python tests with coverage in VS Code! Test coverage is a measure of how much of your code is covered by your tests, which can help you identify areas of your code that are not being fully tested.
To run tests with coverage enabled, select the coverage run icon in the Test Explorer or the “Run with coverage” option from any menu you normally trigger test runs from. The Python extension will run coverage using the pytest-cov plugin if you are using pytest, or with coverage.py for unittest.
Note: Before running tests with coverage, make sure to install the correct testing coverage package for your project.
Once the coverage run is complete, lines will be highlighted in the editor for line level coverage. Test coverage results will appear as a “Test Coverage” sub-tab in the Test Explorer, which you can also navigate to with Testing: Focus on Test Coverage View in Command Palette (F1)). On this panel you can view line coverage metrics for each file and folder in your workspace.
For more information on running Python tests with coverage, see our Python test coverage documentation. For general information on test coverage, see VS Code’s Test Coverage documentation.
Default Python problem matcherWe are excited to announce support for one of our longest request features: there is now a default Python problem matcher! Aiming to simplifying issue tracking in your Python code and offering more contextual feedback, a problem matcher scans the task’s output for errors and warnings and displays them in the Problems panel, enhancing your development workflow. To integrate it, add "problemMatcher": "$python" to your tasks in task.json.
Below is an example of a task.json file that uses the default problem matcher for Python:
{ "version": "2.0.0", "tasks": [ { "label": "Run Python", "type": "shell", "command": "${command:python.interpreterPath}", "args": [ "${file}" ], "problemMatcher": "$python" } ] }For more information on tasks and problem matchers, visit VS Code’s Tasks documentation.
Pylance language server modeThere’s a new setting python.analysis.languageServerMode that enables you to choose between our current IntelliSense experience or a lightweight one that is optimized for performance. If you don’t require the full breadth of IntelliSense capabilities and prefer Pylance to be as resource-friendly as possible, you can set python.analysis.languageServerMode to light. Otherwise, to continue with the experience you have with Pylance today, you can leave out the setting entirely or explicitly set it to default .
This new functionality overrides the default values of the following settings:
Setting light mode default mode “python.analysis.exclude” [“**”] [] “python.analysis.useLibraryCodeForTypes” false true “python.analysis.enablePytestSupport” false true “python.analysis.indexing” false trueThe settings above can still be changed individually to override the default values.
Shell integration in Python terminal REPLThe Python extension now includes a python.terminal.shellIntegration.enabled setting to enable a better terminal experience on MacOS and Linux machines. When enabled, this setting runs a PYTHONSTARTUP script before you launch the Python REPL in the terminal (for example, by typing and entering python), allowing you to leverage terminal shell integrations such as command decorations, re-run command and run recent commands.
Other Changes and Enhancements
We have also added small enhancements and fixed issues requested by users that should improve your experience working with Python and Jupyter Notebooks in Visual Studio Code. Some notable changes include:
- Experimental Implement Abstract Classes with Copilot Code Action available for GitHub Copilot users using Pylance. Enable by adding "python.analysis.aiCodeActions": {"implementAbstractClasses": true} in your User settings.json
- Fixed duplicate Python executable code when sending code to the Terminal REPL by using executeCommand rather than sendText for the activation command in @vscode#23929
We would also like to extend special thanks to this month’s contributors:
- @edgarrmondragon Add uv.lock to file associations in vscode-python#23991
- @vishrutss Remove redundant @typescript-eslint/no-explicit-any suppression in vscode-python#24091
Try out these new improvements by downloading the Python extension and the Jupyter extension from the Marketplace, or install them directly from the extensions view in Visual Studio Code (Ctrl + Shift + X or ⌘ + ⇧ + X). You can learn more about Python support in Visual Studio Code in the documentation. If you run into any problems or have suggestions, please file an issue on the Python VS Code GitHub page.
The post Python in Visual Studio Code – October 2024 Release appeared first on Python.
Real Python: Quiz: Iterators and Iterables in Python: Run Efficient Iterations
In this quiz, you’ll test your understanding of Python’s Iterators and Iterables.
By working through this quiz, you’ll revisit how to create and work with iterators and iterables, understand the differences between them, and review how to use generator functions and the yield statement.
[ 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 ]
Seth Michael Larson: EuroPython 2024 talks about security
Published 2024-10-04 by Seth Larson
Reading time: minutes
EuroPython 2024 which occurred back in July 2024 has published the talk recordings to YouTube earlier this week. I've been under the weather for most of this week, but have had a chance to listen to a few of the security-related talks in-between resting.
Counting down for Cyber Resilience Act: Updates and expectationsThis talk was delivered by Python Software Foundation Executive Director Deb Nicholson and and Board Member Cheuk Ting Ho. The Cyber Resilience Act (CRA) is coming, and it'll affect more software than just the software written in the EU. Deb and Cheuk describe the recent developments in the CRA like the creation of a new entity called the "Open Source Steward" and how open source foundations and maintainers are preparing for the CRA.
For the rest of this year and next year I am focusing on getting the Python ecosystem ready for software security regulations like the CRA and SSDF from the United States.
Starting with improving the Software Bill-of-Materials (SBOM) story for Python, because this is required by both (and likely, future) regulations. Knowing what software you are running is an important first step towards being able to secure that same software.
To collaborate with other open source foundations and projects on this work, I've joined the Open Regulatory Compliance Working Group hosted by the Eclipse Foundation.
Towards licensing standardization in Python packagingThis talk was given by Karolina Surma and it detailed all the work that goes into researching, writing, and having a Python packaging standard accepted (spoiler: it's a lot!). Karolina is working on PEP 639 which is for adopting the SPDX licensing expression and identifier standards in Python as they are the current state of the art for modeling complex licensing situations accurately for machine (and human) consumption.
This work is very important for Software Bill-of-Materials, as they require accurate license information in this exact format. Thanks to Karolina, C.A.M. Gerlach, and many others for working for years on this PEP, it will be useful to so many uers once adopted!
The Update Framework (TUF) joins PyPIThis talk was given by Kairo de Araujo and Lukas Pühringer and it detailed the history and current status of The Update Framework (TUF) integration into the Python Package Index.
TUF provides better integrity guarantees for software repositories like PyPI like making it more difficult to "compel" the index to serve the incorrect artifacts and to make a compromise of PyPI easier to roll-back and be certain that files hadn't been modified. For a full history and latest status, you can view PEP 458 and the top-level GitHub issue for Warehouse.
I was around for the original key-signing ceremony for the PyPI TUF root keys which was live-streamed back in October 2020. Time flies, huh.
Writing Python like it's Rust: more robust code with type hintsThis talk was given by Jakub Beránek about using type hints for more robust Python code. Having written a case-study on urllib3's adoption of type hints to find defects that testing and other tooling missed I highly recommend type hints for Python code as well:
Accelerating Python with Rust: The PyO3 RevolutionThis talk was given by Roshan R Chandar about using PyO3 and Rust in Python modules.
Automatic Trusted Publishing with PyPIThis talk was given by Facundo Tuesca on using Trusted Publishing for authenticating with PyPI to publish packages.
Zero Trust APIs with PythonThis talk was given by Jose Haro Peralta on how to design and implement secure web APIs using Python, data validation with Pydantic, and testing your APIs using tooling for detecting common security defects.
Best practices for securely consuming open source in PythonThis talk was given by Cira Carey which highlights many of today's threats targetting open source consumers. Users should be aware of these when selecting projects to download and install.
Thanks for reading! ♡ Did you find this article helpful and want more content like it?
Get notified of new posts by subscribing to the RSS feed or the email newsletter.
This work is licensed under CC BY-SA 4.0
Trey Hunner: Switching from virtualenvwrapper to direnv, Starship, and uv
Earlier this week I considered whether I should finally switch away from virtualenvwrapper to using local .venv managed by direnv.
I’ve never seriously used direnv, but I’ve been hearing Jeff and Hynek talk about their use of direnv for a while.
After a few days, I’ve finally stumbled into a setup that works great for me. I’d like to note the basics of this setup as well as some fancy additions that are specific to my own use case.
My old virtualenvwrapper workflowFirst, I’d like to note my old workflow that I’m trying to roughly recreate:
- I type mkvenv3 <project_name> to create a new virtual environment for the current project directory and activate it
- I type workon <project_name> when I want to workon that project: this activates the correct virtual environment and changes to the project directory
The initial setup I thought of allows me to:
- Run echo layout python > .envrc && direnv allow to create a virtual environment for the current project and activate it
- Change directories into the project directory to automatically activate the virtual environment
The more complex setup I eventually settled on allows me to:
- Run venv <project_name> to create a virtual environment for the current project and activate it
- Run workon <project_name> to change directories into the project (which automatically activates the virtual environment)
First, I installed direnv and added this to my ~/.zshrc file:
1 eval "$(direnv hook zsh)"Then whenever I wanted to create a virtual environment for a new project I created a .envrc file in that directory, which looked like this:
1 layout pythonThen I ran direnv allow to allow, as direnv instructed me to, to allow the new virtual environment to be automatically created and activated.
That’s pretty much it.
Unfortunately, I did not like this initial setup.
No shell prompt?The first problem was that the virtual environment’s prompt didn’t show up in my shell prompt. This is due to a direnv not allowing modification of the PS1 shell prompt. That means I’d need to modify my shell configuration to show the correct virtual environment name myself.
So I added this to my ~/.zshrc file to show the virtual environment name at the beginning of my prompt:
1 2 3 4 5 6 7 # Add direnv-activated venv to prompt show_virtual_env() { if [[ -n "$VIRTUAL_ENV_PROMPT" && -n "$DIRENV_DIR" ]]; then echo "($(basename $VIRTUAL_ENV_PROMPT)) " fi } PS1='$(show_virtual_env)'$PS1 Wrong virtual environment directoryThe next problem was that the virtual environment was placed in .direnv/python3.12. I wanted each virtual environment to be in a .venv directory instead.
To do that, I made a .config/direnv/direnvrc file that customized the python layout:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 layout_python() { if [[ -d ".venv" ]]; then VIRTUAL_ENV="$(pwd)/.venv" fi if [[ -z $VIRTUAL_ENV || ! -d $VIRTUAL_ENV ]]; then log_status "No virtual environment exists. Executing \`python -m venv .venv\`." python -m venv .venv VIRTUAL_ENV="$(pwd)/.venv" fi # Activate the virtual environment . $VIRTUAL_ENV/bin/activate } Loading, unloading, loading, unloading…I also didn’t like the loading and unloading messages that showed up each time I changed directories. I removed those by clearing the DIRENV_LOG_FORMAT variable in my ~/.zshrc configuration:
1 export DIRENV_LOG_FORMAT= The more advanced setupI don’t like it when all my virtual environment prompts show up as .venv. I want ever prompt to be the name of the actual project… which is usually the directory name.
I also really wanted to be able to type venv to create a new virtual environment, activate it, and create the .envrc file for my automatically.
Additionally, I thought it would be really handy if I could type workon <project_name> to change directories to a specific project.
I made two aliases in my ~/.zshrc configuration for all of this:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 venv() { local venv_name=${1:-$(basename "$PWD")} local projects_file="$HOME/.projects" # Check if .envrc already exists if [ -f .envrc ]; then echo "Error: .envrc already exists" >&2 return 1 fi # Create venv if ! python3 -m venv --prompt "$venv_name"; then echo "Error: Failed to create venv" >&2 return 1 fi # Create .envrc echo "layout python" > .envrc # Append project name and directory to projects file echo "${venv_name} = ${PWD}" >> $projects_file # Allow direnv to immediately activate the virtual environment direnv allow } workon() { local project_name="$1" local projects_file="$HOME/.projects" local project_dir # Check for projects config file if [[ ! -f "$projects_file" ]]; then echo "Error: $projects_file not found" >&2 return 1 fi # Get the project directory for the given project name project_dir=$(grep -E "^$project_name\s*=" "$projects_file" | sed 's/^[^=]*=\s*//') # Ensure a project directory was found if [[ -z "$project_dir" ]]; then echo "Error: Project '$project_name' not found in $projects_file" >&2 return 1 fi # Ensure the project directory exists if [[ ! -d "$project_dir" ]]; then echo "Error: Directory $project_dir does not exist" >&2 return 1 fi # Change directories cd "$project_dir" }Now I can type this to create a .venv virtual environment in my current directory, which has a prompt named after the current directory, activate it, and create a .envrc file which will automatically activate that virtual environment (thanks to that ~/.config/direnv/direnvrc file) whenever I change into that directory:
1 $ venvIf I wanted to customized the prompt name for the virtual environment, I could do this:
1 $ venv my_projectWhen I wanted to start working on that project later, I can either change into that directory or if I’m feeling lazy I can simply type:
1 $ workon my_projectThat reads from my ~/.projects file to look up the project directory to switch to.
Switching to uvI also decided to try using uv for all of this, since it’s faster at creating virtual environments. One benefit of uv is that it tries to select the correct Python version for the project, if it sees a version noted in a pyproject.toml file.
Another benefit of using uv, is that I should also be able to update the venv to use a specific version of Python with something like --python 3.12.
Here are the updated shell aliases for the ~/.zshrc for uv:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 venv() { local venv_name local dir_name=$(basename "$PWD") # If there are no arguments or the last argument starts with a dash, use dir_name if [ $# -eq 0 ] || [[ "${!#}" == -* ]]; then venv_name="$dir_name" else venv_name="${!#}" set -- "${@:1:$#-1}" fi # Check if .envrc already exists if [ -f .envrc ]; then echo "Error: .envrc already exists" >&2 return 1 fi # Create venv using uv with all passed arguments if ! uv venv --seed --prompt "$@" "$venv_name"; then echo "Error: Failed to create venv" >&2 return 1 fi # Create .envrc echo "layout python" > .envrc # Append to ~/.projects echo "${venv_name} = ${PWD}" >> ~/.projects # Allow direnv to immediately activate the virtual environment direnv allow } Switching to starshipI also decided to try out using Starship to customize my shell this week.
I added this to my ~/.zshrc:
1 eval "$(starship init zsh)"And removed this, which is no longer needed since Starship will be managing the shell for me:
1 2 3 4 5 6 7 # Add direnv-activated venv to prompt show_virtual_env() { if [[ -n "$VIRTUAL_ENV_PROMPT" && -n "$DIRENV_DIR" ]]; then echo "($(basename $VIRTUAL_ENV_PROMPT)) " fi } PS1='$(show_virtual_env)'$PS1I also switched my python layout for direnv to just set the $VIRTUAL_ENV variable and add the $VIRTUAL_ENV/bin directory to my PATH, since the $VIRTUAL_ENV_PROMPT variable isn’t needed for Starship to pick up the prompt:
1 2 3 4 5 layout_python() { VIRTUAL_ENV="$(pwd)/.venv" PATH_add "$VIRTUAL_ENV/bin" export VIRTUAL_ENV }I also made a very boring Starship configuration in ~/.config/starship.toml:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 format = """ $python\ $directory\ $git_branch\ $git_state\ $character""" add_newline = false [python] format = '([(\($virtualenv\) )]($style))' style = "bright-black" [directory] style = "bright-blue" [character] success_symbol = "[\\$](black)" error_symbol = "[\\$](bright-red)" vimcmd_symbol = "[❮](green)" [git_branch] format = "[$symbol$branch]($style) " style = "bright-purple" [git_state] format = '\([$state( $progress_current/$progress_total)]($style)\) ' style = "purple" [cmd_duration.disabled]I setup such a boring configuration because when I’m teaching, I don’t want my students to be confused or distracted by a prompt that has considerably more information in it than their default prompt may have.
The biggest downside of switching to Starship has been my own earworm-oriented brain. As I update my Starship configuration files, I’ve repeatedly heard David Bowie singing “I’m a Starmaaan”. 🎶
Ground control to major TOMLAfter all of that, I realized that I could additionally use different Starship configurations for different directories by putting a STARSHIP_CONFIG variable in specific layouts. After that realization, I made my configuration even more vanilla and made some alternative configurations in my ~/.config/direnv/direnvrc file:
1 2 3 4 5 6 7 8 9 10 11 12 layout_python() { VIRTUAL_ENV="$(pwd)/.venv" PATH_add "$VIRTUAL_ENV/bin" export VIRTUAL_ENV export STARSHIP_CONFIG=/home/trey/.config/starship/python.toml } layout_git() { export STARSHIP_CONFIG=/home/trey/.config/starship/git.toml }Those other two configuration files are fancier, as I have no concern about them distracting my students since I’ll never be within those directories while teaching.
You can find those files in my dotfiles repository.
The necessary toolsSo I replaced virtualenvwrapper with direnv, uv, and Starship. Though direnv was is doing most of the important work here. The use of uv and Starship were just bonuses.
I am also hoping to eventually replace my pipx use with uv and once uv supports adding python3.x commands to my PATH, I may replace my use of pyenv with uv as well.
Thanks to all who participated in my Mastodon thread as I fumbled through discovering this setup.
Real Python: Quiz: Python import: Advanced Techniques and Tips
In this quiz, you’ll test your understanding of Python’s import statement and related topics.
By working through this quiz, you’ll revisit how to use modules in your scripts and import modules dynamically at runtime.
[ 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 ]
Real Python: A Guide to Modern Python String Formatting Tools
When working with strings in Python, you may need to interpolate values into your string and format these values to create new strings dynamically. In modern Python, you have f-strings and the .format() method to approach the tasks of interpolating and formatting strings.
In this tutorial, you’ll learn how to:
- Use f-strings and the .format() method for string interpolation
- Format the interpolated values using replacement fields
- Create custom format specifiers to format your strings
To get the most out of this tutorial, you should know the basics of Python programming and the string data type.
Get Your Code: Click here to download the free sample code that shows you how to use modern string formatting tools in Python.
Take the Quiz: Test your knowledge with our interactive “A Guide to Modern Python String Formatting Tools” quiz. You’ll receive a score upon completion to help you track your learning progress:
Interactive Quiz
A Guide to Modern Python String Formatting ToolsYou can take this quiz to test your understanding of modern tools for string formatting in Python. These tools include f-strings and the .format() method.
Getting to Know String Interpolation and Formatting in PythonPython has developed different string interpolation and formatting tools over the years. If you’re getting started with Python and looking for a quick way to format your strings, then you should use Python’s f-strings.
Note: To learn more about string interpolation, check out the String Interpolation in Python: Exploring Available Tools tutorial.
If you need to work with older versions of Python or legacy code, then it’s a good idea to learn about the other formatting tools, such as the .format() method.
In this tutorial, you’ll learn how to format your strings using f-strings and the .format() method. You’ll start with f-strings to kick things off, which are quite popular in modern Python code.
Using F-Strings for String InterpolationPython has a string formatting tool called f-strings, which stands for formatted string literals. F-strings are string literals that you can create by prepending an f or F to the literal. They allow you to do string interpolation and formatting by inserting variables or expressions directly into the literal.
Creating F-String LiteralsHere you’ll take a look at how you can create an f-string by prepending the string literal with an f or F:
Python 👇 >>> f"Hello, Pythonista!" 'Hello, Pythonista!' 👇 >>> F"Hello, Pythonista!" 'Hello, Pythonista!' Copied!Using either f or F has the same effect. However, it’s a more common practice to use a lowercase f to create f-strings.
Just like with regular string literals, you can use single, double, or triple quotes to define an f-string:
Python 👇 >>> f'Single-line f-string with single quotes' 'Single-line f-string with single quotes' 👇 >>> f"Single-line f-string with double quotes" 'Single-line f-string with single quotes' 👇 >>> f'''Multiline triple-quoted f-string ... with single quotes''' 'Multiline triple-quoted f-string\nwith single quotes' 👇 >>> f"""Multiline triple-quoted f-string ... with double quotes""" 'Multiline triple-quoted f-string\nwith double quotes' Copied!Up to this point, your f-strings look pretty much the same as regular strings. However, if you create f-strings like those in the examples above, you’ll get complaints from your code linter if you have one.
The remarkable feature of f-strings is that you can embed Python variables or expressions directly inside them. To insert the variable or expression, you must use a replacement field, which you create using a pair of curly braces.
Interpolating Variables Into F-StringsThe variable that you insert in a replacement field is evaluated and converted to its string representation. The result is interpolated into the original string at the replacement field’s location:
Python >>> site = "Real Python" 👇 >>> f"Welcome to {site}!" 'Welcome to Real Python!' Copied!In this example, you’ve interpolated the site variable into your string. Note that Python treats anything outside the curly braces as a regular string.
Read the full article at https://realpython.com/python-formatted-output/ »[ 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 ]
Kushal Das: Thank you Gnome Nautilus scripts
As I upload photos to various services, I generally resize them as required based on portrait or landscape mode. I used to do that for all the photos in a directory and then pick which ones to use. But, I wanted to do it selectively, open the photos in Gnome Nautilus (Files) application and right click and resize the ones I want.
This week I noticed that I can do that with scripts. Those can be in any given language, the selected files will be passed as command line arguments, or full paths will be there in an environment variable NAUTILUS_SCRIPT_SELECTED_FILE_PATHS joined via newline character.
To add any script to the right click menu, you just need to place them in ~/.local/share/nautilus/scripts/ directory. They will show up in the right click menu for scripts.
Below is the script I am using to reduce image sizes:
#!/usr/bin/env python3 import os import sys import subprocess from PIL import Image # paths = os.environ.get("NAUTILUS_SCRIPT_SELECTED_FILE_PATHS", "").split("\n") paths = sys.argv[1:] for fpath in paths: if fpath.endswith(".jpg") or fpath.endswith(".jpeg"): # Assume that is a photo try: img = Image.open(fpath) # basename = os.path.basename(fpath) basename = fpath name, extension = os.path.splitext(basename) new_name = f"{name}_ac{extension}" w, h = img.size # If w > h then it is a landscape photo if w > h: subprocess.check_call(["/usr/bin/magick", basename, "-resize", "1024x686", new_name]) else: # It is a portrait photo subprocess.check_call(["/usr/bin/magick", basename, "-resize", "686x1024", new_name]) except: # Don't care, continue passYou can see it in action (I selected the photos and right clicked, but the recording missed that part):
Real Python: Quiz: A Guide to Modern Python String Formatting Tools
Test your understanding of Python’s tools for string formatting, including f-strings and the .format() method.
Take this quiz after reading our A Guide to Modern Python String Formatting Tools tutorial.
[ 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 ]
Python Software Foundation: Python 3.13 and the Latest Trends: A Developer's Guide to 2025 - Live Stream Event
Join Tania Allard, PSF Board Member, and Łukasz Langa, CPython Developer-in-Residence, for ‘Python 3.13 and the Latest Trends: A Developer’s Guide to 2025’, a live stream event hosted by Paul Everitt from JetBrains. Thank to JetBrains for partnering with us on the Python Developers Survey and this event to highlight the current state of Python!
The session will take place tomorrow, October 3, at 5:00 pm CEST (11:00 am EDT). Tania and Łukasz will be discussing the exciting new features in Python 3.13, plans for Python 3.15 and current Python trends gathered from the 2023 Annual Developers Survey. Don't miss this chance to hear directly from the experts behind Python’s development!
Watch the live stream event on YouTubeDon’t forget to enable YouTube notifications for the stream and mark your calendar.
Chris Rose: uv, direnv, and simple .envrc files
I have adopted uv for a lot of Python development. I'm also a heavy user of direnv, which I like as a tool for setting up project-specific environments.
Much like Hynek describes, I've found uv sync to be fast enough to put into the chdir path for new directories. Here's how I'm doing it.
Direnv LibrariesFirst, it turns out you can pretty easily define custom direnv functions like the built-in ones (layout python, etc...). You do this by adding functions to ~/.config/direnv/direnvrc or in ~/.config/direnv/lib/ as shell scripts. I use this extensively to make my .envrc files easier to maintain and smaller. Now that I'm using uv here is my default for python:
function use_standard-python() { source_up_if_exists dotenv_if_exists source_env_if_exists .envrc.local use venv uv sync } What does that even mean?Let me explain each of these commands and why they are there:
-
source_up_if_exists -- this direnv stdlib function is here because I often group my projects into directories with common configuration. For example, when working on Chicon 8, I had a top level .envrc that set up the AWS configuration to support deploying Wellington and the Chicon 8 website. This searches up til it finds a .envrc in a higher directory, and uses that. source_up is the noisier, less-adaptable sibling.
-
dotenv_if_exists -- this loads .env from the current working directory. 12-factor apps often have environment-driven configuration, and docker compose uses them relatively seamlessly as well. Doing this makes it easier to run commands from my shell that behave like my development environment.
-
source_env_if_exists .envrc.local -- sometimes you need more complex functionality in a project than just environment variables. Having this here lets me use .envrc.local for that. This comes after .env because sometimes you want to change those values.
-
use venv -- this is a function that activates the project .venv (creating it if needed); I'm old and set in my ways, and I prefer . .venv/bin/activate.fish in my shell to the more newfangled "prefix it with a runner" mode.
-
uv sync -- this is a super fast, "install my development and main dependencies" command. This was way, way too slow with pip, pip-tools, poetry, pdm, or hatch, but with uv, I don't mind having this in my .envrc
With this set up in direnv's configuration, all I need in my .envrc file is this:
use standard-pythonI've been using this pattern for a while now; it lets me upgrade how I do default Python setups, with project specific settings, easily.
PyCharm: Prompt AI Directly in the Editor
With PyCharm, you now have the support of AI Assistant at your fingertips. You can interact with it right where you do most of your work – in the editor.
Stuck with an error in your code? Need to add documentation or tests? Just start typing your request on a new line in the editor, just as if you were typing in the AI Assistant chat window. PyCharm will automatically recognize your natural language request and generate a response.
PyCharm leaves a purple mark in the gutter next to lines changed by AI Assistant so you can easily see what has been updated.
If you don’t like the initial suggestion, you can generate a new one by pressing Tab. You can also adjust the initial input by clicking on the purple block in the gutter or simply pressing Ctrl+/ or ⌘/.
Want to get assistance with a specific argument? You can narrow the context that AI Assistant uses for its response as much as you want. Just put the caret in the relevant context, type the $ or ? symbol, and start writing. PyCharm will recognize your prompt and take the current context into account for its suggestions.
The new inline AI assistance works for Python, JavaScript, TypeScript, JSON, and YAML file formats, while the option to narrow the context works only for Python so far.
This feature is available to all AI Assistant subscribers in the second PyCharm 2024.3 EAP build. You can get a free trial version of AI Assistant straight in the IDE: to enable AI Assistant, open a project in PyCharm, click the AI icon on the right-hand toolbar, and follow the instructions that appear.
Tryton News: Security Release for issue #93
Cédric Krier has found that python-sql does not escape non-Expression for unary operators (like And and Or) which makes any system exposing those vulnerable to an SQL injection attack.
Impact- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: Low
- User Interaction: None
- Scope: Changed
- Confidentiality: High
- Integrity: Low
- Availability: Low
There is no known workaround.
ResolutionAll affected users should upgrade python-sql to the latest version.
Affected versions: <= 1.5.1
Non affected versions: >= 1.5.2
Any security concerns should be reported on the bug-tracker at https://bugs.tryton.org/python-sql with the confidential checkbox checked.
2 posts - 2 participants
William Minchin: u202410012332
Microblogging v1.3.0 for Pelican released! Posts should now sort as expected. Thanks @ashwinvis. on PyPI #Microblogging #Pelican Plugins #Releases #Python
Pages
Recent Publications
- Managing Hidden Dependencies in OO Software: a Study Based on Open Source Projects
- Open Source Communities as Liminal Ecosystems
- Investigating developers' email discussions during decision-making in Python language evolution
- Developers, Quality Control and Download Volume in Open Source Software (OSS) Projects
More...FLOSS Project Planets
FLOSS Research
- Driving Open Source forward: make your impact in 2025
- Improving Open Source security with the new GitHub Secure Open Source Fund
- Celebrating 5 years at the Open Source Initiative: a journey of growth, challenges, and community engagement
- Highlights from the Digital Public Goods Alliance Annual Members Meeting 2024
- Give Your Input on the State of Open Source Survey