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 5 of 5 — ← Prev page 1 2 3 4 [5]

#96260

On 09/10/2015 01:27 AM, Antoon Pardon wrote:
> Op 09-09-15 om 19:55 schreef Steven D'Aprano:
>> 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?
> 
> What is wrong with that?

Makes for a common error of putting an assignment in a conditional
expression like:

if (a=4) this_is_always_true();

GCC will give you a warning over that these days.  But many C
programmers still adopt a notation of

if (4 == a) do_something();

to protect them if they accidentally leave out one =.  If assignment was
not an expression, then the compiler would properly error out every time
you used a solitary = in the conditional of an if statement.

Python strikes a good compromise.  You can chain = in an assignment
statement, but you can't use them in a conditional expression.

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

#96329

Op 10-09-15 om 16:21 schreef Michael Torrie:
> On 09/10/2015 01:27 AM, Antoon Pardon wrote:
>> Op 09-09-15 om 19:55 schreef Steven D'Aprano:
>>> 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?
>> What is wrong with that?
> Makes for a common error of putting an assignment in a conditional
> expression like:
>
> if (a=4) this_is_always_true();

No it doesn't. You confuse a semantic characteristic with the
specifix syntax that was chosen to express it in C.

Should C have chosen '<-' as token for assignment, that error
would have been far less common.

The error is also facilitated because C doesn't have booleans
and so everything can be used as one. If C would have had
proper booleans and only allowed those as conditions in if
and while statements, most of those errors would have been
caught too, because the expression a=4 wouldn't produce a
boolean.

> GCC will give you a warning over that these days.  But many C
> programmers still adopt a notation of
>
> if (4 == a) do_something();
>
> to protect them if they accidentally leave out one =.  If assignment was
> not an expression, then the compiler would properly error out every time
> you used a solitary = in the conditional of an if statement.

A language can provide this kind of protection and still allow
assignment as an expression. A lousy syntactical choice, doesn't
invalidate a particular choice in semantics.

> Python strikes a good compromise.  You can chain = in an assignment
> statement, but you can't use them in a conditional expression.

Python could have chosen other options, like a different assignment
token, like providing a proper boolean type and expection such a type
in a condition context. It could reverse the assignment so that you
would have to write: expression = var, so that if someone accidently
writes if var = expression instead of if var == expression, that would
have been caught. It could combine some of these options.

Now you possibly don't like these possibilities, but they show there
are multiple syntactical possibilities that all allow for assignment
as expressions, and that are less vulnerable than C for a specific
kind of error.

-- 
Antoon Pardon

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

#96388

On Fri, 11 Sep 2015 05:28 pm, Antoon Pardon wrote:

> Should C have chosen '<-' as token for assignment, that error
> would have been far less common.
> 
> The error is also facilitated because C doesn't have booleans
> and so everything can be used as one. If C would have had
> proper booleans 
[...]


In other words, "If C were some other language, then assignment as an
expression would be fine."

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.

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.

There's an argument to be made that, clean or not, assignment as an
expression is useful. So be it -- other languages do that. I personally
find it more confusing and annoying than useful when I come across it, but
YMMV.



-- 
Steven

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

#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

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

#96652

On Mon, 14 Sep 2015 06:30 pm, Antoon Pardon wrote:

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

Python is a remarkably clean and consistent language. There's only one kind
of value (the object -- everything is an object, even classes are objects).
The syntax isn't full of special cases. For example, there's nothing like
this horror from Ruby:

#!/usr/bin/ruby
def a(x=4)
    x+2
end

b = 1
print "a + b => ", (a + b), "\n"
print "a+b   => ", (a+b), "\n"
print "a+ b  => ", (a+ b), "\n"
print "a +b  => ", (a +b), "\n"


which prints:

7
7
7
3

