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

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

Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?)

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: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Laura Creighton <lac@openend.se> - 2015-11-19 21:18 +0100
    Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Marko Rauhamaa <marko@pacujo.net> - 2015-11-19 22:57 +0200
      Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Laura Creighton <lac@openend.se> - 2015-11-19 23:41 +0100
        Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) BartC <bc@freeuk.com> - 2015-11-20 14:00 +0000
      Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Steven D'Aprano <steve@pearwood.info> - 2015-11-20 11:33 +1100
        Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-11-25 09:14 +0100
          Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Steven D'Aprano <steve@pearwood.info> - 2015-11-25 21:52 +1100
            Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-11-25 13:25 +0100
            Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) BartC <bc@freeuk.com> - 2015-11-25 13:20 +0000
              Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Ned Batchelder <ned@nedbatchelder.com> - 2015-11-25 07:13 -0800
                Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Laura Creighton <lac@openend.se> - 2015-11-25 16:59 +0100
                  Multiplication [was Re: Late-binding of function defaults] Steven D'Aprano <steve@pearwood.info> - 2015-11-26 05:09 +1100
                    Re: Multiplication [was Re: Late-binding of function defaults] Laura Creighton <lac@openend.se> - 2015-11-25 19:45 +0100
                    Re: Multiplication [was Re: Late-binding of function defaults] Marko Rauhamaa <marko@pacujo.net> - 2015-11-25 23:04 +0200
                Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Arie van Wingerden <xapwing@gmail.com> - 2015-11-25 17:12 +0100
                Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Chris Angelico <rosuav@gmail.com> - 2015-11-26 03:29 +1100
                Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) BartC <bc@freeuk.com> - 2015-11-25 17:18 +0000
                  Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Ian Kelly <ian.g.kelly@gmail.com> - 2015-11-25 11:03 -0700
                    Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) BartC <bc@freeuk.com> - 2015-11-25 18:48 +0000
                  Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-11-25 20:50 +0000
                    Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) BartC <bc@freeuk.com> - 2015-11-25 21:56 +0000
                      Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Marko Rauhamaa <marko@pacujo.net> - 2015-11-26 00:16 +0200
                        Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) BartC <bc@freeuk.com> - 2015-11-25 22:41 +0000
                          Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Steven D'Aprano <steve@pearwood.info> - 2015-11-26 11:31 +1100
                            Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) BartC <bc@freeuk.com> - 2015-11-26 01:23 +0000
                              Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Ned Batchelder <ned@nedbatchelder.com> - 2015-11-25 17:52 -0800
                                Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Ben Finney <ben+python@benfinney.id.au> - 2015-11-26 16:08 +1100
                                Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-11-26 06:39 +0000
                                Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-11-26 09:31 +0100
                                Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) BartC <bc@freeuk.com> - 2015-11-26 12:53 +0000
                                  Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Chris Angelico <rosuav@gmail.com> - 2015-11-27 00:15 +1100
                                    Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) BartC <bc@freeuk.com> - 2015-11-26 14:40 +0000
                                      Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) MRAB <python@mrabarnett.plus.com> - 2015-11-26 16:14 +0000
                                    Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) BartC <bc@freeuk.com> - 2015-11-26 22:27 +0000
                                      Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Chris Angelico <rosuav@gmail.com> - 2015-11-27 10:07 +1100
                                      Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Random832 <random832@fastmail.com> - 2015-11-26 19:15 -0500
                                      Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Chris Angelico <rosuav@gmail.com> - 2015-11-27 11:48 +1100
                                      Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) MRAB <python@mrabarnett.plus.com> - 2015-11-27 01:15 +0000
                                  Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) MRAB <python@mrabarnett.plus.com> - 2015-11-26 16:16 +0000
                                  Re: Late-binding of function defaults (was Re: What is a function   parameter =[] for?) Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-11-27 10:48 +1300
                                Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Steven D'Aprano <steve@pearwood.info> - 2015-11-27 12:46 +1100
                                  Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) BartC <bc@freeuk.com> - 2015-11-27 02:01 +0000
                              Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Marko Rauhamaa <marko@pacujo.net> - 2015-11-26 08:41 +0200
                              Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Steven D'Aprano <steve@pearwood.info> - 2015-11-27 12:09 +1100
                                Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) BartC <bc@freeuk.com> - 2015-11-27 10:31 +0000
                                  Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Marko Rauhamaa <marko@pacujo.net> - 2015-11-27 13:30 +0200
                Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Ben Finney <ben+python@benfinney.id.au> - 2015-11-26 06:57 +1100
                  Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Marko Rauhamaa <marko@pacujo.net> - 2015-11-25 23:00 +0200
              Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Emile van Sebille <emile@fenx.com> - 2015-11-25 10:56 -0800
              Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Steven D'Aprano <steve@pearwood.info> - 2015-11-26 13:01 +1100
            Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Chris Angelico <rosuav@gmail.com> - 2015-11-26 00:24 +1100
            Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-11-25 15:17 +0100
            Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Emile van Sebille <emile@fenx.com> - 2015-11-25 10:51 -0800
        Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Chris Angelico <rosuav@gmail.com> - 2015-11-25 19:32 +1100
          Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Marko Rauhamaa <marko@pacujo.net> - 2015-11-25 10:43 +0200
            Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Steven D'Aprano <steve@pearwood.info> - 2015-11-25 21:58 +1100
          Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) BartC <bc@freeuk.com> - 2015-11-25 12:35 +0000
            Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Marko Rauhamaa <marko@pacujo.net> - 2015-11-25 15:06 +0200
              Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) BartC <bc@freeuk.com> - 2015-11-25 13:37 +0000
                Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Marko Rauhamaa <marko@pacujo.net> - 2015-11-25 15:53 +0200
                  Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) BartC <bc@freeuk.com> - 2015-11-25 14:34 +0000
                    Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-11-25 13:32 -0500
                    Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Steven D'Aprano <steve@pearwood.info> - 2015-11-26 11:53 +1100
                      Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Marko Rauhamaa <marko@pacujo.net> - 2015-11-26 08:52 +0200
                        Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Chris Angelico <rosuav@gmail.com> - 2015-11-26 18:14 +1100
                          Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Marko Rauhamaa <marko@pacujo.net> - 2015-11-26 10:27 +0200
                            Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Chris Angelico <rosuav@gmail.com> - 2015-11-26 19:34 +1100
                              Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Marko Rauhamaa <marko@pacujo.net> - 2015-11-26 12:54 +0200
                                Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Chris Angelico <rosuav@gmail.com> - 2015-11-26 22:04 +1100
                                  Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Marko Rauhamaa <marko@pacujo.net> - 2015-11-26 13:23 +0200
                                    Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Chris Angelico <rosuav@gmail.com> - 2015-11-26 22:35 +1100
                                      Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Marko Rauhamaa <marko@pacujo.net> - 2015-11-26 14:03 +0200
                                    Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Steven D'Aprano <steve@pearwood.info> - 2015-11-27 12:43 +1100
                            Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-11-26 09:45 +0100
                            Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-11-27 10:20 +1300
                              Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Marko Rauhamaa <marko@pacujo.net> - 2015-11-26 23:36 +0200
                            Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Steven D'Aprano <steve@pearwood.info> - 2015-11-27 12:23 +1100
                        Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-11-26 11:17 +0000
              Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Chris Angelico <rosuav@gmail.com> - 2015-11-26 00:44 +1100
              Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Ben Finney <ben+python@benfinney.id.au> - 2015-11-26 06:55 +1100
              Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Random832 <random832@fastmail.com> - 2015-11-26 00:52 +0000
              Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Ian Kelly <ian.g.kelly@gmail.com> - 2015-11-25 20:01 -0700
              Semantics of collection types (was: Late-binding of function defaults (was Re: What is a function parameter =[] for?)) Ben Finney <ben+python@benfinney.id.au> - 2015-11-26 16:04 +1100
            Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Chris Angelico <rosuav@gmail.com> - 2015-11-26 00:35 +1100
          Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Larry Hudson <orgnut@yahoo.com> - 2015-11-25 22:44 -0800
        Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?) Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-11-25 10:13 +0100

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

