Fix some minor typos/formatting
This commit is contained in:
parent
9cf994cde3
commit
c19fe93c56
11
pep-3107.txt
11
pep-3107.txt
|
@ -25,7 +25,7 @@ Rationale
|
|||
|
||||
Because Python's 2.x series lacks a standard way of annotating a
|
||||
function's parameters and return values (e.g., with information about
|
||||
a what type a function's return value should be), a variety of tools
|
||||
what type a function's return value should be), a variety of tools
|
||||
and libraries have appeared to fill this gap [#tailexamp]_. Some
|
||||
utilise the decorators introduced in "PEP 318", while others parse a
|
||||
function's docstring, looking for annotations there.
|
||||
|
@ -69,14 +69,14 @@ what annotations are and are not:
|
|||
Another library might be used to provide typechecking for Python
|
||||
functions and methods. This library could use annotations to
|
||||
indicate the function's expected input and return types, possibly
|
||||
something like ::
|
||||
something like::
|
||||
|
||||
def haul(item: Haulable, *vargs: PackAnimal) -> Distance:
|
||||
...
|
||||
|
||||
However, neither the strings in the first example nor the
|
||||
type information in the second example have any meaning on their
|
||||
own; meaning comes from third-party libraries alone.
|
||||
own; meaning comes from third-party libraries alone.
|
||||
|
||||
3. Following from point 2, this PEP makes no attempt to introduce
|
||||
any kind of standard semantics, even for the built-in types.
|
||||
|
@ -99,7 +99,7 @@ Parameters
|
|||
|
||||
Annotations for parameters take the form of optional expressions that
|
||||
follow the parameter name. This example indicates that parameters 'a'
|
||||
and 'c' should both be a ``Number``, while parameter 'b' should both
|
||||
and 'c' should both be a ``Number``, while parameter 'b' should
|
||||
be a ``Mapping``::
|
||||
|
||||
def foo(a: Number, b: Mapping, c: Number = 5):
|
||||
|
@ -149,8 +149,7 @@ The parameter list can now be followed by a literal ``->`` and a
|
|||
Python expression. Like the annotations for parameters, this
|
||||
expression will be evaluated when the function definition is executed.
|
||||
|
||||
The grammar for function definitions [#grammar]_ is now something like
|
||||
::
|
||||
The grammar for function definitions [#grammar]_ is now something like::
|
||||
|
||||
funcdef ::= [decorators] "def" funcname "("
|
||||
[parameter_list] ")" ["->" expression] ":" suite
|
||||
|
|
Loading…
Reference in New Issue