Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: How can I get better at writing production-level Python?

news.ycombinator.com

Post reply on HN
Print view View original

21–30 of 56 posts

Re: Ask HN: How can I get better at writing production-level Python?

#21

Post by anyfoo »

nick-of-time wrote: post #17
anyfoo wrote: post #13

Earlier 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…

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.

Good to know, thanks! I've warmed up to python again when I discovered mypy, having successfully used it for a personal project with rather complicated types (async and thus futures were involved, over more basic types but with complicated shapes). Knowing that there is also adequate IDE support makes it even more of a candidate again...

Re: Ask HN: How can I get better at writing production-level Python?

#22

Post by Aperocky »

anyfoo wrote: post #20
Aperocky wrote: post #18

Earlier quoted context omitted.

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…

My opinion is manual navigation is O(log(N)) for well organized projects. Which scales very well - especially as the package should be optimized for local changes/split into dependencies when it gets above a certain size. For a project that's not organized at all, it's O(N) which means it will soon become untenable.

Most project is somewhere in between but from what I've seen it tends towards the latter. As there are overwhelming amount of people utilizing the ease of IDE and do not care at all about the structure, or maintenance of the structure of a package.

Re: Ask HN: How can I get better at writing production-level Python?

#23

Post by tablarasa »

anyfoo wrote: post #13
Aperocky wrote: post #10

Avoid 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…

> "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."

I've felt this pain a lot. I finally took the time to learn how to make use of the type hinting that python does offer, and now I write those type hints without even thinking about it. It makes the development experience so much better for me and across the team, since we've all bought in. It doesn't do everything. It is kind of lipstick on a pig. But it's worth doing.

Re: Ask HN: How can I get better at writing production-level Python?

#24

Post by Aperocky »

tablarasa wrote: post #23
anyfoo wrote: post #13

Earlier 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…

> "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." I've felt this pain a lot. I finally took the time to learn how to make use of the type hinting that python does offer, and now I write those type hints without even thinking about it.…

I feel a similar way about typescript. It outsource the mental complexity into compile stage instead of directly on runtime.

Re: Ask HN: How can I get better at writing production-level Python?

#25

Post by anyfoo »

Aperocky wrote: post #22
anyfoo wrote: post #20

Earlier quoted context omitted.

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…

My opinion is manual navigation is O(log(N)) for well organized projects. Which scales very well - especially as the package should be optimized for local changes/split into dependencies when it gets above a certain size. For a project that's not organized at all, it's O(N) which means it will soon become untenable. Most project is somewhere in between but from what I've seen it tends towards the latter. As there are…

I'm talking about pretty large projects. Try navigating, for example, an operating system kernel for its very many functions you encounter just when writing a device driver. You won't know where to find everything (most things maybe even), so manual navigation is certainly not O(log(N)).

Unless you want to mindlessly click through directory structures and files hunting for vague hints, what are you going to do? Full text search? Unless you're both careful and lucky, you will find a lot or all of the call sites as well. Which, again, gets worse the larger the project (and thus the number of call sites) gets.

Then, you better remember the arguments' type, order, and significance of the many functions you call, otherwise it's back to the navigation I've described above every time you want to use it.

This was one of the more extreme examples, but the whole problem starts to rear its ugly head pretty early in much smaller projects. The issue is however somewhat masked if you are the only or one of very few developers with high familiarity of the project. Of course then you know which file to click on and where to scroll to.

But then, even on a small project, that project rarely exists in a vacuum (the OS kernel example above is actually almost somewhat of an exception). You will use other frameworks and libraries, at the very least the language's standard library, usually, which is effectively a big project again.

Re: Ask HN: How can I get better at writing production-level Python?

#26

Post by more_corn »

Learn good style (if you aren’t given one the google style guide is pretty common)and unit test your code. At google they call writing good code “readability”. When you get “python readability” your code is readable. Which makes it easier to understand, debug and maintain.

Re: Ask HN: How can I get better at writing production-level Python?

#27

Post by wombatpm »

anyfoo wrote: post #13
Aperocky wrote: post #10

Avoid 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 a good job

Re: Ask HN: How can I get better at writing production-level Python?

#28

Post by commandersaki »

Aperocky wrote: post #10

Avoid 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…

If you want to see an exercise of writing Java in Python look no further than the logging module source.

Re: Ask HN: How can I get better at writing production-level Python?

#29

Post by Aperocky »

anyfoo wrote: post #25
Aperocky wrote: post #22

Earlier quoted context omitted.

My opinion is manual navigation is O(log(N)) for well organized projects. Which scales very well - especially as the package should be optimized for local changes/split into dependencies when it gets above a certain size. For a project that's not organized at all, it's O(N) which means it will soon become untenable. Most project is somewhere in between but from what I've seen it tends towards the latter. As there are…

I'm talking about pretty large projects. Try navigating, for example, an operating system kernel for its very many functions you encounter just when writing a device driver. You won't know where to find everything (most things maybe even), so manual navigation is certainly not O(log(N)). Unless you want to mindlessly click through directory structures and files hunting for vague hints, what are you going to do? Full…

> what are you going to do? Full text search?

Actually yes, I often have a grep tab open on the next terminal tab (whereas vim lives in the other one). Granted, I don't use it nearly as often as one would CTRL-B in intellij. grep (and other GNU utilities) is very powerful and can be used for more than just text searches. In fact for even project I develop using intellij I often find myself doing the same grep window in remote just because it's faster and I can make manual edits on the fly.

For navigation, I usually to tabe or vert sb and this allow the other call signature to simply exist on my desktop real estate or a gt away until I don't need it anymore.

You might feel like I'm simply proving your point, and you might just be right. But I do use the same method of editing on larger project outside of personal space, and delivers at speed if not just due to the fact that I need very minimal setup (the context switching is hefty when the package space is littered with various packages and not just a single one that you change all the time). I do use IDE for certain languages (yes, java), but I think it has more to deal with the verbosity and inherited complexity (chicken and egg here) then I would attribute to size alone.

The bottom line is, having been using IDE and not IDE for different projects for a long time, I would default to not using IDE if I could. It's not like I'm pathologically averse to the idea of IDE, in fact I use it daily. I just think not using the IDE has benefits both on speed for certain projects, and clarity and skill growth for others.

Post reply on HN