Path: csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail
From: Chris Angelico <rosuav@gmail.com>
Newsgroups: comp.lang.python
Subject: Re: can't add variables to instances of built-in classes
Date: Thu, 21 Jul 2016 12:29:38 +1000
Lines: 48
Message-ID: <mailman.13.1469068181.22221.python-list@python.org>
References: <4f796d95-0e87-4610-a0a8-1eff07c60ace@googlegroups.com> <nmfqrg$ea7$1@ger.gmane.org> <mailman.63.1468755660.2307.python-list@python.org> <b24bede0-be29-4c45-856e-90e6a63c99d0@googlegroups.com> <578b9e62$0$22141$c3e8da3$5496439d@news.astraweb.com> <3e934f83-2076-407d-b85b-686ecdec6ff8@googlegroups.com> <nmi127$r0e$1@ger.gmane.org> <mailman.70.1468827536.2307.python-list@python.org> <2bc29306-ac90-4424-84c2-64be494c5a75@googlegroups.com> <bff64f31-d618-4d47-a81b-aa817db8c456@googlegroups.com> <230d1aff-b1a3-4f16-b9a6-b5d9fd07e4b4@googlegroups.com> <62dd86d4-74f7-4e97-a29c-7e45aced77d9@googlegroups.com> <f988e9a1-beba-41f3-bd11-8ed4c7a69a81@googlegroups.com> <CAPTjJmrup=D9pP5buOytY7x1zQYC6Nh-R=WkaXcJBAfbD+_JJA@mail.gmail.com> <mailman.1.1468995572.22221.python-list@python.org> <cadcdba3-61a0-4803-afc5-894d8de4f0cc@googlegroups.com> <nmn92l$4jh$1@ger.gmane.org> <mailman.3.1468999586.22221.python-list@python.org> <18acf908-b761-4a60-8d7c-5e4576b03320@googlegroups.com> <nmnfgf$697$1@ger.gmane.org> <mailman.4.1469006175.22221.python-list@python.org> <d633242c-7aca-485d-9daa-9008640a6f46@googlegroups.com> <CAPTjJmpPMidJCmhB_D6UAY0Jze_oKgNRkp=RZ3xD_a6AVzsD4Q@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <d633242c-7aca-485d-9daa-9008640a6f46@googlegroups.com>
Precedence: list
Xref: csiph.com comp.lang.python:111688

On Thu, Jul 21, 2016 at 8:11 AM, Lawrence D=E2=80=99Oliveiro
<lawrencedo99@gmail.com> wrote:
> On Wednesday, July 20, 2016 at 9:16:30 PM UTC+12, Peter Otten wrote:
>>
>> Lawrence D=E2=80=99Oliveiro wrote:
>>
>>> On Wednesday, July 20, 2016 at 7:26:36 PM UTC+12, Peter Otten wrote:
>>>
>>>> pylint can detect candidates for accidental attribute creation:
>>>
>>> And __slots__ will prevent them outright.
>>
>> And attributes added intentionally.
>
> You mean, being able to dynamically add new attributes to an object?
>
> Probably not a good idea to mix that with read/write properties...

This is exactly what Steven was talking about. If you can't handle
dynamic read-write attributes (whether they're properties or simple
attributes is orthogonal to this), why even use Python? You can get a
linter to tell you about misspelled attribute names, which has a huge
advantage over __slots__ in that it can give you the information prior
to actually hitting that line of code (prior to even running the
program - and some editors have integrated linters, so you don't even
need to consciously run the linter, you just see the results as you
type). That gives you virtually the same benefit as C/Java style of
coding, where you're forced to declare all your members in the class;
but as an added bonus, you can *dynamically add attributes*! Don't
think that's useful? Well, the other day I wanted to add a wrapper
around the constructor for someone else's object to stash a bit of
extra information into it (to track down a resource leak - turned out
there was an ever-growing collection of objects, because they weren't
being removed from that object), and if I'd been using Java, the
response would have been "no way does that even make sense". Thanks to
dynamic code, I could do what I needed to and track down the leak. If
the author of that object had used __slots__, though, I'd have been
utterly stuck.

Using __slots__ basically takes your object down to the level of a
Java one. That's generally fine for something immutable (you really
don't need to be adding attributes to the integer 42), but even with
immutables, I've sometimes wanted to add hidden attributes; with
mutable objects, it's common enough that you want to leave the option
open unless you have good reason not to. And "my editor sucks" is not
a good reason; nor is "my debugging skills suck".

ChrisA