Feeds

<p>’Tis the season when people are posting their “Django wishlists”, for specific technical or organizational or community initiatives they’d like to see undertaken. Here are a few&nbsp;examples:</p> <ul> <li><a href="https://gist.github.com/sarahboyce/68ffaaeae24d2501cf27a914f77fb97c">Sarah&nbsp;Boyce</a></li> <li><a href="https://www.better-simple.com">Tim&nbsp;Schilling</a></li> <li><a href="https://softwarecrafts.co.uk/100-words/day-203">Andy&nbsp;Miller</a></li> <li><a href="https://emma.has-a.blog/articles/django-wishlist-explained.html">Emma&nbsp;Delescolle</a></li> </ul> <p>So, in the spirit of the season, here is my own list, which I’ve narrowed down to three wishes (in the tradition of many stories about wishes), consisting of one organizational item and two technical&nbsp;ones.</p> <h3>Pass the&nbsp;torch</h3> <p>This one requires a bit of background, so please bear with&nbsp;me.</p> <p><a href="https://www.djangoproject.com/foundation/">The Django Software Foundation</a> — usually just abbreviated “<span class="caps">DSF</span>” — is the nonprofit organization which officially “owns” Django. It’s the legal holder of all the intellectual property, including both the copyright to the original Django codebase (generously donated by the Lawrence Journal-World, where it was first developed) and the trademarks, such as the registered trademark on the name “Django” itself. The <span class="caps">DSF</span> does a lot (and could do more, with a bigger budget) to support the Django community, and offers financial support to the development of Django itself, but does <em>not</em> directly develop Django, or oversee Django’s development or technical&nbsp;direction.</p> <p>Originally, that job went to Django co-creators Adrian Holovaty and Jacob Kaplan-Moss. They granted commit permissions to a growing team of collaborators, but remained the technical leaders of the Django project until 2014, when they stepped aside and a new body, called the Technical Board, was introduced to replace them. The Technical Board was elected by the Django committers — by this point usually referred to as “Django Core” — and although the committers continued to have broad authority to make additions or changes to Django’s codebase, the Technical Board became the ultimate decision-maker for things that needed a tie-breaking vote, or that were too large for a single committer to do solo (usually via Django Enhancement Proposals, or DEPs, modeled on the processes of many other open-source projects, including Python’s&nbsp;“PEPs”).</p> <p>One thing the <span class="caps">DSF</span> <em>has</em> done is use some of its funds on <a href="https://www.djangoproject.com/fundraising/#fellowship-program">the Django Fellowship program</a>, which pays contractors (the “Django Fellows”) to carry out tasks like ticket triage, pull-request review, etc. which would otherwise rely on volunteer labor (with all the problems that&nbsp;involves).</p> <p>But the system of “Django Core” committers and Technical Board did not work out especially well. Many of the committers were either intermittently active or just completely inactive, new committers were added rarely if ever, and it was unclear what sort of path there was (or even if there <em>was</em> a path) for a motivated contributor to work their way toward committer status. About the only thing that did work well was the Fellowship program, which largely was what kept Django running as a software project toward the end of that&nbsp;era.</p> <p>This caused a lot of debates focused on the theme of what to do about “Django Core” and how to reform the project and get it back on a healthy footing. The end result of that was a Django Enhancement Proposal numbered as <span class="caps">DEP</span> 10, which I spent most of 2018 and 2019 working on. I <a href="https://www.b-list.org/weblog/2018/nov/20/core/">wrote an explanation at the time</a>, and I’ll just link it here and mention that <span class="caps">DEP</span> 10 (which passed <a href="https://www.djangoproject.com/weblog/2020/mar/12/governance/">in early 2020</a>) kept the Technical Board as a tie-breaking and oversight body, and introduced two other main roles — “Mergers” and “Releasers” — which have mostly but not exclusively been filled by the Django Fellows. The first <span class="caps">DEP</span> 10 Technical Board drafted and passed another <span class="caps">DEP</span>, <span class="caps">DEP</span> 12, renaming themselves to “Steering Council” (similar to Python’s technical governing body, but a name I’ve never liked because the Django version doesn’t meaningfully “steer” Django) and making a few&nbsp;tweaks.</p> <p>So, that brings us to the present day. Where, sadly, the <span class="caps">DEP</span> 10/12 era is looking like as much of a failure as the preceding “Django Core” + committer-elected Technical Board era. The <span class="caps">DEP</span> 10 Technical Boards/Steering Councils have been dysfunctional at best, and there’s been no influx of new people from outside the former “Django Core”. A stark example: I ran for the the Steering Council last year to try to work on fixing some of this, but the Steering Council election attracted only four total candidates for five seats, all of them former “Django Core”&nbsp;members.</p> <p>Recently there was a lot of discussion on the <span class="caps">DSF</span> members’ forum about what to do with the Steering Council, and a few attempts to take action which failed in frustrating ways. The end result was the resignation of two Steering Council members, which brought the group below quorum and has automatically triggered an election (though one that will run under the existing <span class="caps">DEP</span> 10/12 rules, since triggering an election locks the eligibility and election rules against&nbsp;changes).</p> <p>I believe the ongoing inability to develop stable technical governance and meaningful turnover of technical leadership is the single greatest threat to Django’s continued viability as a project. This is an unfortunate vindication of what I said six years ago in that blog post about developing <span class="caps">DEP</span>&nbsp;10:</p> <blockquote> <p>Django’s at risk of being badly off in the future; for some time now, the project has not managed to bring in new committers at a sufficient rate to replace those who’ve become less active or even entirely inactive, and that’s not sustainable for much&nbsp;longer.</p> </blockquote> <p>The good news is there’s a new generation of contributors who I believe are more than ready to take up the technical leadership of Django, and even a structured program — <em>not</em> run by former “Django Core”! — <a href="https://djangonaut.space">for recruiting and mentoring new contributors on an ongoing basis and helping them build familiarity with working on and contributing to Django</a>. The bad news is there’s a huge obstacle in their way: all of us old-time “Django Core” folks who keep occupying all the official leadership positions. Just recruiting people to run against such long-time well-known names in the project is difficult, and actually <em>winning</em> against us probably close to&nbsp;impossible.</p> <p>So the biggest thing I’d like for Django, right now, is for the entire former “Django Core” group — myself included! — to simply <em>get out of the way</em>. I thought I could come back last year and help fix things after stepping down post-<span class="caps">DEP</span>-10, but doing so was a mistake and only prolonged the problem. I will not be running in the upcoming Steering Council election and I <em>beg</em> my “Django Core” colleagues to all do likewise. There are qualified, motivated folks out there who should be given their chance to step up and run things, and we should collectively place Django into their capable hands. Then they can sort out the rest of the technical governance however they see&nbsp;fit.</p> <p>And honestly, I’ve been in and out of just about every formal role the Django project has for (checks calendar) seventeen years now. It’s <em>time</em>. It’s time for me, and the rest of the old guard, to give way to new folks before we do serious harm to Django by continuing to hold on to leadership&nbsp;roles.</p> <h3>Give Django a&nbsp;hint</h3> <p>Python 3.0 introduced the ability to add “annotations” to function and method declarations, and though it didn’t specify what they were to be used for, people almost immediately started developing ways to specify static type information via annotations, which came to be known as “type hints”. Python 3.5 formalized this and introduced <a href="https://docs.python.org/3/library/typing.html">the <code>typing</code> module in the standard library</a> with tools to make the type-hint use case easier, and Python 3.6 introduced the ability to annotate other names, including standalone variables and class&nbsp;attributes.</p> <p>Django has a complicated history with this feature of modern Python. There’ve been multiple efforts to add type annotations directly in Django’s own code, there’s <a href="https://pypi.org/project/django-stubs/">a third-party package</a> which provides annotations as an add-on, <a href="https://github.com/django/deps/pull/65">a proposed <span class="caps">DEP</span></a> never went anywhere because <a href="https://groups.google.com/g/django-developers/c/C_Phs05kL1Q/m/fE301y-JCQAJ">the Technical Board at the time was against it</a>, and it’s just been stuck as a frequently-requested feature ever&nbsp;since.</p> <p>Let me be absolutely clear: I don’t have any issue with statically-typed programming languages as a concept. I’ve used both statically- and dynamically-typed languages and liked and disliked examples of each. If I weren’t writing Python, personally I probably would be writing C# (statically-typed). But I also have absolutely no interest in static type checking for Python as a feature or a use&nbsp;case.</p> <p>What I <em>do</em> have an interest in is all the other use cases type hints enable. There’s a whole booming ecosystem of modern Python tools out there now which use type hints to enable all sorts of interesting <em>runtime</em> behavior. <a href="https://docs.pydantic.dev/latest/">Pydantic</a> and <a href="https://jcristharif.com/msgspec/">msgspec</a> do runtime derivation of validation and serialization/deserialization behavior from type hints. <a href="https://fastapi.tiangolo.com">FastAPI</a> and <a href="https://litestar.dev">Litestar</a> are web frameworks which use type hints to drive input/output schemas, dependency injection and more. <a href="https://www.sqlalchemy.org">SQLAlchemy</a> as of version 2.0 can use type hints to drive <span class="caps">ORM</span> class&nbsp;definitions.</p> <p>I am <em>very</em> interested in those sorts of things, and right now they’re not available from vanilla Django because Django doesn’t do type hints (you can use <a href="https://django-ninja.dev">a third-party package</a> to turn Django into something resembling one of the newer type-hint-driven frameworks, but it’s an extra package and a whole new way of doing things that doesn’t “feel like&nbsp;Django”).</p> <p>Compare, for example, this Django <span class="caps">ORM</span>&nbsp;model:</p> <div class="codehilite"><pre><span></span><code><span class="kn">from</span> <span class="nn">django.db</span> <span class="kn">import</span> <span class="n">models</span> <span class="k">class</span> <span class="nc">Person</span><span class="p">(</span><span class="n">models</span><span class="o">.</span><span class="n">Model</span><span class="p">):</span> <span class="n">name</span> <span class="o">=</span> <span class="n">models</span><span class="o">.</span><span class="n">CharField</span><span class="p">()</span> <span class="n">date_of_birth</span> <span class="o">=</span> <span class="n">models</span><span class="o">.</span><span class="n">DateField</span><span class="p">()</span> </code></pre></div> <p>With its modern SQLAlchemy&nbsp;equivalent:</p> <div class="codehilite"><pre><span></span><code><span class="kn">from</span> <span class="nn">datetime</span> <span class="kn">import</span> <span class="n">date</span> <span class="kn">from</span> <span class="nn">sqlalchemy.orm</span> <span class="kn">import</span> <span class="n">DeclarativeBase</span><span class="p">,</span> <span class="n">Mapped</span> <span class="n">Base</span> <span class="o">=</span> <span class="n">DeclarativeBase</span><span class="p">()</span> <span class="k">class</span> <span class="nc">Person</span><span class="p">(</span><span class="n">Base</span><span class="p">):</span> <span class="n">__tablename__</span> <span class="o">=</span> <span class="s2">&quot;person&quot;</span> <span class="n">name</span><span class="p">:</span> <span class="n">Mapped</span><span class="p">[</span><span class="nb">str</span><span class="p">]</span> <span class="n">date_of_birth</span><span class="p">:</span> <span class="n">Mapped</span><span class="p">[</span><span class="n">date</span><span class="p">]</span> </code></pre></div> <p>You <em>can</em> use SQLAlchemy’s <code>mapped_column()</code> function to be more verbose and specify a bunch more information, but for a basic column you <em>don’t have to</em>. Just write a type hint and it does the right&nbsp;thing.</p> <p>I think type hint support in Django has the potential to unlock a huge variety of useful new features and conveniences, and the lack of it is causing Django to fall well behind the current state of the art in Python web development. So if I could somehow wave a magic wand and get any single technical change instantly made to Django, type hints would be&nbsp;it.</p> <h3>More generic&nbsp;Django</h3> <p>Django includes a feature known as “generic views” (keep in mind that Django doesn’t strictly follow regular <span class="caps">MVC</span> terminology, and so a Django “view” is what most pure <span class="caps">MVC</span> implementations would call the “controller”), which are reusable implementations of common operations like “<span class="caps">CRUD</span>” (create, retrieve, update, delete operations — including both individual-result and list-of-results), date-based archives of data,&nbsp;etc.</p> <p>And basically everybody agrees Django’s generic views are too complicated. There’s a giant complex <a href="https://docs.djangoproject.com/en/5.1/ref/class-based-views/">inheritance tree of classes</a> involved, with a huge mess of different attributes and methods you can set or override to affect behavior depending on exactly which set of classes you’re inheriting from, creating a steep learning curve and requiring even experienced developers to spend a lot of time with both official and unofficial documentation (<a href="https://ccbv.co.uk">ccbv.co.uk</a> is the usual reference people are directed&nbsp;to).</p> <p>There’s a reason for this complexity: originally, Django’s generic views were <em>functions</em>, not classes, and you customized their behavior by passing arguments to them. The class-based generic views were introduced in Django 1.3 (released in 2011), and for compatibility and ease of migration at the time, were implemented in a way which <em>precisely</em> mirrored the functionality of the function-based views. Which means that for every thing you could do via an argument to the function-based views, there is a mixin class, method, or attribute on the class-based ones corresponding to&nbsp;it.</p> <p>This made some sense at the time, because it was a big migration to ask people to go through. It makes much less sense now, over 13 years later, when the complexity of Django’s hierarchy of class-based views mostly just scares people and makes them not want to use what is otherwise a pretty useful feature: class-based views are a huge reduction in repetitive/boilerplate code when you know how to use them (for example, see <a href="https://github.com/ubernostrum/b_list/blob/main/blog/views.py">the views used by this site</a> for date-based browsing of entries and detail/list views of entries by category — that really is all the code needed to provide all the backend&nbsp;logic).</p> <p>At this point the overcomplexity of Django’s generic views is basically a meme in the community, and is one of the things I see most often cited by new Django users as making their experience difficult. So if I were going to be given the magic wand a second time and allowed to make another instant technical change, it’d be to finally deprecate the complicated generic-view class hierarchy and replace it with a ground-up rewrite aimed at providing a clear, powerful <span class="caps">API</span> rather than maintaining compatibility with a set of older functions that were deprecated nearly a decade and a half&nbsp;ago.</p> <h3>What do you wish&nbsp;for?</h3> <p>Of course, there’s a lot more that <em>could</em> be done to or for Django besides the three items I’ve outlined here. I’d encourage anyone who uses Django to think about what <em>they’d</em> like to see, to post about it, and, ideally, to get involved with Django’s development. That’s not just a way to get bits of your own wishlist implemented; it’s also the way to make sure Django continues to be around for people to have wishes about, and I hope that continues for many years to&nbsp;come.</p>

