Planet Python
Python People: Pamela Fox - Teaching Python, Accessibility, and Tools
Pamela Fox is a Python Cloud Developer Advocate at Microsoft.
Topics include:
- Girl Develop It
- Django Girls
- Girls Who Code
- Teaching a language vs teaching a tool
- What a dev advocate does
- Accessibility (A11y) testing
- Playwright
- axe-core
- Snapshot testing
- pytest plugin authoring
- Flask SQLAlchemy
- Relearning Go
Links from the show:
- Python Bytes 323 with Pamela: AI search wars have begun
- Python Test 199 with Pamela: Is Azure Right for a Side Project?
- gdi: Girl Develop It
- Django Girls
- Girls Who Code
- "Automated accessibility audits" - Pamela Fox (North Bay Python 2023)
- Playwright
- axe-core
- pytest-axe-playwright-snapshot, plugin from Pamela
- pytest-crayons plugin is from a PyCascades talk about building plugins
- pytest-check, yet another plugin
- FlaskSQLAlchemy
- Concurrency is not Parallelism by Rob Pike
The Complete pytest Course
- Level up your testing skills and save time during coding and maintenance.
- Check out courses.pythontest.com
Python Bytes: #367 A New Cloud Computing Paradigm at Python Bytes
Seth Michael Larson: urllib3 is fundraising for HTTP/2 support
Published 2024-01-16 by Seth Larson
Reading time: minutes
TLDR: urllib3 is raising ~$40,000 USD to release HTTP/2 support and ensure long-term sustainable maintenance of the project after a sharp decline in financial support for 2023.
What is urllib3?urllib3 is an HTTP client library for Python and is depended on by widely used projects like pip, Requests, major cloud and service provider SDKs, and more. urllib3 is one of the most used Python packages overall, installed over 4 billion times in 2023 with 1.5 million dependent repos on GitHub, up 50% from just last year.
Project update2023 was a transformative year for urllib3, headlined by the first stable release of v2.0 after multiple years of development by our maintainers and community. This major release is only the beginning of our plans to overhaul the library’s capabilities by removing constraints on our HTTP implementation while preserving backwards compatibility.
We’ve been able to accomplish this incredible work in 2023 thanks to financial support from Tidelift, the Spotify 2022 FOSS Fund, and our other sponsors which allowed us to offer bounties on tasks to fairly compensate maintainers and contributors for their time investments with the project.
Unfortunately, compared to past years we’ve experienced a sharp drop in financial support from non-Tidelift sources heading into 2024.
Year Non-Tidelift Funding 2019 $18,580 2020 $100* 2021 $9,950 2022 $14,493 2023 $2,330* December 2020 was the first time we offered ad-hoc financial support via GitHub Sponsors. Before this we only accepted grants for funding.
Our team has worked hard to set the stage for HTTP/2 support with urllib3 v2.0, and we plan to land HTTP/2 support without compromising on the sustainability of the project. Backwards-compatible HTTP/2 support in urllib3 would immediately benefit millions of users, among them the largest companies in the world, and requires adding more long-term maintenance burden to maintainers. This important work and its maintenance should not be uncompensated.
To ensure timely and sustainable development of HTTP/2 for urllib3 we're launching a fundraiser with a goal of raising our Open Collective balance to $50,000 USD. HTTP/2 support has just started being developed and we're hoping to release stable support once our fundraising goal has been reached. Donations to Open Collective directly or to platforms like GitHub Sponsors or Thanks.dev will all be counted towards this fundraising goal.
Our team has a long track record of using our financial resources to complete larger projects like secure URL parsing, TLS 1.3, modernizing our test suite framework, and finding security issues across multiple projects. All receipts are published publicly on our Open Collective with links to the work items being accomplished and blogged about by our maintainers. If you or your organization has questions about this fundraiser please email sethmichaellarson@gmail.com or ask in our community Discord.
There’s more information below about the work we’ve done so far for HTTP/2 support and what else we plan to do in 2024 during our fundraiser. Thanks for supporting open source software!
Funding updateurllib3 received $17,830 US dollars in financial support in 2023 from all sources and distributed $24,350 to contributors and maintainers. Our primary supporter continues to be Tidelift, who provided $15,500 to core maintainers Seth, Quentin, and Illia.
We distributed $1,800 to community contributors through our bounty program, less than last year but still a sizable amount. We are looking to leverage our bounty program more in 2024 to implement HTTP/2 and WebAssembly features.
Our Open Collective started the year with nearly $19,000 USD and ended the year with $12,179. This statistic clearly shows the gap in funding, comparing this year's fundraising of $2,330 to the average across 4 prior years of over $10,000 per year.
2022 OC Balance → Open Collective: $18,932 Tidelift → Tidelift Lifters: $15,500 Open Collective → 2023 OC Balance: $12,179 Tidelift → Tidelift Partnerships*: $12,000 Tidelift Partnerships* → Seth Larson: $12,000 Tidelift Lifters → Seth Larson: $6,904 Tidelift Lifters → Quentin Pradet: $6,603 Open Collective → Illia Volochii: $3,275 Open Collective → Quentin Pradet: $2,325 Tidelift Lifters → Illia Volochii: $1,993 Open Collective → Bounty Program: $1,800 Open Collective → Seth Larson: $1,450 GitHub Sponsors → Open Collective: $1,346 Sourcegraph → Open Collective: $600 Thanks.dev → Open Collective: $379 Open Collective → OSC Host Fees: $233 Donations → Open Collective: $5 Tidelift: $27,500 Tidelift Partnerships*: $12,000 Seth Larson: $20,354 Tidelift Lifters: $15,500 Quentin Pradet: $8,928 Illia Volochii: $5,268 2022 OC Balance: $18,932 Open Collective: $21,262 GitHub Sponsors: $1,346 Sourcegraph: $600 Thanks.dev: $379 Donations: $5 Bounty Program: $1,800 2023 OC Balance: $12,179 OSC Host Fees: $233 Tidelift$27,500 Tidelift Partnerships*$12,000 Seth Larson$20,354 Tidelift Lifters$15,500 Quentin Pradet$8,928 Illia Volochii$5,268 2022 OC Balance$18,932 Open Collective$21,262 GitHub Sponsors$1,346 Sourcegraph$600 Thanks.dev$379 Donations$5 Bounty Program$1,800 2023 OC Balance$12,179 OSC Host Fees$233* Seth Larson was also paid $7,000 by Tidelift for a packaging security standards project and $5,000 as a part of their "lifter advocate" program. Neither of these projects are directly related to urllib3 but are listed for completeness.
Maintenance update2023 marks the 15th anniversary of urllib3 being first published to PyPI! 🥳 Not many open source projects stand the test of time and continue to see the widespread usage that urllib3 does every day. We attribute our longevity to quickly elevating contributors from our community into project maintainers which we believe is a critical property of a sustainable open source project. Financial rewards through our bounty program is a crucial piece of our approach to staying sustainable for the long-term.
This year we welcomed a new core maintainer to our team, Illia Volochii! 🎉 Illia has been putting in high quality and consistent work to get v2.0 out the door. Illia started contributing to urllib3 in 2022 and after landing multiple high-quality pull requests was asked to join the team of collaborators and begin reviewing PRs and issues and helping with the release process.
After adding Illia we now have three core maintainers including Seth Larson and Quentin Pradet, in addition to multiple collaborators and community contributors.
We landed 160 commits from 13 unique contributors during 2023 which is up from ~130 commits during 2022. We published 16 releases to PyPI in 2023, up from 8 in 2022.
From a security perspective, we continue to lead the pack for Python packages in terms of implementing security standards. urllib3 is the highest rated project according to OpenSSF Scorecard with a score of 9.6 out of 10 overall. We also were an early adopter of Trusted Publishers, adopting the new feature days after they were announced during PyCon US 2023.
We remediated two moderate-severity vulnerabilities in 2023 and made the fixes available in both the new v2.0 and security-fix only v1.26.x release streams. Support for the previous major version of urllib3 is provided thanks to funding from Tidelift.
Support for HTTP/2When you first read this post you might have thought:
“Hasn't HTTP/2 been around for a long time?” 🤔
And you'd be right! HTTP/2 was published in 2015 in RFC 7540 and is now used for the majority of web requests. HTTP/2 and has been around for so long that there's an already HTTP/3!
So why are we only just now starting to add support for HTTP/2 to urllib3? The reason is that the standard library module http.client only supports HTTP/1 and before urllib3 v2.0 was released urllib3 was strongly tied to http.client APIs. By breaking backwards compatibility in a few key ways (while maintaining compatibility where it matters for most users) we've been able to set the stage for adding HTTP/2 to urllib3! 🚀
urllib3 is in good company: many of Python's stable HTTP clients don't support HTTP/2 like Requests (which uses urllib3 under the hood), aiohttp, and httplib2.
Even though we're waiting to release HTTP/2 support until after our fundraiser concludes, we aren't waiting to get started. Our team has already started some of the required prep-work to implement HTTP/2. Want to follow along? We have a top-level tracking issue for HTTP/2 support on GitHub.
Over the past two months Quentin has migrated our test suite from the venerable Tornado web backend to using the Hypercorn server and Quart microframework. Our test application communicates with the server using ASGI, which is perfect for our use-case: low-level enough to satisfy the needs of the test suite and high-level enough to abstract the differences between HTTP/1 and HTTP/2. Now that the test suite runs with both HTTP/1 and HTTP/2, we can start developing HTTP/2 with an extensive initial battery of test cases.
Support for Webassembly and EmscriptenWhen PyScript was first announced at PyCon US 2022 during a keynote by Peter Wang, Seth was sitting front row to witness Python moving to the web. Later that same day in the PyScript open space there were experiments for making HTTP requests with urllib3 and Pyodide together using a synchronous call to the JavaScript fetch() API. At the time, despite having assistance from PyScript maintainers, there didn't seem to be a way forwards yet.
Fast-forward to today, the pyodide-http project has figured out how to make a synchronous or streaming HTTP exchange using the fetch() and XMLHttpRequest JavaScript APIs along with Web Workers. Now that a synchronous approach to HTTP requests was possible we could add support to urllib3!
Thanks to Joe Marshall, urllib3 now has experimental support for the Emscripten platform, complete with bundling a small JavaScript stub for Web Worker support and testing against Chrome and Firefox in our CI. What's next is to thoroughly test and document the feature. We're aiming to release stable Emscripten support for urllib3 in 2024.
The most exciting part of this is that once a core dependency like urllib3 has been made compatible with Emscripten we'll likely see a wave of other packages that immediately become compatible too, bringing even more of the Python package ecosystem to the web 🥳
Stable release of urllib3 v2.0urllib3 had its first stable release of v2.0 in April 2023 and later the v2.1.0 release to remove many long-deprecated features like the [secure] extra which had become redundant with new improvements to the ssl standard library module and the urllib3.contrib.securetransport module which was needed on macOS due to unavailability of an OpenSSL library on the platform to perform HTTPS with PyPI.
This release also put the project in a good place for future improvements like those discussed above. The biggest blocker to adopting new HTTP implementations were vestigial APIs from urllib3 primarily subclassing the standard libraries http.client (or for Python 2: httplib) modules.
By removing and discouraging these implicit APIs we're better able to adopt alternate HTTP implementations such as the h2 library for HTTP/2 and JavaScript's fetch API for Emscripten.
Increasing adoption of urllib3 v2.xThe initial adoption of urllib3 v2.x was lower than expected, due to the following factors:
- By default, RedHat Enterprise Linux 7 (RHEL 7), AWS Lambda, Amazon Linux 2 and Read the Docs were all compiling the ssl module with OpenSSL 1.0.2. While botocore still pinned urllib3 to 1.26.x, Amazon Linux 2 was more popular than we expected and many users were not pinning or resolving their dependencies correctly and thus were receiving an incompatible version of urllib3.
- Various third-party packages like dockerpy, request-toolbelt and vcrpy were relying on implementation details of urllib3 that were deprecated or removed in v2.0 so couldn’t upgrade right away.
- And finally, we intentionally removed the strict parameter from HTTPResponse which had no effect since Python 3. This affected only a few users.
After a few weeks, we had around 3 millions daily downloads for v2.0. That's a lot of downloads, but only accounted for 30% of 1.26.x downloads at the time without any obvious upward trend. The only exception was Read the Docs that encouraged users to move to Ubuntu 22.04 and Python 3.11 shortly after the urllib3 2.0 release. To avoid a prolonged split in the ecosystem, we took various actions to help migrating to 2.x:
- Helped some libraries upgrade, including requests, docker-py, vcrpy, and requests-toolbelt.
- We added common migration issues to the v2 migration guide.
- With help from a LibreSSL developer and a Gentoo user, we added back LibreSSL support.
- To allow google-auth-library-python and the rest of the Google ecosystem to upgrade, we added back pyOpenSSL to allow in-memory certificate support.
Our friend and Requests maintainer, Nate Prewitt allowed urllib3 v2.0 for Python 3.10+ users of botocore. This work on Requests inspired snowflake-connector-python to follow suit.
Today, most popular libraries support urllib3 2.0 and later, at least with Python 3.10 and above. And the libraries that don't support it yet get requests from users. urllib3 2.x is reliably above 70% of 1.26.x downloads and growing. Additionally, Python 3.10+ users already download 2.x more than 1.26.x, making us confident that the ecosystem split will eventually disappear in favor of the newest major version of urllib3.
👋 That's all for now, if you want to discuss this article you can join our community Discord. Please share this article to help spread the word of our fundraiser and coming HTTP/2 support.
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
Chris Warrick: Python Packaging, One Year Later: A Look Back at 2023 in Python Packaging
A year ago, I wrote about the sad state of Python packaging. The large number of tools in the space, the emphasis on writing vague standards instead of rallying around the One True Tool, and the complicated venv-based ecosystem instead of a solution similar to node_modules. What has changed in the past year? Has anything improved, is everything the same, or are things worse than they were before?
The toolsThe original post listed a bunch of packaging tools, calling fourteen tools at least twelve too many. My idea with that was that most people would be happy with one tool that does everything, but the scientific-Python folks might have special requirements that would work best as a second tool.
Out of the tools named in last year’s post, all of them still seem to be maintained. Except for Flit (zero new commits in the past 30 days) and virtualenv (only automated and semi-automated version bumps), the tools have recent commits, pull requests, and issues.
All of those tools are still in use. Françoise Conil analysed all PyPI packages and checked their PEP 517 build backends: setuptools is the most popular (at 50k packages), Poetry is second at 41k, Hathling is third at 8.1k. Other tools to cross 500 users include Flit (4.4k), PDM (1.3k), Maturin (1.3k, build backend for Rust-based packages).
There are some new tools, of course. Those that crossed my radar are Posy and Rye. Posy is a project of Nathaniel J. Smith (of trio fame), Rye is a project of Armin Ronacher (of Flask fame). The vision for both of them is to manage Python interpreters and projects, but not have a custom build backend (instead using something like hatchling). Posy is built on top of PyBI (a format for distributing binaries of Python interpreters, proposed by Smith in draft PEP 711), Rye uses Gregory Szorc’s pre-built Pythons. Rye seems to be fairly complete and usable, Posy is right now a PoC of the PyBI format, and only offers a REPL with pre-installed packages.
Both Posy and Rye are written in Rust. On the one hand, it makes sense that the part that manages Python interpreters is not written in Python, because that would require a separate Python, not managed by Posy/Rye, to run those tools. But Rye also has its own pyproject.toml parser in Rust, and many of its commands are implemented mostly or largely using Rust (sometimes also calling one-off Python scripts; although the main tasks of creating venvs, installing packages, and working with lockfiles are handed off to venv, pip, and pip-tools respectively).
Speaking of Rust and Python, there’s been another project in that vein that has grown a lot (and gathered a lot of funding) in the past year. That project is Ruff, which is a linter and code formatter. Ruff formats Python code, and is written in Rust. This means it’s 10–100× faster than existing tools written in Python (according to Ruff’s own benchmarks). Fast is good, I guess, but what does this say about Python? Is the fact that package tools (which aren’t rocket science, maybe except for fast dependency solvers, and which often need access to Python internals to do their job) and code formatters (which require a deep understanding of Python syntax, and parsing Python sources to ASTs, something easy by the ast Python module) are written in another language? Does this trend make Python a toy language (as it is also often considered a glue language for NumPy and friends)? Also, why should contributing to a tool important to many Python developers require learning Rust?
The standardsLast time we looked at packaging standards, we focused on PEP 582. It proposed the introduction of __pypackages__, which would be a place for third-party packages to be installed to locally, on a per-project basis, without involving virtual environments, similarly to what node_modules is for node. The PEP was ultimately rejected in March 2023. The PEP wasn’t perfect, and some of its choices were questionable or insufficient (such as not recursively searching for __pypackages__ in parent directories, or focusing on simple use-cases only). No new standards for something in that vein (with a better design) were proposed to this day.
Another contentious topic is lock files. Lock files for packaging systems are useful for reproducible dependency installations. The lock file records all installed packages (i.e. includes transitive dependencies) and their versions. Lock files often include checksums (like sha512) of the installed packages, and they often support telling apart packages installed via different groups of dependencies (runtime, buildtime, optional, development, etc.).
The classic way of achieving this goal are requirements.txt files. They are specific to pip, and they only contain a list of packages, versions, and possibly checksums. Those files can be generated by pip freeze, or the third-party pip-compile from pip-tools. pip freeze is very basic, pip-compile can’t handle different groups of dependencies other than making multiple requirements.in files, compiling them, and hoping there are no conflicts.
Pipenv, Poetry, and PDM have their own lockfile implementations, incompatible with one another. Rye piggybacks on top of pip-tools. Hatch doesn’t have anything in core; they’re waiting for a standard implementation (there are some plugins though). PEP 665 was rejected in January 2022. Its author, Brett Cannon, is working on a PoC of something that might become a standard (named mousebender).
This is the danger of the working model adopted by the Python packaging world. Even for something as simple as lock files, there are at least four incompatible standards. An attempt at a specification was rejected due to “lukewarm reception”, even though there exist at least four implementations which are achieving roughly the same goals, and other ecosystems also went through this before.
Another thing important to Python are extension modules. Extension modules are written in C, and they are usually used to interact with libraries written in other languages (and also sometimes for performance). Poetry, PDM, and Hatchling don’t really support building extension modules. Setuptools does; SciPy and NumPy migrated from their custom numpy.distutils to Meson. The team behind the PyO3 Rust bindings for Python develops Maturin, which allows for building Rust-based extension modules — but it’s not useful if you’re working with C.
There weren’t many packaging-related standards that were accepted in 2023. A standard worth mentioning is PEP 668, which allows distributors to prevent pip from working (to avoid breaking distro-owned site packages) by adding an EXTERNALLY-MANAGED file. It was accepted in June 2022, but pip only implemented support for it in January 2023, and many distros already have enabled this feature in 2023. Preventing broken systems is a good thing.
But some standards did make it through. Minor and small ones aside, the most prominent 2023 standard would be PEP 723: inline script metadata. It allows to add a comment block at the top of the file, that specifies the dependencies and the minimum Python version in a way that can be consumed by tools. Is it super useful? I don’t think so; setting up a project with pyproject.toml would easily allow things to grow. If you’re sending something via a GitHub gist, just make a repo. If you’re sending something by e-mail, just tar the folder. That approach promotes messy programming without source control.
Learning curves and the deception of “simple”Microsoft Word is simple, and a great beginner’s writing tool. You can make text bold with a single click. You can also make it blue in two clicks. But it’s easy to make an inconsistent mess. To make section headers, many users may just make the text bold and a bit bigger, without any consistency or semantics [1]. Making a consistent document with semantic formatting is hard in Word. Adding section numbering requires you to select a heading and turn it into a list. There’s also supposedly some magic involved, that magic doesn’t work for me, and I have to tell Word to update the heading style. Even if you try doing things nicely, Word will randomly break, mess up the styles, mix up styles and inline ad-hoc formatting, and your document may look differently on different computers.
LaTeX is very confusing to a beginner, and has a massive learning curve. And you can certainly write \textbf{hello} everywhere. But with some learning, you’ll be producing beautiful documents. You’ll define a \code{} command that makes code monospace and adds a border today, but it might change the background and typeset in Comic Sans tomorrow if you so desire. You’ll use packages that can render code from external files with syntax highlighting. Heading numbering is on by default, but it can easily be disabled for a section. LaTeX can also automatically put new sections on new pages, for example. LaTeX was built for scientific publishing, so it has stellar support for maths and bibliographies, among other things.
Let’s now talk about programming. Python is simple, and a great beginner’s programming language. You can write hello world in a single line of code. The syntax is simpler, there are no confusing leftovers from C (like the index-based for loop) or machine-level code (like break in switch), no pointers in sight. You also don’t need to write classes at all; you don’t need to write a class only to put a public static void main(String[] args) method there [2]. You don’t need an IDE, you can just write code using any editor (even notepad.exe will do for the first day or so), you can save it as a .py file and run it using python whatever.py.
Your code got more complicated? No worry, you can split it into multiple .py files, use import name_of_other_file_without_py and it will just work. Do you need more structure, grouping into folders perhaps? Well, forget about python whatever.py, you must use python -m whatever, and you must cd to where your code is, or mess with PYTHONPATH, or install your thing with pip. This simple yet common action (grouping things into folders) has massively increased complexity.
The standard library is not enough [3] and you need a third-party dependency? You find some tutorial that tells you to pip install, but pip will now tell you to use apt. And apt may work, but it may give you an ancient version that does not match the tutorial you’re reading. Or it may not have the package. Or the Internet will tell you not to use Python packages from apt. So now you need to learn about venvs (which add more complexity, more things to remember; most tutorials teach activation, venvs are easy to mess up via basic operations like renaming a folder, and you may end up with a venv in git or your code in a venv). Or you need to pick one of the many one-stop-shop tools to manage things.
In other ecosystems, an IDE is often a necessity, even for beginners. The IDE will force you into a project system (maybe not the best or most common one by default, but it will still be a coherent project system). Java will force you to make more than one file with the “1 public class = 1 file” rule, and it will be easy to do so, you won’t even need an import.
Do you want folders? In Java or C#, you just create a folder in the IDE, and create a class there. The new file may have a different package/namespace, but the IDE will help you to add the correct import/using to the codebase, and there is no risk of you using too many directories (including something like src) or using too few (not making a top-level package for all your code) that will require correcting all imports. The disruption from adding a folder in Java or C# is minimal.
The project system will also handle third-party packages without you needing to think about where they’re downloaded or what a virtual environment is and how to activate it from different contexts. A few clicks and you’re done. And if you don’t like IDEs? Living in the CLI is certainly possible in many ecosystems, they have reasonable CLI tools for common management tasks, as well as building and running your project.
PEP 723 solves a very niche problem: dependency management for single-file programs. Improving life for one-off things and messy code was apparently more important to the packaging community than any other improvements for big projects.
By the way, you could adapt this lesson to static and dynamic typing. Dynamic typing is easier to get started with and requires less typing, but compile-type checking can prevent many bugs — bugs that require higher test coverage to catch with dynamic typing. That’s why the JS world has TypeScript, that’s why mypy/pyright/typing has gained a lot of mindshare in the Python world.
The future…Looking at the Python Packaging Discourse, there were some discussions about ways to improve things.
For example, this discussion about porting off setup.py was started by Gregory Szorc, who had a long list of complaints, pointing out the issues with the communication from the packaging world, and documentation mess (his post is worth a read, or at least a skim, because it’s long and full of packaging failures). There’s one page which recommends setuptools, another which has four options with Hatchling as a default, and another still promoting Pipenv. We’ve seen this a year ago, nothing changed in that regard. Some people tried finding solutions, some people shared their opinions… and then the Discourse moderator decided to protect his PyPA friends from having to read user feedback and locked the thread.
Many other threads about visions were had, like the one about 10-year views or about singular packaging tools. The strategy discussions, based on the user survey, had a second part (the first one concluded in January 2023), but it saw less posts than the first one, and discussions did not continue (and there were discussions about how to hold the discussions). There are plans to create a packaging council — design-by-committee at its finest.
But all those discussions, even when not locked by an overzealous moderator, haven’t had any meaningful effect. The packaging ecosystem is still severely fragmented and confusing. The PyPA docs and tutorials still contradict each other. The PyPA-affiliated tools still have less features than the unaffiliated competition (even the upstart Rye has some form of lockfiles, unlike Hatch or Flit), and going by the PEP 517 build backend usage statistics, they are more popular than the modern PyPA tools. The authors of similar yet competing tools have not joined forces to produce the One True Packaging Tool.
…is looking pretty bleakOn the other hand, if you look at the 2023 contribution graphs for most packaging tools, you might be worried about the state of the packaging ecosystem.
Pip has had a healthy mix of contributors and a lot of commits going into it.
Pipenv and setuptools have two lead committers, but still a healthy amount of commits.
Hatch, however, is a one-man-show: Ofek Lev (the project founder) made 184 commits, the second place belongs to Dependabot with 6 commits, and the third-place contributor (who is a human) has five commits. The bus factor of Hatch and Hatchling is 1.
The non-PyPA tools aren’t doing much better:
Poetry has two top contributors, but at least there are four human contributors with a double-digit number of commits.
PDM is a one-man-show, like Hatch.
Rye has one main contributor, and three with a double-digit number of commits; note it’s pretty new (started in late April 2023) and it’s not as popular as the others.
I understand the PyPA is a loose association of volunteers. It is sometimes said the name Python Packaging Authority was originally a joke. However, they are also the group that maintains all the packaging standards, so they are the authority when it comes to packaging. For example, PEP 668 starts with a warning block saying it’s a historical document, and the up-to-date version of the specification is on PyPA’s site (as well as a bunch of other packaging specs).
The PyPA should shut down or merge some duplicate projects, and work with the community (including maintainers of non-PyPA projects) to build One True Packaging Tool. To make things easier. To avoid writing code that does largely the same thing 5 times. To make sure thousands of projects don’t depend on tools with a bus factor of 1 or 2. To turn packaging from a problem and an insurmountable obstacle to something that just works™, something that an average developer doesn’t need to think about.
It’s not rocket science. Tons of languages, big and small, have a coherent packaging ecosystem (just read last year’s post for some examples of how simple it can be). Instead of focusing on specifications and governance, focus on producing one comprehensive, usable, user-friendly tool.
Discuss below or on Hacker News.
Footnotes [1]Modern Word at least makes this easier, because the heading styles get top billing on the ribbon; they were hidden behind a completely non-obvious combo box that said Normal in Word 2003 and older.
[2]C# 10 removed the requirement to make a class with a Main method, it can pick up one file with top-level statements and make it the entrypoint.
[3]The Python standard library gets a lot of praise. It is large compared to C, but nothing special compared to Java or C#. It is also full of low-quality libraries, like http.server or urllib.request, yet some people insist on only using the standard library. The standard library is also less stable and dependable (with constant deprecations and removals, and with new features requiring upgrading all of Python). All the “serious” use-cases, like web development or ML/AI/data science are impossible with just the standard library.
TechBeamers Python: Create a Full-fledged LangChain App – A ChatBot
In this tutorial, we have provided the basic code to create the LangChain chatbot app. You’ll find a comprehensive example, instructions, and guidance to help you. Also Read: Introduction to LangChain – Use With Python LangChain ChatBot App Here’s a detailed example of a chatbot that generates poems based on user-provided prompts. Firstly, let’s try […]
The post Create a Full-fledged LangChain App – A ChatBot appeared first on TechBeamers.
Django Weblog: DjangoCon Europe 2025 Call for Proposals
DjangoCon Europe 2024 will be held June 5th-9th in Vigo, Spain but we're already looking ahead to the 2025 conference. Could your town - or your football stadium, circus tent, private island or city hall - host this wonderful community event?
Hosting a DjangoCon is an ambitious undertaking. It's hard work, but each year it has been successfully run by a team of community volunteers, not all of whom have had previous experience - more important is enthusiasm, organizational skills, the ability to plan and manage budgets, time and people - and plenty of time to invest in the project.
How to applyWe've set up a working group of previous DjangoCon Europe organizers that you can reach out to with questions about organizing and running a DjangoCon Europe. european-organizers-support@djangoproject.com. There will also be an informational session set up towards the end of January or early February for interested organizers. Please email the working group to express interest in participating.
In order to give people the chance to go to many different conferences DjangoCon Europe should be held between January 5 and April 15 2025. Please read the licensing agreement the selected organizers will need to sign for the specific requirements around hosting a DjangoCon Europe
If you're interested, we'd love to hear from you. This year we are going to do rolling reviews of applications, in order to hopefully give more time and certainty to the selected proposal to start planning. The board will begin evaluating proposals on February 20th. The selection will be made at any time between February 20th and May 31st. The DSF Board will communicate when a selection has been made and the application process is complete. IF you are interested in organizing it is in your best interest to get a good proposal in early.
Following the established tradition, the selected hosts will be publicly announced at this year's DjangoCon Europe by the current organizers.
The more detailed and complete your proposal, the better. Things you should consider, and that we'd like to know about, are:
- dates Ideally between early January and mid April 2025
- numbers of attendees
- venue(s)
- accommodation
- transport links
- budgets and ticket prices
- committee members
We'd like to see:
- timelines
- pictures
- prices
- draft agreements with providers
- alternatives you have considered
Email you proposals to djangocon-europe-2025-proposals at djangoproject dot com. We look forward to reviewing great proposals that continue the excellence the whole community associates with DjangoCon Europe.
Real Python: Inheritance and Composition: A Python OOP Guide
In this tutorial, you’ll explore inheritance and composition in Python. Inheritance and composition are two important concepts in object-oriented programming that model the relationship between two classes. They’re the building blocks of object-oriented design, and they help programmers to write reusable code.
By the end of this tutorial, you’ll know how to:
- Use inheritance in Python
- Model class hierarchies using inheritance
- Use multiple inheritance in Python and understand its drawbacks
- Use composition to create complex objects
- Reuse existing code by applying composition
- Change application behavior at runtime through composition
Get Your Code: Click here to get the free sample code that shows you how to use inheritance and composition in Python.
What Are Inheritance and Composition?Inheritance and composition are two major concepts in object-oriented programming that model the relationship between two classes. They drive the design of an application and determine how the application should evolve as new features are added or requirements change.
Both of them enable code reuse, but they do it in different ways.
What’s Inheritance?Inheritance models what’s called an is a relationship. This means that when you have a Derived class that inherits from a Base class, you’ve created a relationship where Derived is a specialized version of Base.
Inheritance is represented using the Unified Modeling Language, or UML, in the following way:
This model represents classes as boxes with the class name on top. It represents the inheritance relationship with an arrow from the derived class pointing to the base class. The word extends is usually added to the arrow.
Note: In an inheritance relationship:
- Classes that inherit from another are called derived classes, subclasses, or subtypes.
- Classes from which other classes are derived are called base classes or super classes.
- A derived class is said to derive, inherit, or extend a base class.
Say you have the base class Animal, and you derive from it to create a Horse class. The inheritance relationship states that Horse is an Animal. This means that Horse inherits the interface and implementation of Animal, and you can use Horse objects to replace Animal objects in the application.
This is known as the Liskov substitution principle. The principle states that if S is a subtype of T, then replacing objects of type T with objects of type S doesn’t change the program’s behavior.
You’ll see in this tutorial why you should always follow the Liskov substitution principle when creating your class hierarchies, and you’ll learn about the problems that you’ll run into if you don’t.
What’s Composition?Composition is a concept that models a has a relationship. It enables creating complex types by combining objects of other types. This means that a class Composite can contain an object of another class Component. This relationship means that a Composite has a Component.
UML represents composition as follows:
The model represents composition through a line that starts with a diamond at the composite class and points to the component class. The composite side can express the cardinality of the relationship. The cardinality indicates the number or the valid range of Component instances that the Composite class will contain.
In the diagram above, the 1 represents that the Composite class contains one object of type Component. You can express cardinality in the following ways:
- A number indicates the number of Component instances that Composite contains.
- The * symbol indicates that the Composite class can contain a variable number of Component instances.
- A range 1..4 indicates that the Composite class can contain a range of Component instances. You indicate the range with the minimum and maximum number of instances, or minimum and many instances like in 1..*.
Note: Classes that contain objects of other classes are usually referred to as composites, while classes that are used to create more complex types are referred to as components.
For example, your Horse class can be composed by another object of type Tail. Composition allows you to express that relationship by saying Horse has a Tail.
Read the full article at https://realpython.com/inheritance-composition-python/ »[ 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 ]
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
- About QML Efficiency: Compilers, Language Server, and Type Annotations
- CKEditor: Enhance Your Drupal Experience with the Free CKEditor 5 Plugin Pack
- Zato Blog: What is an API gateway?
- FSF Blogs: Sharing day two of LibrePlanet 2024: Cultivating Community
- Sharing day two of LibrePlanet 2024: Cultivating Community