#99091 — Re: Late-binding of function defaults (was Re: What is a function parameter =[] for?)

In a message of Fri, 20 Nov 2015 06:46:42 +1100, Chris Angelico writes:

>Would this satisfy the people who get confused about "=[]"?
>
>ChrisA

My experience says that the people who are confused want lists to
behave like tuples.  period.  i.e. they don't want lists to be 
mutable.  Which means when I say 'use a tuple instead' they go
away happy. Lots of very occasional programmers in my world (children)
just use tuples instead of lists and never get surprises and 
never go on to learn about lists and why they are a good idea.

But then there are those who come back with the problem:
'my python program is too slow'.  From a perspective of
'Let us understand why this is so and what could we do to make
things faster', I can get them to come up with the idea of a 
python list all on their own.  But this requires the sort of
brain that is interested in how interpreters work, otherwise
this conversation will not happen.

Without the actual problem biting them, the whole idea of
mutable objects seems, ah, hazardous.  I wonder if we do people
a disservice by introducing them straight off in teaching python
to absolute beginners, and if the learning would go easier if
we taught tuples and made them all use them a while before we
gave them lists.

At any rate, 'what is a mutable object' is a conversation that I 
have had too many times with people who really aren't interested.
I now think that 'use a tuple instead' is the way to go, with the
addition -- come back and talk to me about this at any time if you
want to learn why this is so.

Laura

[toc] | [next] | [standalone]

#99096

Laura Creighton <lac@openend.se>:

> My experience says that the people who are confused want lists to
> behave like tuples. period. i.e. they don't want lists to be mutable.

I think it's simpler than that. When you have:

   def f(x=[]):
       y = []

the first [] is evaluated when "def" is executed, while the latter [] is
evaluated whenever "f" is executed. It's easy to be confused.


Marko

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

#99101

In a message of Thu, 19 Nov 2015 22:57:10 +0200, Marko Rauhamaa writes:
>Laura Creighton <lac@openend.se>:
>
>> My experience says that the people who are confused want lists to
>> behave like tuples. period. i.e. they don't want lists to be mutable.
>
>I think it's simpler than that. When you have:
>
>   def f(x=[]):
>       y = []
>
>the first [] is evaluated when "def" is executed, while the latter [] is
>evaluated whenever "f" is executed. It's easy to be confused.
>
>
>Marko

Note: Ned Bachelder (who is probably reading this on python-list
anyway added cc on this mail, as if I am to discuss somebody, however
briefly, they deserve to hear about it.  Which may irritate him to
get 2 copies instead of one, but so it goes.  I am talking about
BartC as well, but since this is his thread, I assume he is here.)

Now back to what Marko said:

This is one of the times when it is nice to be dealing with children.
The whole notion of 'when def is executed' is not on their radar
at all.  It is all a matter of 'I write this, I want that'. :)

And with reasonable amount of authority from experience, I can
tell you that 'write it with round brackets not square ones'
makes the code *just work* for a large number of students who
only have a limited amount of patience for 'understanding 
what they are doing'.  They want to be able to do it first,
and have understanding come later (if at all).

