Feeds

Review: Overdue and Returns, by Mark Lawrence

Publisher: Mark Lawrence Copyright: June 2023 Copyright: February 2024 ASIN: B0C9N51M6Y ASIN: B0CTYNQGBX Format: Kindle Pages: 99

Overdue is a stand-alone novelette in the Library Trilogy universe. Returns is a collection of two stories, the novelette "Returns" and the short story "About Pain." All of them together are about the length of a novella, so I'm combining them into a single review.

These are ancillary stories in the same universe as the novels, but not necessarily in the same timeline. (Trying to fit "About Pain" into the novel timeline will give you a headache and I am choosing to read it as author's fan fiction.) I'm guessing they're part of the new fad for releasing short fiction on Amazon to tide readers over and maintain interest between books in a series, a fad about which I have mixed feelings. Given the total lack of publisher metadata in either the stories or on Amazon, I'm assuming they were self-published even though the novels are published by Ace, but I don't know that for certain.

There are spoilers for The Book That Wouldn't Burn, so don't read these before that novel. There are no spoilers for The Book That Broke the World, and I don't think the reading order would matter.

I found all three of these stories irritating and thuddingly trite. "Returns" is probably the best of the lot in terms of quality of storytelling, but I intensely dislike the structural implications of the nature of the book at its center and am therefore hoping that it's non-canonical.

I would not waste your time with these even if you are enjoying the novels.

"Overdue": Three owners of the same bookstore at different points in time have encounters with an albino man named Yute who is on a quest. One of the owners is trying to write a book, one of them is older, depressed, and closed off, and one of them has regular conversations with her sister's ghost. The nature of the relationship between the three is too much of a spoiler, but it involves similar shenanigans as The Book That Wouldn't Burn.

Lawrence uses my least favorite resolution of benign ghost stories. The story tries very hard to sell it as a good thing, but I thought it was cruel and prefer fantasy that rejects both branches of that dilemma. Other than that, it was fine, I guess, although the moral was delivered with all of the subtlety of the last two minutes of a Saturday morning cartoon. (5)

"Returns": Livira returns a book deep inside the library and finds that she can decipher it, which leads her to a story about Yute going on a trip to recover another library book. This had a lot of great Yute lines, plus I always like seeing Livira in exploration mode. The book itself is paradoxical in a causality-destroying way, which is handwaved away as literal magic. I liked this one the best of the three stories, but I hope the world-building of the main series does not go in this direction and I'm a little afraid it might. (6)

"About Pain": A man named Holden runs into a woman named Clovis at the gym while carrying a book titled Catcher that his dog found and that he's returning to the library. I thoroughly enjoy Clovis and was happy to read a few more scenes about her. Other than that, this was fine, I guess, although it is a story designed to deliver a point and that point is one that appears in every discussion of classics and re-reading that has ever happened on the Internet. Also, I know I'm being grumpy, but Lawrence's puns with authors and character names are chapter-epigraph amusing but not short-story-length funny. Yes, yes, his name is Holden, we get it. (5)

Rating: 5 out of 10

Focus

This month I didn't have any particular focus. I just worked on issues in my info bubble.

Changes

• ArchiveBot: improve dashboard filtering
• Debian wiki pages: ArmPorts, Exploits

Issues

• FLOSS license needed for ThreadTree
• Features in ThreadTree (1 2 3 4 5), systemd-cron
• Warnings in kraft, python3-pypandoc

Sponsors

All work was done on a volunteer basis.

The shared web proxy used on Wikimedia Cloud VPS now has technical support for using arbitrary domains (and not just wmcloud.org subdomains) in proxy names. I think this is a good example of how software slowly evolves over time as new requirements emerge, with each new addition building on top of the previous ones.

According to the edit history on Wikitech, the web proxy service has its origins in 2012, although the current idea where you create a proxy and map it to a specific instance and port was only introduced a a year later. (Before that, it just directly mapped the subdomain to the VPS instance with the same name).

There were some smaller changes in the coming years like the migration to acme-chief for TLS certificate management, but the overall logic stayed very similar until 2020 when the wmcloud.org domain was introduced. That was implemented by adding a config option listing all possible domains, so future domain additions would be as simple as adding the new domain to that list in the configuration.

Then the changes start becoming more frequent:

• In 2022, for my Terraform support project, a bunch of logic, including the list of supported backend domains was moved from the frontend code to the backend. This also made it possible to dynamically change which projects can use which domains suffixes for their proxies.
• Then, early this year, I added support for zones restricted to a single project, because we wanted to use the proxy for the *.svc.toolforge.org Toolforge infrastructure domains instead of coming up with a new system for that use case. This also added suport for using different TLS certificates for different domains so that we would not have to have a single giant certificate with all the names.
• Finally, the last step was to add two new features to the proxy system: support for adding a proxy at the apex of a domain, as well as support for domains that are not managed in Designate (the Cloud VPS/OpenStack auth DNS service). In addition, we needed a bit of config to ensure http-01 challenges get routed to the acme-chief instance.

Video: An Introduction to Human-Centred Design

Watch the recording of 'An Introduction to Human-Centred Design', presented by Elise West at DrupalCon Barcelona 2024

Tamsin Fox-Davies Thu, 10/31/2024 - 22:23

…to talk about the so-called “Intellectual Property”?

We are happy to announce the release of Qt Creator 15 Beta2!

I’ve been writing code for the Z3 SMT solver for several months now. Here are my findings.

Python is used here as the base language. Python/Z3 feels like a two-layer programming model—declarative code for Z3, imperative code for Python. In this it seems reminiscent of C++/CUDA programming for NVIDIA GPUs—in that case, mixed CPU and GPU imperative code. Either case is a clever combination of methodologies that is surprisingly fluent and versatile, albeit not a perfect blend of seamless conceptual cohesion.

Other comparisons:

• Both have two separate memory spaces (CUDA CPU/GPU memories for one; pure Python variables and Z3 variables for the other).
• Both can be tricky to debug. In earlier days, CUDA had no debugger, so one had to fall back to the trusty “printf” statement (for a while it didn’t even have that!). If the code crashed, you might get no output at all. To my knowledge, Z3 has no dedicated debugger. If the problem being solved comes back as satisfiable, you can print out the discovered model variables, but if satisfiability fails, you get very little information. Like some other novel platforms, something of a “black box.”
• In both cases, programmer productivity can be well-served by developing custom abstractions. I developed a Python class to manage multidimensional arrays of Z3 variables, this was a huge time saver.

There are differences too, of course.

• In Python, “=” is assignment, but in Z3, one only has “==”, logical or numeric equality, not assignment per se. Variables are set once and can’t be changed—sort of a “write-once variables” programming model—as is natural to logic programming.
• Code speed optimization is challenging. Code modifications for Z3 constraints/variables can have extreme and unpredictable runtime effects, so it’s hard to optimize. Z3 is solving an NP-complete problem after all, so runtimes can theoretically increase massively. Speedups can be massive also; one round of changes I made gave 2000X speedup on a test problem. Runtime of CUDA code can be unpredictable to a lesser degree, depending on the PTX and SASS code generation phases and the aggressive code optimizations of the CUDA compiler. However, it seems easier to “see through” CUDA code, down to the metal, to understand expected performance, at least for smaller code fragments. The Z3 solver can output statistics of the solve, but these are hard to actionably interpret for a non-expert.
• Z3 provides many, many algorithmic tuning parameters (“tactics”), though it’s hard to reason about which ones to pick. Autotuners like FastSMT might help. Also there have been some efforts to develop tools to visualize the solve process, this might be of help.

It would be great to see more modern tooling support and development of community best practices to help support Z3 code developers.

The post How hard is constraint programming? first appeared on John D. Cook.

Drupal 11 Released - Key Features and Modernised Technology Drupal Logo_vertical_Black.png sinduri.guntup… Thu, 10/31/2024 - 12:00 Drupal 11 was released on August 2, 2024, introducing a suite of new features and enhancements aimed at improving functionality, performance, and user experience. In this article, we will highlight the most significant updates, and emphasise the importance of ongoing maintenance for your Drupal sites.

In an era where digital security is paramount, the European Union is taking steps to improve cybersecurity legislation with the introduction of the European Union Cyber Resilience Act (CRA). As the European Union has now adopted the CRA, Qt Group continues to work towards making our products CRA compliant and supporting our customers with their compliancy. 

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

Ankündigung

Python Meeting Herbst Sprint 2024 in
Düsseldorf

Samstag, 09.11.2024, 10:00-18:00 Uhr
Sonntag, 10.11.2024. 10:00-18:00 Uhr

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

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

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

• Sprint Ort in Google Maps
  

Folgende Themengebiete sind als Anregung bereits angedacht:

• AI/ML: Bilderkennung mit Azure Computervision
• AI/ML: Texte und Meta Daten aus Presseseiten extrahieren, mit Hilfe eines lokalen LLMs
• AI/ML: Transkription von Videos/Audiodateien mit Whisper
• Kodi Add-Ons für ARD, ZDF und ARTE
  

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

Anmeldung, Kosten und weitere Infos

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

• Python Spring Sprint & Hackathon in Düsseldorf
  

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

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

• PyDDF Telegram Gruppe

Über das Python Meeting Düsseldorf

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

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

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

Viel Spaß !

Marc-André Lemburg, eGenix.com

We just released CXX-Qt version 0.7!

CXX-Qt is a set of Rust crates for creating bidirectional Rust ⇄ C++ bindings with Qt. It supports integrating Rust into C++ applications using CMake or building Rust applications with Cargo. CXX-Qt provides tools for implementing QObject subclasses in Rust that can be used from C++, QML, and JavaScript.

For 0.7, we have stabilized the cxx-qt bridge macro API and there have been many internal refactors to ensure that we have a consistent baseline to support going forward. We encourage developers to reach out if they find any unclear areas or missing features, to help us ensure a roadmap for them, as this may be the final time we can adapt the API. In the next releases, we’re looking towards stabilizing the cxx-qt-build and getting the cxx-qt-lib APIs ready for 1.0.

Check out the new release through the usual channels:

• The CXX-Qt book
• The CXX-Qt documentation
• The CXX-Qt-lib documentation
• Our Github repository

Some of the most notable developer-facing changes: Stabilized #[cxx_qt::bridge] macro

CXX-Qt 0.7 reaches a major milestone by stabilizing the bridge macro that is at the heart of CXX-Qt. You can now depend on your CXX-Qt bridges to remain compatible with future CXX-Qt versions. As we’re still pre-1.0, we may still introduce very minor breaking changes to fix critical bugs in the edge-cases of the API, but the vast majority of bridges should remain compatible with future versions.

This stabilization is also explicitly limited to the bridge API itself. Breaking changes may still occur in e.g. cxx-qt-lib, cxx-qt-build, and cxx-qt-cmake. We plan to stabilize those crates in the next releases.

Naming Changes

The handling of names internally has been refactored to ensure consistency across all usages. During this process, implicit automatic case conversion has been removed, so cxx_name and rust_name are now used to specify differing Rust and C++ names. Since the automatic case conversion is useful, it can be explicitly enabled using per extern block attributes auto_cxx_name and auto_rust_name, while still complimenting CXX. For more details on how these attributes can be used, visit the attributes page in the CXX-Qt book.

// with 0.6 implicit automatic case conversion #[cxx_qt::bridge] mod ffi { unsafe extern "RustQt" { #[qobject] #[qproperty(i32, my_number) // myNumber in C++ type MyObject = super::MyObjectRust; fn my_method(self: &MyObject); // myMethod in C++ } } // with 0.7 cxx_name / rust_name #[cxx_qt::bridge] mod ffi { unsafe extern "RustQt" { #[qobject] #[qproperty(i32, my_number, cxx_name = "myNumber") type MyObject = super::MyObjectRust; #[cxx_name = "myMethod"] fn my_method(self: &MyObject); } } // with 0.7 auto_cxx_name / auto_rust_name #[cxx_qt::bridge] mod ffi { #[auto_cxx_name] // <-- enables automatic cxx_name generation within the `extern "RustQt"` block unsafe extern "RustQt" { #[qobject] #[qproperty(i32, my_number) // myNumber in C++ type MyObject = super::MyObjectRust; fn my_method(self: &MyObject); // myMethod in C++ } } cxx_file_stem Removal

In previous releases, the output filename of generated C++ files used the cxx_file_stem attribute of the CXX-Qt bridge. This has been changed to use the filename of the Rust source file including the directory structure.

Previously, the code below would generate a C++ header path of my_file.cxxqt.h. After the changes, the cxx_file_stem must be removed and the generated C++ header path changes to crate-name/src/my_bridge.cxxqt.h. This follows a similar pattern to CXX.

// crate-name/src/my_bridge.rs // with 0.6 a file stem was specified #[cxx_qt::bridge(cxx_file_stem = "my_file")] mod ffi { ... } // with 0.7 the file path is used #[cxx_qt::bridge] mod ffi { ... } Build System Changes

The internals of the build system have changed so that dependencies are automatically detected and configured by cxx-qt-build, libraries can pass build information to cxx-qt-build, and a CXX-Qt CMake module is now available providing convenience wrappers around corrosion. This means that the cxx-qt-lib-headers crate has been removed and only cxx-qt-lib is required. With these changes, there is now no need for the -header crates that existed before. Previously, some features were enabled by default in cxx-qt-lib. Now these are all opt-in. We have provided full and qt_full as convenience to enable all features; however, we would recommend opting in to the specific features you need.

We hope to improve the API of cxx-qt-build in the next cycle to match the internal changes and become more modular.

Further Improvements

CXX-Qt can now be successfully built for WASM, with documented steps available in the book and CI builds for WASM to ensure continued support.

Locking generation on the C++ side for all methods has been removed, which simplifies generation and improves performance. Using queue from cxx_qt::CxxQtThread is still safe, as it provides locking, but it is up to the developer to avoid incorrect multi-threading in C++ code (as in the CXX crate). Note that Qt generally works well here, with the signal/slot mechanism working safely across threads.

As with most releases, there are more Qt types wrapped in cxx-qt-lib and various other changes are detailed in the CHANGELOG.

Make sure to subscribe to the KDAB YouTube channel, where we’ll post more videos on CXX-Qt in the coming weeks.

Thanks to all of our contributors that helped us with this release:

• Ben Ford
• Laurent Montel
• Matt Aber
• knox (aka @knoxfighter)
• Be Wilson
• Joshua Goins
• Alessandro Ambrosano
• Alexander Kiselev
• Alois Wohlschlager
• Darshan Phaldesai
• Jacob Alexander
• Sander Vocke

About KDAB

If you like this article and want to read similar material, consider subscribing via our RSS feed.

Subscribe to KDAB TV for similar informative short video content.

KDAB provides market leading software consulting and development services and training in Qt, C++ and 3D/OpenGL. Contact us.

The post CXX-Qt 0.7 Release appeared first on KDAB.

KDE’s yearly fundraiser is now live, with the theme of spooooky proprietary software. Go check it out — no, really! It’s great!

I think this one absolutely nails it, because the stories there are relatable. They describe common problems with proprietary software most of us have personally experienced in our journeys to the FOSS world, and how FOSS fixes it.

Let me share some of mine:

• When I was a kid, I liked to make movies with my friends and add wacky special effects using a program called AlamDV. I even bought a license to it! After a year, it broke and the developer released version 2, which I dutifully also bought a new license for. Unfortunately, none of my AlamDV 1 projects opened in it. They were lost to the wind.
• Similarly, I also used Apple’s iMovie editing app. At a certain point, they changed it completely to have a totally different UI and no longer open old projects. Still a kid, I never managed to figure out the new UI and all my old projects were lost forever.
• A lot of the digital art I made as a kid was saved in Apple’s .pict file format, which even they eventually dropped support for. When I moved to Linux, I had to write a script to open these files individually and take screenshots of them in order to not lose them forever.
• I’ve been able to consistently recycle older computers and keep them relevant with Plasma. Both of my kids have perfectly serviceable hand-me-down computers revitalized with Fedora KDE. My wife’s old 10 year-old laptop is a testbed for KDE Linux.
• My sister-in-law just last weekend was complaining to me about AI in Photoshop, and was very receptive to the idea of ditching Microsoft and Adobe software entirely. It’s a big turn-off to artists.

This stuff is real, and the work we do has significant impact. It’s not just a toy for nerds. It’s not a basement science project for bored tinkerers. It’s the way computers should be, and can be if enough of us donate our skills, time, and money towards the goal.

How will the fundraised money be used? Principally, to help KDE e.V. balance its budget and stop operating at a loss (about -110k last year, projected -70k this year) due to the legal requirement to spend down large lump-sum donations in a timely manner. We can sustain this level of deficit spending for a few more years, but of course would prefer not to. It’s been a tough environment for nonprofits, and you might have heard that the GNOME Foundation recently ran into financial trouble trouble had to cut back. We want to avoid that! The sooner we’re operating at a surplus again, the sooner we can expand our sponsorship of engineering work beyond its current level.

So go donate today, and make a difference in the most important movement in software today!

When it comes to digital content, accessibility isn't just a nice-to-have. It's essential. That's why we recently took on the challenge of transforming our eBook collection from PDFs into a fully accessible web format. We often help our clients clean up their PDFs, and absent very specific circumstances, we recommend avoiding them as web content. Based on our own advice, our own website was lacking.

In this episode of The Python Show Podcast, we welcome Yury Selivanov as our guest. Yury is a core CPython developer and co-founder of EdgeDB and MagicStack.

We chatted about many different topics, including the following:

• Core Python development

• EdgeDB and how it differs from relational databases

• Python without the GIL

• Python subinterpreters

• Memhive

• and more!

Links

Learn more about our guest and the topics we talked about with the following links:

• Yury’s GitHub page

• EdgeDB on GitHub

• EdgeDB’s website

• PyCon 2024 - Yury Selivanov: Overcoming GIL with subinterpreters and immutability

• An article about Memhive

Use Google Search Console to be a better listener by understanding what search queries that are bringing visitors to your website.

As a member of the leadership team for Drupal CMS, the new product that makes Drupal more accessible to marketers and content teams, I’ve spent the last three months engaging with various teams about their CMS decisions. While I take notes on marketing tools, ease of use, benefits of open source, DXP capabilities, and SaaS options, the core of these conversations often revolves around people and culture.

Who Decides on a CMS?

The decision-maker for a CMS can vary: sometimes it’s a marketer or an IT professional, other times it’s the “head of digital,” or even an agency hired to handle the organization’s digital needs. Although many focus on features, decisions often hinge on feelings, prior experiences, and familiarity. Ultimately, the decisions reflect the experiences of those in the room.
This isn’t to say that the right technical fit isn’t important; rather, it often takes a backseat to personal experiences. it’s crucial to communicate why Drupal aligns with an organization’s digital strategy based on its goals.

Three Types of Websites: Why Drupal is a Great Fit

Let’s categorize websites into three types and discuss why Drupal suits each.

1. Cornerstone of Your Digital Strategy

Every organization needs a digital front door. For established brands, this digital presence serves as the foundation of their online strategy. A known brand must maintain consistent online expression, while an unknown brand needs to tell its story effectively, helping users recognize its voice and identity.
Users want to quickly understand if they’re in the right place and how to connect. They expect seamless integration with third-party tools and easy access to internal data.

Why Choose Drupal?

Drupal excels here because it goes beyond basic content management, offering flexibility for both internal and external users. It supports:

• Integration with third-party tools and data management.
• Enterprise-grade workflows and content management.
• Custom features and transactions.
• Tailored information architecture.
• A blend of structured content and marketing pages.

 Planned Parenthood Direct's mobile-first website serves as a cornerstone of its digital strategy, focusing on creating a distinct sub-brand that resonates with younger audiences while maintaining alignment with the larger Planned Parenthood identity. The site leverages bold colours, playful design elements, and clear messaging to connect with users, driving them to download the app and access reproductive healthcare services.
2. CMS Platform

Many organizations manage a complex ecosystem of websites, often hindered by internal politics and multiple CMSs that lead to inconsistent branding.
A successful CMS platform balances flexibility with guidelines, making site creation easy while adhering to the organization’s branding and content strategy. It often requires standardization of third-party tools.

Why Choose Drupal?

Drupal’s modularity simplifies standardization across websites. It supports:

• Configuration management to allow control over customization
• Flexibility that enables governance at both the platform and individual site levels
• As a widely adopted solution in enterprises, it benefits from optimized hosting tools designed for multi-site management (e.g., Pantheon Custom Upstreams, Acquia Site Factory).

 Evolving Web partnered with the Bibliothèque et Archives nationales du Québec (BAnQ) to redesign its website, building a platform where staff can curate content and users can search across multiple data sources.
3. Marketing Microsite Designed to Scale

Not every organization is large; some startups aim to create single-purpose websites quickly. These organizations need to build fast without sacrificing security or accessibility. Often, marketers seek easy drag-and-drop tools for rapid site creation.

While Drupal has traditionally been overlooked for quick projects, Drupal CMS provides a solution that fosters familiarity among a broader audience, because it lowers the barrier to entry and speeds up the timeline to launch a website. When marketers can create a website quickly, it enhances creativity and ownership, and frees up more time to focus on content and marketing strategy. Drupal CMS will be especially important for making the case for using Drupal for these types of projects.

Why Choose Drupal?

Drupal allows for the rapid launch of marketing sites, which can later scale into a digital cornerstone for an established brand. In particular, Drupal CMS will support:

• Built-in AI tools for site building that free up time to focus on content strategy and handling the influx of feature requests and content decisions that they are often faced with
• Allowing small sites to leverage the same modules and recipes available to larger sites
• No limitations to scaling up a small website to accommodate more content, authors, or functionality

Conclusion: If Drupal Wins, We All Win

Increased usage of Drupal leads to a better experience for everyone involved—developers, site builders, marketers, and content teams. As an open-source platform, Drupal's growth benefits the broader community, including government and non-profit organizations. Improving Drupal enhances a public good rather than enriching proprietary solutions. 

If you're looking to talk more about Drupal and Drupal CMS don’t hesitate to get in touch. 

If Drupal wins, we all win.

+ more awesome articles by Evolving Web

In Python, a closure is typically a function defined inside another function. This inner function grabs the objects defined in its enclosing scope and associates them with the inner function object itself. The resulting combination is called a closure.

Closures are a common feature in functional programming languages. In Python, closures can be pretty useful because they allow you to create function-based decorators, which are powerful tools.

In this tutorial, you’ll:

• Learn what closures are and how they work in Python
• Get to know common use cases of closures
• Explore alternatives to closures

To get the most out of this tutorial, you should be familiar with several Python topics, including functions, inner functions, decorators, classes, and callable instances.

Get Your Code: Click here to download the free sample code that shows you how to use closures in Python.

Take the Quiz: Test your knowledge with our interactive “Python Closures: Common Use Cases and Examples” quiz. You’ll receive a score upon completion to help you track your learning progress:

Interactive Quiz

Python Closures: Common Use Cases and Examples

In this quiz, you'll test your understanding of Python closures. Closures are a common feature in functional programming languages and are particularly popular in Python because they allow you to create function-based decorators.

Getting to Know Closures in Python

A closure is a function that retains access to its lexical scope, even when the function is executed outside that scope. When the enclosing function returns the inner function, then you get a function object with an extended scope.

In other words, closures are functions that capture the objects defined in their enclosing scope, allowing you to use them in their body. This feature allows you to use closures when you need to retain state information between consecutive calls.

Closures are common in programming languages that are focused on functional programming, and Python supports closures as part of its wide variety of features.

In Python, a closure is a function that you define in and return from another function. This inner function can retain the objects defined in the non-local scope right before the inner function’s definition.

To better understand closures in Python, you’ll first look at inner functions because closures are also inner functions.

Inner Functions

In Python, an inner function is a function that you define inside another function. This type of function can access and update names in their enclosing function, which is the non-local scope.

Here’s a quick example:

Python >>> def outer_func(): ... name = "Pythonista" ... def inner_func(): ... print(f"Hello, {name}!") ... inner_func() ... >>> outer_func() Hello, Pythonista! >>> greeter = outer_func() >>> print(greeter) None Copied!

In this example, you define outer_func() at the module level or global scope. Inside this function, you define the name local variable. Then, you define another function called inner_func(). Because this second function lives in the body of outer_func(), it’s an inner or nested function. Finally, you call the inner function, which uses the name variable defined in the enclosing function.

When you call outer_func(), inner_func() interpolates name into the greeting string and prints the result to your screen.

Note: To learn more about inner functions, check out the Python Inner Functions: What Are They Good For? tutorial.

In the above example, you defined an inner function that can use the names in the enclosing scope. However, when you call the outer function, you don’t get a reference to the inner function. The inner function and the local names won’t be available outside the outer function.

In the following section, you’ll learn how to turn an inner function into a closure, which makes the inner function and the retained variables available to you.

Function Closures

All closures are inner functions, but not all inner functions are closures. To turn an inner function into a closure, you must return the inner function object from the outer function. This may sound like a tongue twister, but here’s how you can make outer_func() return a closure object:

Python >>> def outer_func(): ... name = "Pythonista" ... def inner_func(): ... print(f"Hello, {name}!") ... return inner_func ... >>> outer_func() <function outer_func.<locals>.inner_func at 0x1066d16c0> >>> greeter = outer_func() >>> greeter() Hello, Pythonista! Copied! Read the full article at https://realpython.com/python-closure/ »

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

Zizmor is a new tool to check your GitHub action workflows for security concerns. I found it really helpful to lock down actions.

Action workflows can be esoteric, and continuous integration is not everyone’s top concern, so it’s easy for them to have subtle flaws. A tool like zizmor is great for drawing attention to them.

When I ran it, I had a few issues to fix:

• Some data available to actions is manipulable by unknown people, so you have to avoid interpolating it directly into shell commands. For example, you might want to add the branch name to the action summary: - name: "Summarize"
    run: |
      echo "### From branch ${{ github.ref }}" >> $GITHUB_STEP_SUMMARY
  But github.ref is a branch name chosen by the author of the pull request. It could have a shell injection which could let an attacker exfiltrate secrets. Instead, put the value into an environment variable, then use it to interpolate: - name: "Summarize"
    env:
      REF: ${{ github.ref }}
    run: |
      echo "### From branch ${REF}" >> $GITHUB_STEP_SUMMARY
  
• The actions/checkout step should avoid persisting credentials: - name: "Check out the repo"
    uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
    with:
      persist-credentials: false
  
• In steps where I was pushing to GitHub, this meant I needed to explicitly set a remote URL with credentials: - name: "Push digests to pages"
    env:
      GITHUB_TOKEN: ${{ secrets.token }}
    run: |
      git config user.name nedbat
      git config user.email ned@nedbatchelder.com
      git remote set-url origin https://x-access-token:${GITHUB_TOKEN}@github.com/${GITHUB_REPOSITORY}.git
  

There were some other things that were easy to fix, and of course, you might have other issues. One improvement to zizmor: it could link to explanations of how to fix the problems it finds, but it wasn’t hard to find resources, like GitHub’s Security hardening for GitHub Actions.

William Woodruff is zizmor’s author. He was incredibly responsive when I had problems or questions about using zizmor. If you hit a snag, write an issue. It will be a good experience.

If you are like me, you have repos lying around that you don’t think about much. These are a special concern, because their actions could be years old, and not well maintained. These dusty corners could be a good vector for an attack. So I wanted to check all of my repos.

With Claude’s help I wrote a shell script to find all git repos I own and run zizmor on them. It checks the owner of the repo because my drive is littered with git repos I have no control over:

#!/bin/bash
# zizmor-repos.sh

echo "Looking for workflows in repos owned by: $*"

# Find all git repositories in current directory and subdirectories
find . \
    -type d \( \
        -name "Library" \
        -o -name "node_modules" \
        -o -name "venv" \
        -o -name ".venv" \
        -o -name "__pycache__" \
    \) -prune \
    -o -type d -name ".git" -print 2>/dev/null \
| while read gitdir; do
    # Get the repository directory (parent of .git)
    repo_dir="$(dirname "$gitdir")"

    # Check if .github/workflows exists
    if [ -d "${repo_dir}/.github/workflows" ]; then
        # Get the GitHub remote URL
        remote_url=$(git -C "$repo_dir" remote get-url origin)

        # Check if it's our repository
        # Handle both HTTPS and SSH URL formats
        for owner in $*; do
            if echo "$remote_url" | grep -q "github.com[/:]$owner/"; then
                echo ""
                echo "Found workflows in $owner repository: $repo_dir"
                ~/.cargo/bin/zizmor $repo_dir/.github/workflows
            fi
        done
    fi
done

After fixing issues, it’s very satisfying to see:

% zizmor-repos.sh nedbat BostonPython
Looking for workflows in repos owned by: nedbat BostonPython

Found workflows in nedbat repository: ./web/stellated
🌈 completed ping-nedbat.yml
No findings to report. Good job!

Found workflows in nedbat repository: ./web/nedbat_nedbat
🌈 completed build.yml
No findings to report. Good job!

Found workflows in nedbat repository: ./scriv
🌈 completed tests.yml
No findings to report. Good job!

Found workflows in nedbat repository: ./lab/gh-action-tests
🌈 completed matrix-play.yml
No findings to report. Good job!

Found workflows in nedbat repository: ./aptus/trunk
🌈 completed kit.yml
No findings to report. Good job!

Found workflows in nedbat repository: ./cog
🌈 completed ci.yml
No findings to report. Good job!

Found workflows in nedbat repository: ./dinghy/nedbat
🌈 completed test.yml
🌈 completed daily-digest.yml
🌈 completed docs.yml
No findings to report. Good job!

Found workflows in nedbat repository: ./dinghy/sample
🌈 completed daily-digest.yml
No findings to report. Good job!

Found workflows in nedbat repository: ./coverage/badge-samples
🌈 completed samples.yml
No findings to report. Good job!

Found workflows in nedbat repository: ./coverage/django_coverage_plugin
🌈 completed tests.yml
No findings to report. Good job!

Found workflows in nedbat repository: ./coverage/trunk
🌈 completed dependency-review.yml
🌈 completed publish.yml
🌈 completed codeql-analysis.yml
🌈 completed quality.yml
🌈 completed kit.yml
🌈 completed python-nightly.yml
🌈 completed coverage.yml
🌈 completed testsuite.yml
No findings to report. Good job!

Found workflows in BostonPython repository: ./bospy/about
🌈 completed past-events.yml
No findings to report. Good job!

Nice.

Dacid Brin wrote an interesting article about AI ecosystems and how humans might work with machines on creative projects [1]. Also he’s right about “influencers” being like funghi.

Cory Doctorow wrote an interesting post about DRM, coalitions, and cheating [2]. It seems that people like me who want “trusted computing” to secure their own computers don’t fit well in any of the coalitions.

The CHERI capability system for using extra hardware to validate jump addresses is an interesting advance in computer science [3]. The lecture is froim the seL4 Summit, this sort of advance in security goes well with a formally proven microkernel. I hope that this becomes a checkbox when ordering a custom RISC-V design.

Bunnie wrote an insightful blog post about how the Mossad might have gone about implementing the exploding pager attack [4]. I guess we will see a lot more of this in future, it seems easy to do.

Interesting blog post about Control Flow Integrity in the V8 engine of Chrome [5].

Interesting blog post about the new mseal() syscall which can be used by CFI among other things [6].

This is the Linux kernel documentation about the Control-flow Enforcement Technology (CET) Shadow Stack [7]. Unfortunately not enabled in Debian/Unstable yet.

ARM added support for Branch Target Identification in version 8.5 of the architecture [8].

The CEO of Automatic has taken his dispute with WPEngine to an epic level, this video catalogues it, I wonder what is wrong with him [9].

NuShell is an interesting development in shell technology which runs on Linux and Windows [10].

Interesting article about making a computer game without coding using ML [11]. I doubt that it would be a good game, but maybe educational for kids.

Krebs has an insightful article about location tracking by phones which is surprisingly accurate [12]. He has provided information on how to opt out of some of it on Android, but we need legislative action!

Interesting YouTube video about how to make a 20kW microwave oven and what it can do [13]. Don’t do this at home, or anywhere else!

The Void editor is an interesting project, a fork of VSCode that supports DIRECT connections to LLM systems where you don’t have their server acting as a middle-man and potentially snooping [14].

• [1] https://tinyurl.com/26geg4az
• [2] https://tinyurl.com/29n4hyvv
• [3] https://www.youtube.com/watch?v=VcufX8hZ5-o
• [4] https://tinyurl.com/2beb7ala
• [5] https://v8.dev/blog/control-flow-integrity
• [6] https://tinyurl.com/26p8hlcr
• [7] https://docs.kernel.org/next/x86/shstk.html
• [8] https://tinyurl.com/26ffcrho
• [9] https://www.youtube.com/watch?v=v-imW24OXLY
• [10] https://www.youtube.com/watch?v=zoX_S6d-XU4
• [11] https://tinyurl.com/ysqe79q7
• [12] https://tinyurl.com/258r74cl
• [13] https://www.youtube.com/watch?v=mg79n_ndR68
• [14] https://tinyurl.com/2xtu7kvv

Related posts:

1. Links August 2024 Bruce Schneier and Kim Córdova wrote an insightful article about...
2. Links September 2024 CNA Insider has an insightful documentary series about Chinese illegal...
3. Links June 2024 Modos Labs have released the design of an e-ink display...