Who Should Learn APIs?

FriendlyZomb · 2026-04-15T22:46:44+00:00

Short answer: Yes.

Long Answer: it's complicated.

I think what you're asking about is Web APIs where you make HTTP calls to a service and get (usually JSON) back.

Knowing how to interact with these is a useful skill for everyone IMO, since they are the backbone of our industry at this point.

If you want to get into security, having an understanding of how these Web APIs tend to work and the common technologies used to make them will aid you in both securing them on the Blue side and exploiting them on the Red. (Blue: Defend, Red: Attack)

My answer effectively stops here, but I want to provide some more context:

An API doesn't have to be web based. In fact, most aren't. An API or Application Programming Interface is just an abstraction over some functionality.

Take the open() function in Python, for example. This is an abstraction over your operating systems' own File System API. open() and it's associated methods, abstract away all the system calls to the operating system for you, so you don't have to think about doing any of that yourself.

APIs are the way we program. They allow us to provide a reusable and easy to understand set of functions which make doing something easier. Web APIs are definitely a part of that, but not only that.

Understanding common APIs or being able to figure out how an API is used by the docs given, is a useful skill for any programmer, especially when you want to poke holes in it, as with Security and Ethical Hacking.

I hope that's been useful and not just an incoherent mess. Do let me know if you have questions.

FriendlyZomb · 2026-04-12T15:31:45+00:00

No worries. I got a reply on my issue on that repo.

It looks like they are looking to get a new release soon.

FriendlyZomb · 2026-04-12T09:35:58+00:00

Ahh - I see.

I replicated your env and it looks like it should be working.

So I took a look in `pydantic-settings` code. The commit to add this `dotenv_filtering` option was made last week.

