Python Properties vs Methods: The Contract You Didn’t Know You Were Making

Comments · 108

• AR

  @ArjanCodes · 6 months ago (edited) · pinned

  🧱 Build software that lasts. Join the Software Design Mastery waiting list → <a href="https://arjan.codes/mastery">https://arjan.codes/mastery</a>.

• CF

  @cfossto · 7 months ago

  Imma spam this video to an entire team I worked with... &quot;just because you can, doesn&apos;t mean you should&quot;.

  76

• RE

  @realms4219 · 7 months ago (edited)

  All our Python scripting is written by Java programmers. How can I tell? How can I NOT tell lmfaooo this video is finally giving me confirmation

  18

• WT

  @wtzeb · 7 months ago (edited)

  Incredibly happy you&apos;re still digging into the code and creating these videos.

  19

• UN

  @UNgineering · 7 months ago

  between awaiting a property and saving-on-assignment, i think i have a way to completely poison OpenAI training dataset on python

  23

• CA

  @caujka · 6 months ago

  Thanks for the explanation! You brought awesome examples to illustrate the idea!

• EX

  @Exolodem · 7 months ago

  Great Video!

  1

• SL

  @sleeping_monkey · 7 months ago (edited)

  <a href="https://www.youtube.com/watch?v=wHLZ_uTrCYA&amp;t=500">8:20</a> There&apos;s another way to define properties<br><br>def get_is_active(self) ...<br>def set_is_active(self, value) ...<br><br>is_active = property(get_is_active, set_is_active)<br><br>And you can actually define a write-only property this way:<br><br>def set_is_active(self, value) ...<br>is_active = property(None, set_is_active)<br><br>or<br><br>is_active = property(fset=set_is_active)<br><br>You can take it further and create a delete-only property...

  19

• MA

  @malteplath · 7 months ago

  I totally agree with your suggestion about the use of properties. &nbsp;One specific other use case would be to fake an interface: If some third party function expects an attribute but it is not an attribute (but rather a derived &quot;property&quot;) of your class, a @property is the perfect fit. - rather than writing a complete wrapper around your existing class.<br>I am looking forward to your video on descriptors. I have not managed to get my head around those! Pure (black) magic to a mere human.

  2

• TO

  @tonny_dourado · 7 months ago

  Async properties is a crazy concept, my first instinct was it wouldn&apos;t work, but when I thought about it a bit, it clearly works. Feels like an almost unintended interaction between features, though 😅

  13

• SR

  @srh1034 · 6 months ago

  Something I really love about your tutorials is the depth of knowledge your share, but what I do not like and I belive is the biggest shortcoming of yur videos is taht so many words are used to explain, rather than just some simple graphics when explaining and then actual implementation which you do amazingly! Big fan anyway!

• ED

  @edvardasposka · 7 months ago

  Properties can be write-only, i.e. by tweaking the getter method of properties &nbsp;we can create create write-only attributes. We can make our getter method raise an exception every time a user accesses the underlying attribute, e.g. <br>@property<br> &nbsp; &nbsp;def password(self):<br> &nbsp; &nbsp; &nbsp; &nbsp;raise AttributeError(&quot;Password is write-only&quot;)<br><br>@password.setter<br> &nbsp; &nbsp;def password(self, plaintext):<br> &nbsp; &nbsp; &nbsp; &nbsp;salt = os.urandom(32)<br> &nbsp; &nbsp; &nbsp; &nbsp;self._hashed_password = hashlib.pbkdf2_hmac(<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&quot;sha256&quot;, plaintext.encode(&quot;utf-8&quot;), salt, 100_000<br> &nbsp; &nbsp; &nbsp; &nbsp;)<br>This turns &quot;password&quot; into a write-only attribute. &nbsp;Then we store the resulting hashed password in the non-public attribute, doing so ensures that we never save the &quot;plaintext&quot; password in any retrievable attribute.

  2