This is the learning approach of 'training' as opposed to
'educating'.  And, for all that we _talk_ of 'educating our
children' -- what we really do, a whole lot of the time, is
train them.  The very basic skills of reading, writing (typing?) 
and arithmetic and foreign languages  need to be trained, and no
amount of understanding the theory behind such things will
ever directly translate into being able to do it.

Indeed, the best authority on the planet on 13th century French court
dances is a one-legged Frenchman, (whose name I now forget).
Although he has (or maybe had, he is likely dead by now, he lost
his leg in WW2) the education and the theory and the scholasticism, 
anybody with 2 legs, however ignorant, can dance the court dances
better. 

Sometimes you want to understand what you are doing.  Sometimes
you just want to do it.  And sometimes, well, the only real way 
to get an understanding of what you are doing is to do it more.
This is, in my opinion, Bartc's problem. He doesn't program in
python enough to understand it more.  He wants us to give him
a better theoretical understanding of Python, but for me, at 
any rate he is hitting the wrong audience.  And Ned Batchelder
is unlikely to help.  Both of us come from the practical end
of things, and write lessons and talks like the one ChrisA
recommended -- which is wonderful.  And how I wish I could 
write like that -- but they are aimed at telling a practical
python programmer 'now that you know how to do it, here is how
to understand what you do'.  And then, pedagogically, you can 
move to 'and now you understand what you have been doing, here
are some awesome cool tricks you can do to make your life easier
(and impress your friends, for a particularly nerdy set of
freinds).

I don't think that Ned works for the untrained python programmer.
And until Bart writes a bunch of code in python, for many weeks
or even months, I will not be able to help him, either.

But in my life, I end up teaching programming, often to some very
smart young people who are specialists at being trained. They want me
to train them, not educate them.  When you are 9 years old,
approaching all of life with the attitude of 'how do I get <anything>
to spit out the results I want' is enormously adaptive.

They have the opposite problem of BartC -- they want to be excellent
programmers without understanding anything, while he wants to 
understand everything before he knows how to write decent python code.

It's a pedagogical problem.

Laura

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

#99150

On 19/11/2015 22:41, Laura Creighton wrote:
> In a message of Thu, 19 Nov 2015 22:57:10 +0200, Marko Rauhamaa writes:

> Note: Ned Bachelder (who is probably reading this on python-list
> anyway added cc on this mail, as if I am to discuss somebody, however
> briefly, they deserve to hear about it.  Which may irritate him to
> get 2 copies instead of one, but so it goes.  I am talking about
> BartC as well, but since this is his thread, I assume he is here.)

Actually that thread was started by 'fl'.

> Sometimes you want to understand what you are doing.  Sometimes
> you just want to do it.  And sometimes, well, the only real way
> to get an understanding of what you are doing is to do it more.
> This is, in my opinion, Bartc's problem. He doesn't program in
> python enough to understand it more.

That's true. I'll have to do a substantial project soon. But a lot of my 
interest is about comparisons between Python and the languages I work on.

(Especially of speed. Up to now my interpreters have been comfortably 
faster. But with PyPy I might now have do do a bit more work on mine 
next year. This is where a proper application is needed for comparison 
and not small benchmarks.)

I'm also interested in what handy features I can 'borrow' from Python. 
Enough that I was planning a big upgrade earlier this year to bring it 
more into line with how Python works. (/That/ is a good way of learning 
about a language! To try and implement a lookalike.)

But that was changing my language too much (I was losing too many 
features of my own) so it was abandoned. (Perhaps it can be a separate, 
higher level language at some point as I quite like the Python style 
even if I have misgivings about some features.)

> They have the opposite problem of BartC -- they want to be excellent
> programmers without understanding anything, while he wants to
> understand everything before he knows how to write decent python code.

I can already tell you that I will never be able to write 'Pythonic' 
code if that is what you mean by 'decent'. But at least everyone will be 
able to understand it!

-- 
Bartc

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

#99114

On Fri, 20 Nov 2015 07:57 am, Marko Rauhamaa wrote:

> Laura Creighton <lac@openend.se>:
> 
>> My experience says that the people who are confused want lists to
>> behave like tuples. period. i.e. they don't want lists to be mutable.
> 
> I think it's simpler than that. When you have:
> 
>    def f(x=[]):
>        y = []
> 
> the first [] is evaluated when "def" is executed, while the latter [] is
> evaluated whenever "f" is executed. It's easy to be confused.

It shouldn't be. The function declaration 

    def f(x=[]):

is executed only once. The function body, conveniently indented to make it
stand out:

        y = []

is executed every time you call the function. 


[Aside: that nice clean design is somewhat muddied by docstrings. Despite
being indented, docstrings are actually part of the declaration in the
sense that they are handled only once, at function definition time.]


-- 
Steven

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

#99419

Op 20-11-15 om 01:33 schreef Steven D'Aprano:
> On Fri, 20 Nov 2015 07:57 am, Marko Rauhamaa wrote:
>
>> Laura Creighton <lac@openend.se>:
>>
>>> My experience says that the people who are confused want lists to
>>> behave like tuples. period. i.e. they don't want lists to be mutable.
>> I think it's simpler than that. When you have:
>>
>>    def f(x=[]):
>>        y = []
>>
>> the first [] is evaluated when "def" is executed, while the latter [] is
>> evaluated whenever "f" is executed. It's easy to be confused.
> It shouldn't be. The function declaration 
>
>     def f(x=[]):
>
> is executed only once. The function body, conveniently indented to make it
> stand out:
>
>         y = []
>
> is executed every time you call the function. 

