mirror of
				https://github.com/python/cpython.git
				synced 2025-10-25 10:44:55 +00:00 
			
		
		
		
	Terminology fix: exceptions are raised, except in generator.throw().
This commit is contained in:
		
							parent
							
								
									e8e02e3b5b
								
							
						
					
					
						commit
						7cb1319688
					
				
					 17 changed files with 32 additions and 32 deletions
				
			
		|  | @ -959,7 +959,7 @@ Python-level trace functions in previous versions. | |||
| .. cvar:: int PyTrace_C_EXCEPTION | ||||
| 
 | ||||
|    The value for the *what* parameter to :ctype:`Py_tracefunc` functions when a C | ||||
|    function has thrown an exception. | ||||
|    function has raised an exception. | ||||
| 
 | ||||
| 
 | ||||
| .. cvar:: int PyTrace_C_RETURN | ||||
|  |  | |||
|  | @ -154,7 +154,7 @@ The following is a very popular anti-idiom :: | |||
| 
 | ||||
| Consider the case the file gets deleted between the time the call to | ||||
| :func:`os.path.exists` is made and the time :func:`open` is called. That means | ||||
| the last line will throw an :exc:`IOError`. The same would happen if *file* | ||||
| the last line will raise an :exc:`IOError`. The same would happen if *file* | ||||
| exists but has no read permission. Since testing this on a normal machine on | ||||
| existing and non-existing files make it seem bugless, that means in testing the | ||||
| results will seem fine, and the code will get shipped. Then an unhandled | ||||
|  |  | |||
|  | @ -116,7 +116,7 @@ The :mod:`bdb` module also defines two classes: | |||
|       * ``"exception"``: An exception has occurred. | ||||
|       * ``"c_call"``: A C function is about to be called. | ||||
|       * ``"c_return"``: A C function has returned. | ||||
|       * ``"c_exception"``: A C function has thrown an exception. | ||||
|       * ``"c_exception"``: A C function has raised an exception. | ||||
| 
 | ||||
|       For the Python events, specialized functions (see below) are called.  For | ||||
|       the C events, no action is taken. | ||||
|  |  | |||
|  | @ -1673,7 +1673,7 @@ There are two exceptions that may be raised by :class:`DebugRunner` instances: | |||
| 
 | ||||
| .. exception:: DocTestFailure(test, example, got) | ||||
| 
 | ||||
|    An exception thrown by :class:`DocTestRunner` to signal that a doctest example's | ||||
|    An exception raised by :class:`DocTestRunner` to signal that a doctest example's | ||||
|    actual output did not match its expected output. The constructor arguments are | ||||
|    used to initialize the member variables of the same names. | ||||
| 
 | ||||
|  | @ -1697,9 +1697,9 @@ There are two exceptions that may be raised by :class:`DebugRunner` instances: | |||
| 
 | ||||
| .. exception:: UnexpectedException(test, example, exc_info) | ||||
| 
 | ||||
|    An exception thrown by :class:`DocTestRunner` to signal that a doctest example | ||||
|    raised an unexpected exception.  The constructor arguments are used to | ||||
|    initialize the member variables of the same names. | ||||
|    An exception raised by :class:`DocTestRunner` to signal that a doctest | ||||
|    example raised an unexpected exception.  The constructor arguments are used | ||||
|    to initialize the member variables of the same names. | ||||
| 
 | ||||
| :exc:`UnexpectedException` defines the following member variables: | ||||
| 
 | ||||
|  |  | |||
|  | @ -17,7 +17,7 @@ The following exception classes are defined in the :mod:`email.errors` module: | |||
| 
 | ||||
| .. exception:: MessageParseError() | ||||
| 
 | ||||
|    This is the base class for exceptions thrown by the :class:`~email.parser.Parser` | ||||
|    This is the base class for exceptions raised by the :class:`~email.parser.Parser` | ||||
|    class.  It is derived from :exc:`MessageError`. | ||||
| 
 | ||||
| 
 | ||||
