Maybe I'm missing something, but this seems hideously over-engineered:

sorting imports in is barely a problem to begin with.

While I appreciate the advantages of "Easier to Ask for Permission than Forgiveness", given how poorly distinguished exception type hierarchies are in , for the sake of providing good error reporting, I find "Look Before You Leap" makes a lot of sense a lot of the time. I'm thinking of the cases where you have a set of options for sets of provided parameters: Checking what's intended and then doing just that thing means that when the operation fails, I can report "<commanded operation> failed" vs trying each thing in series as the previous thing fails and then reporting all of the things that might have failed, only one of which was the intended one.

Really, I haven't found much reason to prefer EAFP outside of certain situations like dictionary accesses, where "checking" is the same thing as access, so it's redundant, or where checking first would cause TOCTOU ( errors, in which case it's just a correctness thing. Maybe my example above for error reporting is a strawman and not what people have in mind when they say you should prefer EAFP, but given that it looks like basically the same kind of case where EAFP *is* generally recommended (until it doesn't), seems like without talking about the logic behind it (TOCTOU, redundancy, maybe others), you'll tend to mispredict the right approach.

I'm finally able to remove 2.7 from my systems without giving up anything I use. Certainly has been a long time coming. Hopefully the Python community never has to deal with such a long good-bye again.

Altruism is weird. I'm maintaining this package. I don't add features or anything because I don't use it anymore myself, but I don't want to just drop it because I know some ppl actually use it. Like, I just spent the better part of my day fixing issues with it when I could have been ... cleaning my house or something.

Does everyone use ’s object() for unique tokens? Like:

no_match = object()val = some_dict.get('key', no_match)if val is not no_match:    do_something()

I don’t know what else object() would be used for (and why they’d keep it).

seems to have a nasty habit of breaking installations for each new release.

Useful resource if you're trying to use d-bus with Python GIO bindings. Docs are scarce about this specifically, so it helps to have an example. (probably less troublesome if you're used to the bindings generally)

weird fact: you can actually give a class pretty much any name you want using `type`: special chars (including periods!), spaces, numerals

Qoto Mastodon

QOTO: Question Others to Teach Ourselves. A STEM-oriented instance.

An inclusive free speech instance.
All cultures and opinions welcome.
Explicit hate speech and harassment strictly forbidden.
We federate with all servers: we don't block any servers.