This is not a bug in the language (well, yes it is, it's a design bug), but
it is a consequence of the syntax.

Python has nothing like this. Python's syntax is quite clean and consistent.


[...]
> 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.

Sure, I already said that some commands might return a value.

But assignment? Assignment is a pure command. There's nothing to return.
Having `x = 23` return 23 is, well, weird. If we start from the premise
that a return result is generated from a *calculation* or a *query*, we
have to ask what is being calculated or asked? 

I'm not quite willing to say that assignment-as-expression is an error,
because I acknowledge that it could be useful in some places. But it seems
bolted on and arbitrary, like having del return the name you just unbound:

assert (del x) == 'x'

And one other reason why I dislike it: it makes for a verbose and messy
interactive experience. Take Ruby:

irb(main):001:0> a = 23
=> 23


I don't need to see 23 printed, because I already know what the value is, so
that takes two lines where one would do. (On the rare case I did want to
see the value of something I had just assigned to, I could just print the
expression.)


-- 
Steven

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

#96653

On Wed, 16 Sep 2015 11:13 am, Steven D'Aprano wrote:

> Python is a remarkably clean and consistent language. There's only one
> kind of value (the object -- everything is an object, even classes are
> objects). The syntax isn't full of special cases. For example, there's
> nothing like this horror from Ruby:
> 
> #!/usr/bin/ruby
> def a(x=4)
>     x+2
> end
> 
> b = 1
> print "a + b => ", (a + b), "\n"
> print "a+b   => ", (a+b), "\n"
> print "a+ b  => ", (a+ b), "\n"
> print "a +b  => ", (a +b), "\n"
> 
> 
> which prints:
> 
> 7
> 7
> 7
> 3


Of course it doesn't. It prints:

a + b => 7
a+b   => 7
a+ b  => 7
a +b  => 3


Sorry about that.



-- 
Steven

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

#96655

On Wed, Sep 16, 2015 at 11:20 AM, Steven D'Aprano <steve@pearwood.info> wrote:
> On Wed, 16 Sep 2015 11:13 am, Steven D'Aprano wrote:
>
>> Python is a remarkably clean and consistent language. There's only one
>> kind of value (the object -- everything is an object, even classes are
>> objects). The syntax isn't full of special cases. For example, there's
>> nothing like this horror from Ruby:
>>
>> #!/usr/bin/ruby
>> def a(x=4)
>>     x+2
>> end
>>
>> b = 1
>> print "a + b => ", (a + b), "\n"
>> print "a+b   => ", (a+b), "\n"
>> print "a+ b  => ", (a+ b), "\n"
>> print "a +b  => ", (a +b), "\n"
>>
>>
>> which prints:
>>
>> 7
>> 7
>> 7
>> 3
>
>
> Of course it doesn't. It prints:
>
> a + b => 7
> a+b   => 7
> a+ b  => 7
> a +b  => 3
>
>
> Sorry about that.

I'm not a Rubyist, but my reading of this is that the last one is
calling a with +b as its argument, where all the others are calling a
with no argument, and then using the result in an expression. ISTM the
problem here is omitting the parentheses on a function call.

ChrisA

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

#96654

Steven D'Aprano <steve@pearwood.info> writes:
> I don't need to see 23 printed, because I already know what the value is, so
> that takes two lines where one would do. (On the rare case I did want to
> see the value of something I had just assigned to, I could just print the
> expression.)

Of course, you could just as well say that you _never_ need to see
anything printed unless you ask for it. The first time I used the REPL I
was irritated by the fact that None wasn't printed. The reason that None
isn't printed is, of course, because Python has no distinction between a
function that returns None as a value and a function that doesn't return
a value.

The alternative is to make assignments special within the REPL, or even
turn it into something that looks less like a REPL and more like the
variable/expression list that some IDE debuggers have.

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

#96666

Op 16-09-15 om 03:13 schreef Steven D'Aprano:
> On Mon, 14 Sep 2015 06:30 pm, Antoon Pardon wrote:
>
>> 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.
> Python is a remarkably clean and consistent language.

Which is beside the point. Python may generally be a remarkable clean
and consistent language, we were not discussing the language in general
but a specific aspect. Arguing against C because it doesn't makes a
clear seperation between questions and actions (because the assignment
is an expression) while python doesn't either (but in other places) strikes
me as disingineous.
 

>> 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.
> Sure, I already said that some commands might return a value.
>
> But assignment? Assignment is a pure command. There's nothing to return.
> Having `x = 23` return 23 is, well, weird. If we start from the premise
> that a return result is generated from a *calculation* or a *query*, we
> have to ask what is being calculated or asked?

You are stating your opinion as fact. Suppose I write the following class

class SetGet:
    def __init__(self, value):
        self.val = value

    def get(self):
        return self.val

    def set(self, value):
        self.val = value
        return value

So now I can write the following

index = SetGet(0)
while index.set(index.get() + 1) < 10:
  do_what_ever


So how would you answer your question as to what is calculated or asked
in the while condition here? The answer would be similar if we had just
allowed an assignment in the condition.

> And one other reason why I dislike it: it makes for a verbose and messy
> interactive experience. Take Ruby:

We are not talking about likes and dislikes. This discussion started
by you stating the the assignment as an expression in C was a design
flaw in the language. I can understand people preferring the assignment
not to be an operator. But when people start suggesting that assignment
as an operator is some kind of design flaw, which they use to criticise
a specific language, personal likes and dislikes are not important.

-- 
Antoon Pardon

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

#96339

On Fri, Sep 11, 2015, at 03:28, Antoon Pardon wrote:
> The error is also facilitated because C doesn't have booleans
> and so everything can be used as one.

Python does have booleans and everything can be used as one - the
logical conclusion is that being able to use everything as a boolean is
a positive feature that has nothing to do with lacking a "proper"
boolean type.

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

#96154

Mario Figueiredo <marfig@gmx.com> writes:

> Note:
> 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.

I can think of numerous widely-adpoted languages that disprove that
assertion, by nevertheless being poorly-designed languages that are
loathed by the vast majority of programmers who use them.

On the other hand, I think there is merit in an argument that runs the
other way: the quality of languages that a community adopts are
predictive of the quality of programs that community will produce.

-- 
 \      “It's up to the masses to distribute [music] however they want |
  `\    … The laws don't matter at that point. People sharing music in |
_o__)        their bedrooms is the new radio.” —Neil Young, 2008-05-06 |
Ben Finney

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

#96155

On Wed, Sep 9, 2015 at 11:26 AM, Ben Finney <ben+python@benfinney.id.au> wrote:
> On the other hand, I think there is merit in an argument that runs the
> other way: the quality of languages that a community adopts are
> predictive of the quality of programs that community will produce.

Broadly, yes. But regardless of its flaws, a language can be used
because of a unique position; for instance, JavaScript/ECMAScript is
going to continue to be the primary language of client-side web
browser scripting for a long time, unless the major browsers all start
supporting a new language (and until they all do, the benefit to one
of them is low). ECMAScript isn't an abysmal language by any means,
but it certainly has detectable flaws that come up fairly
consistently. (Easy example: Find any fill-out form that says "Maximum
X characters" and has a little counter that ticks down as you type.
Now key in some astral characters. The odds are fairly good that
they'll decrement the counter by 2 each.) If Apple declares that the
iPhone 9 will be programmed exclusively in Even Swiftier, then it
won't matter how terrible a language it is, people who want to say
"Our app works on the iPhone 9" will write it in Even Swiftier. That's
how PHP got to its position of being the default web scripting
language for so many people - if you got yourself some cheap hosting,
you could confidently expect PHP support, but until relatively
recently, you couldn't depend on Ruby or Python (and certainly
couldn't install your own); which, in turn, means that anyone who's
building something for other people to deploy (a wiki, a forum, a
blogging system, etc) will write it in PHP. And in all of these cases,
a competent programmer can turn out good quality code.

But if you take the average of all PHP programs, it'll tend toward a
level that much better follows your estimate. A poorer language will
generally have an overall poorer codebase.

ChrisA

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

#96156

On 09-09-2015 02:26, Ben Finney wrote:
> Mario Figueiredo <marfig@gmx.com> writes:
>
>> Note:
>> 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.
>
> I can think of numerous widely-adpoted languages that disprove that
> assertion, by nevertheless being poorly-designed languages that are
> loathed by the vast majority of programmers who use them.
>
> On the other hand, I think there is merit in an argument that runs the
> other way: the quality of languages that a community adopts are
> predictive of the quality of programs that community will produce.
>

I'll have to agree to an extent. And you did remind me of PHP. So 
there's that.

But in a way PHP served an important purpose in its time. Despite its 
flaws, it was once an important language that helped solve programming 
problems. And for that it served the purpose. Many of us went through it 
for the lack of a better fast-and-dirty alternative to server-side 
scripting. I remember others, like Cold Fusion or ASP. (Can't recall 
exactly why Cold Fusion didn't experience a wider support. But, truth be 
told I barely touched it).

In any case, it stands that, unless a programming language is so ruined 
by bad design choices it is unusable, there is some kind of merit to its 
ability to solve computational problems. And Lua, Java, Python, C++, C, 
let me stop naming some popular or mildly popular languages, aren't 
nowhere close to being in that game. They are superior choices, despite 
our personal dislikes.

I can't stand Java. I just don't think calling it a mistake. It's worth 
has been proven by its level of adoption and by the usable software that 
has been made with it. Javascript/ECMAScript is criticized by so many 
and yet there's no denying of its importance. Even today we struggle to 
find a better alternative to client-side scripting. Python is criticized 
by so many. And yet I don't think calling on Python developers as an 
inferior breed of programmers.

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

#96157

On Wed, Sep 9, 2015 at 12:43 PM, Mario Figueiredo <marfig@gmx.com> wrote:
> I can't stand Java. I just don't think calling it a mistake. It's worth has
> been proven by its level of adoption and by the usable software that has
> been made with it. Javascript/ECMAScript is criticized by so many and yet
> there's no denying of its importance. Even today we struggle to find a
> better alternative to client-side scripting.

Yeah, the reason for that is simple: anything else adds (sometimes
massive) overhead. Would you suggest creating a client/server
architecture, a RESTful API, and a triple-redundant HTTPS+SSL+Blowfish
security system, to enumerate files on your hard drive? No, you'd just
use ls(1). In the same way, there's not a lot of point downloading
megs and megs of PyPyJS engine before running a single line of code,
when you could skip that and just write in JS. Before Python can be "a
better alternative", it has to overcome this massive hump.

If Python 3.x were as well supported by web browsers as ECMAScript 5.x
is, I think we'd see a dramatic shift in usage. But it ain't, so we
won't.

ChrisA

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

#96162

Mario Figueiredo <marfig@gmx.com> writes:

> On 09-09-2015 02:26, Ben Finney wrote:
> > Mario Figueiredo <marfig@gmx.com> writes:
> >
> >> 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.
> >
> > I can think of numerous widely-adpoted languages that disprove that
> > assertion, by nevertheless being poorly-designed languages that are
> > loathed by the vast majority of programmers who use them.
>
> I'll have to agree to an extent. And you did remind me of PHP. So
> there's that.
>
> But in a way PHP served an important purpose in its time.

Important, yes.

> In any case, it stands that, unless a programming language is so
> ruined by bad design choices it is unusable, there is some kind of
> merit to its ability to solve computational problems.

That's a *very much* lower bar than your earlier claim I responded to:
that “[widespread] adoption is the sign of a respected and well designed
language”.

> I can't stand Java. I just don't think calling it a mistake. It's
> worth has been proven by its level of adoption and by the usable
> software that has been made with it. Javascript/ECMAScript is
> criticized by so many and yet there's no denying of its importance.

You're making the case for importance, and capability to implement
programs that solve problems.

Maybe it's true, but it's irrelevant to the earlier point. It is quite
separate from the language being well designed, and it is quite separate
from the language being respectable. Many languages — some of which
you've named — are poorly-designed, are not deserving of respect,
despite being widely-adopted.

> Even today we struggle to find a better alternative to client-side
> scripting. Python is criticized by so many. And yet I don't think
> calling on Python developers as an inferior breed of programmers.

Glad to know that :-)

-- 
 \         “I have the simplest tastes. I am always satisfied with the |
  `\                                               best.” —Oscar Wilde |
_o__)                                                                  |
Ben Finney

[toc] | [prev] | [standalone]

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

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

csiph-web