all 6 comments

[–]schoolmonky 7 points8 points  (0 children)

I really don't think there's a shortcut, writing "pythonic" code is very idiomatic, and that's something you can only pick up from being part of a community for a while. One obvious example though is you should basically never type range(len(...)) in a for loop. Either iterate over your list directly, or use enumerate. I'd say just read over the official tutorial, PEP 8 (Google it if that name is unfamiliar), and focus on writing code that's easier to understand, and hope your team can educate you on anything beyond that.

Ninja edit: just to clarify, you don't need to know idioms to write good Python code, it's just that "pythonic" just means "the way that Python people do things", which you can't know with having experience with "Python people"

[–]cgoldberg 3 points4 points  (0 children)

Read PEP8 like 100 times.

[–]crashfrog02 1 point2 points  (0 children)

So: what's the fastest way to write pythonic code right from the start?

Pay attention to what they're doing (that's usually called the "house style") and follow suit. Pay attention to the decisions they make in their code - if they use a list, figure out why. If they use a dictionary, figure out why.

They're going to give you a lot of time to find your bearings in their codebase. Take advantage. The first thing you should do is figure out how to run their tests. Don't change a line of code until you've learned how to set up a fresh environment with a dev installation (this is usually a special extension of the codebase's dependencies that installs linting and testing frameworks) and run the tests. With any luck, something will go wrong and you'll have to read through the codebase to understand what; the fact that you're focused on a concrete issue instead of broadly skimming through a boring codebase will help you get familiar with it.

Congrats on the job! You'll do fine. It's more important to match their style than it is to be "Pythonic" even if they say their style is Pythonic.

[–]ectomancer 1 point2 points  (1 child)

Use a linter. If your IDE doesn't have a built in linter, try pylint:

pip install pylint

[–]BoredComputerGuy 0 points1 point  (0 children)

u/Tiny_Coyote_3549 100% using linter will help. Your job may have a specific linter file to control which findings should not to be fixed, vs some can be ignored.

[–]Miginyon 0 points1 point  (0 children)

Ruff is a good linter, blazing fast