Tl;dr: don't use @property during design, it's almost certainly the wrong pattern. But use it to retrofit a method to a value.
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
Yup. I pretty much only use it if I need to ensure new values are valid or provide a default value.
I do the same in other languages, like C# and JavaScript. Properties are cool, but should be quite rare.
this is a method, and always was a method, I just wanted it to look like an attribute for aesthetic reasons
I think "aesthetic reasons" is an oversimplification. There are certain assumptions a developer makes when reading some code that uses properties. While these assumptions are not clearly defined and may differ per developer, I think there is a common core.
(1) There are no side-effects. The object is not mutated (or any other object), no IO takes place.
(2) The time and space complexity is O(1).
(3) The result is consistent. Consequent calls to the property should return the same value unless there is a mutation between them.
The combination of properties 1 and 3 makes it a pure function, which is also useful in compiled or jittable languages because it allows for a variety of optimizations.
(tried to delete this comment but somehow didn't work, I re-read the article and have a different outlook, sorry for the low effort comment)
Nah, I think I'll continue to.