.embed-container { position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden; max-width: 100%; } .embed-container iframe, .embed-container object, .embed-container embed { position: absolute; top: 0; left: 0; width: 100%; height: 100%; }

I’ve been teaching Python in one hour knowledge sharing sessions, some of which I’ve put online on youtube.

This is the link to the playlist of the sessions:

• Python Knowledge Share Videos on YouTube

The slides for each of the sessions, along with some example code, can be found in this github repository:

• https://github.com/voidspace/talks

So far there are seven one-hour sessions (with more planned) on:

• Python Core Object Model
  • Python objects
  • Slots
  • Attribute lookup and the MRO
  • Inheritance, multiple inheritance and super
  • Inside Python objects and classes
• Closures and decorators (functional programming)
  • Functional programming: higher order functions and functions as objects
  • Lambdas
  • Closures: functions that build functions
  • Variable scoping: global, local and nonlocal
  • Decorators: functions wrapping functions
  • Decorator factories (decorators that take arguments)
  • Class decorators
  • Decorator order and using functools.wraps
• Generators and Iterators
  • The iteration protocol
  • Stateful iteration with generators
  • Adding iteration support to objects
  • References, assignment and mutability
  • Identity versus equality
  • Call by object
  • Object copying
• Unicode, Floats and regex
  • Floating point numbers
  • Unicode, encodings and strings
  • Regular expressions
