The syntax of the Python programming language is the set of rules that defines how a Python program will be written and interpreted (by both the runtime system and by human readers). The Python language has many similarities to Perl, C, and Java. However, there are some definite differences between the languages. It supports multiple programming paradigms, including structured programming, object-oriented programming, and functional programming, and boasts a dynamic type system and automatic memory management. Python's syntax is simple and consistent, adhering to the principle that "There should be one-and preferably only one-obvious way to do it." The language incorporates built-in data types and structures, control flow mechanisms, first-class functions, and modules for better code reusability and organization. Python also uses English keywords where other languages use punctuation, contributing to its uncluttered visual layout. The language provides robust error handling through exceptions, and includes a debugger in the standard library for efficient problem-solving. Python's syntax, designed for readability and ease of use, makes it a popular choice among beginners and professionals alike.
Design philosophy Python was designed to be a highly readable language. It has a relatively uncluttered visual layout and uses English keywords frequently where other languages use punctuation. Python aims to be simple and consistent in the design of its syntax, encapsulated in the mantra "There should be one— and preferably only one —obvious way to do it", from the Zen of Python. This mantra is deliberately opposed to the Perl and Ruby mantra, "there's more than one way to do it".
Keywords Python 3 has 35 keywords or reserved words; they cannot be used as identifiers.
In addition, Python 3 also has 4 soft keywords, including type added in Python 3.12. Unlike regular hard keywords, soft keywords are reserved words only in the limited contexts where interpreting them as keywords would make syntactic sense. These words can be used as identifiers elsewhere, in other words, match and case are valid names for functions and variables.
_ case match type
Function annotations Function annotations (type hints) are defined in PEP 3107. They allow attaching data to the arguments and return of a function. The act of annotations is not defined by the language, and is left to third party frameworks. For example, a library could be written to handle static typing:
While annotations are optional in Python, the rest of this article will use annotations to provide clarity.
Modules and import statements In Python, code is organized into files called modules, and namespaces are defined by the individual modules. Since modules can be contained in hierarchical packages, then namespaces are hierarchical too. In general when a module is imported then the names defined in the module are defined via that module's namespace, and are accessed in from the calling modules by using the fully qualified name.
The from ... import ... statement can be used to insert the relevant names directly into the calling module's namespace, and those names can be accessed from the calling module without the qualified name:
Since this directly imports names (without qualification) it can overwrite existing names with no warnings. A special form of the statement is from ... import * which imports all names defined in the named package directly in the calling module's namespace. Use of this form of import, although supported within the language, is generally discouraged as it pollutes the namespace of the calling module and will cause already defined names to be overwritten in the case of name clashes. However, this page will present code as if the line "from typing import *" were included, for referring to collection types. The different import statements are demonstrated here:
Using from import statements in Python can simplify verbose namespaces, such as nested namespaces.
Python also supports import x as y as a way of providing an alias or alternative name for use by the calling module:
When a module is imported, the Python interpreter first checks if it exists in the sys.modules cache, and reuses it if it had been imported previously, otherwise it loads it. When loading, it searches it in sys.path, and compiles it to bytecode or interprets its contents. All code in the global scope of the module is executed. However, this can be mitigated using an explicit main function, which behaves similarly to an entry point in most compiled languages, using the entry point idiom described as follows.
Entry point A pseudo-entry point can be created by the following idiom, which relies on the internal variable __name__ being set to __main__ when a program is executed, but not when it is imported as a module (in which case it is instead set to the module name); there are many variants of this structure:
In this idiom, the call to the named entry point main is explicit, and the interaction with the operating system (receiving the arguments, calling system exit) are done explicitly by library calls, which are ultimately handled by the Python runtime. This contrasts with C, where these are done implicitly by the runtime, based on convention.
Indentation Python uses whitespace to delimit control flow blocks (following the off-side rule). Python borrows this feature from its predecessor ABC: instead of punctuation or keywords, it uses indentation to indicate the run of a block. In so-called "free-format" languages – that use the block structure derived from ALGOL – blocks of code are set off with braces ({ }) or keywords. In most coding conventions for these languages, programmers conventionally indent the code within a block, to visually set it apart from the surrounding code. A recursive function named foo, which is passed a single parameter, x, and if the parameter is 0 will call a different function named bar and otherwise will call baz, passing x, and also call itself recursively, passing x-1 as the parameter, could be implemented like this in Python:
and could be written like this in C:
Incorrectly indented code could be misread by a human reader differently than it would be interpreted by a compiler or interpreter. For example, if the function call foo(x - 1) on the last line in the example above was erroneously indented to be outside the if/else block:
… excerpt ends here. Continue reading the full article.
