Skip to content

BaseException.__init__ accepts **kwargs#1704

Merged
JelleZijlstra merged 2 commits into
python:masterfrom
anentropic:mypy-issue-4138-baseexception-kwargs
Nov 4, 2017
Merged

BaseException.__init__ accepts **kwargs#1704
JelleZijlstra merged 2 commits into
python:masterfrom
anentropic:mypy-issue-4138-baseexception-kwargs

Conversation

@anentropic

Copy link
Copy Markdown
Contributor

This is to fix python/mypy#4183

@JelleZijlstra

Copy link
Copy Markdown
Member

Can you apply the same change in Python 3, and use object instead of Any?

@anentropic

Copy link
Copy Markdown
Contributor Author

certainly!

why does Python 3 BaseException need object rather than Any?

I don't question it, I'd just like to understand.

I see it already has *args: object ... but a bunch of the other builtins have **kwargs: Any

@anentropic
anentropic force-pushed the mypy-issue-4138-baseexception-kwargs branch from 4bb7cec to 0217ce2 Compare November 1, 2017 17:38
@JelleZijlstra

Copy link
Copy Markdown
Member

I think they should be object in both Python 2 and 3. Any generally means "the type system is not powerful enough to describe this type", and object means "all instances of object are accepted". In this case, we want the latter, not the former. (I think it's purely a semantic difference here; it doesn't actually accept the code type checkers will accept right now.)

@anentropic

Copy link
Copy Markdown
Contributor Author

wouldn't that mean in Python 2 that old-style classes were not acceptable args?

So it's maybe correct for Python 2 but in Python 3 more of the Anys in the typeshed should be object?

@JelleZijlstra

Copy link
Copy Markdown
Member

object includes old-style classes in Python 2 (isinstance(o, object) returns True for them). I don't think Python 2 and 3 should be different here.

@anentropic

Copy link
Copy Markdown
Contributor Author

then I am curious what, if anything, would pass a type-check for Any but fail for object or vice-versa

I appreciate there's a semantic difference but it is pretty subtle, what makes it apply here?

@JelleZijlstra

Copy link
Copy Markdown
Member

I don't think in this case the difference will directly affect type checker output; it's more about cleanliness, because we try to minimize usage of Any where possible.

In some cases it can make a difference though. If you have an API that takes a callback of type Callable[[Any], None], then a user can pass a callback that actually takes int as an argument. But if you take a callback of type Callable[[object], None], then the callback with an int argument will be rejected by the type checker.

Would it be easier to discuss this further in the typing chatroom at https://gitter.im/python/typing?

@JelleZijlstra
JelleZijlstra merged commit 05f527c into python:master Nov 4, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Reporting "too many arguments" to __init__ for class which takes *args

2 participants