2016-12-28 18:37:28 +01:00
|
|
|
# This mypy stubs file ensures that mypy can correctly analyze REQ.
|
2017-07-20 00:19:42 +02:00
|
|
|
from typing import Any, Callable, Text, TypeVar
|
2016-07-22 15:10:19 +02:00
|
|
|
from django.http import HttpResponse
|
|
|
|
|
|
JsonableError: Move into a normally-typed file.
The file `zerver/lib/request.py` doesn't have type annotations
of its own; if they did, they would duplicate the annotations that
exist in its stub file `zerver/lib/request.pyi`. The latter exists
so that we can provide types for the highly dynamic `REQ` and
`has_request_variables`, which are beyond the type-checker's ken
to type-check, but we should minimize the scope of code that gets
that kind of treatment and `JsonableError` is not at all the sort of
code that needs it.
So move the definition of `JsonableError` into a file that does
get type-checked.
In doing so, the type-checker points out one issue already:
`__str__` should return a `str`, but we had it returning a `Text`,
which on Python 2 is not the same thing. Indeed, because the
message we pass to the `JsonableError` constructor is generally
translated, it may well be a Unicode string stuffed full of
non-ASCII characters. This is potentially a bit of a landmine.
But (a) it can only possibly matter in Python 2 which we intend to
be off before long, and (b) AFAIK it hasn't been biting us in
practice, so we've probably reasonably well worked around it where
it could matter. Leave it as is.
2017-07-20 00:51:54 +02:00
|
|
|
from zerver.lib.exceptions import JsonableError as JsonableError
|
2016-05-30 16:40:59 +02:00
|
|
|
|
JsonableError: Move into a normally-typed file.
The file `zerver/lib/request.py` doesn't have type annotations
of its own; if they did, they would duplicate the annotations that
exist in its stub file `zerver/lib/request.pyi`. The latter exists
so that we can provide types for the highly dynamic `REQ` and
`has_request_variables`, which are beyond the type-checker's ken
to type-check, but we should minimize the scope of code that gets
that kind of treatment and `JsonableError` is not at all the sort of
code that needs it.
So move the definition of `JsonableError` into a file that does
get type-checked.
In doing so, the type-checker points out one issue already:
`__str__` should return a `str`, but we had it returning a `Text`,
which on Python 2 is not the same thing. Indeed, because the
message we pass to the `JsonableError` constructor is generally
translated, it may well be a Unicode string stuffed full of
non-ASCII characters. This is potentially a bit of a landmine.
But (a) it can only possibly matter in Python 2 which we intend to
be off before long, and (b) AFAIK it hasn't been biting us in
practice, so we've probably reasonably well worked around it where
it could matter. Leave it as is.
2017-07-20 00:51:54 +02:00
|
|
|
ViewFuncT = TypeVar('ViewFuncT', bound=Callable[..., HttpResponse])
|
2016-05-30 16:40:59 +02:00
|
|
|
|
|
|
|
|
class RequestVariableMissingError(JsonableError): ...
|
2016-12-28 18:37:28 +01:00
|
|
|
class RequestVariableConversionError(JsonableError): ...
|
2016-05-30 16:40:59 +02:00
|
|
|
|
|
|
|
|
def REQ(*args: Any, **kwargs: Any) -> Any: ...
|
|
|
|
|
|
2016-07-22 15:10:19 +02:00
|
|
|
def has_request_variables(view_func: ViewFuncT) -> ViewFuncT: ...
|
