Missing attributes on tkinter.Events, tkinter.ttk.Frame, and tkinter.ttk.Treeview

[jcrmatos]

Hello,

Mypy complains that tkinter.Event doesn't have x_root/y_root attributes, which is incorrect.
Here is an example (abridged) of code that mypy complains about.

...
    def show(self, event):
        # Position the tooltip below and to the rigth of the cursor (16x16).
        # Mypy returns an error Event has no attr x_root/y_root.
        x_pos = event.x_root + 16  # type: ignore
        y_pos = event.y_root + 16  # type: ignore
        self.geometry('+{0}+{1}'.format(x_pos, y_pos))

        self.deiconify()
        self.visible = True

        self.after(self.delay, self.hide)  # Milliseconds.
...
widget.bind('<Enter>', self.show)
...

Best regards,

JM

[jcrmatos]

Hello,

Forgot to say that it also doesn't recognize the x, y, and widget attributes.
I'm using Python 3.5.3 and mypy 0.521.

Best regards,

JM

[jcrmatos]

Hello,

Just checked that it also complains about tkinter.ttk.Frame.master and tkinter.ttk.Treeview.master attributes.

Best regards,

JM

[JelleZijlstra]

Feel free to open a PR adding those! I don't think the stubs for tkinter have had a lot of attention.

[Akuli]

Tkinter stubs use a lot of Any, and they generate lots of mypy errors with mypy --strict.

I have written my own tkinter stubs, but I don't think that creating a pull request that adds them to typeshed is a good idea. I explained why in the README of my stubs, but the tl;dr is:

• My stubs are missing many things, and completing them perfectly would be a lot more work than I'm interested in doing. I'd rather add support for features as they are actually needed.
• My stubs contain some copy/pasta due to how tkinter's widget options work, and the copy/pasta amount would be pretty bad if my stubs supported every feature of tkinter.
• Putting my stubs to typeshed would break tkinter code that currently typechecks correctly in mypy.
• My stubs use Python 3.8 features. I guess typeshed must be more backwards compatible than that?
• My stubs would be more work to maintain than what's currently in typeshed. New features would need to be added every time a new release of Tk comes out, even when the duck-typed tkinter code doesn't need changes.

[srittau]

We are grateful for any improvements that can be made to our stubs. Stubs generally follow Python 3.7 syntax. For positional only arguments, we need to use the __x syntax, instead of being able to use the forward slash.

[Akuli]

I wonder how many people are actually using mypy and tkinter together, i.e. how bad it would be to break backwards compatibility in tkinter stubs. At least I'm quite confident that nobody uses mypy --strict and tkinter together, because that just doesn't work.

[Akuli]

I guess I should clarify that "breaking backwards compatibility" means need to change type hints and add asserts to make mypy checks pass again. On the other hand, the newly generated mypy errors could also help with discovering bugs.

[hauntsaninja]

tkinter stubs are the most poorly supported stdlib stubs in typeshed, like Sebastian I'd be grateful for improvements to typeshed.

Just a scattered reply to some of your concerns raised here and at https://github.com/Akuli/porcupine/tree/a6925e617/my_stubs#why-not-pull-request

My stubs use typing.Literal generously. That's new in Python 3.8, but typeshed stubs need to be backwards compatible.

typeshed stubs are able to use Literal (and it works for Python 3.7 and earlier as well). You just have to import it from typing_extensions (all type checkers understand this pattern).

Any code using constants like tkinter.END would need to be changed to use strings like 'end' instead or I would need to add support for tkinter.END and similar constants.

If a method is missing from my stubs but present in what's currently in typeshed, then all mypy-checked code using that method will stop working.

This is the kind of backward incompatibility I'd very much prefer not to have. But it's totally okay to introduce new type errors in user's code from type narrowing that result in true positives (or useful warnings) a lot of the time.

However, typeshed does err on the side of avoiding false positives, so for instance, we'd prefer to have a loosely typed __getitem__ over omitting it.

If someone calls a tkinter method in a way that I have never used, such as after(ms) in the above example, then they would start getting mypy errors.

In my opinion, this kind of issue is preferred to not having any definition or having a mostly untyped definition.

In the past, typeshed contributors decided to not support '??' in tkinter.Event (see above). My tkinter.Event does that "right" and supports '??', and a lot of assert thing != '??' would need to be added to mypy checked code to make it work with my stubs.

