Path: csiph.com!news.mixmin.net!feeds.phibee-telecom.net!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!nzpost1.xs4all.net!not-for-mail
MIME-Version: 1.0
In-Reply-To: <55f1c85d$0$1638$c3e8da3$5496439d@news.astraweb.com>
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> <mailman.281.1441825163.8327.python-list@python.org> <55f1a8df$0$1660$c3e8da3$5496439d@news.astraweb.com> <mailman.323.1441902714.8327.python-list@python.org> <55f1c85d$0$1638$c3e8da3$5496439d@news.astraweb.com>
Date: Fri, 11 Sep 2015 04:33:42 +1000
Subject: Re: Python handles globals badly.
From: Chris Angelico <rosuav@gmail.com>
Cc: "python-list@python.org" <python-list@python.org>
Content-Type: text/plain; charset=UTF-8
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.330.1441910026.8327.python-list@python.org>
Lines: 68
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:96283

On Fri, Sep 11, 2015 at 4:13 AM, Steven D'Aprano <steve@pearwood.info> wrote:
> Sometimes they might be. But in general, I think it is meaningless to expect
> a imperative command to have a return result. The whole point of an
> imperative command is that it operates by side-effect.
>
> For example, what would `del x` return if it were an expression instead of a
> statement? I can think of two reasonable alternatives, but both feel a bit
> wrong to me.
>
> (1) Return True if x was successfully unbound, False if it wasn't. Except
> that raising an exception seems more Pythonic, in which case returning True
> seems redundant. It will *always* return True, unless there's an exception.
> So why bother? We only bother because there's no way to *not* return a
> result if "everything is an expression".
>
> (2) Return None, like functions do by default. But again, it only returns
> None, not because None is a meaningful thing to return, but because we
> don't actually have a way to say "it doesn't return anything".

Yes, or: (3) Return the old value that x contained, the way dict.pop()
does. That makes it a "destructive retrieval" rather than simply a
destruction operation.

> Or os.abort. The docs for that say:
>
> Help on built-in function abort in module posix:
>
> abort(...)
>     abort() -> does not return!
>
>     Abort the interpreter immediately.  This 'dumps core' or otherwise fails
>     in the hardest way possible on the hosting operating system.
>
>
> So, what would os.abort() return, if everything is an expression?

Since this is in the os module, and is thus a thin wrapper around
lower-level operations, I could imagine it returning an error code
(the way the C-level exec functions do - if they succeed, they don't
return, but if they fail, they return an error number); in Python,
it'd be best to have it either abort the process (and thus not
return), or raise an exception (and thus not return).

But abort functions are a rarity. It's not a problem to have a rule
"all functions must return something" (as Python does), and then have
functions that never actually use the normal return path:

def raise_(exc): raise exc
raise_stopiteration = iter([]).__next__
raise_typeerror = lambda: ""()

Calling one of these functions is *syntactically* an expression, but
at run time, it'll never actually get as far as producing a value. If
it's at all possible for the operation to, based on run-time
information, NOT abort, then it absolutely has to be able to return.

> Because that's the definition of an expression in this context. An
> expression is evaluated to either return a result, or raise an exception.

I'd define it more simply: An expression always produces a result.
It's possible that, during the evaluation of an expression, an
exception will be raised; if that happens, evaluation stops. Doesn't
matter whether the expression itself caused that, or if an OS-level
signal did (eg triggering KeyboardInterrupt), or if the expression was
"yield 1" and an exception got thrown in. But yes, an expression is
something that generates a result; a statement isn't.

ChrisA