You'd always want to use varname: type_description = initial_value
pattern. It's readable, is the same pattern you use in method params, and linters and IDEs recognize this pattern. And it makes sense for the type description be on the left side of the assignment operator, together with the variable it's describing.
Python
Welcome to the Python community on the programming.dev Lemmy instance!
π Events
October 2023
- PyConES Canarias 2023, 6-8th
- DjangoCon US 2023, 16-20th (!django π¬)
November 2023
- PyCon Ireland 2023, 11-12th
- PyData Tel Aviv 2023 14th
Past
July 2023
- PyDelhi Meetup, 2nd
- PyCon Israel, 4-5th
- DFW Pythoneers, 6th
- Django Girls Abraka, 6-7th
- SciPy 2023 10-16th, Austin
- IndyPy, 11th
- Leipzig Python User Group, 11th
- Austin Python, 12th
- EuroPython 2023, 17-23rd
- Austin Python: Evening of Coding, 18th
- PyHEP.dev 2023 - "Python in HEP" Developer's Workshop, 25th
August 2023
- PyLadies Dublin, 15th
- EuroSciPy 2023, 14-18th
September 2023
- PyData Amsterdam, 14-16th
- PyCon UK, 22nd - 25th
π Python project:
- Python
- Documentation
- News & Blog
- Python Planet blog aggregator
π Python Community:
- #python IRC for general questions
- #python-dev IRC for CPython developers
- PySlackers Slack channel
- Python Discord server
- Python Weekly newsletters
- Mailing lists
- Forum
β¨ Python Ecosystem:
π Fediverse
Communities
- #python on Mastodon
- c/django on programming.dev
- c/pythorhead on lemmy.dbzer0.com
Projects
- PythΓΆrhead: a Python library for interacting with Lemmy
- Plemmy: a Python package for accessing the Lemmy API
- pylemmy pylemmy enables simple access to Lemmy's API with Python
- mastodon.py, a Python wrapper for the Mastodon API
Feeds
I'm pretty sure most type checkers recognise both forms.
The first one, has a implicit call to the constructor that need infer the type annotation of the result. BTW, the second form is a direct statement with a explicit type annotation, more recommended. When you see the AST of both statements, you can see the overload of calling the constructor and the use of AnnAssign (assign with type annotation) vs Assign:
thing = list[str]()
Module(
body=[
Assign(
targets=[
Name(id='thing', ctx=Store())],
value=Call(
func=Subscript(
value=Name(id='list', ctx=Load()),
slice=Name(id='str', ctx=Load()),
ctx=Load()),
args=[],
keywords=[]))],
type_ignores=[])
thing: list[str] = []
Module(
body=[
AnnAssign(
target=Name(id='thing', ctx=Store()),
annotation=Subscript(
value=Name(id='list', ctx=Load()),
slice=Name(id='str', ctx=Load()),
ctx=Load()),
value=List(elts=[], ctx=Load()),
simple=1)],
type_ignores=[])
How do u get this output
With the dump
function:
from ast import dump, parse
st = parse("thing = list[str]()")
print(dump(st, indent=4))
st = parse("thing: list[str] = []")
print(dump(st, indent=4))
Preesh
I find like you that the first one is strange.
But I think that both are useless because you can put what you want in a list in python.
thing = List[str]()
type(thing)
#
stuff: List[str] = []
type(stuff)
#
But in other hand it's helpful in IDE to get some warning like Expected type 'str' (matched generic type '_T'), got 'int' instead
.
Soooo, in the end I say that I choose this one thing: list[str] = []
because it looks more widely used and easily readable.
But I think that both are useless because you can put what you want in a list in python.
You can say that about all type hinting, but assuming you actually adhere to the type hints, it's a great tool to make python projects manageable.
In addition to what others have said, collection literals are also faster. list[str]()
performs a function call that technically might not be the built-in list
. Where []
is always an empty list and it can be created with less overhead.
You can't do the first in Python 3.8
the second works if you swap list for List
Is there a pep for this first form?
It's described in PEP 585, https://peps.python.org/pep-0585/#parameters-to-generics-are-available-at-runtime