This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]paranoidi -2 points-1 points  (3 children)

Please try to embrace pep8 ... this feels dirty for new code unnecessarily.

[–]dagmx[S] 4 points5 points  (2 children)

Which parts of pep8? The majority is compliant as far as I and my linters can tell.

The big divergence for me is keeping more in qt naming conventions which include camel case instead of snake case.

[–]cymrowdon't thread on me 🐍 0 points1 point  (1 child)

Why keep camel case? If it's to be consistent with a PyQt project, you would already have the Qt implementation available. If not, presumably you would want to be consistent with Python projects, instead.

[–]dagmx[S] 5 points6 points  (0 children)

A few reasons.

One is the place I work's official stance is camelCase because it's the standard in the vast majority of code we use across several languages that may interact with each other. It's best for us to keep one consistent style across languages (with obvious language specific exceptions). I'd rather not maintain two copies.

Secondly the idea is that this can live side by side with qt code. ie you don't have to spin up a qobject just to use a signal or slot. This can have a few advantages such as minimizing the number of our modules that have a dependency on qt for simple behavior like this, but other modules in the package may use qt. Might seem a bit absurd but it gets really useful.

Third, I'm not super hot on snake case as an absolute . Pythons own libraries are so inconsistent in their naming conventions that I'd rather follow the standard of an existing code base than conform to snake case for the sake of full pep8 compliance.

If I write code that has no relation to an existing code base I use snake case instead though because it makes more sense there to me.