As the reviewer of that PR, I still stand by what I said then: "Re "??", I'll trust [the contributor] on whether Union[str, whatever] is a more helpful type than whatever. Note that generally typeshed prefers to stick to implementation, so if this causes issues down the road, we'll change it."

Generally speaking, tkinter is a tricky case for me, since it's not a type-friendly design and I don't have experience with using the library. This means we're likely to have imperfect types no matter what we do and it's hard for me to ascertain what the right tradeoff is.
I think what to do here might come down to the specifics of what's missing from your stubs. We'd certainly accept PRs that improved the existing stubs based on yours, but it sounds like you might have in mind wholesale swapping out of the existing stubs for your stubs, in which case we might want to be a little more circumspect and/or do the work of merging the two.

[Akuli]

Any code using constants like tkinter.END would need to be changed to use strings like 'end' instead or I would need to add support for tkinter.END and similar constants.
...

This is the kind of backward incompatibility I'd very much prefer not to have.

I will add type hints for tkinter.END and similar constants if I actually create a pull request. Some people like them, and this comes down to opinions. I don't want to shove my opinions into other people's code.

As the reviewer of that PR, I still stand by what I said then: "Re "??", I'll trust [the contributor] on whether Union[str, whatever] is a more helpful type than whatever.

I would dislike Union[str, whatever] myself too, but my code does Union[Literal['??'], whatever]. I think that's reasonable, and actually checking for that leads to a readable assert event.thing != '??' as opposed to a confusing assert not isinstance(event.thing, str). I guess Literal['??'] wasn't considered in the tkinter Event field pull request.

Generally speaking, tkinter is a tricky case for me, since it's not a type-friendly design... This means we're likely to have imperfect types no matter what we do...

Tkinter is stringly typed because it's a wrapper for a stringly typed programming language. I really like using Literal with tkinter.

...and I don't have experience with using the library.

I'm more than familiar with tkinter.

I think what to do here might come down to the specifics of what's missing from your stubs.

If I'll actually make a pull request, then I won't delete any existing Any-typed methods without adding in "correctly" typed methods that replace those. I might leave a bunch of the Any-typed methods under a TODO comment or something, and similarly add TODO comments for missing option names.

Edit:

However, typeshed does err on the side of avoiding false positives, so for instance, we'd prefer to have a loosely typed __getitem__ over omitting it.

My stubs allow for example label['text'], which comes out as a string, but not label['blablabla'] or label[variable_with_type_str]. Both of those result in mypy errors, but a variable with e.g. type Literal['text'] works. What's currently in typeshed allows all these and gives typing.Any for them all. What would be the preferable thing for this?

I created my stubs for my "large" tkinter project (wc -l *.py */*.py says 8112 with type hints) and I didn't have any issues with the now-disallowed label[variable_with_type_str]. I created code like this exactly once:

        State = typing.Union[typing.Literal['normal'],
                             typing.Literal['disabled']]
        matches_something_state: State
        replace_this_state: State
        ...
        self.previous_button['state'] = matches_something_state
        self.next_button['state'] = matches_something_state
        self.replace_this_button['state'] = replace_this_state
        self.replace_all_button['state'] = matches_something_state

[Akuli]

Copy/pasta will be another problem. How much copy/pasta is acceptable in stub files? The subprocess stubs have many long and mostly copy/pasta overrides for subprocess.Popen.__new__.

With the current mypy features that I'm aware of, every tkinter widget option would have quite a lot of copy/pasta:

• __init__ kwarg
• configure kwarg
• config kwarg (config is an alias for configure)
• cget argument of type Literal['option name']
• __setitem__ argument
• __getitem__ argument (__getitem__ is an alias for cget)
• Copy/pasting all these to inherited classes

Much of the copy/pasta could be avoided with nicer mypy features that are currently not implemented:

• __init__, configure, config kwargs: Allow using TypedDict for more precise typing of **kwds mypy#4441
• Inheritance issues: (support overloading methods in subclass mypy#9133)
• Typing aliased methods: some way to specify "these two methods have exactly the same type"

If all this was available, then there would be almost no copy/pasta left for each option:

• TypedDict or something else for kwargs of __init__, configure, config
• __setitem__ with exactly the same types as __init__, configure, config (unless there's some way to borrow the __setitem__ of a TypedDict)
• cget and __getitem__ (the types of the options are different for these than for __init__, config, configure, __setitem__)

Meanwhile, is it acceptable to write a script that generates the copy/pasta for stub files?

This affects only two stub files, tkinter/__init__.pyi and tkinter/ttk.pyi.