|  |  | |||
|  | @ -145,7 +145,7 @@ An exception is defined as well: | |||
|    Method called when an unrecognized SGML declaration is read by the parser. | ||||
|    The *data* parameter will be the entire contents of the declaration inside | ||||
|    the ``<!...>`` markup.  It is sometimes useful to be be overridden by a | ||||
|    derived class; the base class implementation throws an :exc:`HTMLParseError`. | ||||
|    derived class; the base class implementation raises an :exc:`HTMLParseError`. | ||||
| 
 | ||||
| 
 | ||||
| .. method:: HTMLParser.handle_pi(data) | ||||
|  |  | |||
|  | @ -17,7 +17,7 @@ built-in :func:`open` function is defined in this module. | |||
| At the top of the I/O hierarchy is the abstract base class :class:`IOBase`.  It | ||||
| defines the basic interface to a stream.  Note, however, that there is no | ||||
| separation between reading and writing to streams; implementations are allowed | ||||
| to throw an :exc:`IOError` if they do not support a given operation. | ||||
| to raise an :exc:`IOError` if they do not support a given operation. | ||||
| 
 | ||||
| Extending :class:`IOBase` is :class:`RawIOBase` which deals simply with the | ||||
| reading and writing of raw bytes to a stream.  :class:`FileIO` subclasses | ||||
|  |  | |||
|  | @ -16,7 +16,7 @@ The :mod:`linecache` module defines the following functions: | |||
| 
 | ||||
| .. function:: getline(filename, lineno, module_globals=None) | ||||
| 
 | ||||
|    Get line *lineno* from file named *filename*. This function will never throw an | ||||
|    Get line *lineno* from file named *filename*. This function will never raise an | ||||
|    exception --- it will return ``''`` on errors (the terminating newline character | ||||
|    will be included for lines that are found). | ||||
| 
 | ||||
|  |  | |||
|  | @ -184,7 +184,7 @@ To map anonymous memory, -1 should be passed as the fileno along with the length | |||
| 
 | ||||
|       Copy the *count* bytes starting at offset *src* to the destination index | ||||
|       *dest*.  If the mmap was created with :const:`ACCESS_READ`, then calls to | ||||
|       move will throw a :exc:`TypeError` exception. | ||||
|       move will raise a :exc:`TypeError` exception. | ||||
| 
 | ||||
| 
 | ||||
|    .. method:: read(num) | ||||
|  | @ -210,7 +210,7 @@ To map anonymous memory, -1 should be passed as the fileno along with the length | |||
| 
 | ||||
|       Resizes the map and the underlying file, if any. If the mmap was created | ||||
|       with :const:`ACCESS_READ` or :const:`ACCESS_COPY`, resizing the map will | ||||
|       throw a :exc:`TypeError` exception. | ||||
|       raise a :exc:`TypeError` exception. | ||||
| 
 | ||||
| 
 | ||||
|    .. method:: rfind(sub[, start[, end]]) | ||||
|  | @ -245,7 +245,7 @@ To map anonymous memory, -1 should be passed as the fileno along with the length | |||
|       Write the bytes in *bytes* into memory at the current position of the | ||||
|       file pointer; the file position is updated to point after the bytes that | ||||
|       were written. If the mmap was created with :const:`ACCESS_READ`, then | ||||
|       writing to it will throw a :exc:`TypeError` exception. | ||||
|       writing to it will raise a :exc:`TypeError` exception. | ||||
| 
 | ||||
| 
 | ||||
|    .. method:: write_byte(byte) | ||||
|  | @ -253,4 +253,4 @@ To map anonymous memory, -1 should be passed as the fileno along with the length | |||
|       Write the the integer *byte* into memory at the current | ||||
|       position of the file pointer; the file position is advanced by ``1``. If | ||||
|       the mmap was created with :const:`ACCESS_READ`, then writing to it will | ||||
|       throw a :exc:`TypeError` exception. | ||||
|       raise a :exc:`TypeError` exception. | ||||
|  |  | |||
|  | @ -114,7 +114,7 @@ and ``'exec'`` forms. | |||
|    The :func:`expr` function parses the parameter *source* as if it were an input | ||||
|    to ``compile(source, 'file.py', 'eval')``.  If the parse succeeds, an ST object | ||||
|    is created to hold the internal parse tree representation, otherwise an | ||||
|    appropriate exception is thrown. | ||||
|    appropriate exception is raised. | ||||
| 
 | ||||