• Concurrency (async, threads, processes, the GIL)
  • The history of concurrency from AmigaOS to a multi-core world
  • Python and the Global Interpreter Lock
  • I/O bound and CPU bound tasks
  • Threads and processes
  • Async programming (green threading, coroutines)
  • Concurrency with threads
  • Concurrency with multiprocessing
  • Looking to the future (Python 3.13): optional GIL (PEP 703) and subinterpreters (PEP 554)
• Testing with pytest
  • virtual environments and pipenv (installing pytest)
  • pytest command line for collecting and running tests
  • Simple test functions and asserts
  • Test fixtures and conftest.py
  • Testing exceptions
  • Test parameterisation for test combinations
  • Test marking for running test subsets
  • Principles of testing (unit tests versus end to end testing, building test helpers etc)
  • Mocking and patching
• Modules and Namespaces
  • Import syntax variations
  • namespaces and variable lookups
  • sys.modules and the import cache
  • Module objects
  • Module level functionality: __dir__ and __getattr__
  • Packages and the filesystem
  • Relative import syntax
  • Module reloading (how to do it and why not to do it)
  • Circular imports, avoiding and fixing
  • Executable modules and packages

Other Talks

A selection of some of the talks and interviews I’ve given on Python and software engineering across my career.

• UK Health Security Agency Software Development Practise Conf 2024
• PyCon UK 2023, Metaclasses in 5 Minutes Lightning Talk
• PyCon MEA 2022 How Python Took Over the World
• Test and Code Podcast Episode 145: For Those About to Mock
• PyCon Belarus 2020 How Python Took Over the World
• PyLondinium 2019 The Python Object Model
• Interview on Podcast.__init__ on testing, Mock and the Python community (2018)
• The Role of Abstractions: Lightning Talk PyCon US 2018
• Best Practises for Software Development and Testing (2017)
• PyCon UK Panel 2015
• To the Clouds: EuroPython 2015
• Automated Deployments with Juju: PyCon UK 2014
• Python and Pythons: PyCon NZ 2013
• Testing with Mock: PyCon US 2011
• A Little Bit of Python Podcast (2010-11)
• New and Improved unittest 2: PyCon US 2010
• Michael Foord on IronPython: Hanselminutes 2009
• Michael Foord on IronPython: TechEd 2007

I’ve been a fan of Agile ever since my first programming job with Resolver Systems back in 2006. I had taught myself programming and there I really learned engineering, how to build software products whilst caring about quality. I became passionate about testing as a way to ensure a minimal level of quality and about agile processes which are able to change quickly.

My only experience of Scrum was for a year at a heavily waterfall shop which layered Scrum for project management on top of heavily waterfall software development processes. It wasn’t a fun experience but I still learned a great deal.

I’ve been working with Gigaclear, as team lead on backend API servers, including One Touch Switch, for about a year now. I enjoy our software development practises and processes; we use a combination of agile for software development, devops (devsecops of course) for software deployment and maintenance, and Scrum for project management. It’s a very effective combination.

I recently attended a course with the Agile Alliance, led by John McFadyen, and became certified as a Scrummaster.

The course was fantastic and very inspiring. At Gigaclear we’re systematically evaluating all our systems, systems architecture and processes. This process and the course have been hugely inspirational and I have an article on software development processes coming shortly…

It’s the weekend, and I have some Thoughts about federated social media. So, buckle up, I guess, it’s time to start some fights.

Recently there has been some discourse about Bluesky’s latest fundraising round. I’ve been participating in conversations about this on Mastodon, and I think I might sometimes come across as a Mastodon partisan, but my feelings are complex and I really don’t want to be boosting the ActivityPub Fediverse without qualification.

So here are some qualifications.

Bluesky Is Evil

To the extent that I am an ActivityPub partisan in the discourse between ActivityPub and ATProtocol, it is because I do not believe that Bluesky is a meaningfully decentralized social network. It is a social network, run by a company, which has a public API with some elements that might, one day, make it possible for it to be decentralized. But today, it is not, either practically or theoretically.

The Bluesky developers are putting in a ton of effort to maybe make it decentralized, hypothetically, someday. A lot of people think they will succeed. But ActivityPub (and, of course, Mastodon specifically) are already, today, meaningfully decentralized, as you can see on FediDB, there are instances with hundreds of thousands of people on them, before we even get to esoterica like the integrations Threads, Wordpress, Flipboard, and Ghost are doing.

The inciting incident for this post — that a lot of people are also angry about Bluesky raising millions of dollars from Evil Guys Doing Evil Stuff Capital — is indeed a serious concern. It lights the fuse that burns towards their eventual, inevitable incredible journey. ATProtocol is just an API, and that API will get shut off one day, whenever their funders get bored of the pretense of their network being “decentralized”.

At time of writing, it is also interesting that 3 of the 4 times that the CEO of Bluesky has even skeeted the word “blockchain” is to say “no blockchain”, to reassure users that the scam magnet of “Blockchain” is not actually near their product or protocol, which is a much harder position to maintain when your lead investor is “Blockchain Capital”.

I think these are all valid criticisms of Bluesky. But I also think that the actual engineers working on the product are aware of these issues, and are making a significant effort to address them or mitigate them in any way they can. All that work can still be easily incinerated by a slow quarter in terms of user growth numbers or a missed revenue forecast when the VCs are getting impatient, but it’s not nothing, it is a life’s work.

Really, who among us could not have our life’s ambitions trivially destroyed in an afternoon, simply because a billionaire decided that they should be? If you feel like you are safe from this, I have some bad news about how money works. So we are all doing our best in an imperfect system and maybe Bluesky is on to something here. That’s eminently possible. They’re certainly putting forth an earnest effort.

Mastodon Is Stupid

Meanwhile, not nearly as much has been made recently of Mastodon refusing funding from a variety of sources, when all indications are that funding is low, and plummeting, far below the level required to actually sustain the site, and they haven’t done a financial transparency report for over a year, and that report was already nearly a year late.

Mastodon and the fediverse are not nearly in a position to claim moral superiority over Bluesky. Sure, taking blockchain VC money might seem like a rookie mistake, but going out of business because you are spurning every possible source of funding is not that wise either.

Some might think that, sure, Mastodon the company might die but at least the Fediverse as a whole will keep going strong, right? Lots of people run their own instances! I even find elements of this argument convincing, and I think there is probably some truth to it. But to really believe this argument as claimed, that it’s a fait accompli that the fediverse will survive in some form, that all those self-run servers will be a robust network that will self-repair, requires believing some obviously false stuff. It is frankly unprofitable to run a Fediverse instance. Realistically, if you want to operate a mastodon server for yourself, it is going to cost at least $100/year once you include stuff like having a domain name, and managing the infrastructure costs is a complex problem that keeps getting harder to manage as the software itself gets slower.

Cory Doctorow has recently argued that this is all worth it, because at least on Mastodon, you’re in control, not at the whims of centralized website operators like Bluesky. In his words,

On Mastodon (and other services based on Activitypub), you can easily leave one server and go to another, and everyone you follow and everyone who follows you will move over to the new server. If the person who runs your server turns out to be imperfect in a way that you can’t endure, you can find another server, spend five minutes moving your account over, and you’re back up and running on the new server

He concludes:

Any system where users can leave without pain is a system whose owners have high switching costs and whose users have none

(Emphasis mine).

This is a beautiful vision. It is, however, an incorrect assessment of the state of the Fediverse as it stands today. It’s not true in two important ways:

First, if you look at any account of a user’s fediverse account migration, like this one from Steve Bate or this one from the Ente project or this one from Erin Kissane, you will see that it is “painful for the foreseeable future” or “wasn’t as seamless as advertised”, and that “the best time to […] migrate instances […] is never”. This language does not presage a pleasant experience, as Doctorow puts it, “without pain”.

