-
Notifications
You must be signed in to change notification settings - Fork 161
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Should we use self.set_title(title="...") instead #200
Comments
It's not a big difference, IMHO. I think it's clear what the code's intent is. I would leave it as it is. |
For me, if subclassed, code it as really subclassed .. that was the thought.. (So I am not so keen on all the super() things, after all. Please read on.) Let me re-remind you that one code was in python2 style. layout_listbox_example.py at:
Considering the reason behind adopting the syntax change on super() with PEP-3135, at least, we need to get rid of this old python2 syntax code in tutorial document. https://www.python.org/dev/peps/pep-3135/#rationale Maybe I am wrong. But this and the following are what I saw today by poking upstream documents which seems to demand more style changes. As I learn more on coding in Python, subclassing seems to be a bad idea these days for overhead etc.
The example code by the upstream pyobject developer doesn't use subclass with
Gtk.Template codes, of course, need class but no
As a tutorial, complicating code by subclass may not be desirable thing if it has clear merits. For example, Section 6.1.1 Examples can be as simple as the following without class:
Although, we are more likely to use Gtk.Template, it is very educational how each Gtk components are used. I thank your effort which gave me good heads up. Thank you. |
I agree that using Python 3's super() is a good idea, but is unrelated
to this.
I'm not sure what you are proposing at this point, get rid of keyword
argument in super calls, or sub-classes in general?
I don't think PyGObject is outlawing sub-classes in general, because it
would essentially discard the object-oriented nature of Python. I think
what they are saying is that overriding methods can be problematic.
|
Hi,
I just send the PR #199. I was conservative.
It may be even nicer to change all instances from:
to even cleaner style:
This example is more expandable for user in future. Just a thought ...
The text was updated successfully, but these errors were encountered: