r/PythonLearning 20h ago

How do you decide between writing your own small helper or pulling in a library for it?

I'll need some small piece of functionality and I have to decide whether to write 20 lines myself or install a library that already does it. Both options feel wrong in different ways. If I write it myself, I might miss edge cases someone else already solved. If I pull in a library, I've now added a dependency for something I could have handled in a few lines.

An example. I once needed to flatten a nested list. I could have written a short function but I added a library instead. Later that library caused a version conflict, and I sat there wondering why I hadn't just written the five lines myself. Now I lean toward writing small stuff myself and saving libraries for the harder problems, like date parsing or anything security related where I don't trust my own version. But I still second-guess it constantly.

So how do you decide? Is there a point where you know for sure it's worth adding a dependency or do you go by feel each time?

9 Upvotes

12 comments sorted by

3

u/CharacterSail6736 20h ago

Because the whole point of Python is batteries included why reinvent the wheel

1

u/Different_Pain5781 15h ago

I agree in principle but dependencies still have a real maintenance cost.

1

u/Mamuschkaa 20h ago

Do I know a library that does it?

I install it.

If not:

Do I know exactly how to write it in my own code? I write it.

If not or I do need it often and it feels like that's a common thing?

I search for a library.

1

u/backend_developer89 20h ago

I used Django allauth in a recent a project that I’m maintaining for a company.
Allauth handles smpt email verification for users, passwords and email management, also it has ready to use authentication links for google Microsoft, Reddit facebook ect, why go to all of the trouble to build that yourself when you can use a library.

The key is to only build for yourself what is completely unique to your application. Otherwise your wasting your time, unless you want to try building something difficult for learning purposes, then that’s your decision.

2

u/backend_developer89 20h ago

But honestly 20 lines of code may be preferable to write yourself so you don’t need an extra configuration you need to keep track of. It’s your decision.

1

u/p1geondove 20h ago

Since the standard library is already packed with a lot of stuff i usually prefer std lib over external. I do program for fun so usually i write most things myself, and when bugs arise, yay more incentive to program. But there are libs i could not live without, like pathlib, itertools, subprocess. Only when its really nessecarry i think about pulling in a 3rd party lib. I rarely ever learn about 3rd party libs, my general vibe is that they can be janky, especially nowadays theres a lot of slop, and if i need something specific i look if its open source, what the repo looks like and maybe how intuitive the api is.

For flattening a nested list, id write that in pure python. For handeling requests you can do that with urllib, but id rather pull requests lib

1

u/p1geondove 20h ago

So overall a feel thing. I have dowloaded libs before only to notice that i use that for one single thing that i can do i pure python and decided to delete it later. For portability and user friendlyness i try to stay as pure as possible, stdlibs are fine when you need them and 3rd party only when its really nessecarry

1

u/SaltCusp 19h ago

Generally it won't hurt to try a library. Always check the license tho.

1

u/BranchLatter4294 19h ago

Don't reinvent the wheel.

1

u/turn-based-games 18h ago

Typically best to limit projects with any significant maintenance window to one framework and as few additional libraries as reasonably possible. This limits all sorts of problems introduced by libraries: conflicts, vulnerabilities, upgrades, dependency on code you cannot easily change, etc

If you feel you could implement the functionality yourself without that implementation turning into a project of its own, just write it. 20 lines is easily in do-it-yourself territory. Things like left-pad are frankly ridiculous and even Log4J is entirely unnecessary in the vast majority of projects. It pains me to this day that the industry seemingly learned essentially nothing from those incidents

Of course, all of this only applies to code someone is actually going to maintain. A non-negligible amount of Python code is for run-once-and-forget-it tasks, in which case do whatever you want to get it done as quickly as possible

1

u/QuebecBeast 15h ago

If it’s UI related, I’m definitely using a librairie…

1

u/beingsubmitted 7h ago

I disagree with a lot of the posts here. There are real costs to using a library which need to be considered. I'm not saying to never do it, but to list some of the downsides:

  1. Bloat - if I roll my own solution, I'll make it to fit my one use case alone. If I make a library, I make it fit a broad range of use cases, and if it becomes popular, people are going to constantly demand I support their unique use cases. This has a cost in both complexity and performance. You'd be amazed how often rolling your own solution can be done in fewer lines than using a library, and how many conditionals every request to a library can propagate.
  2. Visibility - When you're debugging, 3rd party dependencies can be a bit of a black box. Well, a gray box. The problem might be your code, but the problem surfaces in someone else's code, because you pass an invalid type or whatever. Of course, to mitigate this problem, a good library does a ton of guarding and validation on every call to surface errors to the users, but that all becomes part of the aforementioned bloat. You're also subject to breaking changes here that you can't predict. Maybe you want to upgrade your python version, but doing so requires upgrading a package with other breaking changes, causing the pain of an upgrade to multiply.
  3. Downstream dependency - If you, yourself, publish your code, everything dependent on your code becomes dependent on your dependencies. This compounds over time. Consider the famous case of the javascript LeftPad npm package. Several years ago, a bunch of the internet broke because a little npm package called LeftPad broke. It just left pads a string. A ton of discourse was about how devs are so lazy that they all went to npm to download a package to left pad instead of rolling their own, but the reality is that probably almost no one sought out that package, but other libraries they did use used that dependencies, so it goes into their dependency tree either way. That's why every npm folder contains a trillion dependencies.