Second, migration is an active process that requires engagement from the instance that hosts you. If you have been blocked or banned, or had your account terminated, you are just out of luck. You do not have control over your data or agency over your online identity unless you’ve shelled out the relatively exorbitant amount of money to actually operate your own instance.

In short, ActivityPub is no panacea. A federated system is not really a “decentralized” system, as much as it is a bunch of smaller centralized systems that all talk to each other. You still need to know, and care, about your social and financial relationship to the operators of your instance. There is probably no getting away from this, like, just generally on the Internet, no matter how much peer-to-peer software we deploy, but there certainly isn’t in the incomplete mess that is ActivityPub.

JOIN, or DIE.

Neither Mastodon (or ActivityPub) nor Bluesky (or ATProtocol) has a comprehensive solution to the problem of decentralized social media. These companies, and these protocols, are both deeply flawed and if everything keeps bumping along as it is, I believe both are likely to fail. At different times, on different timelines, and for different reasons, but fail nonetheless.

However, these networks are both small and growing, and we are not yet in the phase of enshittification where margins are shrinking and audiences are captured and the screws must be tightened to juice revenue. There are stil possibilities. Mastodon is crowdfunded and what they lack in resources they make up for in flexibility and scrappiness. Bluesky has money and while there will eventually be a need to monetize somehow, they have plenty of runway to come up with that answer, and a lot of sophisticated protocol work has been done. Not enough to make a complete circut and allow users true, practical decentralization, but it’s not nothing, either.

Mastodon and Bluesky are both organizations with humans in them, and piles of data that is roughly schema-compatible even if the nuances and details are different. I know that there is a compatible model becuse thanks to both platforms being relatively open, there is a functioning ActivityPub/ATProtocol bridge in the form of Brid.gy Fed. You can use it today, and I highly recommend that you do so, so that “choice of protocol” does not fully define your audience. If you’re on bluesky, follow this account, and if you’re on Mastodon or elsewhere on the Fediverse, search for and follow @bsky.brid.gy@bsky.brid.gy.

The reality that fans of decentralized, independent social media must confront is that we are a tiny audicence right now. Whichever site we are looking at, we are talking about a few million monthly active users at best, in a world where even the pathetic husk of Twitter still has hundreds of millions and Facebook has billions. Interneceine fights are not going to get us anywhere. We need to build bridges and links and connect our networks as densely as possible. If I’m being honest, Bridgy Fed looks like a pretty janky solution, but it’s something, and we need to start doing something soon, so we do not collectively become a permanent minority that mass markets can safely ignore.

As users, we need to set an example, so that the developers of the respective platforms get their shit together and work together directly so that workarounds like Bridgy are not required. Frankly, this is mostly on the ActivityPub and Mastodon devs, as far as I can tell. Unfortunately, not a lot of this seems to be public, or at least I haven’t witnessed a lot of it directly, but I have heard repeatedly that the ActivityPub developers are prickly, and this is one high-profile public example where an ActivityPub partisan is incredibly, pointlessly hostile and borderline harrassing towards someone — Mike Masnick, a long-time staunch advocate for open protocols and open patents, someone with a Mastodon account, and thus as good a prospective ally as the ActivityPub fediverse might reasonably find — explaining some of the relative benefits of Bluesky.

Most of us are technology nerds in one way or another. In that way we can look at signifiers like “ActivityPub” and “ATProtocol”, and feel like these are hard boundaries around different all-encompassing structures for the future, and thus tribes we must join and support.

A better way to look at this, however, is to see social entities like Mastodon gGmbH and Bluesky PBC — or, more to the point, Fosstodon, SFBA Social, Hachyderm (and maybe, one day, even an instance which isn’t fully just for software development nerds), as groups that deploy these protocols to access some data that they publish, just as they might publish their website over HTTP or their newsletters over SMTP. There are technical challenges involved in bridging between mutually unintelligible domain models, but that is, like, network software's whole deal. Most software is just some kind of translation from one format or context to another. The best possible future for the fediverse is the one where users care as much about the distinction between ATProtocol and ActivityPub as they do about the distinction between POP3 and IMAP.

To both developers and users of these systems, I say: get it together. Be nice to each other. Because the rest of the social media ecosystem is sure as shit not going to be nice to us if we ever see even a hint of success and start to actually cut into their user base.

Acknowledgments

Thank you to my patrons who are supporting my writing on this blog. If you like what you’ve read here and you’d like to read more of it, or you’d like to support my various open-source endeavors, you can support my work as a sponsor!

Session submission open and featured speakers announced for Florida DrupalCamp 2025 mherchel Sun, 11/03/2024 - 16:45

DrupalCamp Scotland returned after a small hiatus of 5 years on the 25th October 2024, and saw nearly 50 people attend the university of Edinburgh Paterson's Land building for a day of talks and sessions. I had the honor of being invited to speak at the conference, which was the first physical speaking session I've had since 2019.

I arrived early to the conference on a sunny Friday morning after driving up the night before. After a cup of coffee and a lovely chat with the organisers and the first few attendees to arrive we started the conference.

The opening talk was from Billy Wardrop, who is Web Development Team Manager in University of Edinburgh. In his talk, A 7 year journey from Drupal 7 to Drupal 10 and what we learned migrating over 600 websites, he went through the lessons he had learned in that migration. This was a fascinating run through of all of the challenges that a web master faces and the history of the migration to Drupal 10 for the University of Edinburgh. It also highlighted the challenges of migrating hundreds of websites from different university departments away from their random systems and into a decent managed Drupal environment. Of particular interest was the talk about deployments as I have faced similar challenges with just 20 sites in the same system.

Next on the agenda was me! I have been writing a lot about the Batch API recently so I decided that I should probably conclude this series of articles with a talk on An Introduction to the Drupal Batch API. Thankfully, I had the week before the conference off, which gave me some time to prepare both the talk and the accompanying code examples.

Read more

The Python square root function, sqrt(), is part of the math module and is used to calculate the square root of a given number. To use it, you import the math module and call math.sqrt() with a non-negative number as an argument. For example, math.sqrt(9) returns 3.0.

This function works with both integers and floats and is essential for mathematical operations like solving equations and calculating geometric properties. In this tutorial, you’ll learn how to effectively use the square root function in Python.

By the end of this tutorial, you’ll understand how:

• Python’s sqrt() function calculates square roots using Python’s math.sqrt() for quick and accurate results in your programs.
• math.sqrt() calculates the square root of positive numbers and zero but raises an error for negative inputs.
• Python’s square root function can be used to solve real-world problems like calculating distances using the Pythagorean theorem.

Time to dive in!

Python Pit Stop: This tutorial is a quick and practical way to find the info you need, so you’ll be back to your project in no time!

Free Bonus: Click here to get our free Python Cheat Sheet that shows you the basics of Python 3, like working with data types, dictionaries, lists, and Python functions.

Square Roots in Mathematics

In algebra, a square, x, is the result of a number, n, multiplied by itself: x = n²

You can calculate squares using Python:

Python >>> n = 5 >>> x = n**2 >>> x 25 Copied!

The Python ** operator is used for calculating the power of a number. In this case, 5 squared, or 5 to the power of 2, is 25.

The square root, then, is the number n, which when multiplied by itself yields the square, x.

In this example, n, the square root of 25, is 5.

25 is an example of a perfect square. Perfect squares are the squares of integer values:

Python >>> 1**2 1 >>> 2**2 4 >>> 3**2 9 Copied!

You might have memorized some of these perfect squares when you learned your multiplication tables in an elementary algebra class.

If you’re given a small perfect square, it may be straightforward enough to calculate or memorize its square root. But for most other squares, this calculation can get a bit more tedious. Often, an estimation is good enough when you don’t have a calculator.

Read the full article at https://realpython.com/python-square-root-function/ »

[ 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 ]

