Gyroplast

"Cash or credit?" "Arch, btw."

You can open up many avenues of feeding yourself "well enough" if you reconsider your definition of a meal, and consider actual cooking/food prep to be an option.

Cheap and storage-friendly ingredients off the top of head are potatoes, rice, (dried) pasta, flour, cheese, eggs (no need for refrigeration, just don't wash off the protective layer), onions, garlic, tofu, and many hardier vegetables like broccoli, cauliflower, tomatoes, zucchini, carrots, and up to a point even iceberg salad, cucumbers, mushrooms (keep dry and airy if fresh, they dry out), as well as various pickles as snacks, if you're so inclined. With onions, potatoes, and eggs alone you can stuff your face for weeks without repeating a single dish. :)

I keep (vegan) crème fraîche, soy/rice/almond/oat drinks, and "cooking cream" around for weeks unrefrigerated as great milk and cream substitutes, but the milk-based products have a solid shelf life as well as long as they're unopened. This is perfectly viable for various creamy sauces or dips, and for cereals as a snack or breakfast option. With a nice oil or butter and a few seasonings you can whip up a surprising amount of simple meals, starting with classic pasta with a tomato sauce of your liking, to the typical trifecta of "carbs, meat, and veggies with optional sauce" that passes for an actual meal. You can easily build almost any kind of sauce you wish from stable ingredients to go with whatever, too.

There's a good bunch of great thai curry pastes around that go well with a handful of veggies and rice, and keep cooking effort to a minimum. If I'm particularly lazy, I boil a pot of potatoes and eat those straight with sour cream. Leftovers are due for the chippy treatment in a pan with onions and eggs, or just eaten cold as a snack with salt or leftover dip. Same goes for rice, the amount of stuff people throw atop their rice to chase it down is astonishing. Lao Gan Ma chili crisp is great, a straight sweet chili sauce works in a pinch, and if you're into chinese cooking anyway, you can throw almost anything in a pan, fry it up, and toss it to your rice with a generic "brown sauce" deal.

The biggest issue I see is fresh meat, though. That's quickly a serious hazard when kept at room temp, so I'd suggest to try reducing your meat intake as long as you're unable to store it properly, and otherwise cook the same day you buy. Truth be told, a lot of the vegan meat substitutes are surprisingly good by now, even though they're highly processed garbage and pretty expensive for what they are, but they keep unrefrigerated much longer and safer than the real deal. Don't expect a good steak, but anything "chicken" is nigh indistinguishable, IMHO.

All the other things do keep "fresh enough" at least for a couple of days, but you'll need to consider what you buy and when you are able to cook beforehand so things don't spoil, especially if you cannot buy fresh groceries more often than weekly for any reason.

TL;DR: For a generic meal, combine potatoes, rice, or pasta with a vegetable of your least distrust, optionally fresh meat if available, and a decent sauce. In a pinch, sauce + anything also works just fine, and sometimes even without sauce. Just don't take pictures for Insta when horking down a bowl of pasta with ketchup, we've all been there.

Delete the existing file /usr/share/icons/bloom/icon-theme.cache, install the package normally without forcing, and don't sweat it. That cache can (and should automatically) be recreated afterwards with gtk4-update-icon-cache /usr/share/icons/bloom, but it's strictly not critical.

The previous version of the package did not include this file, lending credibility to the assumption of a packaging mistake, as does the existence of an issue for that problem already.

Just fix this nag yourself as described, and expect this to be fixed by the packager eventually.

Generally speaking, there is a race condition lurking where the OS may do whatever to your file you just checked, rendering the check strictly obsolete the moment you get the result. This isn't typical, but possible, and a lovely old-school security vulnerability class. :)

A more practical argument is that you're going to handle any errors your open() may throw, anyway, and therefore it's simply redundant to check for file existence explicitly beforehand.

Under specific circumstances, you may want to do explicit, very specific tests for more detailed error reporting than "error opening file!", for example "save file is corrupted" if it's too short or zero-length, or "save file directory is gone. What the hell, dude? Recreating it, but stop fiddling with my files!"

