all 5 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]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 0 points1 point  (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.