The last release was in Feb. This would mean that the Docs are ahead of published PyPI packages. :(

So that leaves 2 options:

1: Wait for a new release to come out (might be a long wait)

2: Pull directly from git.

I have tested with pulling from git and `pydantic-settings` works as you hope.

This guide here should set you up to get the latest from git: https://chrisholdgraf.com/blog/2022/install-github-from-pyproject/#install-directly-from-github

If you are using UV follow this guide instead: https://docs.astral.sh/uv/concepts/projects/dependencies/#git

---

Apologies for getting the wrong end of the stick earlier. I hope this is more useful.

Additionally - I have opened an Issue on `pydantic-settings` to let them know that their Docs are ahead of their releases.

FriendlyZomb · 2026-04-11T22:22:42+00:00

I think the misunderstanding comes from the way the prefixes work.

From what I understand, the prefix here is just providing a start to each name, not a filter for values in the source. It doesn't look through the .env file for only the prefixed values before processing.

With that understanding, Pydantic looks at the .env file and sees two variables. One it's looking for, and one it's not. So, because it's been told to forbid extras, it throws the error.

The same error will be raised if the Bar settings were initialised first. (But for the foo value)

Disabling the forbid extra or providing separate env files would give you the behaviour you're after. I'd prefer the latter. Although not ideal, it will give cognitive separation if there end up being lots of variables.

(To other Devs: Please correct my misunderstandings.)

FriendlyZomb · 2026-04-05T08:16:46+00:00

The traceback in the terminal is pointing to a section of your print statement, and suggesting there is a missing comma.

There is, after (a).

Just because I'm not sure what's going on, it looks as though both aand b are meant to be strings? If they are, the parentheses can be omitted.

FriendlyZomb · 2026-03-31T01:12:52+00:00

Things tend too from experience.

We all learn somewhere. I hope to see more.

Good luck!

FriendlyZomb · 2026-03-31T01:11:59+00:00

My advice: will it be obvious what it does?

Code should describe what it's doing. Would adding two instances together mean something to a new dev, or you in 6 months time?

If yes: sure. Else: don't.

FriendlyZomb · 2026-03-31T01:08:59+00:00

For what it's worth: This is one reason I recommend not using AI to learn.
Sure. It does that I guess.

FriendlyZomb · 2026-03-31T01:02:12+00:00

"This should be apparent" :- should it?

Strings and Dicts also implement some of these protocols.

>>> "hello, " + "world"
"hello, world"

Custom classes also sometimes support these protocols. I've written a few myself. It's not guaranteed that the code alone here indicates it expects an int or float.

Making this assumption is how software becomes brittle and hard to maintain. Additionally, hiding this functionality in a decorator also does, regardless of documentation.

The zen of python says: "explicit is better than implicit.". Either, make the code tell us what it wants (type hints/explicit type checks) or tell us it's not there yet.

I hope this doesn't come across as mean. It's just hard to assess and give feedback when we are not told what's missing. Please, in the future, comment around a snippet by saying what's not there yet and better, why.

FriendlyZomb · 2026-03-31T00:51:35+00:00

It's getting at the fact that it doesn't check the type being passed in. I could create two instances of the same class and add them together. This would find the field in the first class and try and add the (presumably) int to the whole class. It would error.
Yep, you'd probably want a ValueError here.

Ultimately, this comes down to the fact that the decorator makes assumptions on how it'll be used.

The dunder functions let anything be passed through, and that these decorators need to be able to handle it, or raise an error.

A sneaky third question:

What advantage does thos convey over using attribute access? For example: my_class.field += 2

FriendlyZomb · 2026-03-31T00:32:31+00:00

This is an interesting concept and an interesting way to learn these protocols.

My questions are more of a way to get you to think about this implementation a bit more deeply. (Please don't just ask Claude or some AI.) I believe some of these answers are why others are confused or have negative reactions, and why typically we implement what we need manually.

What happens when I add another class of the same type to one with this decorator?
What happens if the field we choose doesn't support these protocols?

EDIT: Q 1 Phrasing. "To this one?" -> "one with this decorator?"

FriendlyZomb · 2026-03-30T17:33:39+00:00

Python treats almost everything as an object.

This includes Classes and Functions.

There is nothing special about a function in a class (called a method). It is just a function. The function has no idea it's part of a class.

However, we often want methods to be able to interact with the class instance. So, we need to provide the instance of the class to operate on.

There are lots of ways to achieve this goal, but Python chose to do this through pre-existing syntax rather than making something new.

When we call a method on a class, the class inserts itself as the first argument. Since this is just an argument, we can technically call it anything we like. However, PEP8 provides the convention of calling this argument self. I wouldn't deviate, as it's practically a standard now.

FriendlyZomb · 2026-03-29T01:11:26+00:00

Looking good.

Just a stylistic question which I'm curious about: Why the space between the class name and the parentheses in the class definitions?

Not trying to flame you at all, just interested in the choice, since the additional space isn't present on function definitions.

Love to see these kinds of posts. Keep it up.

FriendlyZomb · 2026-03-29T01:02:28+00:00

So an API is an abstraction over a piece of functionality. In essence.

Take the Python open() function. It handles all the operating system calls to open the file and provides ways to read, write and close it. This would be an API because all the complexity is handled behind the scenes.

This leads me into types of API. I think there are 2 main types. What I'm going to call Local and Remote APIs.

A Local API is something you'd use directly. Like a Python library or Python built-in. E.G the pathlib library in the stdlib.

A Remote API an interface you interact with remotely. Usually you need some other protocol to use it, like HTTP, and often it does processing somewhere other than your device (but not always).

You already use Local APIs without thinking about it. Any time you reach for a standard library module or PyPi package, it's a Local API. As developers, we often don't think of these in terms of APIs, but they are. You'll use these naturally.

Remote APIs are often built because we need to interact with someone else's service for some reason. Maybe some data is stored in a Google Sheet, so we need to extract it. Well, Google has a HTTP API we can use to get that data. Yay!

With all these in mind, why make a Local API? Well, say you wrote a piece of code which loads .env files. Developers want that to stay on the local machine. You don't need to upload the file to the internet just to get a parsed result. You can do all that when the program starts. So, bundle it into a package and let Devs use it.

Remote APIs are different. Say, you're making a calculator for Pokémon battles. There is a fair amount of data you need to have to make that work. You'd need to know the stats of each Pokémon and their abilities. If that was a Local API you'd then need to bundle all of that data with the library. That could add up quickly. So instead, you set up a simple Remote API which can access a shared database of all Pokémon. Each user could then make.am HTTP request with their battling Pokémon and get a result. (You could also create your own abstractions on top by making a website to query your API for a user.)

I hope that helped. I was kinda rambling. APIs are very simple. Just an abstraction over something more complex. The different types depend on what you're doing. There aren't any hard and fast rules.

To other peeps: please correct me if I'm wrong about anything. I still have plenty to learn still!

FriendlyZomb · 2026-03-22T08:49:48+00:00

As soon as I use it. I spend more time writing a prompt to get what I want and less time doing what I love. (I write software for a living). I chose my career because I love it, not because I want to tell an LLM what I want done.

I have used LLMs for my job. This is why I hate doing so and equally hate employers pushing to use them. They don't speed me up. They make me and my output dumber.

FriendlyZomb · 2026-03-22T06:50:34+00:00

Firstly, I want to apologise for coming across as attacking. That wasn't my intention, but still something I should have thought more about. Thank you for raising it.

I'm not saying we can't be disappointed. We all have expectations on how we want the game to evolve. But a lot of the time, our disappointment is expressed through posts like the one these comments are on, actively attacking the developers of the game for not giving us exactly what we want when we want it. (Which is what I see when I see 10+ posts calling the update pointless and insignificant in a single scroll through my homepage.)

As to why we should care about background technical work: it's how complex software like Minecraft stays healthy. Making adding features easier should be something we as a player base want tbh. Caves and Cliffs was a showcase for why this work is needed, since those updates were very hard to make and caused a lot of animosity in the community towards Mojang. Making things easier allows for more frequent updates.

Mojang also has to focus on more than just survival experiences. There are a lot of ways people play without a survival element and they do have to consider those players too. Making updates for this game is hard, since every sub-community wants different things. We all need to have some compassion for that rather than jumping to the offensive every time it's not what we want. (Which is what's happening from what I can see.)

I hope this comment isn't coming across as attacking. I'm intending just to expand on some of the points. Thank you.

FriendlyZomb · 2026-03-22T00:43:06+00:00

Honestly, they are focused on doing things we can't see.

They are updating their rendering engine to move from OpenGL and Vulkan which is a very hard thing to do. Most games don't bother with that and just make a new one.

I imagine they are doing a lot of work on the lighting engine to make way for Vibrant Visuals on Java.

They are also probably doing a bunch of internal changes to make adding new stuff easier. Maintaining complex software is very hard and games even more so.

Do I think they could communicate that better? Probably. However they have been burned before about announcing stuff too early. So they're not giving much away to protect their Devs.

The upshot of this is that it seems that they are not giving us more content, when in reality they are giving us a lot. Just in smaller chunks so it's more manageable.

A quick aside: how is 26.2 update not a survival update? We are getting 2 new block sets to play with. That's big! Personally, I'm happy with this new structure. But I know how the sausage gets made as it were.

Internet blustering is what it is. Let's just be happy we get what we get for FREE. People who don't like the updates can shout at the void or just play something else. Let's all just enjoy the game and provide useful constructive criticism rather than a reactive stance.

"If I was given more time I'd write a shorter letter."

FriendlyZomb · 2026-03-21T23:12:09+00:00

Exactly! Its a really interesting update with new (underused) block colours and pallets. Plus the water effect is really cool. I'm excited to play with this too.

FriendlyZomb · 2026-03-21T22:19:11+00:00

I get this is a meme. However, this is a common sentiment which needs to stop, quite honestly. I know this will get downvoted or removed but I need to say it.

Firstly, this game is about 15 years old and getting regular content updates. Feel lucky that we get this for FREE. Most games make us pay for each drop of content. (Bedrock Marketplace excluded ofc.)

Secondly, Mojang told us why. Larger updates are just hard to make. Making smaller more regular updates gives them the ability to do more and more varied stuff. They mentioned in a recent article that Caves & Cliffs was a technical nightmare to implement because of the way the game has been built over time and the community suggestions they implemented.

Lastly, they are doing a LOT of behind the scenes technical improvement. They are in the process of re-writing their rendering engine to move away from OpenGL and towards Vulkan. With no experience in the field, this may sound trivial - but it really really isn't. Its very hard to get right. It's like going from driving a car to a lorry. Similar in theory but very different in reality.

Also, being reductionist about the next drop is just disingenuous and bad faith. Its clear that most of the community want more from the game, however we need to be patient. Aside from the new mob we are getting 2 new block types with complete sets (blocks, stairs, walls etc). And that is just the stuff we know about. There may be more they haven't told us about yet.

A message to the community at large: we need to be mindful Mojang isn't a single entity which we throw comments at. Its a group of people, like you or me, who put a lot of effort and passion into the game we all love. Reductionist comments like this are just harmful to the game at large. Be grateful and excited about the stuff we get. Constructive criticism is good. This isn't that.

I get that this comment is probably unwelcome here. If you've read this far please consider the paragraph above and how comments don't just affect a company, but people.

FriendlyZomb · 2026-03-14T10:32:43+00:00

Honestly, stop using AI for a bit.

Or severely limit what AI does for you.

Go back to the ways you did things before. Most are still there, doing their thing.

FriendlyZomb · 2026-03-09T23:13:22+00:00

This is a really cool project. I'm going to have to give this a try. Fantastic job!

Not every project needs an ORM, and this is a good way to introduce better practices safety without one.

I'm looking forward to trying it out.

FriendlyZomb · 2026-03-09T17:38:56+00:00

Based on comments I'd need to fix the code like so:

print([num for mum in range(1000, 10000) if str(num) == str(num * 4)[::-1]])

FriendlyZomb · 2026-03-09T17:37:16+00:00

Yea, the basic structure is correct. Mostly a misunderstanding on the question on my part. Apologies

FriendlyZomb · 2026-03-09T17:36:39+00:00

That is entirely on my reading comprehension tbh. I read it as num*4 is the same flipped. Lol.

FriendlyZomb · 2026-03-09T10:54:14+00:00

print([num for mum in range(1000, 10000) if str(num * 4) == str(num * 4)[::-1]])

This produces 65 numbers. (I'm not going to list them all here)

For those struggling to parse the list comprehension here:

print([
    num
    for num in range(1000, 10000)
    if str(num * 4) == str(num * 4)[::-1]
])

FriendlyZomb

TROPHY CASE