What exactly is your point? People's confusions don't disappear
because you as an expert have a good understanding of what is
going on and so are no longer confused.

Some aspects in the langauage are easily grasped and other
aspects tend to create confusion. I see nothing wrong with
people trying to point out what the cause of this confusion
could be. You arguing that people shouldn't be confused is
not helping.

-- 
Antoon.

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

#99435

On Wed, 25 Nov 2015 07:14 pm, Antoon Pardon wrote:

> Op 20-11-15 om 01:33 schreef Steven D'Aprano:
>> On Fri, 20 Nov 2015 07:57 am, Marko Rauhamaa wrote:
>>
>>> Laura Creighton <lac@openend.se>:
>>>
>>>> My experience says that the people who are confused want lists to
>>>> behave like tuples. period. i.e. they don't want lists to be mutable.
>>> I think it's simpler than that. When you have:
>>>
>>>    def f(x=[]):
>>>        y = []
>>>
>>> the first [] is evaluated when "def" is executed, while the latter [] is
>>> evaluated whenever "f" is executed. It's easy to be confused.
>> It shouldn't be. The function declaration
>>
>>     def f(x=[]):
>>
>> is executed only once. The function body, conveniently indented to make
>> it stand out:
>>
>>         y = []
>>
>> is executed every time you call the function.
> 
> What exactly is your point? 

That there is a simple analogy between the distinction between code
inside/outside a for-loop, and code inside/outside a function. If you can
understand why this loops forever, instead of just twice, then you can
understand why function defaults work the way they do:

L = [1, 2]
for i in L:
    L.append(i)
    print(L)


There is nothing "bizarre" or complicated or difficult to understand
happening here. It might not be what you want to happen. It might not be
what you expect to happen. But if you can't understand why it happens even
after multiple explanations, then your learning skills are severely
lacking.



> People's confusions don't disappear 
> because you as an expert have a good understanding of what is
> going on and so are no longer confused.

I'm an expert? Awesome!

No. But people's confusion would disappear if they would:

- think about the process
- try to follow the steps of what is happening
- pay attention to the explanations given
- and ask for clarification instead of arguing.

I have come to the conclusion that there is nobody as stupid as an
intelligent person who refuses to learn.

I really don't know how more clear we can possibly be. If you take a list,
initialised as the empty list ONCE, and then modify it repeatedly, the list
doesn't magically become empty just because you want it to be empty.

I completely understand beginners making this mistake:

# Simulate tossing a coin until it is heads.
count = 1
coin = random.choice(['heads', 'tails'])
while coin != 'heads':
    count += 1

"Why does the loop run forever?"


The coin doesn't magically toss itself, no matter how intuitively obvious it
is that it should. (And I'm not making this example up -- I've seen three
or four beginners make equivalent errors. It seems to be a very common
conceptual mistake.)

These beginners, at least, don't argue back that it is "bizarre" and stupid
and crazy that you have to choose a new value for the coin variable each
time through the loop. They soon learn that code outside the loop only runs
once, if you want it to run each time through the loop, you should put it
inside the body of the loop.

Just like functions. If you want code to run each time you call the
function, PUT IT INSIDE THE FUNCTION BODY.


> Some aspects in the langauage are easily grasped and other
> aspects tend to create confusion. 

You're right. Some aspects of the language are inherently confusing and hard
to reason about. Threads are an example of that. The more powerful, and
tricky, aspects of regular expressions. The weird stuff that happens during
interpreter shutdown if you have __del__ methods in your objects. __del__
methods in general. There are many things which are hard to reason about,
and therefore confusing.

*This is not one of them.*

This is not hard to reason about. The rules are no different from what
happens in simple, ordinary code:

L = []  # Initialise the list *once*.
def func():
    L.append(1)
    return L

If I call func() three times, what value does it return? If you can get
that, you can get this:

def func(L=[]):  # Initialise the list *once*.
    L.append(1)
    return L

Confusing? Absolutely not. Or rather, if anyone cannot understand the
behaviour of either function *after having it explained multiple times*,
then programming is the wrong area for them. They should take up something
more suited to their intellectual limitations, like dish washing, ditch
digging, or politics.

But is it predictable or intuitive? No, I agree, this behaviour is not
intuitive, if you are coming from a background without equivalent rules. I
will completely grant you that most people without Python experience would
not correctly predict the behaviour of mutable defaults.

I was caught out on that too, as I already admitted. Even though I already
knew all the facts I needed to predict the behaviour correctly, I didn't
put 2+2 together and get 4. That's *my bad*, not the language's fault.

How much harder must it be for those who don't know the essential facts? I
don't expect anyone to intuit the behaviour of Python defaults. That would
be unreasonable. There's no shame in guessing wrong from a position of
ignorance.

Me, on the other hand... I should have known better. I did know better.

