Lanzamento da linguaxe de programación Python 3.11

Despois dun ano de desenvolvemento, publicouse a importante versión da linguaxe de programación Python 3.11. A nova rama estará soportada durante un ano e medio, despois de que durante outros tres anos e medio xeraranse correccións para que elimine vulnerabilidades.

Ao mesmo tempo, comezaron as probas alfa da rama Python 3.12 (de acordo co novo calendario de desenvolvemento, o traballo nunha nova rama comeza cinco meses antes do lanzamento da rama anterior e chega á fase de probas alfa no momento da seguinte versión). ). A rama de Python 3.12 estará en versión alfa durante sete meses, durante os cales engadiranse novas funcións e corrixiranse erros. Despois disto, probaranse as versións beta durante tres meses, durante os cales prohibirase engadir novas funcións e prestarase toda a atención á resolución de erros. Durante os dous últimos meses anteriores á liberación, a sucursal estará na fase de candidato a liberación, na que se realizará a estabilización final.

As novas incorporacións a Python 3.11 inclúen:

• Realizouse un traballo importante para optimizar o rendemento. A nova rama inclúe cambios relacionados coa aceleración e o despregamento en liña de chamadas de funcións, o uso de intérpretes rápidos de operacións estándar (x+x, x*x, xx, a[i], a[i] = z, f(arg) C(arg), o.method(), o.attr = z, *seq), así como optimizacións preparadas polos proxectos Cinder e HotPy. Dependendo do tipo de carga, hai un aumento na velocidade de execución do código do 10-60%. De media, o rendemento na suite de probas pyperformance aumentou un 25%.

  Rediseñouse o mecanismo de caché de código de bytes, o que reduciu o tempo de inicio do intérprete nun 10-15%. Os obxectos con código e bytecode agora son asignados de forma estática polo intérprete, o que permitiu eliminar as fases de desmarshalling bytecode extraído da caché e converter obxectos con código para colocalos na memoria dinámica.

• Cando se mostran trazos de chamadas en mensaxes de diagnóstico, agora é posible mostrar información sobre a expresión que causou o erro (anteriormente, só se resaltaba a liña sen detallar que parte da liña provocou o erro). Tamén se pode obter información de rastrexo estendida a través da API e utilizarse para asignar instrucións de bytecode individuais a unha posición específica no código fonte mediante o método codeobject.co_positions() ou a función C API PyCode_Addr2Location(). O cambio facilita moito a depuración de problemas con obxectos de dicionario aniñados, chamadas de funcións múltiples e expresións aritméticas complexas. Traceback (última chamada máis recente): ficheiro "calculation.py", liña 54, no resultado = (x / y / z) * (a / b / c) ~~~~~~^~~ ZeroDivisionError: división por cero
• Engadiuse soporte para grupos de excepcións, dándolle ao programa a posibilidade de xerar e procesar varias excepcións diferentes á vez. Para agrupar varias excepcións e xeralas, propuxéronse novos tipos de excepcións ExceptionGroup e BaseExceptionGroup, e engadiuse a expresión "excepto*" para resaltar as excepcións individuais dun grupo.
• O método add_note() engadiuse á clase BaseException, o que lle permite anexar unha nota de texto á excepción, por exemplo, engadindo información contextual que non está dispoñible cando se lanza a excepción.
• Engadiuse un tipo especial de Self para representar a clase privada actual. Self pódese usar para anotar métodos que devolven unha instancia da súa clase dun xeito máis sinxelo que usando TypeVar. clase MyLock: def __enter__(self) -> Self: self.lock() return self
• Engadiuse un tipo especial LiteralString que só pode incluír literais de cadea compatibles co tipo LiteralString (é dicir, cadeas nuas e LiteralString, pero non cadeas de cadea arbitrarias ou combinadas). O tipo LiteralString pódese usar para limitar o paso de argumentos de cadea a funcións, substitución arbitraria de partes de cadeas nas que pode provocar vulnerabilidades, por exemplo, cando se xeran cadeas para consultas SQL ou comandos de shell. def run_query(sql: LiteralString) -> ... ... def caller( arbitrary_string: str, query_string: LiteralString, table_name: LiteralString, ) -> None: run_query("SELECT * FROM students") # ok run_query(literal_string) # ok run_query( "SELECT * FROM" + literal_string) # ok run_query (cadea_arbitraria) # Erro run_query( # Erro f"SELECT * FROM estudantes WHERE nome = {cadea_arbitraria}" )
• Engadiuse o tipo TypeVarTuple, que permite o uso de variables xenéricas, a diferenza de TypeVar, que non cobren un tipo, senón un número arbitrario de tipos.
• A biblioteca estándar inclúe o módulo tomllib con funcións para analizar o formato TOML.
• É posible marcar elementos individuais dos dicionarios escritos (TypedDict) con etiquetas Required e NotRequired para determinar os campos obrigatorios e opcionais (por defecto, todos os campos declarados son obrigatorios se o parámetro total non está definido como Falso). class Movie(TypedDict): title: str year: NotRequired[int] m1: Movie = {"title": "Black Panther", "year": 2018} # OK m2: Movie = {"title": "Star Wars" } # Aceptar (o campo do ano é opcional) m3: Película = {“ano”: 2022} # Erro, o campo de título obrigatorio non está cuberto)
• A clase TaskGroup engadiuse ao módulo asincrónico coa implementación dun xestor de contexto asíncrono que espera a que se complete un grupo de tarefas. Engadir tarefas a un grupo realízase mediante o método create_task(). async def main(): async con asyncio.TaskGroup() as tg: task1 = tg.create_task(some_coro(...)) task2 = tg.create_task(other_coro(...)) print("Ambas tarefas completáronse agora .")
• Engadiuse o decorador @dataclass_transform para clases, métodos e funcións, cando se especifica, o sistema de verificación de tipos estáticos trata o obxecto coma se usase o decorador @dataclasses.dataclass. No seguinte exemplo, a clase CustomerModel, ao comprobar os tipos, procesarase de forma similar a unha clase co decorador @dataclasses.dataclass, é dicir. como ter un método __init__ que acepta variables id e nome. @dataclass_transform() clase ModelBase: ... clase CustomerModel(ModelBase): id: int nome: str
• Nas expresións regulares, engadiuse a capacidade de usar agrupacións atómicas ((?>...)) e cuantificadores posesivos (*+, ++, ?+, {m,n}+).
• Engadiuse a opción de liña de comandos "-P" e a variable de ambiente PYTHONSAFEPATH para desactivar o anexo automático de rutas de ficheiros potencialmente inseguras a sys.path.
• A utilidade py.exe para a plataforma Windows mellorouse significativamente, engadindo soporte para a sintaxe "-V:". / " Ademais de "- . "
• Moitas macros da API C convértense en funcións en liña regulares ou estáticas.
• Os módulos uu, cgi, pipes, crypt, aifc, chunk, msilib, telnetlib, audioop, nis, sndhdr, imghdr, nntplib, spwd, xdrlib, cgitb, mailcap, ossaudiodev e sunau quedaron en desuso e eliminaranse en Python Versión 3.13. Elimináronse as funcións PyUnicode_Encode*.

Fonte: opennet.ru