On Wed, 22 Aug 2018 03:58:29 +1000, Chris Angelico wrote:
> On Wed, Aug 22, 2018 at 2:38 AM, Marko Rauhamaa <ma...@pacujo.net>
> wrote:
>> Gregory Ewing <greg.ew...@canterbury.ac.nz>:
>>
>>> Marko Rauhamaa wrote:
>>>> Lexically, there is special access:
>>>>
>>>> class C:
>>>> def __init__(self, some, arg):
>>>> c = self
>>>> class D:
>>>> def method(self):
>>>> access(c)
>>>> access(some)
>>>> access(arg)
>>>
>>> [...]
>>>
>>> you can do that without creating a new class every time you want an
>>> instance. You just have to be *slightly* more explicit about the link
>>> between the inner and outer instances.
>>
>> By "*slightly* more explicit," do you mean more syntactic clutter?
>>
>>
> No, he actually means "explicit" in the normal English sense. You're
> trying to use it in the python-ideas sense of "code that I like", and
> since you don't like it, you want to call it "implicit" instead, but it
> obviously isn't that, so you call it "syntactic clutter".
That's an incredible insight into Marko's internal mental state you have
there. And you get that all from the words "syntactic clutter"? I thought
he just meant that it was cluttered code. How naive was that?
*wink*
> But this is actually a case of explicit vs implicit.
To be honest, I don't even understand Greg's comment. With no inner
class, what is this "inner instance" he refers to here?
"you can do that without creating a new class every time you
want an instance. You just have to be *slightly* more explicit
about the link between the inner and outer instances."
Marko wants to use closures. So how do you close over per-instance
variables if you create the closures before the instances are created?
If we only needed *one* function, there would be no problem:
class Outer:
def __init__(self, some, arg):
c = self
def closure():
access(c)
access(some)
access(arg)
# then do something useful with closure
But as soon as you have a lot of them, its natural to want to wrap them
up in a namespace, and the only solution we have for that is to use a
class.
Its a truism that anything you can do with a closure, you can do with a
class (or vise versa) so I dare say there are alternative designs which
avoids closures altogether but we don't know the full requirements here
and its hard to judge from the outside on why Marko picked the design he
has and whether its a good idea. It could be a case of "ooh, closures are
a shiny new hammer, this problem must be a nail!" but let's give him the
benefit of the doubt and assume he has good reasons, not just reasons.
--
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson
--
https://mail.python.org/mailman/listinfo/python-list