Since WFDF changed their ultimate rules web site to be less-than-ideal (in the name of putting everything into Wordpress…), I made my own, at urules.org. It was a fun journey; I've never fiddled with PWAs before, and I was a bit surprised how low-level it all was. I assumed that since my page is just a bunch of HTML files and ~100 lines of JS, I could just bundle that up—but no, that is something they expect a framework to do for you.

The only primitive you get is seemingly that you can fire up your own background service worker (JS running in its own, locked-down context) and that gets to peek at every HTTP request done and possibly intercept it. So you can use a Web Cache (seemingly a separate concept from web local storage?), insert stuff into that, and then query it to intercept requests. It doesn't feel very elegant, perhaps?

It is a bit neat that I can use this to make my own bundling, though. All the pages and images (painfully converted to SVG to save space and re-flow for mobile screens, mostly by simply drawing over bitmaps by hand in Inkscape) are stuck into a JSON dictionary, compressed using the slowest compressor I could find and then downloaded as a single 159 kB bundle. It makes the site actually sort of weird to navigate; since it pretty quickly downloads the bundle in the background, everything goes offline and the speed of loading new pages just feels… off somehow. As if it's not a Serious Web Page if there's no load time.

Of course, this also means that I couldn't cache PNGs, because have you ever tried to have non-UTF-8 data in a JSON sent through N layers of JavaScript? :-)

Another short status update of what happened on my side last month. Besides a phosh bugfix release improving text input and selection was a prevalent pattern again resulting in improvements in the compositor, the OSK and some apps.

phosh

• Install gir (MR). Needed for e.g. Debian to properly package the Rust bindings.
• Try harder to find an app icon when showing notifications (MR)
• Add a simple Pomodoro timer plugin (MR)
• Small screenshot manager fixes (MR)
• Tweak portals configuration (MR)
• Consistent focus style on lock screen and settings (MR). Improves the visual appearance as the dotted focus frame doesn't match our otherwise colored focus frames
• Don't focus buttons in settings (MR). Improves the visual appearance as attention isn't drawn to the button focus.
• Close Phosh's settings when activating a Settings panel (MR)

phoc

• Improve cursor and cursor theme handling, hide mouse pointer by default (MR)
• Don't submit empty preedit (MR)
• Fix flickering selection bubbles in GTK4's text input fields (MR)
• Backport two more fixes and release 0.41.1 (MR)

phosh-mobile-settings

• Allow to select default text completer (MR, MR)
• Don't crash when we fail to load a pref plugin (MR)

libphosh-rs

• Update with current gir and allow to use status pages (MR)
• Expose screenshot manager and build without warnings (MR). (Improved further by a follow up MR from Sam)
• Fix clippy warnings and add clippy to CI (MR)

phosh-osk-stub

• presage: Always set predictors (MR). Avoids surprises with unwanted predictors.
• Install completer information (MR)
• Handle overlapping touch events (MR). This should improve fast typing.
• Allow plain ctrl and alt in the shortcuts bar (MR
• Use Adwaita background color to make the OSK look more integrated (MR)
• Use StyleManager to support accent colors (MR)
• Fix emoji section selection in RTL locales (MR)
• Don't submit empty preedit (MR). Helps to better preserve text selections.

phosh-osk-data

• Add scripts to build word corpus from Wikipedia data (MR) See here for the data.

xdg-desktop-portal-phosh

• Release 0.42~rc1 (MR)
• Fix HighContrast (MR)

Debian

• Collect some of the QCom workarounds in a package (MR). This is not meant to go into Debian proper but it's nicer than doing all the mods by hand and forgetting which files were modified.
• q6voiced: Fix service configuration (MR)
• chatty: Enable clock test again (MR), and then unbreak translations (MR)
• phosh: Ship gir for libphosh-rs (MR)
• phoc: Backport input method related fix (MR)
• Upload initial package of phosh-osk-data: Status in NEW
• Upload initial package of xdg-desktop-portal-pohsh: Status in NEW
• Backport phosh-osk-stub abbrev fix (MR
• phoc: Update to 0.42.1 (MR
• mobile-tweaks: Enable zram on Librem 5 and PP (MR)

ModemManager

• Some further work on the Cell Broadcast to address comments MR)

Calls

• Further improve daemon mode (MR) (mentioned last month already but got even simpler)

GTK

• Handle Gtk{H,V}Separator when migrating UI files to GTK4 (MR)

feedbackd

• Modernize README a bit (MR)

Chatty

• Use special event for SMS (MR)
• Another QoL fix when using OSK (MR)
• Fix printing time diffs on 32bit architectures (MR)

libcmatrix

• Use endpoints for authenticated media (MR). Needed to support v1.11 servers.

phosh-ev

• Switch to GNOME 47 runtime (MR)

git-buildpackage

• Don't use deprecated pkg-resources (MR)

Unified push specification

• Expand on DBus activation a bit (MR)

swipeGuess

• Small build improvement and mention phosh-osk-stub (Commit)

wlr-clients

• Fix -o option and add help output (MR)

iotas (Note taking app)

• Don't take focus with header bar buttons (MR). Makes typing faster (as the OSK won't hide) and thus using the header bar easier

Flare (Signal app)

• Don't take focus when sending messages, adding emojis or attachments (MR). Makes typing faster (as the OSK won't hide) and thus using those buttons easier

xdg-desktop-portal

• Use categories that work for both xdg-spec and the portal (MR)

Reviews

This is not code by me but reviews on other peoples code. The list is fairly incomplete, hope to improve on this in the upcoming months:

