Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #95887 > unrolled thread

Re: Python handles globals badly.

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Python handles globals badly. tdev@freenet.de - 2015-09-02 11:47 -0700
    Re: Python handles globals badly. tdev@freenet.de - 2015-09-02 12:32 -0700
    Re: Python handles globals badly. Emile van Sebille <emile@fenx.com> - 2015-09-02 12:34 -0700
    Re: Python handles globals badly. Ian Kelly <ian.g.kelly@gmail.com> - 2015-09-02 13:38 -0600
    Re: Python handles globals badly. "Sven R. Kunze" <srkunze@mail.de> - 2015-09-02 22:08 +0200
    Re: Python handles globals badly. MRAB <python@mrabarnett.plus.com> - 2015-09-02 21:22 +0100
    Re: Python handles globals badly. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-02 22:19 +0100
    Re: Python handles globals badly. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-03 02:16 +0100
    Re: Python handles globals badly. Steven D'Aprano <steve@pearwood.info> - 2015-09-03 11:49 +1000
    Re: Python handles globals badly. Vladimir Ignatov <kmisoft@gmail.com> - 2015-09-04 20:05 -0400
    Re: Python handles globals badly. Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-09-08 10:40 +0200
    Re: Python handles globals badly. Vladimir Ignatov <kmisoft@gmail.com> - 2015-09-08 07:55 -0400
    Re: Python handles globals badly. Akira Li <4kir4.1i@gmail.com> - 2015-09-08 15:35 +0300
    Re: Python handles globals badly. Mario Figueiredo <marfig@gmx.com> - 2015-09-08 14:05 +0100
    Re: Python handles globals badly. Ian Kelly <ian.g.kelly@gmail.com> - 2015-09-08 08:31 -0600
      Re: Python handles globals badly. Steven D'Aprano <steve@pearwood.info> - 2015-09-09 01:56 +1000
        Re: Python handles globals badly. Michael Torrie <torriem@gmail.com> - 2015-09-08 17:55 -0600
          Re: Python handles globals badly. Steven D'Aprano <steve@pearwood.info> - 2015-09-09 13:23 +1000
            Re: Python handles globals badly. Christian Gollwitzer <auriocus@gmx.de> - 2015-09-09 18:09 +0200
              Re: Python handles globals badly. Steven D'Aprano <steve@pearwood.info> - 2015-09-10 03:22 +1000
                Re: Python handles globals badly. Chris Angelico <rosuav@gmail.com> - 2015-09-10 03:27 +1000
                Re: Python handles globals badly. William Ray Wing <wrw@mac.com> - 2015-09-09 13:59 -0400
                Re: Python handles globals badly. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-09 20:20 +0100
                  Re: Python handles globals badly. Peter Pearson <pkpearson@nowhere.invalid> - 2015-09-10 20:49 +0000
                Re: Python handles globals badly. MRAB <python@mrabarnett.plus.com> - 2015-09-09 20:22 +0100
                Re: Python handles globals badly. Chris Angelico <rosuav@gmail.com> - 2015-09-10 05:27 +1000
        Re: Python handles globals badly. Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-09-09 12:42 +0200
        Re: Python handles globals badly. Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-09-09 09:33 -0400
    Re: Python handles globals badly. random832@fastmail.us - 2015-09-08 12:13 -0400
    Re: Python handles globals badly. MRAB <python@mrabarnett.plus.com> - 2015-09-08 18:41 +0100
    Re: Python handles globals badly. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-08 23:41 +0100
    Re: Python handles globals badly. MRAB <python@mrabarnett.plus.com> - 2015-09-09 00:20 +0100
    Re: Python handles globals badly. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-09 00:32 +0100
    Re: Python handles globals badly. Random832 <random832@fastmail.com> - 2015-09-08 20:02 -0400
      Re: Python handles globals badly. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-09-11 10:23 +0200
    Re: Python handles globals badly. Mario Figueiredo <marfig@gmx.com> - 2015-09-09 02:09 +0100
      Re: Python handles globals badly. Steven D'Aprano <steve@pearwood.info> - 2015-09-10 03:55 +1000
        Re: Python handles globals badly. Laura Creighton <lac@openend.se> - 2015-09-09 20:05 +0200
        Re: Python handles globals badly. Emile van Sebille <emile@fenx.com> - 2015-09-09 11:23 -0700
          Re: Python handles globals badly. Steven D'Aprano <steve@pearwood.info> - 2015-09-10 22:20 +1000
        Re: Python handles globals badly. "Sven R. Kunze" <srkunze@mail.de> - 2015-09-09 20:26 +0200
          Re: Python handles globals badly. Steven D'Aprano <steve@pearwood.info> - 2015-09-11 01:50 +1000
        Re: Python handles globals badly. random832@fastmail.us - 2015-09-09 14:59 -0400
          Re: Python handles globals badly. Steven D'Aprano <steve@pearwood.info> - 2015-09-11 01:59 +1000
            Re: Python handles globals badly. random832@fastmail.us - 2015-09-10 12:31 -0400
              Re: Python handles globals badly. Steven D'Aprano <steve@pearwood.info> - 2015-09-11 04:13 +1000
                Re: Python handles globals badly. Chris Angelico <rosuav@gmail.com> - 2015-09-11 04:33 +1000
                Re: Python handles globals badly. Jussi Piitulainen <harvesting@makes.email.invalid> - 2015-09-10 22:11 +0300
                Re: Python handles globals badly. random832@fastmail.us - 2015-09-10 16:30 -0400
            Re: Python handles globals badly. Chris Angelico <rosuav@gmail.com> - 2015-09-11 02:48 +1000
            Re: Python handles globals badly. alister <alister.nospam.ware@ntlworld.com> - 2015-09-10 19:56 +0000
            Re: Python handles globals badly. random832@fastmail.us - 2015-09-10 16:07 -0400
            Re: Python handles globals badly. Chris Angelico <rosuav@gmail.com> - 2015-09-11 11:35 +1000
            Re: Python handles globals badly. Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-09-11 12:19 +0200
              Re: Python handles globals badly. Marko Rauhamaa <marko@pacujo.net> - 2015-09-11 14:59 +0300
                Re: Python handles globals badly. Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-09-14 09:13 +0200
        Re: Python handles globals badly. Chris Angelico <rosuav@gmail.com> - 2015-09-10 05:00 +1000
        Re: Python handles globals badly. Laura Creighton <lac@openend.se> - 2015-09-09 21:14 +0200
        Re: Python handles globals badly. Chris Angelico <rosuav@gmail.com> - 2015-09-10 05:18 +1000
          Re: Python handles globals badly. Steven D'Aprano <steve@pearwood.info> - 2015-09-10 22:18 +1000
            Re: Python handles globals badly. jkn <jkn_gg@nicorp.f9.co.uk> - 2015-09-10 08:09 -0700
            Re: Python handles globals badly. rurpy@yahoo.com - 2015-09-10 12:04 -0700
              Re: Python handles globals badly. Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-09-10 20:33 -0400
              Re: Python handles globals badly. Gene Heskett <gheskett@wdtv.com> - 2015-09-10 22:19 -0400
              Re: Python handles globals badly. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-12 03:35 +0100
              Re: Python handles globals badly. Mario Figueiredo <marfig@gmx.com> - 2015-09-12 05:11 +0100
              Re: Python handles globals badly. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-12 05:38 +0100
              Re: Python handles globals badly. Mario Figueiredo <marfig@gmx.com> - 2015-09-12 16:52 +0100
              Re: Python handles globals badly. Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-09-12 12:24 -0400
              Re: Python handles globals badly. Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-09-12 12:29 -0400
              Re: Python handles globals badly. MRAB <python@mrabarnett.plus.com> - 2015-09-12 18:09 +0100
              Re: Python handles globals badly. Mario Figueiredo <marfig@gmx.com> - 2015-09-12 22:57 +0100
              Re: Python handles globals badly. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-12 23:05 +0100
              Re: Python handles globals badly. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-12 23:07 +0100
        Re: Python handles globals badly. "Sven R. Kunze" <srkunze@mail.de> - 2015-09-09 21:21 +0200
        Re: Python handles globals badly. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-09 20:24 +0100
        Re: Python handles globals badly. Mario Figueiredo <marfig@gmx.com> - 2015-09-09 20:57 +0100
        Re: Python handles globals badly. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-09 21:15 +0100
        Re: Python handles globals badly. Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-09-10 09:27 +0200
          Re: Python handles globals badly. Marko Rauhamaa <marko@pacujo.net> - 2015-09-10 10:49 +0300
        Re: Python handles globals badly. Michael Torrie <torriem@gmail.com> - 2015-09-10 08:21 -0600
        Re: Python handles globals badly. Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-09-11 09:28 +0200
          Re: Python handles globals badly. Steven D'Aprano <steve@pearwood.info> - 2015-09-12 13:48 +1000
            Re: Python handles globals badly. Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-09-14 10:30 +0200
              Re: Python handles globals badly. Steven D'Aprano <steve@pearwood.info> - 2015-09-16 11:13 +1000
                Re: Python handles globals badly. Steven D'Aprano <steve@pearwood.info> - 2015-09-16 11:20 +1000
                  Re: Python handles globals badly. Chris Angelico <rosuav@gmail.com> - 2015-09-16 11:58 +1000
                Re: Python handles globals badly. Random832 <random832@fastmail.com> - 2015-09-15 21:54 -0400
                Re: Python handles globals badly. Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-09-16 10:51 +0200
        Re: Python handles globals badly. random832@fastmail.us - 2015-09-11 08:50 -0400
    Re: Python handles globals badly. Ben Finney <ben+python@benfinney.id.au> - 2015-09-09 11:26 +1000
    Re: Python handles globals badly. Chris Angelico <rosuav@gmail.com> - 2015-09-09 11:41 +1000
    Re: Python handles globals badly. Mario Figueiredo <marfig@gmx.com> - 2015-09-09 03:43 +0100
    Re: Python handles globals badly. Chris Angelico <rosuav@gmail.com> - 2015-09-09 13:03 +1000
    Re: Python handles globals badly. Ben Finney <ben+python@benfinney.id.au> - 2015-09-09 15:53 +1000

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

