search

mikemalinowski / qute

A Qt helper library extending Marcus Ottosson's Qt.py library
MIT License
12 stars 3 forks source link

Preference: Unsure why using a different namespace? #2

Closed ldunham1 closed 4 years ago

ldunham1 commented 4 years ago

https://github.com/mikemalinowski/qute/blob/3c5e1c34eba7153ba564910963f5c48c7abd1b4c/qute/__init__.py#L74

Unsure why the package imports using a different namesapce? If related to backwards compatibility, it might be clearer/cleaner to use aliases later on? I can imagine a wide usage of both names depending on where its being imported from, which might cause unnecessary confusion.

mikemalinowski commented 4 years ago

The different namespace is to retain backward compatibility between qute version 2 and qute version 2. Everything from line 59 down is there to hold backward compat for import paths - meaning someone using qute version 2 can upgrade to version 3 without having to alter their code.

These will get a deprecation warning in a minor release soon to come.

ldunham1 commented 4 years ago

Understandable - although I dont understand why the method isnt imported under its own name and then an alias used for the old name? Unless you expect devs to have used it from direct from the styling module?

mikemalinowski commented 4 years ago

the expected way to use it in v3 is...

qute.utilities.styling.apply(..)

but in v2 it was: qute.applyStyle

so in order to retain backward compat, we import the apply function but name it to the old method name.

With v3, we're trying to avoid functions being placed directly in the qute namespace, instead they should go into either utilties or extensions and be in a subcategory from there.

mikemalinowski commented 4 years ago

I plan to wrap all those backward compat imports with deprecation warnings, then in v4 they will be permanently removed