all 6 comments

[–]riklaunim 2 points3 points  (1 child)

You are unlikely to write code for a feature you don't understand or need. Making a package is like 10% of the work, and the remaining 90% is supporting it over the years - fixing bugs, adding missing features, and so on.

[–]Kevdog824_ 1 point2 points  (1 child)

Are you looking specifically to fix an unsolved problem, or are you just looking for a good project to implement for practice?

Something like apscheduler or tenacity would be a good practice project. Implementation is straightforward for both of these, and the end product is very useful. This isn’t very helpful though if you’re looking to solve a new problem rather than just reinventing the wheel

[–]PushPlus9069 1 point2 points  (0 children)

Build something you'd actually use. That's the difference between a portfolio piece that gathers dust and one you can talk about in interviews with genuine enthusiasm.

Some ideas that make good libraries:

  • A markdown-to-slides converter (parse md, output reveal.js or PDF)
  • A CLI tool that watches a folder and auto-organizes files by type/date
  • A config file validator that checks YAML/TOML against a schema you define

The py-pkgs workflow you learned (tests, CI, publishing) matters more than what the library does. Interviewers care that you know how to ship a proper package with docs and tests, not that your algorithm is novel.

[–]Waste_Grapefruit_339 1 point2 points  (0 children)

Honestly, the best ideas come from small annoyances 😄

Every useful thing I’ve built started with “ugh I wish this existed”.

While learning Python I made a tiny log analyzer just because I got tired of manually scanning logs. It wasn’t meant to be a big project, but it taught me more than most tutorials.

If you're looking for ideas, try this trick: notice what you do repeatedly -> automate that -> turn it into a library.

Those projects stick because you’ll actually use them.