#96204

On 09.09.2015 19:55, Steven D'Aprano wrote:
> On Wed, 9 Sep 2015 11:09 am, Mario Figueiredo wrote:
>
>> You know, it is a pointless exercise to try and downplay programming
>> languages (any programming language) that has proven its worth by being
>> generally adopted by the programming community. Adoption is the sign of
>> a respected and well designed language.
> Counter-examples: PHP and C.
>
> Adoption of programming languages is driven by many things, technical
> excellence and careful design are not even in the top 10. Most of them are
> social in nature, particularly "what is everyone else using?". Network
> effects dominate: you could design the perfect language, but if nobody else
> uses it, nobody will use it.
Just to understand it the way you want it to be understood: what do you 
mean by "technical excellence"?
>
> Sometimes a language will actually gain a kind of technical excellence
> despite some really shitty design decisions -- but usually at great cost
> elsewhere. C is a good example of that. Due to lousy decisions made by the
> designers of C, it is a language really well suited for writing fast,
> incorrect code. Since programmers benefit from writing fast code, but
> rarely suffer from writing incorrect code (it's mostly users who suffer the
> consequences of security holes), we have ended up in the situation we live
> in now, where compilers compete to write faster and faster code that has
> less and less relation to what the programmer intended.
>
> (I wanted to link to the "Everything Is Broken" essay on The Medium, but the
> page appears to be gone. This makes me sad. BTW, what's the point of
> Google's cache when it just redirects to the original, missing, page?)
Do you mean https://medium.com/message/everything-is-broken-81e5f33a24e1 ?
> In fairness to the C creators, I'm sure that nobody back in the early
> seventies imagined that malware and security vulnerabilities would be as
> widespread as they have become. But still, the fundamental decisions made
> by C are lousy. Assignment is an expression? Lack of first-class arrays?
> The C pre-processor? They're pretty awful, but *nothing* in the entire
> history of computing, not even Intercal and the COMEFROM command, comes
> even close to the evil that is C "undefined behaviour".
>
> I believe that the computing industry may never recover from the harm done
> to it by the widespread use of C.
It'll take some time.

[toc] | [prev] | [next] | [standalone]

#96266

On Thu, 10 Sep 2015 04:26 am, Sven R. Kunze wrote:

> Just to understand it the way you want it to be understood: what do you
> mean by "technical excellence"?

That's one of those things that are difficult to define precisely. All I can
do is give some partial examples, and counter-examples.

Lisp embodies a form of mathematical elegance and simplicity that one might
call technical excellence. Forth does too, despite their completely
different syntax and computational model.

BASIC does not.

ML's type-checker displays technical excellence:

http://perl.plover.com/yak/typing/notes.html

Haskell, which inherits the same sort of type-checker, does too.

Inform 7's natural language syntax and inference engine displays technical
excellence. APL's mathematics syntax does not, as it doesn't even follow
the same rules that mathematicians expect. (APL, I'm lead to believe, is
evaluated purely from left-to-right -- or was it right to left? -- so that
1+2*3 gives 9 rather than 7 like mathematicians expect.)

Credit where credit is due: although I think that in the broader computing
ecosystem it does more harm than good, the efforts put into optimization by
C compilers show technical excellence. If there's a cycle that can be
shaved, good C compilers like gcc and clang will find it.

It's hard (impossible?) to think of a language that gets *everything* right,
because so much of that depends on subjective factors, but I think that
languages can display technical excellence in a particular subset of
features. It's not "all or nothing" -- a language can be excellent in one
area, and poor in another.


[...]
>> (I wanted to link to the "Everything Is Broken" essay on The Medium, but
>> the page appears to be gone. This makes me sad. BTW, what's the point of
>> Google's cache when it just redirects to the original, missing, page?)
>
> Do you mean https://medium.com/message/everything-is-broken-81e5f33a24e1 ?

Yes, that's the one, thanks.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#96206

On Wed, Sep 9, 2015, at 13:55, Steven D'Aprano wrote:
> In fairness to the C creators, I'm sure that nobody back in the early
> seventies imagined that malware and security vulnerabilities would be as
> widespread as they have become. But still, the fundamental decisions made
> by C are lousy. Assignment is an expression?

Whoa, hold on. The problem with C assignment isn't that it's an
expression, it's that it's spelled "=" and can be used in contexts where
one would normally do an equality comparison.

In some languages (Lisp/Scheme/etc come to mind), *everything* is an
expression. But assignment is spelled with, generally, some variant of
"set" [setq, set!, etc].

[toc] | [prev] | [next] | [standalone]

#96269

On Thu, 10 Sep 2015 04:59 am, random832@fastmail.us wrote:

> On Wed, Sep 9, 2015, at 13:55, Steven D'Aprano wrote:
>> In fairness to the C creators, I'm sure that nobody back in the early
>> seventies imagined that malware and security vulnerabilities would be as
>> widespread as they have become. But still, the fundamental decisions made
>> by C are lousy. Assignment is an expression?
> 
> Whoa, hold on. The problem with C assignment isn't that it's an
> expression, it's that it's spelled "=" and can be used in contexts where
> one would normally do an equality comparison.

Yes, that's what I'm referring to.

Although, I'm not sure that I agree with the idea that "everything is an
expression". I think that's a category mistake, like asking for the speed
of dark[1], or for a bucket of cold. Some things are functional by nature,
and other things are imperative; some may be both, but I don't think that
assignment is one. I think that assignment is imperative, not functional,
and forcing it to return a value is artificial.


> In some languages (Lisp/Scheme/etc come to mind), *everything* is an
> expression. But assignment is spelled with, generally, some variant of
> "set" [setq, set!, etc].

Yes, that at least avoids the possibility of mistaking = for == or similar.



[1] Obviously it's faster than light, since wherever the light arrives, it
finds the dark got there first.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#96271

On Thu, Sep 10, 2015, at 11:59, Steven D'Aprano wrote:
> Although, I'm not sure that I agree with the idea that "everything is an
> expression". I think that's a category mistake, like asking for the speed
> of dark[1], or for a bucket of cold. Some things are functional by
> nature,
> and other things are imperative; some may be both, but I don't think that
> assignment is one. I think that assignment is imperative, not functional,
> and forcing it to return a value is artificial.

Why shouldn't imperative things be expressions? Why should all
expressions return a value?

[toc] | [prev] | [next] | [standalone]

#96277

On Fri, 11 Sep 2015 02:31 am, random832@fastmail.us wrote:

> On Thu, Sep 10, 2015, at 11:59, Steven D'Aprano wrote:
>> Although, I'm not sure that I agree with the idea that "everything is an
>> expression". I think that's a category mistake, like asking for the speed
>> of dark[1], or for a bucket of cold. Some things are functional by
>> nature,
>> and other things are imperative; some may be both, but I don't think that
>> assignment is one. I think that assignment is imperative, not functional,
>> and forcing it to return a value is artificial.
> 
> Why shouldn't imperative things be expressions?

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".

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?

Obviously one can always find some arbitrary value for expressions to
return, in order to keep the invariant "all expressions return something".
But I dislike the arbitrariness of it. Some things aren't conceptually
functional expressions, they're imperative commands that (like Pascal
procedures, or Python statements) don't naturally have a return result.



> Why should all expressions return a value?

Because that's the definition of an expression in this context. An
expression is evaluated to either return a result, or raise an exception.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#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

[toc] | [prev] | [next] | [standalone]

#96291

Steven D'Aprano writes:

> 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?

But os.abort() *is* an expression. It's allowed where only an expression
is valid syntax.

[toc] | [prev] | [next] | [standalone]

#96302

On Thu, Sep 10, 2015, at 14:13, Steven D'Aprano wrote:
> Because that's the definition of an expression in this context. An
> expression is evaluated to either return a result, or raise an exception.

Nonsense. An expression is something allowed within a larger expression.
It's easy to imagine an expression allowing a subexpression that does
not return a result. For example, in non-tail positions of something
like C-comma/Lisp-progn.

Or, for example, if a C-style "for" loop was an expression, the
initializer and increment bits.

This is semantics, to some extent - you could just as well say an
expression may "return" a "result" that is a special non-value which
transforms into an error if it's allowed to escape into a context where
the value is needed (e.g. the argument to a function, a place a boolean
is expected, being assigned to a variable) - C (and other C-family
languages) has such a thing, Lisp does not.

[toc] | [prev] | [next] | [standalone]

#96272

On Fri, Sep 11, 2015 at 2:31 AM,  <random832@fastmail.us> wrote:
> On Thu, Sep 10, 2015, at 11:59, Steven D'Aprano wrote:
>> Although, I'm not sure that I agree with the idea that "everything is an
>> expression". I think that's a category mistake, like asking for the speed
>> of dark[1], or for a bucket of cold. Some things are functional by
>> nature,
>> and other things are imperative; some may be both, but I don't think that
>> assignment is one. I think that assignment is imperative, not functional,
>> and forcing it to return a value is artificial.
>
> Why shouldn't imperative things be expressions? Why should all
> expressions return a value?

I'm not sure what the point would be of having an expression that
doesn't return a value. The point of assignment-as-an-expression is
that you can do other things with the result:

while ((ch=getchar()) != EOF)

In Python, we have a couple of cases where that's done with the 'as' keyword:

with open(fn) as in_file:

except KeyError as e:

and there've been proposals now and then to have the same thing added
to if and while, which actually isn't hard:

while getchar() as ch:

but the trouble is that you can check for falsiness, but nothing else.
(In C, EOF is an integer outside the range 0..255, such that it's
distinct from any byte value. It's usually -1.) If assignment is an
expression, you can capture a value and keep going - something like
this:

stash = [None]
while (stash.__setitem__(0, getchar()) or stash[0]) != -1:
    ch = stash[0]

It's ugly, but it does work - because the setitem call is an
expression. However, for this to succeed, the expression MUST yield a
value. Otherwise it doesn't make sense, and the difference between
expression and statement is a purely technical/theoretical one. (In
this case, the value of the "assignment" expression is always None,
which is less useful than C's policy of returning the value itself;
but at least I know what it's going to be, so I can use the "or
stash[0]" notation.)

Having assignment be a statement (and therefore illegal in a loop
condition) makes sense. Having it be an expression that yields a
useful or predictable value makes sense. Having it be an expression,
but not returning a value, doesn't.

(I'm not going to get into the argument here about whether assignment
SHOULD be a statement or an expression. There are plenty of languages
to choose from, so you can have it both ways if you like.)

ChrisA

[toc] | [prev] | [next] | [standalone]

#96297

On Fri, 11 Sep 2015 01:59:27 +1000, Steven D'Aprano wrote:
> 
> Although, I'm not sure that I agree with the idea that "everything is an
> expression". I think that's a category mistake, like asking for the
> speed of dark[1], or for a bucket of cold. Some things are functional by
> nature, and other things are imperative; some may be both, but I don't
> think that assignment is one. I think that assignment is imperative, not
> functional, and forcing it to return a value is artificial.
> 
> 
> [1] Obviously it's faster than light, since wherever the light arrives,
> it finds the dark got there first.

Incorrect light is simply the absence of dark

https://astro.uni-bonn.de/~dfischer/dark_sucker_2.html

http://tristan.ethereal.net/humor/dark-suckers.html




-- 
Neutrinos have bad breadth.

[toc] | [prev] | [next] | [standalone]

#96298

On Thu, Sep 10, 2015, at 12:48, Chris Angelico wrote:
> Having assignment be a statement (and therefore illegal in a loop
> condition) makes sense. Having it be an expression that yields a
> useful or predictable value makes sense. Having it be an expression,
> but not returning a value, doesn't.

Why not? Having it not return a value (and thus be illegal in places
that expect a value), but be legal in places like C's comma operator or
Lisp's progn that do not use the value, would make logical sense. Your
while loop could be written as something like "while (ch = getchar();
ch): ..."

The main purpose of this would be to prevent you from using it where a
boolean is expected, which wouldn't be necessary if Python hadn't
repeated C's mistake of spelling it "=".

[toc] | [prev] | [next] | [standalone]

#96312

On Fri, Sep 11, 2015 at 6:07 AM,  <random832@fastmail.us> wrote:
> On Thu, Sep 10, 2015, at 12:48, Chris Angelico wrote:
>> Having assignment be a statement (and therefore illegal in a loop
>> condition) makes sense. Having it be an expression that yields a
>> useful or predictable value makes sense. Having it be an expression,
>> but not returning a value, doesn't.
>
> Why not? Having it not return a value (and thus be illegal in places
> that expect a value), but be legal in places like C's comma operator or
> Lisp's progn that do not use the value, would make logical sense. Your
> while loop could be written as something like "while (ch = getchar();
> ch): ..."
>
> The main purpose of this would be to prevent you from using it where a
> boolean is expected, which wouldn't be necessary if Python hadn't
> repeated C's mistake of spelling it "=".

I didn't say it doesn't make _technical_ sense to have an expression
without  value, but it doesn't make any _useful_ sense. In previous
posts I consciously avoided this wording, but I'm going to say it, and
clink my pun jar: There's no value in doing it that way.

In order to make this valueless expression useful, you have to first
have some sort of expression that consists of two subexpressions,
where one of them is ignored. (Like C's comma operator.) Why do it?
Why not simply have the expression yield a useful value - or else not
be an expression, such that you have two _statements_?

ChrisA

[toc] | [prev] | [next] | [standalone]

#96337

Op 10-09-15 om 18:48 schreef Chris Angelico:
> I'm not sure what the point would be of having an expression that
> doesn't return a value. The point of assignment-as-an-expression is
> that you can do other things with the result:
>
> while ((ch=getchar()) != EOF)
>
> In Python, we have a couple of cases where that's done with the 'as' keyword:
>
> with open(fn) as in_file:
>
> except KeyError as e:
>
> and there've been proposals now and then to have the same thing added
> to if and while, which actually isn't hard:
>
> while getchar() as ch:

I just don't get why people want to introduce special cases in python.
Why allow such a construct only in while and if? Why not just allow
it generally as an assignment expression?

Why not allow:

  while (f(x) as fx) > 5:
    proces(fx)

or

  if check(nextvalue() as new):
    treat(new)

One of the things I don't like about python is the limitation of the
slice syntax. I have been in situations where the natural thing to
do was write a method that takes a slice as a parameter and
have it called like: for key, value in Tree.items(lowkey:highkey).

But that doesn't work because slice notation is only allowed in
a subscription context.

It is kind of frustrating when you see something in the language
you think useful, to then notice the language doesn't allow you
to use in the context you need/want it.

At this moment I feel that introducing the "as v" possibily only
in while and if statements would mainly enlargen my frustration.

-- 
Antoon Pardon

[toc] | [prev] | [next] | [standalone]

#96338

Antoon Pardon <antoon.pardon@rece.vub.ac.be>:

> I just don't get why people want to introduce special cases in python.
> Why allow such a construct only in while and if? Why not just allow
> it generally as an assignment expression?
>
> Why not allow:
>
>   while (f(x) as fx) > 5:
>     proces(fx)
>
> or
>
>   if check(nextvalue() as new):
>     treat(new)

Hey, I know, I know!... Let's allow:

   while (fx = f(x)) > 5:
       process(fx)

   if check(new = nextvalue()):
       treat(new)

Seriously, though, I share your distaste of special cases, Antoon. Only
I don't like too much syntax (just look at Perl). There's nothing wrong
in:

   while True:
       fx = f(x)
       if fx <= 5:
           break
       process(fx)

   new = nextvalue()
   if check(new):
       treat(new)


Marko

[toc] | [prev] | [next] | [standalone]

#96551

Op 11-09-15 om 13:59 schreef Marko Rauhamaa:
> Antoon Pardon <antoon.pardon@rece.vub.ac.be>:
>
>> I just don't get why people want to introduce special cases in python.
>> Why allow such a construct only in while and if? Why not just allow
>> it generally as an assignment expression?
>>
>> Why not allow:
>>
>>   while (f(x) as fx) > 5:
>>     proces(fx)
>>
>> or
>>
>>   if check(nextvalue() as new):
>>     treat(new)
> Hey, I know, I know!... Let's allow:
>
>    while (fx = f(x)) > 5:
>        process(fx)
>
>    if check(new = nextvalue()):
>        treat(new)
>
> Seriously, though, I share your distaste of special cases, Antoon. Only
> I don't like too much syntax (just look at Perl).

This proposal would have as an effect less syntax. The 'as ...' syntax
already exists, but as special cases. Making 'as ...' a general assignment
operator would eliminated the special cases and collect them all in the
expression syntax. So less syntax.

>  There's nothing wrong
> in:
>
>    while True:
>        fx = f(x)
>        if fx <= 5:
>            break
>        process(fx)

There was also nothing wrong with:

  if b > c:
    a = 5
  else:
    a = 2

>    new = nextvalue()
>    if check(new):
>        treat(new)

Except that it would need an extra indentation level if
it was an elif.

-- 
Antoon Pardon

[toc] | [prev] | [next] | [standalone]

#96209

On Thu, Sep 10, 2015 at 4:26 AM, Sven R. Kunze <srkunze@mail.de> wrote:
>> Adoption of programming languages is driven by many things, technical
>> excellence and careful design are not even in the top 10. Most of them are
>> social in nature, particularly "what is everyone else using?". Network
>> effects dominate: you could design the perfect language, but if nobody
>> else
>> uses it, nobody will use it.
>
> Just to understand it the way you want it to be understood: what do you mean
> by "technical excellence"?

Suppose it's possible, somehow, to design the perfect language. (It
isn't, because the best language for a job depends on the job, but
suppose it for the nonce.) It is simultaneously more readable than
Python, more ugly than Perl, more functional than Haskell, and
compiles to lower level code than C does. The compiler's/interpreter's
internals are a bug-free demonstration of utter code beauty, and you
no longer have reason to use any other programming language, because
this one is the ultimate.

But nobody uses it except you.

Technical excellence it has a'plenty, but is it going to be on the job
postings? No. Is it going to be on people's resumes? No. When a
programmer pitches a proposal at his manager, will he mention your
language, which he's never heard of? No. When someone asks on Stack
Overflow "How do I...", will the answers recommend the use of your
language? No. It isn't going to be used, no matter how good it is, if
nobody knows about it. And if it isn't used, nobody will get to know
it. Until you start getting some usage, you won't get much usage.

That's what drives programming language adoption: existing usage. It's
self-perpetuating and proves little.

To get started, you need some other sort of kick. Maybe a high-profile
company uses your language. Maybe a hardware manufacturer mandates its
use. Maybe your development team has so many famous names that the
world has been watching with interest. But whatever it is, it has to
be something big or you won't get over that initial usage hump.

ChrisA

[toc] | [prev] | [next] | [standalone]

#96210

In a message of Thu, 10 Sep 2015 05:00:22 +1000, Chris Angelico writes:
>To get started, you need some other sort of kick.

Having Brian Kernighan write a really nice book about you, helps a lot.

Laura

[toc] | [prev] | [next] | [standalone]

#96211

On Thu, Sep 10, 2015 at 5:14 AM, Laura Creighton <lac@openend.se> wrote:
> In a message of Thu, 10 Sep 2015 05:00:22 +1000, Chris Angelico writes:
>>To get started, you need some other sort of kick.
>
> Having Brian Kernighan write a really nice book about you, helps a lot.

It kinda does. And of course, it also helps to have a time machine, so
you can launch your language when there are less languages around.
Today, you compete for attention with myriad languages that simply
didn't exist when C was introduced to an unsuspecting world.

ChrisA

[toc] | [prev] | [next] | [standalone]

#96256

On Thu, 10 Sep 2015 05:18 am, Chris Angelico wrote:

> On Thu, Sep 10, 2015 at 5:14 AM, Laura Creighton <lac@openend.se> wrote:
>> In a message of Thu, 10 Sep 2015 05:00:22 +1000, Chris Angelico writes:
>>>To get started, you need some other sort of kick.
>>
>> Having Brian Kernighan write a really nice book about you, helps a lot.
> 
> It kinda does. And of course, it also helps to have a time machine, so
> you can launch your language when there are less languages around.
> Today, you compete for attention with myriad languages that simply
> didn't exist when C was introduced to an unsuspecting world.

I don't think that's quite right. I think, if anything, there were more
languages in the 1970s than now, it's just that they tended to be
proprietary, maybe only running on a single vendor's machine. But even if
I'm mistaken, I think that there is near-universal agreement that the
single biggest factor in C's popularity and growth during the 1970s and 80s
is that it was tied so intimately to Unix, and Unix was taking over from
mainframes, VAX, etc.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

Back to top | Article view | comp.lang.python

csiph-web