| 
 | ||||
| .. function:: suite(source) | ||||
|  | @ -122,7 +122,7 @@ and ``'exec'`` forms. | |||
|    The :func:`suite` function parses the parameter *source* as if it were an input | ||||
|    to ``compile(source, 'file.py', 'exec')``.  If the parse succeeds, an ST object | ||||
|    is created to hold the internal parse tree representation, otherwise an | ||||
|    appropriate exception is thrown. | ||||
|    appropriate exception is raised. | ||||
| 
 | ||||
| 
 | ||||
| .. function:: sequence2st(sequence) | ||||
|  | @ -132,9 +132,9 @@ and ``'exec'`` forms. | |||
|    to the Python grammar and all nodes are valid node types in the host version of | ||||
|    Python, an ST object is created from the internal representation and returned | ||||
|    to the called.  If there is a problem creating the internal representation, or | ||||
|    if the tree cannot be validated, a :exc:`ParserError` exception is thrown.  An | ||||
|    if the tree cannot be validated, a :exc:`ParserError` exception is raised.  An | ||||
|    ST object created this way should not be assumed to compile correctly; normal | ||||
|    exceptions thrown by compilation may still be initiated when the ST object is | ||||
|    exceptions raised by compilation may still be initiated when the ST object is | ||||
|    passed to :func:`compilest`.  This may indicate problems not related to syntax | ||||
|    (such as a :exc:`MemoryError` exception), but may also be due to constructs such | ||||
|    as the result of parsing ``del f(0)``, which escapes the Python parser but is | ||||
|  | @ -259,8 +259,8 @@ function for information about the exceptions it can raise. | |||
| .. exception:: ParserError | ||||
| 
 | ||||
|    Exception raised when a failure occurs within the parser module.  This is | ||||
|    generally produced for validation failures rather than the built in | ||||
|    :exc:`SyntaxError` thrown during normal parsing. The exception argument is | ||||
|    generally produced for validation failures rather than the built-in | ||||
|    :exc:`SyntaxError` raised during normal parsing. The exception argument is | ||||
|    either a string describing the reason of the failure or a tuple containing a | ||||
|    sequence causing the failure from a parse tree passed to :func:`sequence2st` | ||||
|    and an explanatory string.  Calls to :func:`sequence2st` need to be able to | ||||
|  | @ -268,7 +268,7 @@ function for information about the exceptions it can raise. | |||
|    will only need to be aware of the simple string values. | ||||
| 
 | ||||
| Note that the functions :func:`compilest`, :func:`expr`, and :func:`suite` may | ||||
| throw exceptions which are normally thrown by the parsing and compilation | ||||
| raise exceptions which are normally thrown by the parsing and compilation | ||||
| process.  These include the built in exceptions :exc:`MemoryError`, | ||||
| :exc:`OverflowError`, :exc:`SyntaxError`, and :exc:`SystemError`.  In these | ||||
| cases, these exceptions carry all the meaning normally associated with them. | ||||
|  |  | |||
|  | @ -429,7 +429,7 @@ otherwise stated. | |||
|    Called if the XML document hasn't been declared as being a standalone document. | ||||
|    This happens when there is an external subset or a reference to a parameter | ||||
|    entity, but the XML declaration does not set standalone to ``yes`` in an XML | ||||
|    declaration.  If this handler returns ``0``, then the parser will throw an | ||||
|    declaration.  If this handler returns ``0``, then the parser will raise an | ||||
|    :const:`XML_ERROR_NOT_STANDALONE` error.  If this handler is not set, no | ||||
|    exception is raised by the parser for this condition. | ||||
| 
 | ||||
|  | @ -446,7 +446,7 @@ otherwise stated. | |||
|    responsible for creating the sub-parser using | ||||
|    ``ExternalEntityParserCreate(context)``, initializing it with the appropriate | ||||
|    callbacks, and parsing the entity.  This handler should return an integer; if it | ||||
|    returns ``0``, the parser will throw an | ||||
|    returns ``0``, the parser will raise an | ||||
|    :const:`XML_ERROR_EXTERNAL_ENTITY_HANDLING` error, otherwise parsing will | ||||
|    continue. | ||||
| 
 | ||||
