Skip to content
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

PEP 484: Clarify definition of AnyStr #744

Merged
merged 1 commit into from
Sep 12, 2018
Merged

PEP 484: Clarify definition of AnyStr #744

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 8 additions & 9 deletions pep-0484.txt
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -312,9 +312,9 @@ example, we can define a type variable that ranges over just ``str`` and
``bytes``. By default, a type variable ranges over all possible types.
Example of constraining a type variable::

from typing import TypeVar
from typing import TypeVar, Text

AnyStr = TypeVar('AnyStr', str, bytes)
AnyStr = TypeVar('AnyStr', Text, bytes)

def concat(x: AnyStr, y: AnyStr) -> AnyStr:
return x + y
Expand Down Expand Up @@ -1357,8 +1357,7 @@ without specifying the actual default value. For example::
def foo(x: AnyStr, y: AnyStr = ...) -> AnyStr: ...

What should the default value look like? Any of the options ``""``,
``b""`` or ``None`` fails to satisfy the type constraint (actually,
``None`` will *modify* the type to become ``Optional[AnyStr]``).
``b""`` or ``None`` fails to satisfy the type constraint.
Copy link
Member

Choose a reason for hiding this comment

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

Good call.


In such cases the default value may be specified as a literal
ellipsis, i.e. the above example is literally what you would write.
Expand Down Expand Up @@ -1785,9 +1784,9 @@ A constrained ``TypeVar`` type can often be used instead of using the
``@overload`` decorator. For example, the definitions of ``concat1``
and ``concat2`` in this stub file are equivalent::

from typing import TypeVar
from typing import TypeVar, Text

AnyStr = TypeVar('AnyStr', str, bytes)
AnyStr = TypeVar('AnyStr', Text, bytes)

def concat1(x: AnyStr, y: AnyStr) -> AnyStr: ...

Expand Down Expand Up @@ -2024,12 +2023,12 @@ A few one-off types are defined that test for single special methods

Convenience definitions:

* Optional, defined by ``Optional[t] == Union[t, type(None)]``

* AnyStr, defined as ``TypeVar('AnyStr', str, bytes)``
* Optional, defined by ``Optional[t] == Union[t, None]``
Copy link
Member

Choose a reason for hiding this comment

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

Another good call. Perhaps the section on "Using None" should also be revised? It currently says

When used in a type hint, the expression None is considered equivalent to type(None).

But that's false -- at least for mypy, and IIRC we once discussed this and decided that this is intentional: type(None) is not acceptable at all in type hints!


* Text, a simple alias for ``str`` in Python 3, for ``unicode`` in Python 2

* AnyStr, defined as ``TypeVar('AnyStr', Text, bytes)``

* NamedTuple, used as
``NamedTuple(type_name, [(field_name, field_type), ...])``
and equivalent to
Expand Down