Path: csiph.com!eternal-september.org!feeder.eternal-september.org!feeds.phibee-telecom.net!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!nzpost1.xs4all.net!not-for-mail
Return-Path: <antoon.pardon@rece.vub.ac.be>
X-Original-To: python-list@python.org
Delivered-To: python-list@mail.python.org
X-Spam-Status: OK 0.045
X-Spam-Evidence: '*H*': 0.91; '*S*': 0.00; 'subject:Python': 0.05; 'model,': 0.05; 'received:134': 0.05; 'assignment': 0.07; 'effect.': 0.09; 'functional.': 0.09; 'way:': 0.09; 'python': 0.10; '"move': 0.16; 'assignments.': 0.16; 'received:ac.be': 0.16; 'sorts': 0.16; 'commands,': 0.22; 'context.': 0.22; 'logical': 0.22; 'suppose': 0.22; 'programming': 0.22; 'header:In-Reply- To:1': 0.24; 'header:User-Agent:1': 0.26; "doesn't": 0.26; 'error': 0.27; 'errors.': 0.27; 'fine': 0.28; 'always,': 0.29; 'received:be': 0.30; 'avoiding': 0.33; 'steven': 0.33; 'fail': 0.35; 'requiring': 0.35; 'something': 0.35; "isn't": 0.35; 'but': 0.36; 'there': 0.36; 'to:addr:python-list': 0.36; 'subject:: ': 0.37; 'two': 0.37; 'thought': 0.37; 'things': 0.38; 'green': 0.38; 'sure': 0.39; 'to:addr:python.org': 0.40; 'some': 0.40; 'questions': 0.40; 'side': 0.62; 'necessarily': 0.63; 'within': 0.64; 'believe': 0.66; 'talking': 0.67; 'afaics': 0.84; 'answer,': 0.84; 'answer:': 0.84; 'aspect.': 0.84; 'beats': 0.84; 'commands.': 0.84; "d'aprano:": 0.84; 'pardon': 0.84; 'schreef': 0.84; 'robot': 0.91
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AisGACWF9lWGuA9G/2dsb2JhbABdhDsBg07CEAKBegEBAQEBAYUvAQEDASNVBgsLGgIFFgsCAgkDAgECAUUTCAKIIgi2Do9QhCYBAQgCIIEihVGDd4EGhRQXglKBQwEElVeMfohtkhFjghEcgVaLbAEBAQ
Date: Mon, 14 Sep 2015 10:30:18 +0200
From: Antoon Pardon <antoon.pardon@rece.vub.ac.be>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Icedove/31.8.0
MIME-Version: 1.0
To: python-list@python.org
Subject: Re: Python handles globals badly.
References: <c3363$547e74fe$5419aafe$24179@news.ziggo.nl>	<86fa425b-d660-45ba-b0f7-3beebdec8e14@googlegroups.com>	<CALwzid=sokeEcPA17yP=Npscg4VSJ6AaF_AMn13ypCr-BtVgwA@mail.gmail.com>	<CAK_ErkjJ8ZYhtAoOC0p-DRpd5JQfb6aGWgU2T6uW5ZLtxjY2Mg@mail.gmail.com>	<55EE9EEC.1060907@rece.vub.ac.be>	<CAK_ErkgQPBxSc+zs7c2tGpGgQQ7s_SsAyJFB6qwcvJg68B9g0w@mail.gmail.com>	<55EEDD37.5090602@gmx.com> <CAK_ErkjdWXG7aQ=Q23tq-ZVuyX_etdrC939WtCAPkeu2_5SZ8A@mail.gmail.com> <mailman.243.1441760967.8327.python-list@python.org> <55f072aa$0$1669$c3e8da3$5496439d@news.astraweb.com> <55F130CE.5060203@rece.vub.ac.be> <55F191CD.8040901@gmail.com> <mailman.361.1441957016.8327.python-list@python.org> <55f3a08d$0$1674$c3e8da3$5496439d@news.astraweb.com>
In-Reply-To: <55f3a08d$0$1674$c3e8da3$5496439d@news.astraweb.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-BeenThere: python-list@python.org
X-Mailman-Version: 2.1.20+
Precedence: list
List-Id: General discussion list for the Python programming language <python-list.python.org>
List-Unsubscribe: <https://mail.python.org/mailman/options/python-list>, <mailto:python-list-request@python.org?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/python-list/>
List-Post: <mailto:python-list@python.org>
List-Help: <mailto:python-list-request@python.org?subject=help>
List-Subscribe: <https://mail.python.org/mailman/listinfo/python-list>, <mailto:python-list-request@python.org?subject=subscribe>
Newsgroups: comp.lang.python
Message-ID: <mailman.526.1442219653.8327.python-list@python.org>
Lines: 30
NNTP-Posting-Host: 2001:888:2000:d::a6
X-Trace: 1442219653 news.xs4all.nl 23862 [2001:888:2000:d::a6]:55028
X-Complaints-To: abuse@xs4all.nl
Xref: csiph.com comp.lang.python:96561

Op 12-09-15 om 05:48 schreef Steven D'Aprano:
> I believe I already acknowledged that assignment-as-expression was fine if
> it avoided the = versus == error, from the perspective of avoiding errors.
> But from the perspective of a clean and logical programming model, perhaps
> not so much. Assignment is imperative, not functional, and requiring it to
> return a result is somewhat unclean.

I thought practicallity beats purity? AFAICS python doesn't use such a clean
and logical programming model and it isn't given much critique over it.
So I don't think it is fair to critique assignment as an expression because
of this aspect.

> Look at it this way: suppose you had a robot servant that always, without
> fail or misunderstanding, did what you instructed. There are broadly two
> sorts of things that you can give as instructions: questions, and commands.
> Questions always require an answer: "What's the length of this list?" is
> functional. Commands are imperative, not functional, and don't necessarily
> require an answer: "Move the small red pyramid onto the large green cube."
> Some commands arguable might require an answer, but arguable they are
> better served by an out-of-band error condition (an exception). *Requiring*
> all commands to give an answer is silly, given that the robot servant is
> infallible.

But we are not talking about all commands, we are just talking about assignments.
Sure an assignment has a side effect. But so has ls.pop(). So something having
a side-effect and a value is not unheard of even within a python context.

-- 
Antoon Pardon