This is easy to overengineer. Best is to get into the very sensible habit of always checking for errors or exceptions returned by your calls, and this will become a non-issue.

In this particular use-case of save file loading, you might implement displaying a listing of save files in a directory with opendir/readdir or FindFirstFile/FindNextFile and its ilk, to offer a list of files to load, which doubles as a crude existence test already. Many ways lead away from Rome. If you're considering loading an autosave and offer a "Continue" button or something, a cheap existence test would work very well to decide if that button needs to be displayed in the first place, but doesn't free you from handling any open() errors later. You could also open() and validate an autosave directly, and when/if the user decides to "Continue", use the already reserved file descriptor and maybe even the preloaded save data to quickly jump into the game.

If you want a simple answer: Do not introduce race conditions. Always acquire a lock for a shared resource before doing anything with it.

What kind of soulless psychopath leaves a window of this size unmaximized is the real question here. Also, a horizontal scrollbar in the main section, able to scroll maybe 8 pixels total to see some more of the glorious empty padding, could have been a nice touch as a consequence of the "unintended" window size.

I would not differentiate needlessly between the terms function and ["dunder", "instance", "module", "class"] method, this isn't practical at the current point in time, and arguably not pythonic. They are all callables and behave very similar for all practical purposes, all quacking like a duck.

If you want to deep-dive into the intricacies, there's technically a bunch of alternative "method types" with slightly differing calling and argument passing conventions. There are class methods, static methods, class properties, and module-scope functions off the top of my head, all very similar, but particularly suitable under specific circumstances.

If I wanted a String utility class, for example, I could have that:

class String:
  @staticmethod
  def len(string: str) -> int:
    if not isinstance(string, str):
      raise TypeError("Cannot determine length of non-string object")
    return len(string)

s = "foobar"
assert String.len(s) == 6

In Python I generally find static methods hardly as relevant as in other languages, and tend to create utility modules instead, with plain functions and maybe dataclasses for complex arguments or return values, which can then be imported and called pretty much the same way as a static method, but without the extra organisational class layer. I'd argue that's very much a matter of taste, and how much of a purebred OOP jockey you are, for better or worse.

Class properties are cool, however, you might want to look into that. It's getters/setters on crack, masquerading as their respective property, so that something like this "just works":

s = MyString("foobar")
assert s.len == 6

Are there any other ways I would find the length? Or are methods and functions the only options?

You could get creative and find several inferior, silly, and utterly insane ways of achieving the same result, for example by treating a string as an interable (read: "list" or "array") of its constituent characters, and count the number of characters. This feels very "example (but not exemplary) code on the first pages of a crappy C++ textbook", but hey, it's a way:

length = 0
string = "foobar"
for char in string:
  length = length + 1
print(length)

Mind you, this is not programming. This is toying around, and perfectly valid in that way, but no-one in a halfway sane state of mind would dare suggest doing it this way with Python if you actually care about the result. :)

What is the difference between these types of statements?

Technically, len() is a Python built-in function, while "some string".len() would be an instance method of a string object, if such an instance method existed.

How do I think about this to know which one I should expect to work?

As a very general rule of thumb, I would recommend to keep the list of built-in functions close and memorize the "popular ones" over time. These are special. Anything else you encounter usually is an instance or class method, or a plain function without any object-oriented shenanigans, depending on how structured the code is you are looking at.

Learn to navigate the Python reference docs. Use the search function liberally if you don't come from a search engine result, anyway, or jump directly to the docs for the module you're interested in to see what functionality it offers, and how to use it.

Python is annoyingly flexible, and does not strictly enforce a single way to do anything, so learning what to expect always ends up as building an intuition, and actively looking up documentation for the modules, classes, or functions you intend to use until you have encountered enough (good) Python code to have reasonable expectations in the first place.

TL;DR: grep the relevant module's docs, or Python built-ins. It's typically one or the other where you find detailed help.