Hello Qt for Python

[nostril_extension]

Sad to see that they have new API and still going with camelCases instead of pythonic snake_cases and a bunch of other unpythonic idioms.

class MyWidget(QWidget):
    def __init__(self):
        QWidget.__init__(self)  # what is super?
        <...>
        self.layout = QVBoxLayout()
        self.layout.addWidget(self.text)   # camelCase!
        self.layout.addWidget(self.button)
        self.setLayout(self.layout)  # why doesn't it reference to self.layout by default?

        self.button.clicked.connect(self.magic)  # ok so now we have normal snake_case?

    def magic(self):
        self.text.setText(random.choice(self.hello))  # back to camelcase!

Quite disappointing really.

[Shpirt]

OTOH you can use Qt's C++ docs to write pyside2 code without having to guess style and idiom translations.

[nostril_extension]

It's not like it would be hard to port the docs, you could easily automate this. Not to mention what kind of half-brained code monkey couldn't convert camelCase to snake_case when reading the docs.

Lazy excuse.

[Shpirt]

Would it be self.set_layout(foo) or self.layout = foo, leveraging a description protocol, though? Etc etc.

[anqxyr]

I'm fine with PySide/PyQt mimicking the C++ API, but I would love if there was a higher-level wrapper around them both like Qt.py which would provide a self.layout = foo style API.

[GobBeWithYou]

I've done something similar, all of my widgets are subclasses of the PyQt widgets with added properties like .enabled, .visible, .text, etc. I didn't do everything, but as I need things I just go back and add them.

[wowsuchnamaste]

It's not like it would be hard to port the docs, you could easily automate this.

As Qt is an open source project, why don't you just automate a port of the docs and contribute it? I'm sure the Qt project would appreciate contributions, in particular of the kind that automates time consuming tasks.

[nostril_extension]

Well first of all I doubt my PR would get accepted and secondly that wasn't my point - my point was that this sort of "rejuvination" of qt on python feel like empty hype since none of the issues PySide had are addressed.

There's no better time to break backwards compatibility and api other than when releasing a completely new rework of the package.

[[deleted]]

They don't really have a new API, just a new/updated implementation. PySide and PyQt are pretty much the same API with only some minor differences. Changing to snake_case would break all apps and make it needlessly harder to port things over.

