Print all properties of a Python Class [duplicate]
I now want to print all these properties to a text file. The ugly way I’m doing it now is like:
Is there a better Pythonic way to do this?
6 Answers 6
In this simple case you can use vars() :
If you want to store Python objects on the disk you should look at shelve — Python object persistence.
Note, that dir() tries to reach any attribute that is possible to reach.
Then you can access the attributes e.g. by filtering with double underscores:
This is just an example of what is possible to do with dir() , please check the other answers for proper way of doing this.
inspect — Inspect live objects¶
The inspect module provides several useful functions to help get information about live objects such as modules, classes, methods, functions, tracebacks, frame objects, and code objects. For example, it can help you examine the contents of a class, retrieve the source code of a method, extract and format the argument list for a function, or get all the information you need to display a detailed traceback.
There are four main kinds of services provided by this module: type checking, getting source code, inspecting classes and functions, and examining the interpreter stack.
Types and members¶
The getmembers() function retrieves the members of an object such as a class or module. The functions whose names begin with “is” are mainly provided as convenient choices for the second argument to getmembers() . They also help you determine when you can expect to find the following special attributes (see Import-related module attributes for module attributes):
name with which this class was defined
name of module in which this class was defined
name with which this method was defined
function object containing implementation of method
instance to which this method is bound, or None
name of module in which this method was defined
name with which this function was defined
code object containing compiled function bytecode
tuple of any default values for positional or keyword parameters
mapping of any default values for keyword-only parameters
global namespace in which this function was defined
mapping of parameters names to annotations; "return" key is reserved for return annotations.
name of module in which this function was defined
frame object at this level
index of last attempted instruction in bytecode
current line number in Python source code
next inner traceback object (called by this level)
next outer frame object (this frame’s caller)
builtins namespace seen by this frame
code object being executed in this frame
global namespace seen by this frame
index of last attempted instruction in bytecode
current line number in Python source code
local namespace seen by this frame
tracing function for this frame, or None
number of arguments (not including keyword only arguments, * or ** args)
string of raw compiled bytecode
tuple of names of cell variables (referenced by containing scopes)
tuple of constants used in the bytecode
name of file in which this code object was created
number of first line in Python source code
bitmap of CO_* flags, read more here
encoded mapping of line numbers to bytecode indices
tuple of names of free variables (referenced via a function’s closure)
number of positional only arguments
number of keyword only arguments (not including ** arg)
name with which this code object was defined
fully qualified name with which this code object was defined
tuple of names other than arguments and function locals
number of local variables
virtual machine stack space required
tuple of names of arguments and local variables
is the generator running?
object being iterated by yield from , or None
object being awaited on, or None
is the coroutine running?
original name of this function or method
instance to which a method is bound, or None
Changed in version 3.5: Add __qualname__ and gi_yieldfrom attributes to generators.
The __name__ attribute of generators is now set from the function name, instead of the code name, and it can now be modified.
Changed in version 3.7: Add cr_origin attribute to coroutines.
Changed in version 3.10: Add __builtins__ attribute to functions.
Return all the members of an object in a list of (name, value) pairs sorted by name. If the optional predicate argument—which will be called with the value object of each member—is supplied, only members for which the predicate returns a true value are included.
getmembers() will only return class attributes defined in the metaclass when the argument is a class and those attributes have been listed in the metaclass’ custom __dir__() .
Return all the members of an object in a list of (name, value) pairs sorted by name without triggering dynamic lookup via the descriptor protocol, __getattr__ or __getattribute__. Optionally, only return members that satisfy a given predicate.
getmembers_static() may not be able to retrieve all members that getmembers can fetch (like dynamically created attributes) and may find members that getmembers can’t (like descriptors that raise AttributeError). It can also return descriptor objects instead of instance members in some cases.
New in version 3.11.
Return the name of the module named by the file path, without including the names of enclosing packages. The file extension is checked against all of the entries in importlib.machinery.all_suffixes() . If it matches, the final path component is returned with the extension removed. Otherwise, None is returned.
Note that this function only returns a meaningful name for actual Python modules — paths that potentially refer to Python packages will still return None .
Changed in version 3.3: The function is based directly on importlib .
Return True if the object is a module.
inspect. isclass ( object ) ¶
Return True if the object is a class, whether built-in or created in Python code.
inspect. ismethod ( object ) ¶
Return True if the object is a bound method written in Python.
inspect. isfunction ( object ) ¶
Return True if the object is a Python function, which includes functions created by a lambda expression.
inspect. isgeneratorfunction ( object ) ¶
Return True if the object is a Python generator function.
Changed in version 3.8: Functions wrapped in functools.partial() now return True if the wrapped function is a Python generator function.
Return True if the object is a generator.
inspect. iscoroutinefunction ( object ) ¶
Return True if the object is a coroutine function (a function defined with an async def syntax).
New in version 3.5.
Changed in version 3.8: Functions wrapped in functools.partial() now return True if the wrapped function is a coroutine function .
Return True if the object is a coroutine created by an async def function.
New in version 3.5.
Return True if the object can be used in await expression.
Can also be used to distinguish generator-based coroutines from regular generators:
New in version 3.5.
Return True if the object is an asynchronous generator function, for example:
New in version 3.6.
Changed in version 3.8: Functions wrapped in functools.partial() now return True if the wrapped function is a asynchronous generator function.
Return True if the object is an asynchronous generator iterator created by an asynchronous generator function.
New in version 3.6.
Return True if the object is a traceback.
inspect. isframe ( object ) ¶
Return True if the object is a frame.
inspect. iscode ( object ) ¶
Return True if the object is a code.
inspect. isbuiltin ( object ) ¶
Return True if the object is a built-in function or a bound built-in method.
inspect. ismethodwrapper ( object ) ¶
Return True if the type of object is a MethodWrapperType .
New in version 3.11.
Return True if the object is a user-defined or built-in function or method.
inspect. isabstract ( object ) ¶
Return True if the object is an abstract base class.
inspect. ismethoddescriptor ( object ) ¶
Return True if the object is a method descriptor, but not if ismethod() , isclass() , isfunction() or isbuiltin() are true.
This, for example, is true of int.__add__ . An object passing this test has a __get__() method but not a __set__() method, but beyond that the set of attributes varies. A __name__ attribute is usually sensible, and __doc__ often is.
Methods implemented via descriptors that also pass one of the other tests return False from the ismethoddescriptor() test, simply because the other tests promise more – you can, e.g., count on having the __func__ attribute (etc) when an object passes ismethod() .
inspect. isdatadescriptor ( object ) ¶
Return True if the object is a data descriptor.
Data descriptors have a __set__ or a __delete__ method. Examples are properties (defined in Python), getsets, and members. The latter two are defined in C and there are more specific tests available for those types, which is robust across Python implementations. Typically, data descriptors will also have __name__ and __doc__ attributes (properties, getsets, and members have both of these attributes), but this is not guaranteed.
inspect. isgetsetdescriptor ( object ) ¶
Return True if the object is a getset descriptor.
CPython implementation detail: getsets are attributes defined in extension modules via PyGetSetDef structures. For Python implementations without such types, this method will always return False .
Return True if the object is a member descriptor.
CPython implementation detail: Member descriptors are attributes defined in extension modules via PyMemberDef structures. For Python implementations without such types, this method will always return False .
Retrieving source code¶
Get the documentation string for an object, cleaned up with cleandoc() . If the documentation string for an object is not provided and the object is a class, a method, a property or a descriptor, retrieve the documentation string from the inheritance hierarchy. Return None if the documentation string is invalid or missing.
Changed in version 3.5: Documentation strings are now inherited if not overridden.
Return in a single string any lines of comments immediately preceding the object’s source code (for a class, function, or method), or at the top of the Python source file (if the object is a module). If the object’s source code is unavailable, return None . This could happen if the object has been defined in C or the interactive shell.
inspect. getfile ( object ) ¶
Return the name of the (text or binary) file in which an object was defined. This will fail with a TypeError if the object is a built-in module, class, or function.
inspect. getmodule ( object ) ¶
Try to guess which module an object was defined in. Return None if the module cannot be determined.
inspect. getsourcefile ( object ) ¶
Return the name of the Python source file in which an object was defined or None if no way can be identified to get the source. This will fail with a TypeError if the object is a built-in module, class, or function.
inspect. getsourcelines ( object ) ¶
Return a list of source lines and starting line number for an object. The argument may be a module, class, method, function, traceback, frame, or code object. The source code is returned as a list of the lines corresponding to the object and the line number indicates where in the original source file the first line of code was found. An OSError is raised if the source code cannot be retrieved.
Changed in version 3.3: OSError is raised instead of IOError , now an alias of the former.
Return the text of the source code for an object. The argument may be a module, class, method, function, traceback, frame, or code object. The source code is returned as a single string. An OSError is raised if the source code cannot be retrieved.
Changed in version 3.3: OSError is raised instead of IOError , now an alias of the former.
Clean up indentation from docstrings that are indented to line up with blocks of code.
All leading whitespace is removed from the first line. Any leading whitespace that can be uniformly removed from the second line onwards is removed. Empty lines at the beginning and end are subsequently removed. Also, all tabs are expanded to spaces.
Introspecting callables with the Signature object¶
New in version 3.3.
The Signature object represents the call signature of a callable object and its return annotation. To retrieve a Signature object, use the signature() function.
inspect. signature ( callable , * , follow_wrapped = True , globals = None , locals = None , eval_str = False ) ¶
Return a Signature object for the given callable :
Accepts a wide range of Python callables, from plain functions and classes to functools.partial() objects.
For objects defined in modules using stringized annotations ( from __future__ import annotations ), signature() will attempt to automatically un-stringize the annotations using inspect.get_annotations() . The global , locals , and eval_str parameters are passed into inspect.get_annotations() when resolving the annotations; see the documentation for inspect.get_annotations() for instructions on how to use these parameters.
Raises ValueError if no signature can be provided, and TypeError if that type of object is not supported. Also, if the annotations are stringized, and eval_str is not false, the eval() call(s) to un-stringize the annotations could potentially raise any kind of exception.
A slash(/) in the signature of a function denotes that the parameters prior to it are positional-only. For more info, see the FAQ entry on positional-only parameters .
New in version 3.5: follow_wrapped parameter. Pass False to get a signature of callable specifically ( callable.__wrapped__ will not be used to unwrap decorated callables.)
New in version 3.10: globals , locals , and eval_str parameters.
Some callables may not be introspectable in certain implementations of Python. For example, in CPython, some built-in functions defined in C provide no metadata about their arguments.
A Signature object represents the call signature of a function and its return annotation. For each parameter accepted by the function it stores a Parameter object in its parameters collection.
The optional parameters argument is a sequence of Parameter objects, which is validated to check that there are no parameters with duplicate names, and that the parameters are in the right order, i.e. positional-only first, then positional-or-keyword, and that parameters with defaults follow parameters without defaults.
The optional return_annotation argument, can be an arbitrary Python object, is the “return” annotation of the callable.
Signature objects are immutable. Use Signature.replace() to make a modified copy.
Changed in version 3.5: Signature objects are picklable and hashable .
A special class-level marker to specify absence of a return annotation.
An ordered mapping of parameters’ names to the corresponding Parameter objects. Parameters appear in strict definition order, including keyword-only parameters.
Changed in version 3.7: Python only explicitly guaranteed that it preserved the declaration order of keyword-only parameters as of version 3.7, although in practice this order had always been preserved in Python 3.
The “return” annotation for the callable. If the callable has no “return” annotation, this attribute is set to Signature.empty .
Create a mapping from positional and keyword arguments to parameters. Returns BoundArguments if *args and **kwargs match the signature, or raises a TypeError .
bind_partial ( * args , ** kwargs ) ¶
Works the same way as Signature.bind() , but allows the omission of some required arguments (mimics functools.partial() behavior.) Returns BoundArguments , or raises a TypeError if the passed arguments do not match the signature.
replace ( *[, parameters][, return_annotation] ) ¶
Create a new Signature instance based on the instance replace was invoked on. It is possible to pass different parameters and/or return_annotation to override the corresponding properties of the base signature. To remove return_annotation from the copied Signature, pass in Signature.empty .
Return a Signature (or its subclass) object for a given callable obj . Pass follow_wrapped=False to get a signature of obj without unwrapping its __wrapped__ chain. globalns and localns will be used as the namespaces when resolving annotations.
This method simplifies subclassing of Signature :
New in version 3.5.
New in version 3.10: globalns and localns parameters.
Parameter objects are immutable. Instead of modifying a Parameter object, you can use Parameter.replace() to create a modified copy.
Changed in version 3.5: Parameter objects are picklable and hashable .
A special class-level marker to specify absence of default values and annotations.
The name of the parameter as a string. The name must be a valid Python identifier.
CPython implementation detail: CPython generates implicit parameter names of the form .0 on the code objects used to implement comprehensions and generator expressions.
Changed in version 3.6: These parameter names are exposed by this module as names like implicit0 .
The default value for the parameter. If the parameter has no default value, this attribute is set to Parameter.empty .
The annotation for the parameter. If the parameter has no annotation, this attribute is set to Parameter.empty .
Describes how argument values are bound to the parameter. The possible values are accessible via Parameter (like Parameter.KEYWORD_ONLY ), and support comparison and ordering, in the following order:
Value must be supplied as a positional argument. Positional only parameters are those which appear before a / entry (if present) in a Python function definition.
Value may be supplied as either a keyword or positional argument (this is the standard binding behaviour for functions implemented in Python.)
A tuple of positional arguments that aren’t bound to any other parameter. This corresponds to a *args parameter in a Python function definition.
Value must be supplied as a keyword argument. Keyword only parameters are those which appear after a * or *args entry in a Python function definition.
A dict of keyword arguments that aren’t bound to any other parameter. This corresponds to a **kwargs parameter in a Python function definition.
Example: print all keyword-only arguments without default values:
Describes a enum value of Parameter.kind.
New in version 3.8.
Example: print all descriptions of arguments:
Create a new Parameter instance based on the instance replaced was invoked on. To override a Parameter attribute, pass the corresponding argument. To remove a default value or/and an annotation from a Parameter, pass Parameter.empty .
Changed in version 3.4: In Python 3.3 Parameter objects were allowed to have name set to None if their kind was set to POSITIONAL_ONLY . This is no longer permitted.
Result of a Signature.bind() or Signature.bind_partial() call. Holds the mapping of arguments to the function’s parameters.
A mutable mapping of parameters’ names to arguments’ values. Contains only explicitly bound arguments. Changes in arguments will reflect in args and kwargs .
Should be used in conjunction with Signature.parameters for any argument processing purposes.
Arguments for which Signature.bind() or Signature.bind_partial() relied on a default value are skipped. However, if needed, use BoundArguments.apply_defaults() to add them.
Changed in version 3.9: arguments is now of type dict . Formerly, it was of type collections.OrderedDict .
A tuple of positional arguments values. Dynamically computed from the arguments attribute.
A dict of keyword arguments values. Dynamically computed from the arguments attribute.
A reference to the parent Signature object.
Set default values for missing arguments.
For variable-positional arguments ( *args ) the default is an empty tuple.
For variable-keyword arguments ( **kwargs ) the default is an empty dict.
New in version 3.5.
The args and kwargs properties can be used to invoke functions:
The detailed specification, implementation details and examples.
Classes and functions¶
Arrange the given list of classes into a hierarchy of nested lists. Where a nested list appears, it contains classes derived from the class whose entry immediately precedes the list. Each entry is a 2-tuple containing a class and a tuple of its base classes. If the unique argument is true, exactly one entry appears in the returned structure for each class in the given list. Otherwise, classes using multiple inheritance and their descendants will appear multiple times.
inspect. getfullargspec ( func ) ¶
Get the names and default values of a Python function’s parameters. A named tuple is returned:
FullArgSpec(args, varargs, varkw, defaults, kwonlyargs, kwonlydefaults, annotations)
args is a list of the positional parameter names. varargs is the name of the * parameter or None if arbitrary positional arguments are not accepted. varkw is the name of the ** parameter or None if arbitrary keyword arguments are not accepted. defaults is an n-tuple of default argument values corresponding to the last n positional parameters, or None if there are no such defaults defined. kwonlyargs is a list of keyword-only parameter names in declaration order. kwonlydefaults is a dictionary mapping parameter names from kwonlyargs to the default values used if no argument is supplied. annotations is a dictionary mapping parameter names to annotations. The special key "return" is used to report the function return value annotation (if any).
Note that signature() and Signature Object provide the recommended API for callable introspection, and support additional behaviours (like positional-only arguments) that are sometimes encountered in extension module APIs. This function is retained primarily for use in code that needs to maintain compatibility with the Python 2 inspect module API.
Changed in version 3.4: This function is now based on signature() , but still ignores __wrapped__ attributes and includes the already bound first parameter in the signature output for bound methods.
Changed in version 3.6: This method was previously documented as deprecated in favour of signature() in Python 3.5, but that decision has been reversed in order to restore a clearly supported standard interface for single-source Python 2/3 code migrating away from the legacy getargspec() API.
Changed in version 3.7: Python only explicitly guaranteed that it preserved the declaration order of keyword-only parameters as of version 3.7, although in practice this order had always been preserved in Python 3.
Get information about arguments passed into a particular frame. A named tuple ArgInfo(args, varargs, keywords, locals) is returned. args is a list of the argument names. varargs and keywords are the names of the * and ** arguments or None . locals is the locals dictionary of the given frame.
This function was inadvertently marked as deprecated in Python 3.5.
Format a pretty argument spec from the four values returned by getargvalues() . The format* arguments are the corresponding optional formatting functions that are called to turn names and values into strings.
This function was inadvertently marked as deprecated in Python 3.5.
Return a tuple of class cls’s base classes, including cls, in method resolution order. No class appears more than once in this tuple. Note that the method resolution order depends on cls’s type. Unless a very peculiar user-defined metatype is in use, cls will be the first element of the tuple.
Bind the args and kwds to the argument names of the Python function or method func, as if it was called with them. For bound methods, bind also the first argument (typically named self ) to the associated instance. A dict is returned, mapping the argument names (including the names of the * and ** arguments, if any) to their values from args and kwds. In case of invoking func incorrectly, i.e. whenever func(*args, **kwds) would raise an exception because of incompatible signature, an exception of the same type and the same or similar message is raised. For example:
New in version 3.2.
Deprecated since version 3.5: Use Signature.bind() and Signature.bind_partial() instead.
Get the mapping of external name references in a Python function or method func to their current values. A named tuple ClosureVars(nonlocals, globals, builtins, unbound) is returned. nonlocals maps referenced names to lexical closure variables, globals to the function’s module globals and builtins to the builtins visible from the function body. unbound is the set of names referenced in the function that could not be resolved at all given the current module globals and builtins.
TypeError is raised if func is not a Python function or method.
New in version 3.3.
Get the object wrapped by func. It follows the chain of __wrapped__ attributes returning the last object in the chain.
stop is an optional callback accepting an object in the wrapper chain as its sole argument that allows the unwrapping to be terminated early if the callback returns a true value. If the callback never returns a true value, the last object in the chain is returned as usual. For example, signature() uses this to stop unwrapping if any object in the chain has a __signature__ attribute defined.
ValueError is raised if a cycle is encountered.
New in version 3.4.
Compute the annotations dict for an object.
obj may be a callable, class, or module. Passing in an object of any other type raises TypeError .
Returns a dict. get_annotations() returns a new dict every time it’s called; calling it twice on the same object will return two different but equivalent dicts.
This function handles several details for you:
If eval_str is true, values of type str will be un-stringized using eval() . This is intended for use with stringized annotations ( from __future__ import annotations ).
If obj doesn’t have an annotations dict, returns an empty dict. (Functions and methods always have an annotations dict; classes, modules, and other types of callables may not.)
Ignores inherited annotations on classes. If a class doesn’t have its own annotations dict, returns an empty dict.
All accesses to object members and dict values are done using getattr() and dict.get() for safety.
Always, always, always returns a freshly created dict.
eval_str controls whether or not values of type str are replaced with the result of calling eval() on those values:
If eval_str is true, eval() is called on values of type str . (Note that get_annotations doesn’t catch exceptions; if eval() raises an exception, it will unwind the stack past the get_annotations call.)
If eval_str is false (the default), values of type str are unchanged.
globals and locals are passed in to eval() ; see the documentation for eval() for more information. If globals or locals is None , this function may replace that value with a context-specific default, contingent on type(obj) :
If obj is a module, globals defaults to obj.__dict__ .
If obj is a class, globals defaults to sys.modules[obj.__module__].__dict__ and locals defaults to the obj class namespace.
If obj is a callable, globals defaults to obj.__globals__ , although if obj is a wrapped function (using functools.update_wrapper() ) it is first unwrapped.
Calling get_annotations is best practice for accessing the annotations dict of any object. See Annotations Best Practices for more information on annotations best practices.
New in version 3.10.
The interpreter stack¶
Some of the following functions return FrameInfo objects. For backwards compatibility these objects allow tuple-like operations on all attributes except positions . This behavior is considered deprecated and may be removed in the future.
class inspect. FrameInfo ¶ frame ¶
The frame object that the record corresponds to.
The file name associated with the code being executed by the frame this record corresponds to.
The line number of the current line associated with the code being executed by the frame this record corresponds to.
The function name that is being executed by the frame this record corresponds to.
A list of lines of context from the source code that’s being executed by the frame this record corresponds to.
The index of the current line being executed in the code_context list.
A dis.Positions object containing the start line number, end line number, start column offset, and end column offset associated with the instruction being executed by the frame this record corresponds to.
Changed in version 3.5: Return a named tuple instead of a tuple .
Changed in version 3.11: FrameInfo is now a class instance (that is backwards compatible with the previous named tuple ).
The file name associated with the code being executed by the frame this traceback corresponds to.
The line number of the current line associated with the code being executed by the frame this traceback corresponds to.
The function name that is being executed by the frame this traceback corresponds to.
A list of lines of context from the source code that’s being executed by the frame this traceback corresponds to.
The index of the current line being executed in the code_context list.
A dis.Positions object containing the start line number, end line number, start column offset, and end column offset associated with the instruction being executed by the frame this traceback corresponds to.
Changed in version 3.11: Traceback is now a class instance (that is backwards compatible with the previous named tuple ).
Keeping references to frame objects, as found in the first element of the frame records these functions return, can cause your program to create reference cycles. Once a reference cycle has been created, the lifespan of all objects which can be accessed from the objects which form the cycle can become much longer even if Python’s optional cycle detector is enabled. If such cycles must be created, it is important to ensure they are explicitly broken to avoid the delayed destruction of objects and increased memory consumption which occurs.
Though the cycle detector will catch these, destruction of the frames (and local variables) can be made deterministic by removing the cycle in a finally clause. This is also important if the cycle detector was disabled when Python was compiled or using gc.disable() . For example:
If you want to keep the frame around (for example to print a traceback later), you can also break reference cycles by using the frame.clear() method.
The optional context argument supported by most of these functions specifies the number of lines of context to return, which are centered around the current line.
inspect. getframeinfo ( frame , context = 1 ) ¶
Get information about a frame or traceback object. A Traceback object is returned.
Changed in version 3.11: A Traceback object is returned instead of a named tuple.
Get a list of FrameInfo objects for a frame and all outer frames. These frames represent the calls that lead to the creation of frame. The first entry in the returned list represents frame; the last entry represents the outermost call on frame’s stack.
Changed in version 3.5: A list of named tuples FrameInfo(frame, filename, lineno, function, code_context, index) is returned.
Changed in version 3.11: A list of FrameInfo objects is returned.
Get a list of FrameInfo objects for a traceback’s frame and all inner frames. These frames represent calls made as a consequence of frame. The first entry in the list represents traceback; the last entry represents where the exception was raised.
Changed in version 3.5: A list of named tuples FrameInfo(frame, filename, lineno, function, code_context, index) is returned.
Changed in version 3.11: A list of FrameInfo objects is returned.
Return the frame object for the caller’s stack frame.
CPython implementation detail: This function relies on Python stack frame support in the interpreter, which isn’t guaranteed to exist in all implementations of Python. If running in an implementation without Python stack frame support this function returns None .
Return a list of FrameInfo objects for the caller’s stack. The first entry in the returned list represents the caller; the last entry represents the outermost call on the stack.
Changed in version 3.5: A list of named tuples FrameInfo(frame, filename, lineno, function, code_context, index) is returned.
Changed in version 3.11: A list of FrameInfo objects is returned.
Return a list of FrameInfo objects for the stack between the current frame and the frame in which an exception currently being handled was raised in. The first entry in the list represents the caller; the last entry represents where the exception was raised.
Changed in version 3.5: A list of named tuples FrameInfo(frame, filename, lineno, function, code_context, index) is returned.
Changed in version 3.11: A list of FrameInfo objects is returned.
Fetching attributes statically¶
Both getattr() and hasattr() can trigger code execution when fetching or checking for the existence of attributes. Descriptors, like properties, will be invoked and __getattr__() and __getattribute__() may be called.
For cases where you want passive introspection, like documentation tools, this can be inconvenient. getattr_static() has the same signature as getattr() but avoids executing code when it fetches attributes.
inspect. getattr_static ( obj , attr , default = None ) ¶
Retrieve attributes without triggering dynamic lookup via the descriptor protocol, __getattr__() or __getattribute__() .
Note: this function may not be able to retrieve all attributes that getattr can fetch (like dynamically created attributes) and may find attributes that getattr can’t (like descriptors that raise AttributeError). It can also return descriptors objects instead of instance members.
If the instance __dict__ is shadowed by another member (for example a property) then this function will be unable to find instance members.
New in version 3.2.
getattr_static() does not resolve descriptors, for example slot descriptors or getset descriptors on objects implemented in C. The descriptor object is returned instead of the underlying attribute.
You can handle these with code like the following. Note that for arbitrary getset descriptors invoking these may trigger code execution:
Current State of Generators and Coroutines¶
When implementing coroutine schedulers and for other advanced uses of generators, it is useful to determine whether a generator is currently executing, is waiting to start or resume or execution, or has already terminated. getgeneratorstate() allows the current state of a generator to be determined easily.
inspect. getgeneratorstate ( generator ) ¶
Get current state of a generator-iterator.
GEN_CREATED: Waiting to start execution.
GEN_RUNNING: Currently being executed by the interpreter.
GEN_SUSPENDED: Currently suspended at a yield expression.
GEN_CLOSED: Execution has completed.
New in version 3.2.
Get current state of a coroutine object. The function is intended to be used with coroutine objects created by async def functions, but will accept any coroutine-like object that has cr_running and cr_frame attributes.
CORO_CREATED: Waiting to start execution.
CORO_RUNNING: Currently being executed by the interpreter.
CORO_SUSPENDED: Currently suspended at an await expression.
CORO_CLOSED: Execution has completed.
New in version 3.5.
The current internal state of the generator can also be queried. This is mostly useful for testing purposes, to ensure that internal state is being updated as expected:
inspect. getgeneratorlocals ( generator ) ¶
Get the mapping of live local variables in generator to their current values. A dictionary is returned that maps from variable names to values. This is the equivalent of calling locals() in the body of the generator, and all the same caveats apply.
If generator is a generator with no currently associated frame, then an empty dictionary is returned. TypeError is raised if generator is not a Python generator object.
CPython implementation detail: This function relies on the generator exposing a Python stack frame for introspection, which isn’t guaranteed to be the case in all implementations of Python. In such cases, this function will always return an empty dictionary.
New in version 3.3.
This function is analogous to getgeneratorlocals() , but works for coroutine objects created by async def functions.
New in version 3.5.
Code Objects Bit Flags¶
Python code objects have a co_flags attribute, which is a bitmap of the following flags:
The code object is optimized, using fast locals.
If set, a new dict will be created for the frame’s f_locals when the code object is executed.
The code object has a variable positional parameter ( *args -like).
The code object has a variable keyword parameter ( **kwargs -like).
The flag is set when the code object is a nested function.
The flag is set when the code object is a generator function, i.e. a generator object is returned when the code object is executed.
The flag is set when the code object is a coroutine function. When the code object is executed it returns a coroutine object. See PEP 492 for more details.
New in version 3.5.
The flag is used to transform generators into generator-based coroutines. Generator objects with this flag can be used in await expression, and can yield from coroutine objects. See PEP 492 for more details.
New in version 3.5.
The flag is set when the code object is an asynchronous generator function. When the code object is executed it returns an asynchronous generator object. See PEP 525 for more details.
New in version 3.6.
The flags are specific to CPython, and may not be defined in other Python implementations. Furthermore, the flags are an implementation detail, and can be removed or deprecated in future Python releases. It’s recommended to use public APIs from the inspect module for any introspection needs.
Command Line Interface¶
The inspect module also provides a basic introspection capability from the command line.
By default, accepts the name of a module and prints the source of that module. A class or function within the module can be printed instead by appended a colon and the qualified name of the target object.
Урок 6. Принципы ООП. Классы, объекты, поля и методы. Уровни доступа.
Поговорим про основные принципы объектно-ориентированного программирования: абстракцию, инкапсуляцию, наследование и полиморфизм. Научимся создавать классы и объекты классов в Python. Рассмотрим, чем отличаются понятия поля, свойства, методы и атрибуты класса. Изучим особенности организации уровней доступа к атрибутам: Public, Protected и Private.
Курс «Программирование на Python»
Урок 6.
Принципы ООП. Классы, объекты, поля и методы. Уровни доступа.
- Процедурное программирование
- Объектно-ориентированное программирование (оно же ООП)
По сути любая программа представляет собой совокупность данных и операций по их обработке. Но что важнее, сами данные или операции над ними? В языках, в основе работы которых лежит принцип процедурного программирования ( Basic , C , Pascal , Go ), главным является код для обработки данных. При этом сами данные имеют второстепенное значение.
В чем суть процедурного подхода? Процедурное программирование – это написание функций и их последовательный вызов в некоторой главной( main ) функции.
Для каких проектов подходит процедурное программирование? Идеальные условия для применения данного подхода — простые программы, где весь функционал можно реализовать несколькими десятками процедур/функций. Функции аккуратно вложены друг в друга и легко взаимодействуют посредством передачи данных из одной функции в другую.
Однако проблема в том, что когда мы выходим за пределы этих идеальных условий, выплывают наружу многие недостатки данного подхода:
- В больших проектах приходится создавать огромное количество процедур и функций. В свою очередь, это неизбежно ведет к возникновению множества ошибок и снижает читаемость кода программы.
- Все данные внутри процедуры видны только локально, а значит их нельзя использовать в другом месте. Как следствие, код наполняется дубликатами.
- Высокий порог вхождения — по статистике начинающим данный поход дается сложнее, чем ООП.
- Программа разбивается на объекты. Каждый объект отвечает за собственные данные и их обработку. Как результат — код становится проще и читабельней.
- Уменьшается дупликация кода. Нужен новый объект, содержимое которого на 90% повторяет уже существующий? Давайте создадим новый класс и унаследуем эти 90% функционала от родительского класса!
- Упрощается и ускоряется процесс написания программ. Можно сначала создать высокоуровневую структуру классов и базовый функционал, а уже потом перейти к их подробной реализации.
- В процедурном подходе основой программы является функция. Функции вызывают друг друга и при необходимости передают данные. В программе функции живут отдельно, данные — отдельно.
- Основной недостаток процедурного подхода — сложность создания и поддержки больших программ. Наличие сотен функций в таких проектах очень часто приводит к ошибкам и спагетти-коду.
- В основе объектно-ориентированного программирования лежит понятие объекта. Объект совмещает в себе и функции и данные.
- Основное преимущество ООП перед процедурным программированием — изоляция кода на уровне классов, что позволяет писать более простой и лаконичный код.
- Класс описывает множество объектов, имеющих общую структуру и обладающих одинаковым поведением. Класс — это шаблон кода, по которому создаются объекты. Т. е. сам по себе класс ничего не делает, но с его помощью можно создать объект и уже его использовать в работе.
- Данные внутри класса делятся на свойства и методы. Свойства класса (они же поля) — это характеристики объекта класса.
- Методы класса — это функции, с помощью которых можно оперировать данными класса.
- Объект — это конкретный представитель класса.
- Объект класса и экземпляр класса — это одно и то же.
- Цвет
- Объем двигателя
- Мощность
- Тип коробки передач
- Ехать
- Остановиться
- Заправиться
- Поставить на сигнализацию
- Включить дворники
Что общего будет в объектах? Все объекты создаются по одному шаблону, то есть на выходе обязательно будут машины, никаких велосипедов и мотоциклов. Они будут выкрашены в какой-то цвет, ехать они будут за счет наличия в них двигателя, скорость будет регулироваться с помощью коробки передач. Также объекты данного класса будут обладать одинаковыми методами — все машины этого класса будут ездить, периодически им будет нужна заправка, а от угона они будут защищены установкой сигнализации.
Но в чем разница? Значения свойств будут различаться. Одна машина красная, другая — зеленая. У одной объем двигателя 1968 см3 и коробка-робот, а у другой — 1395 см3 и ездить владельцу придется на механике.
Вывод: Объекты класса на выходе похожие и одновременно разные. Различаются, как правило, свойства. Методы остаются одинаковыми.
- Свойства: Цвет=»Белый», Объем двигателя=»1984 см3″, Мощность=»180 л.с.», Тип коробки передач=»Робот»
- Методы: Ехать, Остановиться, Заправиться, Поставить на сигнализацию, Включить дворники
Принцип 1. Абстракция
- Выделить главные и наиболее значимые свойства предмета.
- Отбросить второстепенные характеристики.
Зачем нужна абстракция? Если мыслить масштабно — то она позволяет бороться со сложностью реального мира. Мы отбрасываем все лишнее, чтобы оно нам не мешало, и концентрируемся только на важных чертах объекта.
Принцип 2. Инкапсуляция
Абстракция утверждает следующее: «Объект может быть рассмотрен с общей точки зрения». А инкапсуляция от себя добавляет: «И это единственная точка зрения, с которой вы вообще можете рассмотреть этот объект.». А если вы внимательно посмотрите на название, то увидите в нем слово «капсула». В этой самой «капсуле» спрятаны данные, которые мы хотим защитить от изменений извне.
- Отсутствует доступ к внутреннему устройству программного компонента.
- Взаимодействие компонента с внешним миром осуществляется посредством интерфейса, который включает публичные методы и поля.
- Инкапсуляция упрощает процесс разработки, т. к. позволяет нам не вникать в тонкости реализации того или иного объекта.
- Повышается надежность программ за счет того, что при внесении изменений в один из компонентов, остальные части программы остаются неизменными.
- Становится более легким обмен компонентами между программами.
Принцип 3. Наследование
- Класс-потомок = Свойства и методы родителя + Собственные свойства и методы.
- Класс-потомок автоматически наследует от родительского класса все поля и методы.
- Класс-потомок может дополняться новыми свойствами.
- Класс-потомок может дополняться новыми методами, а также заменять(переопределять) унаследованные методы. Переопределить родительский метод — это как? Это значит, внутри класса потомка есть метод, который совпадает по названию с методом родительского класса, но функционал у него новый — соответствующий потребностям класса-потомка.
- Дает возможность использовать код повторно. Классы-потомки берут общий функционал у родительского класса.
- Способствует быстрой разработке нового ПО на основе уже существующих открытых классов.
- Наследование позволяет делать процесс написания кода более простым.
МЕТОДЫ
1) Построить (УНАСЛЕДОВАНО)
2) Отремонтировать (УНАСЛЕДОВАНО)
3) Заселить (УНАСЛЕДОВАНО)
4) Снести (УНАСЛЕДОВАНО)
5) Изменить фасад
6) Утеплить
7) Сделать пристройку
СВОЙСТВА
1) Тип фундамента (УНАСЛЕДОВАНО)
2) Материал крыши (УНАСЛЕДОВАНО)
3) Количество окон (УНАСЛЕДОВАНО)
4) Количество дверей (УНАСЛЕДОВАНО)
5) Количество квартир
6) Количество подъездов
7) Наличие коммерческой недвижимости
МЕТОДЫ
1) Построить (УНАСЛЕДОВАНО)
2) Отремонтировать (УНАСЛЕДОВАНО)
3) Заселить (УНАСЛЕДОВАНО)
4) Снести (УНАСЛЕДОВАНО)
5) Выбрать управляющую компанию
6) Организовать собрание жильцов
7) Нанять дворника
Принцип 4. Полиморфизм
Другими словами, полиморфизм позволяет перегружать одноименные методы родительского класса в классах-потомках.
Также для понимания работы этого принципа важным является понятие абстрактного метода:
- В родительском классе(в нашем случае — класс Дом) создают пустой метод(например, метод Построить() ) и делают его абстрактным.
- В классах-потомках создают одноименные методы, но уже с соответствующей реализацией. И это логично, ведь например, процесс постройки Частного и Многоквартирного дома отличается кардинально. К примеру, для строительства Многоквартирного дома необходимо задействовать башенный кран, а Частный дом можно построить и собственными силами. При этом данный процесс все равно остается процессом строительства.
- В итоге получаем метод с одним и тем же именем, который встречается во всех классах. В родительском — имеем только интерфейс, реализация отсутствует. В классах-потомках — имеем и интерфейс и реализацию. Причем в отличие от родительского класса реализация в потомках уже становится обязательной.
- Теперь мы можем увидеть полиморфизм во всей его красе. Даже не зная, с объектом какого из классов-потомков мы работаем, нам достаточно просто вызвать метод Построить(). А уже в момент исполнения программы, когда класс объекта станет известен, будет вызвана необходимая реализация метода Построить().
Как мы видим, для задания класса используется инструкция class , далее следует имя класса Car и двоеточие. После них идет тело класса, которое в нашем случае представлено оператором pass . Данный оператор сам по себе ничего не делает — фактически это просто заглушка.
Чтобы создать объект класса, нужно воспользоваться следующим синтаксисом:
Давайте договоримся, что атрибутом класса/объекта мы будем называть любой элемент класса/объекта (переменную, метод, подкласс), на который мы можем сослаться через символ точки. Т. е. вот так: MyClass.<атрибут> или my_object.<атрибут> .
- Встроенные(служебные) атрибуты
- Пользовательские атрибуты
1. Встроенные атрибуты
Это важно
В теории ООП конструктор класса — это специальный блок инструкций, который вызывается при создании объекта. При работе с питоном может возникнуть мнение, что метод __init__(self) — это и есть конструктор, но это не совсем так. На самом деле, при создании объекта в Python вызывается метод __new__ (cls, *args, **kwargs) и именно он является конструктором класса.
Также обратите внимание, что __new__() — это метод класса, поэтому его первый параметр cls — ссылка на текущий класс. В свою очередь, метод __init__() является так называемым инициализатором класса. Именно этот метод первый принимает созданный конструктором объект. Как вы уже, наверное, не раз замечали, метод __init__() часто переопределяется внутри класса самим программистом. Это позволяет со всем удобством задавать параметры будущего объекта при его создании.
2. Пользовательские атрибуты
Это атрибуты, которые непосредственно составляют основной функционал класса. Если служебные атрибуты наследуются от базового класса object , то пользовательские — пишутся программистом во время реализации начинки класса и дальнейшей работы с ним.
Список атрибутов класса / объекта можно получить с помощью команды dir() . Если взять самый простой класс:
- Атрибутами называем совокупность полей и методов класса / объекта.
- Атрибуты делятся на встроенные и пользовательские.
- Все классы в Python имеют общий родительский класс — он называется object .
- Класс object предоставляет всем своим потомкам набор служебных атрибутов (как переменных (например, __dict__ и __doc__ ), так и методов (например, __str__ ) ).
- Многие из служебных атрибутов можно переопределить внутри своего класса.
- Поля и методы, которые описываются программистом в теле класса, являются пользовательскими и добавляются в общий список атрибутов наряду со встроенными атрибутами.
- Статические поля
- Динамические поля
1. Статические поля (они же переменные или свойства класса)
2. Динамические поля (переменные или свойства экземпляра класса)
Что такое self в Python?
Служебное слово self — это ссылка на текущий экземпляр класса. Как правило, эта ссылка передается в качестве первого параметра метода Python:
class Apple:
____# Создаем объект с общим количеством яблок 12
____def __init__(self):
________self.whole_amount = 12
____# Съедаем часть яблок для текущего объекта
____def eat(self, number):
________self.whole_amount -= number
Стоит обратить внимание, что на самом деле слово self не является зарезервированным. Просто существует некоторое соглашение, по которому первый параметр метода именуется self и передает ссылку на текущий объект, для которого этот метода был вызван. Хотите назвать первый параметр метода по-другому — пожалуйста.
В других языках программирования(например, Java или C++) аналогом этого ключа является служебное слово this .
- Для создания статической переменной достаточно объявления класса, причем данная переменная создается непосредственно в теле класса.
- Динамические переменные создаются только в рамках работы c экземпляром класса.
- Чтоб создать переменную экземпляра, необходимо воспользоваться конструкцией self.<имя_переменной> внутри одного из методов.
- Экземпляр класса сочетает в себе совокупность как статических (уровня класса), так и динамических (уровня самого экземпляра) полей.
- Значения динамических переменных для разных объектов класса могут (и чаще всего так и делают) различаться.
- Методы экземпляра класса (они же обычные методы)
- Статические методы
- Методы класса
1. Методы экземпляра класса (Обычные методы)
2. Статические методы
Статические методы — это обычные функции, которые помещены в класс для удобства и тем самым располагаются в области видимости этого класса. Чаще всего это какой-то вспомогательный код.
Важная особенность заключается в том, что данные методы можно вызывать посредством обращения к имени класса, создавать объект класса при этом не обязательно. Именно поэтому в таких методах не используется self — этому методу не важна информация об объектах класса.
Чтобы создать статический метод в Python, необходимо воспользоваться специальным декоратором — @staticmethod . Выглядит это следующим образом:
3. Методы класса
Методы класса являются чем-то средним между обычными методами (привязаны к объекту) и статическими методами (привязаны только к области видимости). Как легко догадаться из названия, такие методы тесно связаны с классом, в котором они определены.
Обратите внимание, что такие методы могут менять состояние самого класса, что в свою очередь отражается на ВСЕХ экземплярах данного класса. Правда при этом менять конкретный объект класса они не могут (этим занимаются методы экземпляра класса).
Чтобы создать метод класса, необходимо воспользоваться соответствующим декоратором — @classmethod . При этом в качестве первого параметра такого метода передается служебное слово cls , которое в отличие от self является ссылкой на сам класс (а не на объект). Рассмотрим пример:
- Необходимо создать специфичный объект текущего класса
- Нужно реализовать фабричный паттерн — создаём объекты различных унаследованных классов прямо внутри метода
Вам наверняка известно, что в классических языках программирования (таких как C++ и Java) доступ к ресурсам класса реализуется с помощью служебных слов public , private и protected :
- Private. Приватные члены класса недоступны извне — с ними можно работать только внутри класса.
- Public. Публичные методы наоборот — открыты для работы снаружи и, как правило, объявляются публичными сразу по-умолчанию.
- Protected. Доступ к защищенным ресурсам класса возможен только внутри этого класса и также внутри унаследованных от него классов (иными словами, внутри классов-потомков). Больше никто доступа к ним не имеет
- Если переменная/метод начинается с одного нижнего подчеркивания ( _protected_example ), то она/он считается защищенным ( protected ).
- Если переменная/метод начинается с двух нижних подчеркиваний ( __private_example ), то она/он считается приватным ( private ).
Иными словами, это больше вопрос ответственности программиста — он не должен работать с атрибутами, имена которых начинаются с нижнего подчёркивания _ , снаружи класса.
Аналогично, два нижних подчеркивания __ в названии свойства/метода делают его приватным ( private ). Здесь уже интереснее — получить доступ к таким атрибутам напрямую нельзя (но если очень хочется, то все равно можно — об этом чуть ниже):
- Существует три уровня доступа к свойствам/методам класса: public, protected, private
- Физически данный механизм ограничения доступа к атрибутам класса в Python реализован слабо, что от части может противоречить одному из главных принципов ООП — инкапсуляции.
- Однако существует некоторое соглашение, по которому в Python задать уровень доступа к свойству/методу класса можно с помощью добавления к имени одного ( protected ) или двух ( private ) подчеркиваний. Ответственность за соблюдение данного соглашения ложится на плечи программистов.
Как мы уже выяснили выше, механизм наследования позволяет создать новый класс на основе уже существующего. При этом новый класс включает в себя как свойства и методы родительского класса, так и новые (собственные) атрибуты. Эти новые атрибуты и отличают свежесозданный класс от его родителя.
Для того, чтобы в Python создать новый класс с помощью механизма наследования, необходимо воспользоваться следующим синтаксисом:
Теперь давайте рассмотрим пример применения механизма наследования в действии. Перед нами класс Phone (Телефон), у которого есть одно свойство is_on и три метода:
- Инициализатор: __init__()
- Включение: turn_on()
- Звонок: call()
Среди данной совокупности атрибутов нас больше всего интересуют пользовательские свойства и методы: ‘__init__’ , ‘call’ , ‘is_on’ , ‘turn_on’
А теперь предположим, что мы захотели создать новый класс — MobilePhone (Мобильный телефон). Хоть этот класс и новый, но это по-прежнему телефон, а значить — его все так же можно включить и по нему можно позвонить. А раз так, то нам нет смысла реализовывать этот функционал заново, а можно просто унаследовать его от класса Phone . Выглядит это так:
Что такое super?
Как вы могли заметить, в инициализаторе (метод __init__ ) наследуемого класса вызывается метод super() . Что это за метод и зачем он нужен?
Главная задача этого метода — дать возможность наследнику обратиться к родительскому классу. В классе родителе Phone есть свой инициализатор, и когда в потомке MobilePhone мы так же создаем инициализатор (а он нам действительно нужен, так как внутри него мы хотим объявить новое свойство) — мы его перегружаем. Иными словами, мы заменяем родительский метод __init__() собственным одноименным методом. Это чревато тем, что родительский метод просто в принципе не будет вызван, и мы потеряем его функционал в классе наследнике. В конкретном случае, потеряем свойство is_on .
- Внутри инициализатора класса-наследника вызвать инициализатор родителя (для этого вызываем метод super().__init__() )
- А затем просто добавить новый функционал
def __init__(self):
____super().__init__()
____self.battery = 0
Обратите внимание, что вызывать родительский метод необходимо в первую очередь.
Classes
Классы предоставляют средства объединения данных и функциональности вместе. Создание нового класса создает новый тип объекта, позволяя создавать новые экземпляры этого типа. К каждому экземпляру класса могут быть прикреплены атрибуты для поддержания его состояния. Экземпляры класса также могут иметь методы (определяемые его классом) для изменения его состояния.
По сравнению с другими языками программирования,механизм классов Python добавляет классы с минимальным количеством нового синтаксиса и семантики.Он представляет собой смесь механизмов классов,найденных в C++и Modula-3.Классы Python предоставляют все стандартные возможности объектно-ориентированного программирования:механизм наследования классов позволяет использовать несколько базовых классов,производный класс может переопределять любые методы своего базового класса или классов,а метод может вызывать метод базового класса с тем же именем.Объекты могут содержать произвольные объемы и виды данных.Как и модули,классы обладают динамической природой Python:они создаются во время выполнения и могут быть изменены после создания.
В терминологии C++ обычно члены класса (включая элементы данных) являются общедоступными (кроме см. ниже Частные переменные ), а все функции-члены являются виртуальными . Как и в Модуле-3, нет сокращений для ссылки на члены объекта из его методов: функция метода объявляется с явным первым аргументом, представляющим объект, который неявно предоставляется вызовом. Как и в Smalltalk, сами классы являются объектами. Это обеспечивает семантику для импорта и переименования. В отличие от C++ и Modula-3, встроенные типы могут использоваться пользователем в качестве базовых классов для расширения. Кроме того, как и в C++, большинство встроенных операторов со специальным синтаксисом (арифметические операторы, индексация и т. д.) могут быть переопределены для экземпляров класса.
(Не имея общепринятой терминологии, чтобы говорить о классах, я буду время от времени использовать термины Smalltalk и C ++. Я бы использовал термины Modula-3, поскольку его объектно-ориентированная семантика ближе к семантике Python, чем C ++, но я ожидаю, что немногие читатели слышали об этом.)
9.1.Несколько слов об именах и объектах
Объекты обладают индивидуальностью,и к одному и тому же объекту может быть привязано несколько имен (в разных диапазонах).В других языках это известно как алиасинг.При первом знакомстве с Python это обычно не оценивается,и при работе с неизменяемыми базовыми типами (числа,строки,кортежи)его можно смело игнорировать.Однако алиасинг оказывает,возможно,неожиданное влияние на семантику кода Python,связанного с изменяемыми объектами,такими как списки,словари и большинство других типов.Обычно это используется с пользой для программы,поскольку псевдонимы в некоторых отношениях ведут себя как указатели.Например,передача объекта обходится дешевле,поскольку реализация передает только указатель;а если функция изменяет объект,переданный в качестве аргумента,вызывающая функция увидит это изменение-это устраняет необходимость в двух различных механизмах передачи аргументов,как в Паскале.
9.2.Области и пространства имен Python
Прежде чем представить классы,я должен рассказать вам о правилах области видимости в Python.Определения классов играют с пространствами имен,и вам нужно знать,как работают области видимости и пространства имен,чтобы полностью понять,что происходит.Кстати,знание этой темы полезно для любого продвинутого программиста Python.
Давайте начнем с некоторых определений.
Пространство имен — это сопоставление имен с объектами. Большинство пространств имен в настоящее время реализованы в виде словарей Python, но обычно это никак не заметно (кроме производительности) и может измениться в будущем. Примеры пространств имен: набор встроенных имен (содержащих такие функции, как abs() и встроенные имена исключений); глобальные имена в модуле; и локальные имена в вызове функции. В некотором смысле набор атрибутов объекта также образует пространство имен. Важно знать о пространствах имен то, что между именами в разных пространствах имен нет абсолютно никакой связи; например, два разных модуля могут оба определять функцию maximize без путаницы — пользователи модулей должны ставить перед ней имя модуля.
Кстати, я использую слово attribute для любого имени, следующего за точкой — например, в выражении z.real z.real real это атрибут объекта z . Строго говоря, ссылки на имена в модулях являются ссылками на атрибуты: в выражении modname.funcname modname — это объект модуля, а funcname — его атрибут. В этом случае происходит прямое сопоставление между атрибутами модуля и глобальными именами, определенными в модуле: они используют одно и то же пространство имен! 1
Атрибуты могут быть доступны только для чтения или записи. В последнем случае возможно присвоение атрибутам. Атрибуты модуля доступны для записи: вы можете написать modname.the_answer = 42 . Атрибуты, доступные для записи, также могут быть удалены с помощью оператора del .Например, del modname.the_answer удалит атрибут the_answer из объекта с именем modname .
Пространства имен создаются в разные моменты и имеют разное время жизни. Пространство имен, содержащее встроенные имена, создается при запуске интерпретатора Python и никогда не удаляется. Глобальное пространство имен для модуля создается при считывании определения модуля; обычно пространства имен модулей также существуют, пока интерпретатор не завершит работу. Операторы, выполняемые при вызове интерпретатора верхнего уровня, либо считываемых из файла сценария, либо интерактивно, считаются частью модуля с именем __main__ , поэтому у них есть собственное глобальное пространство имен. (Встроенные имена фактически также находятся в модуле; это называется builtins именами .)
Локальное пространство имен для функции создается при вызове функции и удаляется,когда функция возвращается или вызывает исключение,которое не обрабатывается внутри функции.(На самом деле,»забывание» было бы лучшим способом описать то,что происходит на самом деле).Конечно,рекурсивные вызовы имеют свое собственное локальное пространство имен.
Область видимости — это текстовая область программы Python, в которой пространство имен доступно напрямую. «Прямой доступ» здесь означает, что неквалифицированная ссылка на имя пытается найти имя в пространстве имен.
Хотя диапазоны определяются статически,они используются динамически.В любой момент времени во время выполнения существует 3 или 4 вложенные области,пространства имен которых доступны напрямую:
- самая внутренняя область видимости,которая просматривается первой,содержит локальные имена
- области видимости любых объемлющих функций,поиск которых начинается с ближайшей объемлющей области видимости,содержит нелокальные,но и неглобальные имена
- предпоследняя область видимости содержит глобальные имена текущего модуля
- самая внешняя область видимости (ищется последней)-это пространство имен,содержащее встроенные имена
Если имя объявлено глобальным, то все ссылки и присваивания идут непосредственно в среднюю область, содержащую глобальные имена модуля. Чтобы повторно связать переменные, находящиеся за пределами самой внутренней области видимости, можно использовать оператор nonlocal ;если они не объявлены нелокальными, эти переменные доступны только для чтения (попытка записи в такую переменную просто создаст новую локальную переменную в самой внутренней области, оставив внешнюю переменную с таким же именем неизменной).
Обычно локальная область видимости ссылается на локальные имена (текстуально)текущей функции.Вне функций локальная область видимости ссылается на то же пространство имен,что и глобальная область видимости:пространство имен модуля.В определениях классов в локальную область видимости помещается еще одно пространство имен.
Важно понимать,что области видимости определяются текстуально:глобальной областью видимости функции,определенной в модуле,является пространство имен этого модуля,независимо от того,откуда или по какому псевдониму вызывается функция.С другой стороны,фактический поиск имен осуществляется динамически,во время выполнения-однако,определение языка развивается в сторону статического разрешения имен,во время «компиляции»,поэтому не стоит полагаться на динамическое разрешение имен! (На самом деле,локальные переменные уже определяются статически).
Особая особенность Python заключается в том, что если не действует ни один global или nonlocal оператор, присваивание имен всегда выполняется в самой внутренней области видимости. Присваивания не копируют данные — они просто привязывают имена к объектам. То же верно и для удалений: инструкция del x удаляет привязку x из пространства имен, на которое ссылается локальная область. На самом деле все операции, вводящие новые имена, используют локальную область видимости: в частности, операторы import и определения функций связывают имя модуля или функции в локальной области видимости.
Оператор global может использоваться для указания того, что определенные переменные находятся в глобальной области видимости и должны быть перенаправлены туда; оператор nonlocal указывает, что определенные переменные находятся в охватывающей области видимости и должны быть перепривязаны туда.
9.2.1.Области и пространства имен Пример
Это пример, демонстрирующий, как ссылаться на разные области и пространства имен, и как global и nonlocal влияют на привязку переменных:
Код примера выводится следующим образом:
Обратите внимание, что локальное назначение (которое используется по умолчанию) не изменило связывание scope_test со спамом . nonlocal присвоение изменило привязку scope_test к spam , а global присвоение изменило привязку на уровне модуля.
Вы также можете видеть, что перед global назначением не было предыдущей привязки для спама .
9.3.Первый взгляд на классы
Классы представляют немного нового синтаксиса,три новых типа объектов и несколько новых семантик.
9.3.1.Синтаксис определения класса
Простейшая форма определения класса выглядит следующим образом:
Определения классов, такие как определения функций ( операторы def ), должны быть выполнены до того, как они окажут какой-либо эффект. (Вы могли бы разместить определение класса в ветви оператора if или внутри функции.)
На практике утверждения внутри определения класса обычно являются определениями функций,но допускаются и другие утверждения,иногда полезные-мы вернемся к этому позже.Определения функций внутри класса обычно имеют своеобразную форму списка аргументов,продиктованную соглашениями о вызове методов-опять же,это объясняется позже.
Когда вводится определение класса,создается новое пространство имен,которое используется как локальная область видимости-таким образом,все присваивания локальным переменным идут в это новое пространство имен.В частности,определения функций связывают здесь имя новой функции.
Когда определение класса оставляется нормально (через конец), создается объект класса . По сути, это оболочка вокруг содержимого пространства имен, созданного определением класса; мы узнаем больше об объектах класса в следующем разделе. Первоначальная локальная область видимости (действовавшая непосредственно перед вводом определения класса) восстанавливается, и здесь объект класса привязывается к имени класса, указанному в заголовке определения класса ( ClassName в примере).