Type annotations, mypy, lots of documentation.
Where python falls down is the flexibility - if you aren't careful it's write only.
Ask HN: How can I get better at writing production-level Python?
11–20 of 56 posts
Re: Ask HN: How can I get better at writing production-level Python?
#12Assuming you have the fundamentals down, I’d recommend taking the time to dig in and understand the source code of a couple well written packages. Start with some simple libraries like datetime, requests, flask and move on to more complex, modern examples like pandas / fastapi. Clone the package, run the tests, break the tests and try adding functionality. You’ll learn a lot - I know I did when I was starting out. I’…
Fluent Python is fantastic.
Re: Ask HN: How can I get better at writing production-level Python?
#13Avoid writing java in python. Don't stretch inheritance where where they are not needed - avoid factory classes unless you know for certain that it's called for. Use pythonic stuff like @decorators and enjoy functions as first class objects. Finally, try to avoid using an IDE. This keeps your files and folders structures simple and organized out of necessity . In Java it's almost impossible, but it's very possible in…
> Finally, try to avoid using an IDE. This keeps your files and folders structures simple and organized out of necessity.
A good IDE will keep that structure simple and organized, too. The problem with python is more that its dynamic, duck typing type system hinders some of the great benefits that "modern" (as in, from the past ~2 decades) IDEs bring. Since the IDE can hardly infer any type, and since even the ones it could infer can dynamically change in shape at any time, the IDE cannot provide as helpful suggestions and as powerful navigation as IDEs for other languages can.
For the same reason, compile time almost exclusively tells you about crass syntax errors only, which further diminishes an IDE's helpfulness.
I'd be curious to know if there are python IDEs who integrate with mypy (or the underlying static typing PEP) to bring some of the lost magic back to python IDEs.
Re: Ask HN: How can I get better at writing production-level Python?
#14Assuming you have the fundamentals down, I’d recommend taking the time to dig in and understand the source code of a couple well written packages. Start with some simple libraries like datetime, requests, flask and move on to more complex, modern examples like pandas / fastapi. Clone the package, run the tests, break the tests and try adding functionality. You’ll learn a lot - I know I did when I was starting out. I’…
Yeah, reading the Fluent Python book[1] and / or following along with their support files[2] would a good way to start
Re: Ask HN: How can I get better at writing production-level Python?
#15Write Python code and get feedback from a colleague.
If you don't have a colleague, GPT-4 is an acceptable substitute.
Re: Ask HN: How can I get better at writing production-level Python?
#16Avoid writing java in python. Don't stretch inheritance where where they are not needed - avoid factory classes unless you know for certain that it's called for. Use pythonic stuff like @decorators and enjoy functions as first class objects. Finally, try to avoid using an IDE. This keeps your files and folders structures simple and organized out of necessity . In Java it's almost impossible, but it's very possible in…
Inheriting a python app written by java developers was one of the more frustrating code bases I've worked with
Re: Ask HN: How can I get better at writing production-level Python?
#17Avoid writing java in python. Don't stretch inheritance where where they are not needed - avoid factory classes unless you know for certain that it's called for. Use pythonic stuff like @decorators and enjoy functions as first class objects. Finally, try to avoid using an IDE. This keeps your files and folders structures simple and organized out of necessity . In Java it's almost impossible, but it's very possible in…
> Finally, try to avoid using an IDE. This keeps your files and folders structures simple and organized out of necessity. A good IDE will keep that structure simple and organized, too. The problem with python is more that its dynamic, duck typing type system hinders some of the great benefits that "modern" (as in, from the past ~2 decades) IDEs bring. Since the IDE can hardly infer any type, and since even the ones i…
Pycharm does, and so does any other jetbrains IDE with their python plugin installed. It's a large part of the reason I bother putting type annotations in my code, to help my IDE help me.
Re: Ask HN: How can I get better at writing production-level Python?
#18Avoid writing java in python. Don't stretch inheritance where where they are not needed - avoid factory classes unless you know for certain that it's called for. Use pythonic stuff like @decorators and enjoy functions as first class objects. Finally, try to avoid using an IDE. This keeps your files and folders structures simple and organized out of necessity . In Java it's almost impossible, but it's very possible in…
> Finally, try to avoid using an IDE. This keeps your files and folders structures simple and organized out of necessity. A good IDE will keep that structure simple and organized, too. The problem with python is more that its dynamic, duck typing type system hinders some of the great benefits that "modern" (as in, from the past ~2 decades) IDEs bring. Since the IDE can hardly infer any type, and since even the ones i…
Personally, without considering languages, I think IDE subconsciously cause complexity and increase entropy for a project. When things are at the a single key jump it's easy to insert code wherever and eventually build a jumbled mess. I've seen this in too many projects. Going without IDE causes a short term pain but eventually the organization gets there and it speeds up because the code is simply better organized and where to look for things are either imprinted or self evident.
Re: Ask HN: How can I get better at writing production-level Python?
#19Start reading production level Python.
I mean, so many people want to write production-level code and yet never took the time to actually read the production-level code right in their faces!
Even the standard library is worth seeing. Next time you import pathlib.Path, right click it, select "See Definition" and go find out how the sausage is made.
Obviously you are not expected to understand _everything_. But you will be surprised you will understand a bit. And then a bit more. And you will start getting comfortable dealing with production-level code. Soon you'll start writing it yourself.
This little habit skyrocketed my Python game
Re: Ask HN: How can I get better at writing production-level Python?
#20Earlier quoted context omitted.
> Finally, try to avoid using an IDE. This keeps your files and folders structures simple and organized out of necessity. A good IDE will keep that structure simple and organized, too. The problem with python is more that its dynamic, duck typing type system hinders some of the great benefits that "modern" (as in, from the past ~2 decades) IDEs bring. Since the IDE can hardly infer any type, and since even the ones i…
Personally, without considering languages, I think IDE subconsciously cause complexity and increase entropy for a project. When things are at the a single key jump it's easy to insert code wherever and eventually build a jumbled mess. I've seen this in too many projects. Going without IDE causes a short term pain but eventually the organization gets there and it speeds up because the code is simply better organized a…
That may work for small projects[1], but for large projects you quickly run into a limit where manual navigation and lookup become very prohibitive to one's ability to efficiently write code.
Even then I'd rather avoid cumbersome navigation and typing (the fingers on keyboard kind this time, not the type system kind), as well as catching a lot of problems only in the compile step (if existing) in the best case, or at runtime in the worst case (common in python without static typing extensions).
[1] Or, I guess, projects with a small team, where all members are familiar with all or most of the code base.