Skip to content

Conversation

fyquah
Copy link
Contributor

@fyquah fyquah commented Aug 5, 2016

No description provided.

@@ -86,6 +86,9 @@ path_hooks = ... # type: List[Any]
path_importer_cache = ... # type: Dict[str, Any]
displayhook = ... # type: Optional[Callable[[int], None]]
excepthook = ... # type: Optional[Callable[[type, BaseException, TracebackType], None]]
exc_type = ... # type: type
exc_value = ... # type: BaseException
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Strictly speaking, this can be an old-style class as well (and not derive from BaseException).

Declare as "Any"?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we can ignore that detail? Does pytype understand the difference between old-style and new-style classes? Mypy doesn't -- it just assumes all classes have type type and insists that all exception classes inherit from BaseException.

If we go with the mypy model, all three values should just be declared Optional[...]. If we go with Matthias' suggestion then I'm not sure what to use for exc_type -- maybe Union[None, type, types.ClassType]. In either case exc_traceback should be Optional.

(Currently mypy doesn't care about the lack of Optional, but it will.)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

pytype models the difference between old-style and new-style. We're not getting a whole lot of value out of that, though, so we might drop it at some point.

  • sys.exc_type: Union[None, type, types.ClassType] sounds good to me.
  • sys.exc_value: Any (Because you can do raise IOError, 42)
  • sys.exc_traceback: TracebackType (Without Optional.)

About exc_traceback: I can't seem to make this None. It either doesn't exist or it contains a traceback, even when doing things like

raise IOError, IOError(), None

Am I missing something?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have no idea -- I don't want to look it up in the CPython source any more than you do. :-)

That said these types look fine with me -- even though even when you do raise IOError, 42, sys.exc_value is still an IOError instance (it prints as 42 only because that's how the str() or an exception is defined).

In any case, the docs say these have been deprecated since Python 1.5! Do we really need them? (Well I guess the OP found a need...)

@matthiaskramm
Copy link
Contributor

True. Then let's use Union[BaseException, types.Classtype] for sys.exc_value. (This one can't be None either, it seems)

@@ -86,6 +86,9 @@ path_hooks = ... # type: List[Any]
path_importer_cache = ... # type: Dict[str, Any]
displayhook = ... # type: Optional[Callable[[int], None]]
excepthook = ... # type: Optional[Callable[[type, BaseException, TracebackType], None]]
exc_type = ... # type: type
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Optional[type]

@@ -86,6 +86,9 @@ path_hooks = ... # type: List[Any]
path_importer_cache = ... # type: Dict[str, Any]
displayhook = ... # type: Optional[Callable[[int], None]]
excepthook = ... # type: Optional[Callable[[type, BaseException, TracebackType], None]]
exc_type = ... # type: Optional[type]
exc_value = ... # type: Union[BaseException, Classtype]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typo, ClassType.

Change sys.exc_value to Union[BaseException, types.Classtype]

Change 2.7/sys.exc_type to Optional[type]

Import Classtype from types

Fix Classtype typo
@gvanrossum gvanrossum merged commit 6c1a185 into python:master Aug 5, 2016
@gvanrossum
Copy link
Member

Thanks! All merged.

PS. Please don't squash your local commits when re-pushing the branch. We squash commits when we merge, but during code review the local history is useful.

hswong3i pushed a commit to alvistack/python-typeshed that referenced this pull request May 25, 2025
…on#440)


Tests from python/cpython#122074. We don't have to use the base descriptor
approach here because we find the annotations directly in the `__dict__`
for the class, which avoids metaclass problems.
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.

3 participants