10000 Pretty-print Void differently from NoneTyp · Issue #1959 · python/mypy · GitHub
[go: up one dir, main page]
Skip to content

Pretty-print Void differently from NoneTyp #1959

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.

Sign up for GitHub

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

Jump to bottom
Closed
gnprice opened this issue Jul 29, 2016 · 5 comments
Closed

Pretty-print Void differently from NoneTyp #1959

gnprice opened this issue Jul 29, 2016 · 5 comments
Labels
priority-0-high topic-strict-optional

Comments

@gnprice
Copy link
Collaborator
gnprice commented Jul 29, 2016

We've repeatedly seen issues where mypy emits an error that looks like type "foo" does not match type "foo", where the two types in question are identical as printed. That's super confusing for a user and makes mypy look quite buggy -- why is it saying this type doesn't match itself?

There are two recurring causes for this kind of symptom that I can recall seeing:

  • suppressing long lists inside tuples and unions;
  • rendering different types identically with the string "None".

We should probably stop suppressing long lists -- if the type is complicated, it's complicated, and if there's an error the user almost surely would rather see it whatever it is -- but those are at least mitigated by more or less explicitly being elliptical.

The cases with "None" vs "None" are extra confusing because there's nothing the user can see that at all points to why mypy could possibly consider these to be two different types internally. After all, they're just None! -- what internal structure does that have? The most recent instance I've run into is #1956 today.

Our messages would be more informative in these cases if we rendered Void and NoneTyp differently -- so at least one of them wasn't simply the string "None". This may show a bit of puzzling complexity to the user... but it's complexity that's really there in mypy's behavior, and it's probably better for the user to be given a hope of seeing its work. (It's possible that per #1278 and #1847 the ultimate solution should be to eliminate that complexity in the behavior, at which point it'll disappear from the user's view as well and in total honesty.)

For example, based on the docstring of Void:

class Void(Type):
    """The return type 'None'.

    This can only be used as the return type in a callable type and as
    the result type of calling such callable.
    """

perhaps it could be rendered as something like NoneRet -- recognizably connected to "None" but gesturing at its more specific nature.
@gnprice
Copy link
Collaborator Author
gnprice commented Jul 29, 2016

Added the "affects/strict-optional" label because I suspect this issue may be especially acute in the presence of --strict-optional, but we've seen it pop up every so often since long before --strict-optional was implemented.

@gnprice
Copy link
Collaborator Author
gnprice commented Jul 29, 2016

(For the truncation of lists of types in tuples and unions, see #287.)

@gnprice
Copy link
Collaborator Author
gnprice commented Aug 4, 2016

This is fixed in the --strict-optional world by #1975.

@gnprice gnprice added this to the 0.4.x milestone Aug 4, 2016
@gvanrossum
Copy link
Member

A simple fix that prints Void as 'Void' would still be welcome.

@gvanrossum gvanrossum removed this from the 0.4.x milestone Mar 29, 2017
@JukkaL
Copy link
Collaborator
JukkaL commented Apr 4, 2017

Void was removed recently so this doesn't seem relevant any more.

@JukkaL JukkaL closed this as completed Apr 4, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
priority-0-high topic-strict-optional
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@gnprice @JukkaL @gvanrossum
0