tkinter Font options

[jvalenzuela]

The underline and overstrike arguments of the tkinter.font.Font constructor are annotated as bool. Granted, bool is more apt, yet the documentation describes them as int.

Issue exists as of 0e9b8c9.

[Akuli]

A lot of things in tkinter (and elsewhere in typeshed) are annotated as bool if they are meant to be used as bools, even though other objects would work. Here are some reasons why:

• If you accidentally pass in a number, it is nice to get an error when type checking.
• If you see int, you might expect underline=5 to do a really thick underline, and you would be disappointed when it is interpreted as True and you get a regular underline.

Do you have a specific reason to pass int values to the Font constructor?

[srittau]

I'd like to add that these cases often preceed the introduction of bools in Python. It may make sense to fix the Python docs instead of typeshed.

[jvalenzuela]

Do you have a specific reason to pass int values to the Font constructor?

No, in my particular circumstance the option is an inline literal to __init__; it can be whatever. The reason it is currently an int is that is what the Python docs say, e.g, "underline - font underlining (0 - none, 1 - underline)".

I'd like to add that these cases often preceed the introduction of bools in Python. It may make sense to fix the Python docs instead of typeshed.

True, if the underlying Python translation layer and Tk will accept a bool. A quick glance at the CPython tkinter source shows the options are converted to strings then passed to tk, which would require tk to normalize "1" and "True".

[Akuli]

Bools are passed as integes to tcl:

>>> import tkinter
>>> tkinter.Tk().call('puts', True)
1
''
>>> 

[Akuli]

options are converted to strings then passed to tk

Ah, now I what you mean. You're looking at this:

    def _set(self, kw):
        options = []
        for k, v in kw.items():
            options.append("-"+k)
            options.append(str(v))
        return tuple(options)

This also works, because "True" is a valid boolean in Tcl:

>>> tkinter.Tk().call('if', 'True', 'puts hello')
hello
''
>>> tkinter.Tk().call('if', 'False', 'puts hello')
''

[jvalenzuela]

Given tcl accepts the strings "True", "False", "0", and "1" as boolean values, I guess it comes down to the discrepancy between the official documentation and the type annotation. Perhaps a more liberal latter, e.g.:

underline: Union[bool, Literal[0], Literal[1]]

[Akuli]

We already have Literal[0, 1] in a few places in tkinter. I'd rather not add more, because it is not as simple and clear as bool.

If you want, you could make an issue and/or PR at cpython about updating the documentation.

[srittau]

Closing per @Akuli and our long-standing policy on "int bools".

[jvalenzuela]

I was looking into changing my code to replace tkinter.TRUE/FALSE with Python bools in order to rectify these Mypy errors, and noticed several other places where tkinter.TRUE/FALSE are used but do not cause Mypy errors. An example is the expand parameter to Widget.pack(), which permits bool or Literal[0, 1](defined in __init__.Pack), hence its acceptance of tkinter.TRUE/FALSE. Does this seem inconsistent with the current Font option type hints?

[srittau]

@jvalenzuela We should probably remove the literals from them at some point. That said, tkinter.TRUE/FALSE are already typed as bools, so they shouldn't cause any typing problems.

[jvalenzuela]

That said, tkinter.TRUE/FALSE are already typed as bools, so they shouldn't cause any typing problems.

I didn't realize those constants where type hinted differently from their actual value (ref #4669). The source of my original problem was I was using a literal 1 instead of tkinter.TRUE; an error on my part.