Pep8 remark and pythonification of the code about quamash HOT 16 CLOSED

Mark has deliberately chosen to use tabs rather than spaces in this project.

How does your link say you shouldn't put classes in init.py though? To me it sounds way too dogmatic anyway. Let's write code instead of fretting over rules ;)

from quamash.

Weird choice. Really annoying to force to ignore pep8 warning when we want to contribute to quamash... :/

from quamash.

@Insoleet If you use Editorconfig the rules should be applied automatically, and it won't be so much of a hassle.

from quamash.

Interesting. Installing it right now in my PyCharm instance :)

I think the remarks for the init.py still stands, thought.

from quamash.

But why? I really don't understand the point myself.

from quamash.

For multiple reasons.

• logging with outputs information from __init__ module, not really verbose
• the code separation between the different modules (windows, unix, common) is not clear. QEventLoop could be in the common file, imported in the __init__.py for example.

Finally, importing quamash can have a lot of side effects because of the import of the __init__.py. When we import quamash, it triggers all the code in __init__.py, which then imports other modules needed by the code. These side effects could be unwanted when we only import a simple package. Generally when we import a simple package, we do not want it to have a lot of effects.

from quamash.

Yeah I've been wanting to move stuff around for awhile, but I've been sort
of unclear exactly how it should be done, and Arve seems to really like it
this way though, and I think my weak desire for some "more logical" and
"balanced" (most of the code is in one file) without specifics combined
with the Aumanian evidence of Arve's position to keep it the way he wrote
it sort of decided the issue.

I think it would make sense to divide the executor and the eventloop into
their own modules, then have a _common for stuff shared between those.
probably merge util.py into _common.py

In other projects I've put the author and version and stuff into an
about.py to avoid the import quamash in setup.py

On Sep 21, 2015 06:35, "Insoleet" [email protected] wrote:

For multiple reasons.

• logging with outputs information from init module, not really
  verbose
• the code separation between the different modules (windows, unix,
  common) is not clear. QEventLoop could be in the common file, imported in
  the init.py for example.

Finally, importing quamash can have a lot of side effects because of the
import of the init.py. When we import quamash, it triggers all the code
in init.py, which then imports other modules needed by the code. These
side effects could be unwanted when we only import a simple package.
Generally when we import a simple package, we do not want it to have a lot
of effects.

—
Reply to this email directly or view it on GitHub
#48 (comment).

from quamash.

It's not as if I feel strongly about this, just that there's little point in moving things around unless you gain something from it.

from quamash.

Well as quamash can be a new standard for PyQt with Python 3.5 (thanks to async and await new keywords), I think it's important to make the package code more standard and clean.

from quamash.

My argument is it's better to fix bugs and then worry about clean code, though. What's clean is kind of subjective too.

from quamash.

Oh, I agree. But for example, this bug/feature ( #45 ) will need some change in the code organization.
Also, bugs can happen due to have too much core code in the __init__.py package file. This happens (happened?) to the Django project for example.
Generally, one wants the __init__.py file to present the available API of the package.

from quamash.

I'm inclined to think this issue is too vague, really. When it comes to indentation, we should simply decide whether to keep the current standard (tabs) or make the switch to spaces. This is up to Mark really.

When it comes to restructuring, it'd be better to raise separate issues IMO. If there are actual bugs, well, create issues for said bugs. This would be much more practical.

from quamash.

Oh the issue is just here to start a discussion on this topic.

from quamash.

Sounds like we might as well close it then? Eventually @harvimt might want to make the final call wrt. indentation.

from quamash.

Yes, sure. You can close the issue if you do not think that it's a valid one ! It's up to you :)

from quamash.

yeah I'm gonna close this for now, but a more modular quamash might be good... I've got ideas swirling in my head for how I want to arrange this.

from quamash.