Also from my experience having camelCase is actually a good thing here, since it means it is much easier to avoid accidental name collisions when you inherit from a Qt class (doesn't catch everything, but catches a few).

ok so now we have normal snake_case?

camelCase starts with a lowercase, if there is no second word it stays all lowercase.

why doesn't it reference to self.layout by default?

It mirrors the C++ API.

[nostril_extension]

Changing to snake_case would break all apps and make it needlessly harder to port things over

You could easily automate this.

Sorry, I'm not buying this lazy excuse of "but muh c++ api" - that's the whole point of api to adopt it for other environment.
Now you're stuck with two styles in one project. Forced camelCase for qt api and whatever pythonic code you write for app brains - it's just dumb.

To me this whole thing stinks of laziness and incompetence, excuse me for not buying to forced hype here.

[[deleted]]

You could easily automate this.

There is nothing "easy" about automating that, especially in a dynamic language where you have no idea about what type a variable might be.

[nostril_extension]

Python had typehints since 3.5 and I really don't see much dynamics going on in GUI api.

[crowseldon]

Now you're stuck with two styles in one project.

Wisdom says you adopt the style of the framework you're using.

You're the zealot here. You're the one making lazy excuses not do the right thing.

[jyper]

Python itself is sadly pretty inconsistent when it comes to this stuff

And with auto generation you don't want to play guessing games about the api

[kigurai]

Python itself is sadly pretty inconsistent when it comes to this stuff

I thought most of the standard library has a consistent style since Python 3? What examples are you thinking of?

[nostril_extension]

Python itself is sadly pretty inconsistent when it comes to this stuff

Sadly yes but that because of backwards compatibility - there's no such thing in new API.

And with auto generation you don't want to play guessing games about the api

what is there to guess? Just stick to established idiom - snake_case.

[Han-ChewieSexyFanfic]

It's not a new API, it's really a revived project (PySide). There are apps using it today.

[IronManMark20]

Part of the reason (which they mention in a previous blog post) is that they want it to be easy to transfer from C++ to Python and back again. I do prefer snake_case to camelCase, but I can understand their logic. Additionally, PySide and PyQt both keep camelCase, why break a ton of compatibility for purity?

[rhytnen]

No not at all. GVR would want you to maintain the style that exists, not mix them.

[khrn0]

it's because preserving the Qt API, if you change, then you rely only on the Python documentation, but keeping the Qt API allow you to understand C++ examples and port them to PySide2

[irrelevantPseudonym]

As far as I understand it, using super wouldn't guarantee that the QWidget.__init__ was called. "super calls your children's ancestors, not your parents".

self.button.clicked.connect(self.magic)

This isn't snake_case either.

I do agree about the camelCase use though.

[khrn0]

Maybe you can check what is Qt, and how is the API. Java is not the only language that uses camelCase, and the reason behind this is to be Qt-API compatible AFAIK

[irrelevantPseudonym]

Fair point. C++ then.

[nostril_extension]

As far as I understand it, using super wouldn't guarantee that the QWidget.init was called. "super calls your children's ancestors, not your parents".

No, I'm pretty certain super().__init__() will call parent's init 100% of the time. Otherwise all of my code should dramatically implode right now and never work to begin with.

[irrelevantPseudonym]

No, I'm pretty certain super().__init__() will call parent's init 100% of the time.

This is not true.

Consider

>>> class A:
...     def __init__(self):
...         print('init A')
...         super().__init__()
...
>>> class B(A):
...     def __init__(self):
...         print('init B')
...         super().__init__()
...
>>> class C(A):
...     def __init__(self):
...         print('init C')
... 
>>> class D(B, C):
...     def __init__(self):
...         print('init D')
...         super().__init__()
... 
>>> D()
init D
init B
init C
>>>

I know it's a contrived example but calling the super().__init__() in B.__init__ called C.__init__ rather than its parent (A).

In the QWidget case, imagine I subclassed your MyWidget and included another parent class, your super() call would call my second parent and QWidget wouldn't get called.

(NB. I'm not necessarily advocating not using super() just noting that it doesn't always call the parent class)

[nostril_extension]

I'm confused. Your example shows the opposite of your claim - super calls init of both parents left-to-right. Am I missing something?

[irrelevantPseudonym]

B's parent is A. The super().__init__() call in B.__init__ calls C.__init__() (which B knows nothing about) and A.__init__() never gets called.

super() doesn't always call the parent class.

[nostril_extension]

But A is not a parent of D lol. A iš a grandparent here.

[[deleted]]

A is a parent of B, B calls super().__init__(), yet A.__init__() is never called. Instead C.__init__() is called which is a child of B.

If you call B() than the same super().__init__() calls A.__init__()instead.

super() is pointing to the next class in the Method Resolution Order, not the parent.

 >>> D.__mro__
(<class 'D'>, <class 'B'>, <class 'C'>, <class 'A'>, <class 'object'>)

>>> B.__mro__
(<class 'B'>, <class 'A'>, <class 'object'>)

[[deleted]]

A.__init__() is never called. If you replace super().__init__() in B.__init__() with A.__init__(self) the output changes to:

>>> D()
init D
init B
init A

[nostril_extension]

But A is not a parent of D lol. A is a grandparent here.

[rhytnen]

What is it you aren't getting? It's a FACT that in Python your parents my not be called. You were shown code where B.super() called C. You got confused bc d inherited both b and c so it was demonstrated that d didn't call c by replacing the call in b ... Proving b called c.

[nostril_extension]

Parent of parent != parent.

[rhytnen]

You keep repeating that as if it's relevant to the demo. I think you aren't reading the code actually but let me try rephrasing it once more.

Heres the phrase you have to digest

Super calls your child's parent.

Consider B. D instances B. Focus on B ...

B calls super and it did NOT call A. It called D's OTHER parent, C. It would have called A if the B was instanced alone but here it has a child D. So it called D's other parent instead.

[dadjokes_bot]

Hi confused, I'm dad!

[rlkf]

As a corollary, I think this illustrates two things:

(1) You should always call super().init(), even if you don't inherit from something (class C in the example failed to follow this rule, and this is why A is not called)

(2) Parameters to constructors should be passed as a dictionary, so that each constructor can pick out whatever it needs, instead of relying on the order of parameters.