• phosh-tour: add first login mode (MR)
• phosh: Animate swipe closing notifications (MR)
• iio-sensor-proxy: Report correct value on claim (MR)
• iio-sensor-proxy: face-{up,down} (MR)
• phosh-mobile-settings: Squeekboad scaling (MR)
• libcmatrix: Misc cleanups/fixes (MR)
• phosh: Notification separator improvements (MR
• phosh: Accent colors (MR

Help Development

If you want to support my work see donations. This includes a list of hardware we want to improve support for. Thanks a lot to all current and past donors.

Doing more swimming in everyday life for the past few months. Seems like I am keeping that up.

Dolphin's accessibility, Itinerary's travelling aids, and a bunch of new upcoming KDE apps

Welcome to a new issue of "This Week in KDE Apps"! Every week we cover as much as possible of what's happening in the world of KDE apps.

In this issue we discover what developers have been doing to make Dolphin, KDE's most popular (but not only!) file explorer, more accessible. We also take a look at all the new services now integrated into Itinerary that will help you on your travels, the new features for Kate that programmers will enjoy, improvements to Kleopatra to help you manage your certificates and the encryption of your messages, and the flurry of new applications that will soon be available in KDE's software catalog.

This week, we also kicked off our 2024 end-of-year fundraiser just in time for Halloween! Any monetary contribution, however small, will help us cover operational costs, salaries, travel expenses for contributors and in general just keep KDE bringing Free Software to the world. So consider doing a donation today!

Let's dig in!

Dolphin Manage your files

We improved the keyboard navigation of Dolphin, as pressing Ctrl+L multiple times will switch back and forth between focusing and selecting the location bar path and focusing the view. Pressing Escape in the location bar, will now move the focus to the active view (Felix Ernst, 24.12.0. Link).

Speaking of accessibility, the accessibility of the main view of Dolphin was completely overhauled to make it work with screen readers. This work was funded by NGI0 Entrust Fund, a fund established by NLnet with financial support from the European Commission's Next Generation Internet programme (Felix Ernst, 24.12.0. Link).

Another change is that Dolphin will now store its view properties inside the extended file attributes instead of creating hidden .directory files when possible (Méven Car, 24.12.0. Link).

digiKam Photo Management Program

digiKam is KDE's powerful photo management software for both professional and aficionado photographers.

Michael Miller fixed an issue where faces from the facial recognition feature were not deleted when a user untagged or deleted a face (Michael Miller. Link).

Elisa Play music and listen to online radio stations

Jack Hill fixed a few issues related to the lyrics feature. Clicking on the Lyrics button now takes you to the correct lyric and not the previous one, and the last line of the lyrics is not displayed completely (Jack Hill, 24.12.0. Link).

Jack also reworked the metadata dialogs to be more intuitive and correct some bugs (Jack Hill, 24.12.0. Link).

GCompris Educational game for children

GCompris, the educational software suite, got a new activity: Sketch! This fun tool lets children express their creativity and draw beautiful artworks (Timothée Giet. Link).

KDE Itinerary Digital travel assistant

Itinerary now supports extracting reservations from planway.com, flight tickets from VietJet Air and train tickets from the Thai state railway. Additionally, dates from day-specific train tickets from NS (Nederlandse Spoorwegen) are now correctly parsed (Volker Krause, 24.08.3. Link 1, link 2, link 3), and, while on an NS intercity train, you can also access the live journey information provided by the onboard WiFi (Carl Schwan, 24.12.0. Link).

Kate Advanced Text Editor

Kate continues to become more and more developer friendly with the changes made by Christoph Cullmann where the order of the tabs is correctly restored when restoring a previous session (Christoph Cullmann, 24.08.3. Link), and the options of the LSP Symbols are more easily discoverable as they are not only available via a context menu, but also within a menu button at the top (Waqar Ahmed, 24.12.0. Link).

Benjamin Port fixed the Appium UI tests and reenabled them on the CI (Benjamin Port, 28.03.0. Link).

Kdenlive Video editor

Kdenlive is KDE's full-featured video editor, which now lets you resize multiple items on the timeline at the same time. (Jean-Baptiste Mardelle, 24.12.0 Link).

Kleopatra Certificate manager and cryptography app

We redesigned Kleopatra's notepad and sign encrypt dialog. In the notepad, the text editor and the recipients view are also now side by side (Carl Schwan, 24.12.0. Link).

Additionally, Tobias worked on the notepad's result messages and error dialogs to make them clearer. (Tobias Fella, 24.12.0 Link 1, link 2).

Tobias also fixed a crash on non-kwin Wayland compositors (Tobias Fella, 24.08.3. Link), and Kleopatra has a new website (Carl Schwan. Link).

Kongress Conference companion

Kongress is an app which helps you navigate conferences and events.

The newest version will display more information about events in the event list. This includes whether the event is in your bookmarked events and the locations within the event (e.g. the rooms) (cah fof pai, 24.12.0. Link).

Speaking of conferences, multiple KDE people will be at the Chaos Communication Congress (38c3) in Hamburg this December! Come by and say hello!

KStars Desktop Planetarium

KStars is KDE's stargazing app that also helps you control your telescope for astrophotography.

We removed the "Simulate Eyepiece View" feature and stripped down EyepieceField. The reason is the offerings of the eyepiece view feature have already been superseded by two more powerful and easier-to-use features in KStars: the HiPS Overlay and the "Views" feature (Akarsh Simha, 3.7.4. Link).

Kwave Sound editor

Mark Penner wrote a blog post about his work on KWave.

LabPlot Interactive Data Visualization and Analysis

LabPlot is KDE's complete suite of data analysis and visualisation tools.

The LabPlot developers added the RAND_MAX programming constants for GSL (GNU Scientific Library) support. (Martin Marmsoler Link), and rewrote the AsciiFilter to increase the parsing speed, like when parsing livedata from an mqtt feed (Martin Marmsoler. Link).

Kuntal Bar also fixed various issues with HiDPI screens (Kuntal Bar, Link).

Marknote Write down your thoughts

Marknote lets you create rich text notes and easily organise them into notebooks.

The icons in the app are now correctly displayed when running Marknote on other platforms, like Windows (Gary Wang, Link).

Ruqola Rocket Chat Client

Ruqola, KDE's Rocket Chat client, received various fixes for its login, logout and network disconnection features (David Faure & Andras Mantia Link 1, link 2, link 3 and link 4), and the unread message bar now uses buttons instead of more subtle links (Joshua Goins. Link).

Spectacle Screenshot Capture Utility

Spectacle is the utility for taking screenshots and screencasts of your desktop and apps. We fixed an issue where Spectacle would take a screenshot of itself (Noah Davis, 24.08.3. Link).

Other Stuff

The FormCard components used by most Kirigami application are now more compact on the desktop (Carl Schwan, Kirigami Addons 1.6.0 Link).

Before After

The About Page provided by the FormCard component now displays more information about the components used by the application (e.g. Qt, KDE Frameworks) (Carl Schwan, Kirigami Addons 1.6.0. Link).

Playground

This section contains news about non released applications.

Arkade

Arkade, a collection of games written in QML, was updated to Qt6 (Carl Schwan. Link).

Whale

Claudio Cambra ported Whale, a QML based file manager and explorer, to Qt6 (Claudio Cambra. Link). Claudio also added a miller columns view to Whale (Claudio Cambra. Link), and implemented navigation history (Claudio Cambra. Link).

And all this too...

Justin Zobel fixed various appstream files to use the new way of declaring the developer's name (Justin Zobel, KRuler, Gwenview, KEuroCalc, ...).

We ported various projects to use declarative QML declaration for better maintainance and performance (Carl Schwan, Koko, Francis, Kalk).

... And Everything Else

This blog only covers the tip of the iceberg! If you’re hungry for more, check out Nate's blog about Plasma and be sure not to miss his This Week in Plasma series, where every Saturday he covers all the work being put into KDE's Plasma desktop environment.

For a complete overview of what's going on, visit KDE's Planet, where you can find all KDE news unfiltered directly from our contributors.

Get Involved

The KDE organization has become important in the world, and your time and contributions have helped us get there. As we grow, we're going to need your support for KDE to become sustainable.

You can help KDE by becoming an active community member and getting involved. Each contributor makes a huge difference in KDE — you are not a number or a cog in a machine! You don’t have to be a programmer either. There are many things you can do: you can help hunt and confirm bugs, even maybe solve them; contribute designs for wallpapers, web pages, icons and app interfaces; translate messages and menu items into your own language; promote KDE in your local community; and a ton more things.

You can also help us by donating. Any monetary contribution, however small, will help us cover operational costs, salaries, travel expenses for contributors and in general just keep KDE bringing Free Software to the world.

To get your application mentioned here, please ping us in invent or in Matrix.

Best wishes to the entire Debian and Free Software world for a happy and prosperous Gujarati New Year Vikram Samvat 2081 named Anala.

A fun fact: Although Diwali was on Thursday, because it was a vrddha tithi (a lunar day that spans more than one sunrise,) there was a leap day and that's why the new year didn't start till today.

I haven't posted to this blog for almost exactly three years. I had decided that I wasn't going to until I revamped the blog engine to force myself to actually do it and still managed to drag my feet for this long. This post was supposed to be the first public test of the new version but something has gone unexpectedly gone wrong so this is actually a manually uploaded placeholder until I figure out what happened. I have been regularly taking part in the Perl & Raku Weekly Challenge and I write a little about my solutions with yet another half-finished blog engine.

What else have I been up to? Not a lot Debianwise. I voted a couple of times, sponsored a package and (hopefully) assisted one person in becoming a Debian developer. There's the challenge I mentioned which atleast gets me writing some Perl and Raku every week. I did the 7DRL Game Jam again this year and actually produced a playable game. It needs to be polished though (and open sourced.)

This is my major problem; I have all kinds of things which I've started and left incomplete. It's time to do something about it. In the coming months I am going to do a comprehensive review of all the bits of software I've written or contributed to and either complete them, clean them up or properly abandon them. I shall call this Project 2025.

For the last year I’ve been working as a team lead for backend API development with Gigaclear a UK rural ISP who own and run fibre internet to rural communities across the UK. This is alongside my training work.

This image shows the main project I’ve been working on since joining Gigaclear, One Touch Switch. A regulatory requirement for all ISPs to allow automated switching between ISPs. When you sign up with a new internet provider your account is automatically ceased with the old provider and VOIP numbers can be automatically ported.

Our OTS project is just part of the Gigaclear One Touch Switch system which interfaces with Salesforce and Netadmin and the website order flow (the Online Buying Journey) and represents an impressive engineering effort. We were one of the first ISPs with a system ready to take part in industry trials a few months ago, both OTS and our underlying systems passed pen testing with flying colours, and the switch on has been smooth.

Something I’m proud to have been part of. My current project is preparing security awareness training materials based on OWASP for our various engineering departments whilst we also undertake a systematic review of all of our systems and processes.

In the diagram I’m team lead for the Sphinx engineering team.

My first blog post in a few years! I have some articles I’d like to publish, and some adventures to share, so I thought it was time to fire up a blog engine again.

My nine year old son, Benjamin, is really into programming with Scratch and he’s keen to play with electronics and learn MicroPython. Which is awesome because there’s almost nothing I would love to do more with him.

MicroPython is an extremely impressive implementation of Python that will run on embedded devices and microcontrollers, as well as bigger tiny computers like the Raspberry Pi.

I’ve dug out an old MicroBit I had, purchased a Raspberry Pi Pico board/kit and also a ZumoBot 2040 robot which uses the same microcontroller as the Pico, to play with.

I’m now starting to get to grips with the basics, using the Thonny IDE.

I have a bunch of Neopixel LEDs, including a long light strip, I’d like to wire up in my living room controlled by a Pico board and an Android App using Kivy. That’s my goal number 1.

I’d like to program the ZumoBot to explore and map my flat. Goal 2.

Meanwhile Benjamin is enjoying playing with electronics (switches, LEDs, potentiometer and now a motor) with the Pico and on his own he’s programming the MicroBit with Scratch (or at least “blocks” which is the Microsoft equivalent). I’ve also done my first soldering in over a decade.

I have a github repository to track my tinkering, but I’d like to write up some recipes and post them on this blog as I go. (The biggest hurdle is I can’t easily create circuit diagrams. Time to explore.)

The github repository and ZumoBot links:

• https://github.com/voidspace/zumobot
• https://thepihut.com/products/zumo-2040-robot-assembled-with-75-1-hp-motors
• https://www.pololu.com/product/5012
• https://github.com/pololu/zumo-2040-robot

In my opinion, you should only introduce a named tuple to your code when you&aposre updating a preexisting API that was already returning a tuple or you are wrapping a tuple return value from another API.

Let&aposs start with when you should use named tuples. Usually an API that returns a tuple does so when you only have a couple of items in your tuple and the name of the function returning the tuple id enough to explain what each item in the tuple does. But sometimes your API expands and you find that your tuple is no longer self-documenting purely based on the name of the API (e.g., get_mouse_position() very likely has a two-item tuple of X and Y coordinates of the screen while app_state() could be a tuple of anything). When you find yourself in the situation of needing your return type to describe itself and a tuple isn&apost cutting it anymore, then that&aposs when you reach for a named tuple.

So why not start out that way? In a word: simplicity. Now, some of you might be saying to yourself, "but I use named tuples because they are so simple to define!" And that might be true for when you define your data structure (and I&aposll touch on this "simplicity of definition" angle later), but it actually makes your API more complex for both you and your users to use. For you, it doubles the data access API surface for your return type as you have to now support index-based and attribute-based data access forever (or until you choose to break your users and change your return type so it doesn&apost support both approaches). This leads to writing tests for both ways of accessing your data, not just one of them. And you shouldn&apost skimp on this because you don&apost know if your users will use indexes or attribute names to access the data structure, nor can you guarantee someone won&apost break your code in the future by dropping the named tuple and switching to some custom type (thanks to Python&aposs support of structural typing (aka duck typing), you can&apost assume people are using a type checker and thus the structure of your return type becomes your API contract). And so you need to test both ways of using your return type to exercise that contract you have with your users, which is more work than had you not used a named tuple and instead chose just a tuple or just a class.

Named tuples are also a bit more complex for users. If you&aposre reaching for a named tuple you&aposre essentially signalling upfront that the data structure is too big/complex for a tuple alone to work. And yet by using a named tuple means you are supporting the tuple approach even if you don&apost think it&aposs a good idea from the start. On top of that, the tuple API allows for things that you probably don&apost want people doing with your return type, like slicing, iterating over all the items as if they are homogeneous, etc. Basically my argument is the "flexibility" of having the index-based access to the data on top of the attribute-based access isn&apost flexible in a good way.

So why do people still reach for named tuples when defining return types for new APIs? I think it&aposs because people find them faster to define a new type than writing out a new class. Compare this:

Point = namedtuple(&aposPoint&apos, [&aposx&apos, &aposy&apos, z&apos])

To this:

class Point: def __init__(self, x, y, z): self.x = x self.y = y self.z = z

So there is a clear difference in the amount of typing. But there are three more ways to do the same data structure that might not be so burdensome. One is dataclasses:

@dataclasses.dataclass class Point: x: int y: int z: int

Another is simply a dictionary, although I know some prefer attribute-based access to data so much that they won&apost use this option). Toss in a TypedDict and you also get editor support as well:

class Point(typing.TypedDict): x: int y: int z: int # Alternatively ... Point = typing.TypedDict("Point", {"x": int, "y": int, "z": int})

A third option is types.SimpleNamespace if you really want attributes without defining a class:

Point = lambda x, y, z: types.SimpleNamespace(x=x, y=y, z=z)

If none of these options work for you then you can always hope that somehow I convince enough people that my record/struct idea is a good one and get into the language. &#x1F601;

My key point in all of this is to prefer readability and ergonomics over brevity in your code. That means avoiding named tuples except where you are expanding to tweaking an existing API where the named tuple improves over the plain tuple that&aposs already being used.

A hot-fix release 1.0.13-1, consisting of two small PRs relative to the last regular CRAN release 1.0.13, just arrived on CRAN. When we prepared 1.0.13, we included a change related to the ‘tightening’ of the C API of R itself. Sadly, we pinned an expected change to ‘comes with next (minor) release 4.4.2’ rather than now ‘next (normal aka major) release 4.5.0’. And now that R 4.4.2 is out (as of two days ago) we accidentally broke building against the header file with that check. Whoops. Bugs happen, and we are truly sorry—but this is now addressed in 1.0.13-1.

The normal (bi-annual) release cycle will resume with 1.0.14 slated for January. As you can see from the NEWS file of the development branch, we have a number of changes coming. You can safely access that release candidate version, either off the default branch at github or via r-universe artifacts.

The list below details all changes, as usual. The only other change concerns the now-mandatory use of Authors@R.

Changes in Rcpp release version 1.0.13-1 (2024-11-01)

• Changes in Rcpp API:

  • Use read-only VECTOR_PTR and STRING_PTR only with with R 4.5.0 or later (Kevin in #1342 fixing #1341)

• Changes in Rcpp Deployment:

  • Authors@R is now used in DESCRIPTION as mandated by CRAN

Thanks to my CRANberries, you can also look at a diff to the previous release Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page. Bugs reports are welcome at the GitHub issue tracker as well (where one can also search among open or closed issues).

If you like this or other open-source work I do, you can sponsor me at GitHub.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Something many people don’t realize is that I didn’t write the original coverage.py. It was written by Gareth Rees in 2001. I’ve been extending and maintaining it since 2004. This ancient history came up this week, so I grabbed the 2001 version from archive.org to keep it here for posterity.

I already had a copy of Gareth’s original page about coverage.py, which now links to my local copy of coverage.py from 2001. BTW: that page is itself a historical artifact now, with the header from this site as it looked when I first copied the page.

The original coverage.py was a single file, so the “coverage.py” name was literal: it was the name of the file. It only had about 350 lines of code, including a few to deal with pre-2.0 Python! Some of those lines remain nearly unchanged to this day, but most of it has been heavily refactored and extended.

Coverage.py now has about 20k lines of Python in about 100 files. The project now has twice the amount of C code as the original file had Python. I guess in almost 20 years a lot can happen!

It’s interesting to see this code again, and to reflect on how far it’s come.

We can use uv to make linting and testing on GitHub Actions around 1.5 times as fast.

Linting

When using pre-commit for linting:

name: Lint on: [push, pull_request, workflow_dispatch] env: FORCE_COLOR: 1 permissions: contents: read jobs: lint: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 with: persist-credentials: false - uses: actions/setup-python@v5 with: python-version: "3.x" cache: pip - uses: pre-commit/action@v3.0.1

We can replace pre-commit/action with tox-dev/action-pre-commit-uv:

- uses: actions/setup-python@v5 with: python-version: "3.x" - cache: pip - - uses: pre-commit/action@v3.0.1 + - uses: tox-dev/action-pre-commit-uv@v1 name: Lint on: [push, pull_request, workflow_dispatch] env: FORCE_COLOR: 1 permissions: contents: read jobs: lint: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 with: persist-credentials: false - uses: actions/setup-python@v5 with: python-version: "3.x" - uses: tox-dev/action-pre-commit-uv@v1

This means uv will create virtual environments and install packages for pre-commit, which is faster for the initial seed operation when there's no cache.

Lint comparison

For example: python/blurb#32

Before After Times faster No cache 60s 37s 1.62 With cache 11s 11s 1.00 Testing

When testing with tox:

name: Test on: [push, pull_request, workflow_dispatch] permissions: contents: read env: FORCE_COLOR: 1 jobs: test: runs-on: ubuntu-latest strategy: fail-fast: false matrix: python-version: ["3.9", "3.10", "3.11", "3.12", "3.13", "3.14"] steps: - uses: actions/checkout@v4 with: persist-credentials: false - name: Set up Python ${{ matrix.python-version }} uses: actions/setup-python@v5 with: python-version: ${{ matrix.python-version }} allow-prereleases: true cache: pip - name: Install dependencies run: | python --version python -m pip install -U pip python -m pip install -U tox - name: Tox tests run: | tox -e py

We can replace tox with tox-uv:

- name: Set up Python ${{ matrix.python-version }} uses: actions/setup-python@v5 with: python-version: ${{ matrix.python-version }} allow-prereleases: true - cache: pip - - name: Install dependencies - run: | - python --version - python -m pip install -U pip - python -m pip install -U tox + - name: Install uv + uses: hynek/setup-cached-uv@v2 - name: Tox tests run: | - tox -e py + uvx --with tox-uv tox -e py name: Test on: [push, pull_request, workflow_dispatch] permissions: contents: read env: FORCE_COLOR: 1 jobs: test: runs-on: ubuntu-latest strategy: fail-fast: false matrix: python-version: ["3.9", "3.10", "3.11", "3.12", "3.13"] steps: - uses: actions/checkout@v4 with: persist-credentials: false - name: Set up Python ${{ matrix.python-version }} uses: actions/setup-python@v5 with: python-version: ${{ matrix.python-version }} allow-prereleases: true - name: Install uv uses: hynek/setup-cached-uv@v2 - name: Tox tests run: | uvx --with tox-uv tox -e py

tox-uv is tox plugin to replace virtualenv and pip with uv in your tox environments. We only need to install uv, and use uvx to both install tox-uv and run tox, for faster installs of tox, the virtual environment, and the dependencies within it.

Test comparison

For example: python/blurb#32

Before After Times faster No cache 2m 0s 1m 26s 1.40 With cache 1m 58s 1m 22s 1.44 Bonus tip

Run the new tool zizmor to find security issues in GitHub Actions.

Header photo: "Road cycling at the 1952 Helsinki Olympics" by Olympia-Kuva Oy & Helsinki City Museum, Public Domain.

Surprise! This blog post series has now been moved to blogs.kde.org so it’s now open for others to participate and contribute! This week’s post can be found at https://blogs.kde.org/2024/11/02/this-week-in-plasma-spoooooky-ooooooooom-notifications

That’s probably where it should have been all along, as this work is much bigger than me. I’ll remain the editor-in-chief for now, but do welcome contributions to help lighten the load.

Unfortunately, due to GDPR restrictions, I’m unable to migrate existing email subscribers to the new email digest over there. So if you’d like to re-subscribe to “This week in Plasma.” head to https://newsletter.kde.org/subscription/form and re-subscribe.

I’ll still be blogging here about KDE topics of interest to me and hopefully you as well, just not the weekly Plasma news. So I do hope you’ll stick around.

Two months ago I bought a Thinkpad X1 Yoga Gen3 [1]. I’m still very happy with it, the screen is a great improvement over the FullHD screen on my previous Thinkpad. I have yet to discover what’s the best resolution to have on a laptop if price isn’t an issue, but it’s at least 1440p for a 14″ display, that’s 210DPI. The latest Thinkpad X1 Yoga is the 7th gen and has up to 3840*2400 resolution on the internal display for 323DPI. Apple apparently uses the term “Retina Display” to mean something in the range of 250DPI to 300DPI, so my current laptop is below “Retina” while the most expensive new Thinkpads are above it.

I did some tests on external displays and found that this Thinkpad along with a Dell Latitude of the same form factor and about the same age can only handle one 4K display on a Thunderbolt dock and one on HDMI. On Reddit u/Carlioso1234 pointed out this specs page which says it supports a maximum of 3 displays including the built in TFT [2]. The Thunderbolt/USB-C connection has a maximum resolution of 5120*2880 and the HDMI port has a maximum of 4K. The latest Yoga can support four displays total which means 2*5K over Thunderbolt and one 4K over HDMI. It would be nice if someone made a 8000*2880 ultrawide display that looked like 2*5K displays when connected via Thunderbolt. It would also be nice if someone made a 32″ 5K display, currently they all seem to be 27″ and I’ve found that even for 4K resolution 32″ is better than 27″.

With the typical configuration of Linux and the BIOS the Yoga Gen3 will have it’s touch screen stop working after suspend. I have confirmed this for stylus use but as the finger-touch functionality is broken I couldn’t confirm that. On r/thinkpad u/p9k told me how to fix this problem [3]. I had to set the BIOS to Win 10 Sleep aka Hybrid sleep and then put the following in /etc/systemd/system/thinkpad-wakeup-config.service :

# https://www.reddit.com/r/thinkpad/comments/1blpy20/comment/kw7se2l/?context=3 [Unit] Description=Workarounds for sleep wakeup source for Thinkpad X1 Yoga 3 After=sysinit.target After=systemd-modules-load.service [Service] Type=oneshot ExecStart=/bin/sh -c "echo 'enabled' > /sys/devices/platform/i8042/serio0/power/wakeup" ExecStart=/bin/sh -c "echo 'enabled' > /sys/devices/platform/i8042/serio1/power/wakeup" ExecStart=/bin/sh -c "echo 'LID' > /proc/acpi/wakeup" [Install] WantedBy=multi-user.target

Now it works fine, for stylus at least. I still get kernel error messages like the following which don’t seem to cause problems:

wacom 0003:056A:5146.0005: wacom_idleprox_timeout: tool appears to be hung in-prox. forcing it out.

When it wasn’t working I got the above but also kernel error messages like:

wacom 0003:056A:5146.0005: wacom_wac_queue_insert: kfifo has filled, starting to drop events

This change affected the way suspend etc operate. Now when I connect the laptop to power it will leave suspend mode. I’ve configured KDE to suspend when the lid is closed and there’s no monitor connected.

• [1] https://etbe.coker.com.au/2024/01/29/thinkpad-x1-yoga-gen3/
• [2] https://tinyurl.com/2cvq6qts
• [3] https://tinyurl.com/26ho6vxk

Related posts:

1. Thinkpad X1 Yoga Gen3 I just bought myself a Thinkpad X1 Yoga Gen3 for...
2. More About Kogan 5120*2160 Monitor On the 18th of May I blogged about my new...
3. Thinkpad X1 Carbon Gen 6 In February I reviewed a Thinkpad X1 Carbon Gen 1...