If you don't need to reuse the collection or access its items out of order, you can also use Iterable
which accepts even more inputs like generators.
Python
Welcome to the Python community on the programming.dev Lemmy instance!
π Events
Past
November 2023
- PyCon Ireland 2023, 11-12th
- PyData Tel Aviv 2023 14th
October 2023
- PyConES Canarias 2023, 6-8th
- DjangoCon US 2023, 16-20th (!django π¬)
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
The problem is that there's a severe hole in the ABCs: there is no distinction between "container whose elements are mutable" and "container whose elements and size are mutable".
(related, there's no distinction for supporting slice operations or not, e.g. deque
)
Yeah there's definitely a lot of room for improvement here
Good point, and Εukasz Langa mentioned this in his talk (check it out). He names it the robustness principle, in his words (around 22:20
mark:
"Vague in what you accept, concrete in what you return"
But he also mentions some gotchas like how Iterable[str]
can backfire, because str
is also an Iterable[str]
and it might be better to use list[str]
.
The important difference is that you don't need to import anything in order to quickly use list
type. This wins in the majority of the cases, unless I'm building something that will be imported by multiple other modules and it really pays to be that explicit.
That was definitely a nice feature (I forget exactly when list over List was added). That said I've never really been bothered about having imports. Especially when I know the import is side effect free like the typing module. But I definitely use import free list for script files without many lines of code.
Sequence
now lives at collections.abc
. BTW, float
is not a supertype of int
(issubclass(int, float) == False
). Normaly, It is acceptable to use int
instead of float
, but speaking of variance, it is more precise to use numbers.Real
:
issubclass(Integral, Real) == True
issubclass(int, Real) == True
issubclass(float, Real) == True
issubclass(complex, Real) == False
yeah it's an interesting case that an int can be treated as a float. I should probably update my post to mention that it's not strictly a supertype but a special exception mentioned in python's typehinting pep: https://peps.python.org/pep-0484/#the-numeric-tower