Path: csiph.com!usenet.pasdenom.info!gegeweb.org!de-l.enfer-du-nord.net!feeder1.enfer-du-nord.net!feeds.phibee-telecom.net!newsfeed.xs4all.nl!newsfeed4.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <kmj9mq$2la$1@ger.gmane.org>
References: <518a123c$0$11094$c3e8da3@news.astraweb.com> <Z1Eit.289$oB7.283@newsfe02.iad> <518b32ef$0$11120$c3e8da3@news.astraweb.com> <roy-8428A6.09074209052013@news.panix.com> <518be931$0$29997$c3e8da3$5496439d@news.astraweb.com> <mailman.1501.1368124461.3114.python-list@python.org> <518c5bbc$0$29997$c3e8da3$5496439d@news.astraweb.com> <roy-6D8B98.23095509052013@news.panix.com> <518c7f8e$0$29997$c3e8da3$5496439d@news.astraweb.com> <Hm0jt.6$I26.5@newsfe26.iad> <518cd360$0$29997$c3e8da3$5496439d@news.astraweb.com> <kmiojk$12i$1@ger.gmane.org> <kmj9mq$2la$1@ger.gmane.org>
Date: Sat, 11 May 2013 03:24:59 +1000
Subject: Re: object.enable() anti-pattern
From: Chris Angelico <rosuav@gmail.com>
To: python-list@python.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.1543.1368206709.3114.python-list@python.org>
Lines: 61
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:45118

On Sat, May 11, 2013 at 1:44 AM, Serhiy Storchaka <storchaka@gmail.com> wro=
te:
> 10.05.13 15:19, Robert Kern =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=B2(=
=D0=BB=D0=B0):
>
>> I'd be curious to see in-the-wild instances of the anti-pattern that you
>> are talking about, then.
>
>
> Many (if not most) GUI frameworks use this pattern.
>
>     button =3D Button("text")
>     button.setForegroundColor(...)
>     button.setBackgoundColor(...)
>     button.setFont(...)
>     button.setRelief(...)
>     button.setBorder(...)
>     button.setWidth(...)
>     button.setAction(...)
>     button.setMouseListener(...)
>     button.place(...)

The button really exists, though. You could merge the creation and
placement (or in the case of a window/dialog, the creation and
showing), but it's often useful to not. However, in the specific case
you have there, there's an alternative: a mapping of attributes and
values passed to the constructor, and then you could pass the
constructed object directly to a place(). That would let you, if you
wished, effectively construct a Button with a parent right there,
which makes reasonable sense.

> Another example is running a subprocess in Unix-like systems.
>
>     fork()
>     open/close file descriptors, set limits, etc
>     exec*()

Hrm. Not really a corresponding example. After you fork, you have two
actual processes. Following up with an exec is only one of the
possible options; I've done code that forks and execs, and code that
forks and keeps running, and neither of them feels "wrong" in any way.
There IS a function that's similar to what you're saying, and that's
vfork:

"""
(From POSIX.1) The vfork() function has the same effect as fork(2),
except that the behavior is undefined if the process created by
vfork() either modifies any data other than a variable of type pid_t
used to store the return value from vfork(), or returns from the
function in which vfork() was called, or calls any other function
before successfully calling _exit(2) or one of the exec(3) family of
functions.
"""

It's deprecated because it's so fragile (and because regular fork()
isn't that much less efficient now; AIUI, vfork was meant to be a
lightweight fork). I would say that the deprecation of vfork in favour
of fork is a strong indication that the object.enable() anti-pattern
can come up in kernel APIs too, and isn't liked there either.

ChrisA