|  |  | |||
|  | @ -284,9 +284,9 @@ An :class:`SMTP` instance has the following methods: | |||
|    and ESMTP options suppressed. | ||||
| 
 | ||||
|    This method will return normally if the mail is accepted for at least one | ||||
|    recipient. Otherwise it will throw an exception.  That is, if this method does | ||||
|    not throw an exception, then someone should get your mail. If this method does | ||||
|    not throw an exception, it returns a dictionary, with one entry for each | ||||
|    recipient. Otherwise it will raise an exception.  That is, if this method does | ||||
|    not raise an exception, then someone should get your mail. If this method does | ||||
|    not raise an exception, it returns a dictionary, with one entry for each | ||||
|    recipient that was refused.  Each entry contains a tuple of the SMTP error code | ||||
|    and the accompanying error message sent by the server. | ||||
| 
 | ||||
|  |  | |||
|  | @ -163,7 +163,7 @@ implementation as the built-in :meth:`format` method. | |||
|       the format string (integers for positional arguments, and strings for | ||||
|       named arguments), and a reference to the *args* and *kwargs* that was | ||||
|       passed to vformat.  The set of unused args can be calculated from these | ||||
|       parameters.  :meth:`check_unused_args` is assumed to throw an exception if | ||||
|       parameters.  :meth:`check_unused_args` is assumed to raise an exception if | ||||
|       the check fails. | ||||
| 
 | ||||
|    .. method:: format_field(value, format_spec) | ||||
|  |  | |||
|  | @ -843,7 +843,7 @@ always available. | |||
|       A C function has returned. *arg* is ``None``. | ||||
| 
 | ||||
|    ``'c_exception'`` | ||||
|       A C function has thrown an exception.  *arg* is ``None``. | ||||
|       A C function has raised an exception.  *arg* is ``None``. | ||||
| 
 | ||||
|    Note that as an exception is propagated down the chain of callers, an | ||||
|    ``'exception'`` event is generated at each level. | ||||
|  |  | |||
|  | @ -154,7 +154,7 @@ The :class:`XMLReader` interface supports the following methods: | |||
|    Allow an application to set the locale for errors and warnings. | ||||
| 
 | ||||
|    SAX parsers are not required to provide localization for errors and warnings; if | ||||
|    they cannot support the requested locale, however, they must throw a SAX | ||||
|    they cannot support the requested locale, however, they must raise a SAX | ||||
|    exception.  Applications may request a locale change in the middle of a parse. | ||||
| 
 | ||||
| 
 | ||||
|  |  | |||
|  | @ -1066,7 +1066,7 @@ complete list of changes, or look through the CVS logs for all the details. | |||
|   deprecated APIs and removes support for Python versions earlier than 2.3.  The | ||||
|   3.0 version of the package uses a new incremental parser for MIME messages, | ||||
|   available in the :mod:`email.FeedParser` module.  The new parser doesn't require | ||||
|   reading the entire message into memory, and doesn't throw exceptions if a | ||||
|   reading the entire message into memory, and doesn't raise exceptions if a | ||||
|   message is malformed; instead it records any problems in the  :attr:`defect` | ||||
|   attribute of the message.  (Developed by Anthony Baxter, Barry Warsaw, Thomas | ||||
|   Wouters, and others.) | ||||
|  |  | |||
|  | @ -114,7 +114,7 @@ New, Improved, and Deprecated Modules | |||
| 
 | ||||
|   * *ignore_dangling_symlinks*: when ``symlinks=False`` (meaning that the | ||||
|     function copies the file pointed to by the symlink, not the symlink | ||||
|     itself) this option will silence the error thrown if the file doesn't | ||||
|     itself) this option will silence the error raised if the file doesn't | ||||
|     exist. | ||||
| 
 | ||||
|   * *copy_function*: a callable that will be used to copy files. | ||||
|  |  | |||
		Loading…
	
	Add table
		Add a link
		
	
		Reference in a new issue
	
	 Georg Brandl
						Georg Brandl