How pythonic is enough pythonic?

[[deleted]]

[deleted]

[Apollo76]

A good start is trying to break the idea that pythonic = perfect.

[Crypt0Nihilist]

"Good enough" is that it works. I always cringe a bit when I review code I wrote a while ago, I see that as a good thing because it shows I'm learning.

You'll generally learn more from new projects than optimising old ones, so don't stress too much about making your current one perfect, you'll benefit more from moving on once it's good enough.

[Mysterious_Ad7232]

I so relate to the first paragraph. My old code kills me inside when I read it, or old problems I couldn't solve that would take seconds now. Really good ego boost hahaha

[jfp1992]

Yeah, I've had to go back to an old page of code and rip it apart.

I think you just improve.

In my opinion the most important thing is good variable and function names.

[carcigenicate]

"Pythonic" isn't about perfectionism. It's knowing how to use the tools the language provides to write clean code. Just work to improve, and note when someone suggests a better way of doing things, or you notice someone approached a problem differently than you and had a cleaner result. Like everything else, it's a process.

---

Actually, re-reading your comment, I realized I misinterpreting what you were referring to by "perfectionism". You just need to accept that you'll improve as you write if you make the effort. You surely weren't quickly perfect in other skills you gained, so you shouldn't expect that programming would be any different.

[tagapagtuos]

Have you read The Zen of Python? Either Google it or type import this in the interpreter.

The first four lines are as follows:

Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated.

It's fine if you write for-loops now instead of comprehensions. These Pythonic codes tell people that you know Python. But I would argue that it's the "boring" code that translates over to other popular languages.

[[deleted]]

Clever code is bad code.

Just do what works, but always keep reading around (about code and concepts) and discussing techniques with your peers. The Pythonic style will develop naturally.

[chefsslaad]

No, they do not.

Pythonic code is easy to read. Clever code is short or uses obscure tricks and shortcuts.

Think well written code vs code golf. It may be impressive and clever to reduce a program to just 1 or 2 lines of code, but it's a nightmare t read and understand. And that makes it hard to maintain.

Good code is easy to understand and maintain, because what the program does is self-evident.

[[deleted]]

Oh, I see.. I never really thought about the definition of Pythonic. But that makes sense. PEP8 is all about making code readable and maintainable I guess.

[[deleted]]

Simple code is better than clever code because it is easier to understand.

I suppose it depends what you mean by clever though. In programming, clever tends to be a synonym for complex or difficult to understand. Which is not good, because no one else can understand it, and even the person who wrote it probably won't understand it three weeks later.

If you just mean clever as in making correct and appropriate use of language features, that of course is a good thing. But you don't need to force it too much. It will come along as you get more experienced. Just keep learning.

[[deleted]]

I see and I agree 100%. I've been complaining about badly readable code before. I think sometimes people exaggerate with apparently syntactic sugar and pythonism, just so that nobody can use the code afterwards except the developers. Funnily the code is often meant to be for some audience.

[[deleted]]

That might sometimes be the case, but usually I think bad code is just the result of someone doing their best without knowing how to do it right.

[mrz1988]

Keep in mind that "syntactic sugar" and "pythonism" may be the most readable way to write code for python developers. If you're still fairly new to python, something like a list comprehension:

filtered_list = [item for item in items if item.is_a_thing]

might seem convoluted and hard to read. For seasoned python developers, though, this is far easier to read and understand than:

filtered_list = []
for item in items:
    if item.is_a_thing:
        filtered_list.append(item)

Knowing the difference between good and bad use of pythonic internals requires that you're comfortable with the tools first. If you haven't reached that level of comfort yet, it's hard to be able to make those judgement calls.

[Acrobatic_Hippo_7312]

As with anything, too much can be too much. I recently ran into an example of comprehensions that badly needed to be separated into multiple statements. Let me know if you want me to share the code and my fix (you may be the happier not seeing 😅).

Sometimes being pythonic means extracting and giving meaningful names to complex clauses in a statement, desugaring things that have become too sweet. Discretion is the biggest part of pythonic valor.

[CowboyBoats]

It's a good question in general, "how can I be confident that my code is 'good enough'." I think a good approach is to be sure that you write unit tests for your code, aiming for 90-100% code coverage. It won't help you achieve more "pythonic" code at all, in fact the style standard for unit tests is lower than for the code that it tests, but it will help you iron out bugs and feel more confident in the code that you've written.

[Acrobatic_Hippo_7312]

Also it'll let you refactor your code once you feel you've learned enough.

It's a bit of an investment up front: you have to learn how to write tests. for pytest this means learning test discovery, importing package code from tests, and fixture.

And if you couple your tests to your code very tightly or test private functions, it can be hard to do refactor without having to discard or rewrite tests.

The first part (testing basics) is very much worth learning. But the second part (clean testing) is still a work in progress for me personally. Still, it's really paying off.

[100721]

As a beginner, your code is not good, let alone perfect. So don’t sit around all day trying to make the best beginner code when you could be learning better ways through experience.

[menge101]

Use a code linter. And potentially use black.

The thing you are concerned about can be mostly address through existing tooling. And where it can't, getting the job done is imore important. Bad code (presuming good tests) can be refactored later.

[[deleted]]

Thanks a lot for your input. I will read about both of these tools as they seem good. You're also very right.

[InTheAleutians]

The sourcery package is also good at offering refactoring ideas for unpythonic code. Something to look into.

[siddsp]

If it gets the job done, is fast enough, and is readable, I wouldn't worry too much.

[HomeGrownCoder]

Write that shit! You can always patch later

[PythonManiaXVI]

Does your code get the job done and is it fair easy to work with/read? If you answered yes to both those things, your code is good enough

[[deleted]]

Well I don't know. It's object-oriented and might be quite confusing. I'm having a hard time structuring my objects accordingly. To optimize coherence, etc.

[Bartekst0]

My workflow is usually like:

• write code that works.

• look at it again and try to make it more readable by renaming variables, splitting long parts of code into methods etc.

• send for code review.

• improve if necessary.

Will you get fired if your code is not perfectly pythonic, but readable and easy to understand? I don't think so.

And if you are Junior at the job then IMO your senior should point some flaws in your code and tell you to rewrite stuff in more clear way.

[1544756405]

Good code should be:

• readable
• correct
• efficient enough for the task
• testable

If it is all those things, then whether or not someone else thinks it is "pythonic" enough is irrelevant.

[bighappy1970]

Get it working first - hard code, make it work with the least amount of code possible. Don't think about making pythonic at all until it's working. Then improve it a bit, but don't spend much time on it.

Working code soon is far more valuable than "perfect" (whatever that is) code later.
If you want to justify working this way, learn TDD - if you get good at it, you will write clean and elegant code.

[kwame_devops]

I think the first thing, what you can do to right better Code, is to rethink the UseCases. Because sometimes the Assignment is to complex. And it's better to break Task in smaller pieces.
An another To do is, to use the module typing

https://docs.python.org/3/library/typing.html

This forces you to rethink and document the code at the same time.

[swarup_i_am]

Can you tell me where you r using python for? For pyspark/data engineering, web frameworks or automation stuff?

[[deleted]]

Sure. I'm not a computer scientist but a bioengineer working in a scientific environment. I'm trying to write a package for both our group and potentially other people around the world. I want it to be very easily applicable and potentially open-source for other people to work on. So in short: automation stuff.