But there's a big difference between those who guess wrong from a position
of ignorance, and then make an honest attempt to understand the behaviour
and why it actually does make sense and is even sometimes useful (even if
they don't like it), and those people who insist that it is nonsensical,
magical and "bizarre".


 

-- 
Steven

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

#99441

Op 25-11-15 om 11:52 schreef Steven D'Aprano:
> On Wed, 25 Nov 2015 07:14 pm, Antoon Pardon wrote:
>
>> Op 20-11-15 om 01:33 schreef Steven D'Aprano:
>>> On Fri, 20 Nov 2015 07:57 am, Marko Rauhamaa wrote:
>>>
>>>> Laura Creighton <lac@openend.se>:
>>>>
>>>>> My experience says that the people who are confused want lists to
>>>>> behave like tuples. period. i.e. they don't want lists to be mutable.
>>>> I think it's simpler than that. When you have:
>>>>
>>>>    def f(x=[]):
>>>>        y = []
>>>>
>>>> the first [] is evaluated when "def" is executed, while the latter [] is
>>>> evaluated whenever "f" is executed. It's easy to be confused.
>>> It shouldn't be. The function declaration
>>>
>>>     def f(x=[]):
>>>
>>> is executed only once. The function body, conveniently indented to make
>>> it stand out:
>>>
>>>         y = []
>>>
>>> is executed every time you call the function.
>> What exactly is your point? 
> That there is a simple analogy between the distinction between code
> inside/outside a for-loop, and code inside/outside a function. If you can
> understand why this loops forever, instead of just twice, then you can
> understand why function defaults work the way they do:
>
> L = [1, 2]
> for i in L:
>     L.append(i)
>     print(L)
>
>
> There is nothing "bizarre" or complicated or difficult to understand
> happening here. It might not be what you want to happen. It might not be
> what you expect to happen. But if you can't understand why it happens even
> after multiple explanations, then your learning skills are severely
> lacking.

You shouldn't equate that what you understand with what is not bizarre
complicated or difficult.

I think there are reasons to find the above behaviour bizarre. I personnaly
don't find it bizarre, but that is because I'm familiar with what is going
on. But if someone expects the compilor to take a snapshot of L and iterate
over that I am not going to say he shouldn't have expected that.

And IMO each time you proclaim something nothing bizarre or complicated
or difficult you are not helping.

>> People's confusions don't disappear 
>> because you as an expert have a good understanding of what is
>> going on and so are no longer confused.
> I'm an expert? Awesome!
>
> No. But people's confusion would disappear if they would:
>
> - think about the process
> - try to follow the steps of what is happening
> - pay attention to the explanations given
> - and ask for clarification instead of arguing.

People would be more inclined to do so, if there wasn't someone
claiming there was nothing bizarre or complicated or difficult
going on. Telling the above is implying those steps are not
needed because it is obvious what is happening. And if you
don't want people arguing, don't start yourself. Because my
impression of what is most likely to happen when someone says
something like: That is bizarre, is that the regulars here
are the ones that start arguing about it not being bizarre
and then they are annoyed that the other is arguing too.

> I have come to the conclusion that there is nobody as stupid as an
> intelligent person who refuses to learn.

Sure but that works just as much for the regulars here, who despite
that some subjects keep confusing people new to the language, keep
repeating that there is nothing bizarre, complicated or difficult
going on.

>> Some aspects in the langauage are easily grasped and other
>> aspects tend to create confusion. 
> You're right. Some aspects of the language are inherently confusing and hard
> to reason about. Threads are an example of that. The more powerful, and
> tricky, aspects of regular expressions. The weird stuff that happens during
> interpreter shutdown if you have __del__ methods in your objects. __del__
> methods in general. There are many things which are hard to reason about,
> and therefore confusing.
>
> *This is not one of them.*

Please stop using your personal evaluation as if it is some kind of
objective measure. The number of people that seem to get confused by
this, contradicts your claim.

> But is it predictable or intuitive? No, I agree, this behaviour is not
> intuitive, if you are coming from a background without equivalent rules. I
> will completely grant you that most people without Python experience would
> not correctly predict the behaviour of mutable defaults.
>
> I was caught out on that too, as I already admitted. Even though I already
> knew all the facts I needed to predict the behaviour correctly, I didn't
> put 2+2 together and get 4. That's *my bad*, not the language's fault.

Why not? People are not perfect rational thinking machines. And expecting
them to act like ones in order to get the language out of the wind, is
a rather weak argument IMO.

> How much harder must it be for those who don't know the essential facts? I
> don't expect anyone to intuit the behaviour of Python defaults. That would
> be unreasonable. There's no shame in guessing wrong from a position of
> ignorance.
>
> Me, on the other hand... I should have known better. I did know better.
>
> But there's a big difference between those who guess wrong from a position
> of ignorance, and then make an honest attempt to understand the behaviour
> and why it actually does make sense and is even sometimes useful (even if
> they don't like it), and those people who insist that it is nonsensical,
> magical and "bizarre".

There is an equally big difference between trying to explain what is going
on and insisting that what is going on is not bizarre.

-- 
Antoon.

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

#99446

On 25/11/2015 10:52, Steven D'Aprano wrote:
> On Wed, 25 Nov 2015 07:14 pm, Antoon Pardon wrote:

>> What exactly is your point?
>
> That there is a simple analogy between the distinction between code
> inside/outside a for-loop, and code inside/outside a function. If you can
> understand why this loops forever, instead of just twice, then you can
> understand why function defaults work the way they do:
>
> L = [1, 2]
> for i in L:
>      L.append(i)
>      print(L)
>
>
> There is nothing "bizarre" or complicated or difficult to understand
> happening here.

What do you think most people would expect to happen here? I know, 
because you gave a spoiler, that it loops forever, otherwise I wouldn't 
be sure /without trying it/ (but I tried it anyway).

Here's the same code in a somewhat different language:

L := (1,2)
for i in L do
|   L append:= i
|   println L
od

And this is the output:

(1,2,1)
(1,2,1,2)

Which output (infinite series of [1,2,1,2,1,....] or the above) is more 
sensible, and which do you think people might prefer?

The point is that the behaviour of the loop is by no means obvious, so 
neither is the behaviour of the function defaults.

> It might not be what you want to happen. It might not be
> what you expect to happen. But if you can't understand why it happens even
> after multiple explanations, then your learning skills are severely
> lacking.

Accept that some things /are/ a source of confusion. When, in writing 
documentation, I find something hard to explain something, then I try 
and make it simpler in the program. But not enough of that goes on: it 
seems to be more lucrative to write thicker user manuals, and provide 
longer training courses, than to make software simpler.

> I really don't know how more clear we can possibly be. If you take a list,
> initialised as the empty list ONCE, and then modify it repeatedly, the list
> doesn't magically become empty just because you want it to be empty.

Sure. The problem is that it might not be obvious it's initialised once.

> I completely understand beginners making this mistake:
>
> # Simulate tossing a coin until it is heads.
> count = 1
> coin = random.choice(['heads', 'tails'])
> while coin != 'heads':
>      count += 1
>
> "Why does the loop run forever?"
>
> The coin doesn't magically toss itself, no matter how intuitively obvious it
> is that it should.

The concept of variables doesn't take long to learn in an 'ordinary' 
language.

But one problem with Python is that it gives the impression that almost 
anything is possible. Your example can be made to work with a slight tweak:

  count = 1
  coin = lambda: random.choice(['heads', 'tails'])
  while coin() != 'heads':
       count += 1

In some languages, there would never be such a possibility because they 
don't have the extraordinary flexibility and dynamism of Python. But 
once you get the idea that the language can almost do magic, then it 
doesn't seem so far-fetched that you original example could work!

> Just like functions. If you want code to run each time you call the
> function, PUT IT INSIDE THE FUNCTION BODY.

Many languages don't have the concept of code running outside a function 
body. And especially they don't have the truly bizarre one that a 
function definition is itself a piece of code that is executed. Or maybe 
not executed, if it's inside a conditional statement! And therefore does 
not exist. This is an extra hurdle with learning or even using this 
language.

-- 
bartc

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

#99459

On Wednesday, November 25, 2015 at 8:20:59 AM UTC-5, BartC wrote:
> Accept that some things /are/ a source of confusion. When, in writing 
> documentation, I find something hard to explain something, then I try 
> and make it simpler in the program. But not enough of that goes on: it 
> seems to be more lucrative to write thicker user manuals, and provide 
> longer training courses, than to make software simpler.

You seem to be insinuating that someone has made Python unusually complex
for personal gain?  I'm not sure what to do with that: it's an absurd
claim.  

> > "Why does the loop run forever?"
> >
> > The coin doesn't magically toss itself, no matter how intuitively obvious it
> > is that it should.
> 
> The concept of variables doesn't take long to learn in an 'ordinary' 
> language.

There is a natural tension between making a language simple enough that
it has no surprises or difficult parts; and making a language rich
enough that it can be used for building serious systems.

If you have another language to propose as a better beginner's learning
language, please propose it.  I think it serves beginners better to
teach them with a language that they can then go on to use for building
real things.  Is there a real language (an "ordinary" language) that
you think is better than Python for that?  Empirical evidence in the
world says, "not really."

I know you have languages of your own, and that you like the way they
work better.  We have no way of evaluating their power or simplicity,
since they are not available to us.

I agree with you: there are things about Python that surprise people.
That's because it's a programming language, and very very little about
programming languages is obvious.  The best we can hope for is "familiar,"
and even then, familiar to who?  High school algebra students will at
first be baffled by "x = x + 1", an equation which is clearly
unsatisfiable.

So yes, there are parts of Python that are hard, and surprising. There
are subtleties that require study and careful thought.  We believe that
on the balance, Python is better than many of the alternatives. You
are welcome to disagree, but don't be surprised if you encounter
vigorous counter-arguments in a Python mailing list!

There isn't much we can do about the structure of the language, certainly
not the parts that have been discussed in this thread.  The best we can
do is try to explain it better.

--Ned.

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

#99461

In a message of Wed, 25 Nov 2015 07:13:41 -0800, Ned Batchelder writes:
>That's because it's a programming language, and very very little about
>programming languages is obvious.  The best we can hope for is "familiar,"
>and even then, familiar to who?  High school algebra students will at
>first be baffled by "x = x + 1", an equation which is clearly
>unsatisfiable.

The great sticking point for the children I am teaching is
'*' means multiplication.  You can really see that some people 
have to make extensive mental modifications in order to handle
the concept that mathematical truths are expressed in linguistic
and orthographic conventions, and that one can swap out a particular
convention 'x means multiply' and swap in another one '* means
multiply' while leaving the underlying truth unchanged.

Laura

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

#99470 — Multiplication [was Re: Late-binding of function defaults]

On Thu, 26 Nov 2015 02:59 am, Laura Creighton wrote:

> The great sticking point for the children I am teaching is
> '*' means multiplication.  You can really see that some people
> have to make extensive mental modifications in order to handle
> the concept that mathematical truths are expressed in linguistic
> and orthographic conventions, and that one can swap out a particular
> convention 'x means multiply' and swap in another one '* means
> multiply' while leaving the underlying truth unchanged.

Wow. What age children are you talking about?

I wasn't introduced to programming in any real depth until uni, after
graduating secondary school. I had lots of problems understanding bits of
it, and so did many of my fellow students, but * for multiplication wasn't
one of them.

But by this time, we had already learned in secondary school that you can
use any of the following to write multiplication:

x × y
x ⋅ y
x y

just as you can write division as:

x / y
x ÷ y

Adding * to the list of ways to write multiplication wasn't hard.

And I don't remember anyone having conceptual difficulty learning that xy is
a short-cut for x×y in maths class.


-- 
Steven

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

#99476 — Re: Multiplication [was Re: Late-binding of function defaults]

In a message of Thu, 26 Nov 2015 05:09:13 +1100, "Steven D'Aprano" writes:
>On Thu, 26 Nov 2015 02:59 am, Laura Creighton wrote:
>
>> The great sticking point for the children I am teaching is
>> '*' means multiplication.  You can really see that some people
>> have to make extensive mental modifications in order to handle
>> the concept that mathematical truths are expressed in linguistic
>> and orthographic conventions, and that one can swap out a particular
>> convention 'x means multiply' and swap in another one '* means
>> multiply' while leaving the underlying truth unchanged.
>
>Wow. What age children are you talking about?

12 and 13 and 14 year olds. Smart 12, 13 and 14 year olds.

They want to build web servers and host pictures of their pets.
and use the gimp to do image manipulation like crazy. They are
as interested in art as much as, or perhaps even more so than
in programming -- they just need to learn enough programming to
get to make the art and serve it up.

Designing your own Magic The Gathering cards, which has manipulated
pictures of your friends on them, and then using them to play games 
with said friends has been the craze since September.

It's not that the idea of we will use '*' is hard, but if you have
never thought about the difference between THE TRUTH and the notation
used to express the truth before, then well, you may need some time
to get used to the idea.

Laura

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

#99490 — Re: Multiplication [was Re: Late-binding of function defaults]

Steven D'Aprano <steve@pearwood.info>:

> But by this time, we had already learned in secondary school that you can
> use any of the following to write multiplication:
>
> x × y

Not where I lived. (Those x's would have been a nightmare for the
teacher who had to mark people's test answers.)

> x ⋅ y

Yes. After all, it would never get mixed up with the decimal comma.

> x y

Not to multiply numbers with each other.

> just as you can write division as:
>
> x / y

Not where I lived.

> x ÷ y

Not that one, either.

               x
We only had:  ---
               y


Marko

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

#99462

>and even then, familiar to who?  High school algebra students will at
>first be baffled by "x = x + 1", an equation which is clearly
>unsatisfiable.
Some languages are "better" in that specific case in my opinion (mind te
double quotes :-)
   - Ada and Pascal use := instead of = which is simpler to grasp for n00bs
(I think)
   - Erlang uses pattern matching. So when left hand side does NOT right
hand side, yuou get an exception.
         Each variable can be only assigned once and only once.
         That is the most purely mathematical approach (I think)
   - Haskell


2015-11-25 16:13 GMT+01:00 Ned Batchelder <ned@nedbatchelder.com>:

> On Wednesday, November 25, 2015 at 8:20:59 AM UTC-5, BartC wrote:
> > Accept that some things /are/ a source of confusion. When, in writing
> > documentation, I find something hard to explain something, then I try
> > and make it simpler in the program. But not enough of that goes on: it
> > seems to be more lucrative to write thicker user manuals, and provide
> > longer training courses, than to make software simpler.
>
> You seem to be insinuating that someone has made Python unusually complex
> for personal gain?  I'm not sure what to do with that: it's an absurd
> claim.
>
> > > "Why does the loop run forever?"
> > >
> > > The coin doesn't magically toss itself, no matter how intuitively
> obvious it
> > > is that it should.
> >
> > The concept of variables doesn't take long to learn in an 'ordinary'
> > language.
>
> There is a natural tension between making a language simple enough that
> it has no surprises or difficult parts; and making a language rich
> enough that it can be used for building serious systems.
>
> If you have another language to propose as a better beginner's learning
> language, please propose it.  I think it serves beginners better to
> teach them with a language that they can then go on to use for building
> real things.  Is there a real language (an "ordinary" language) that
> you think is better than Python for that?  Empirical evidence in the
> world says, "not really."
>
> I know you have languages of your own, and that you like the way they
> work better.  We have no way of evaluating their power or simplicity,
> since they are not available to us.
>
> I agree with you: there are things about Python that surprise people.
> That's because it's a programming language, and very very little about
> programming languages is obvious.  The best we can hope for is "familiar,"
> and even then, familiar to who?  High school algebra students will at
> first be baffled by "x = x + 1", an equation which is clearly
> unsatisfiable.
>
> So yes, there are parts of Python that are hard, and surprising. There
> are subtleties that require study and careful thought.  We believe that
> on the balance, Python is better than many of the alternatives. You
> are welcome to disagree, but don't be surprised if you encounter
> vigorous counter-arguments in a Python mailing list!
>
> There isn't much we can do about the structure of the language, certainly
> not the parts that have been discussed in this thread.  The best we can
> do is try to explain it better.
>
> --Ned.
> --
> https://mail.python.org/mailman/listinfo/python-list
>

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

#99463

On Thu, Nov 26, 2015 at 2:13 AM, Ned Batchelder <ned@nedbatchelder.com> wrote:
> I agree with you: there are things about Python that surprise people.
> That's because it's a programming language, and very very little about
> programming languages is obvious.  The best we can hope for is "familiar,"
> and even then, familiar to who?  High school algebra students will at
> first be baffled by "x = x + 1", an equation which is clearly
> unsatisfiable.

And then *lots* of people are confused by "x += 1" being almost, but
not entirely, identical to the above. Actually, if there were one
change I could make to Python, it would be to redefine the augmented
assignment operators to be semantically identical to their expanded
forms; there might be some optimizations, but absolutely no difference
in effect. (Which would mean, among other things, that it would be a
very bad way to append to a list, instead of being an alias for
.extend.)

ChrisA

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

#99465

On 25/11/2015 15:13, Ned Batchelder wrote:
> On Wednesday, November 25, 2015 at 8:20:59 AM UTC-5, BartC wrote:
>> Accept that some things /are/ a source of confusion. When, in writing
>> documentation, I find something hard to explain something, then I try
>> and make it simpler in the program. But not enough of that goes on: it
>> seems to be more lucrative to write thicker user manuals, and provide
>> longer training courses, than to make software simpler.
>
> You seem to be insinuating that someone has made Python unusually complex
> for personal gain?  I'm not sure what to do with that: it's an absurd
> claim.

Actually I was thinking of certain Microsoft products. But I think my 
point stands: the design of software could be influenced more by the 
documentation. In the case of languages, that's perhaps harder because 
languages tend to evolve, and they usually have to be backwards compatible.

>>> "Why does the loop run forever?"
>>>
>>> The coin doesn't magically toss itself, no matter how intuitively obvious it
>>> is that it should.
>>
>> The concept of variables doesn't take long to learn in an 'ordinary'
>> language.

> There is a natural tension between making a language simple enough that
> it has no surprises or difficult parts; and making a language rich
> enough that it can be used for building serious systems.

Well, with Python I get the impression it's gone too far. Too many 
things are dynamic for the sake of it, and people are perhaps tempted to 
make too much use of that.

Although I do find Python's design interesting, from a language design 
and implementation point of view. It looks deceptively simple...

 > I know you have languages of your own, and that you like the way they
 > work better.  We have no way of evaluating their power or simplicity,
 > since they are not available to us.

My language, while simpler, has its own problems. And I don't want to 
get into support (I've done that in the past with other languages).

So at present, I'd probably still recommend Python, although there is 
also the similar Ruby and the smaller language Lua. There a few others 
but I haven't tried them.

 > We have no way of evaluating their power or simplicity,
 > since they are not available to us.

I'll see if I can rustle up a comparison so that Python users can see 
what they're missing!

-- 
Bartc

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

#99469

On Wed, Nov 25, 2015 at 10:18 AM, BartC <bc@freeuk.com> wrote:
>> We have no way of evaluating their power or simplicity,
>> since they are not available to us.
>
> I'll see if I can rustle up a comparison so that Python users can see what
> they're missing!

Unless you're going to make the actual languages available for public
use, what's the point?

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

#99477

On 25/11/2015 18:03, Ian Kelly wrote:
> On Wed, Nov 25, 2015 at 10:18 AM, BartC <bc@freeuk.com> wrote:
>>> We have no way of evaluating their power or simplicity,
>>> since they are not available to us.
>>
>> I'll see if I can rustle up a comparison so that Python users can see what
>> they're missing!
>
> Unless you're going to make the actual languages available for public
> use, what's the point?

For ideas? Sometimes it's interesting to know about other approaches to 
a feature or new ones that can be useful.

Then someone else can implement them! I'd be sharing my language design 
ideas not my amateurish implementations.

(Which aren't easy to distribute anyway because they are implemented in 
themselves.)

-- 
Bartc

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

#99487

On 25/11/2015 17:18, BartC wrote:
> On 25/11/2015 15:13, Ned Batchelder wrote:
>> On Wednesday, November 25, 2015 at 8:20:59 AM UTC-5, BartC wrote:
>>> Accept that some things /are/ a source of confusion. When, in writing
>>> documentation, I find something hard to explain something, then I try
>>> and make it simpler in the program. But not enough of that goes on: it
>>> seems to be more lucrative to write thicker user manuals, and provide
>>> longer training courses, than to make software simpler.
>>
>> You seem to be insinuating that someone has made Python unusually complex
>> for personal gain?  I'm not sure what to do with that: it's an absurd
>> claim.
>
> Actually I was thinking of certain Microsoft products. But I think my
> point stands: the design of software could be influenced more by the
> documentation. In the case of languages, that's perhaps harder because
> languages tend to evolve, and they usually have to be backwards compatible.
>
>>>> "Why does the loop run forever?"
>>>>
>>>> The coin doesn't magically toss itself, no matter how intuitively
>>>> obvious it
>>>> is that it should.
>>>
>>> The concept of variables doesn't take long to learn in an 'ordinary'
>>> language.
>
>> There is a natural tension between making a language simple enough that
>> it has no surprises or difficult parts; and making a language rich
>> enough that it can be used for building serious systems.
>
> Well, with Python I get the impression it's gone too far. Too many
> things are dynamic for the sake of it, and people are perhaps tempted to
> make too much use of that.
>
> Although I do find Python's design interesting, from a language design
> and implementation point of view. It looks deceptively simple...
>
>  > I know you have languages of your own, and that you like the way they
>  > work better.  We have no way of evaluating their power or simplicity,
>  > since they are not available to us.
>
> My language, while simpler, has its own problems. And I don't want to
> get into support (I've done that in the past with other languages).
>
> So at present, I'd probably still recommend Python, although there is
> also the similar Ruby and the smaller language Lua. There a few others
> but I haven't tried them.
>
>  > We have no way of evaluating their power or simplicity,
>  > since they are not available to us.
>
> I'll see if I can rustle up a comparison so that Python users can see
> what they're missing!
>

Can you please let us know what you're taking, what it costs and where 
we can get it, as we would also like to live in cloud cuckoo land, 
provided that The Price Is Right™.

Although credit where credit is due, you are one of the most successful 
trolls to con this list in years.  I must offer my congratulations.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

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

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

csiph-web