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

#99617

On Thu, 26 Nov 2015 12:52 pm, Ned Batchelder wrote:

> For someone who claims to be interested in language design, you're
> remarkably dismissive of pretty much the entire industry.  I don't think
> it's worth the effort to try to change your mind.

In fairness to BartC, I don't think that's malicious or trolling. I think it
is as pure an example of what Paul Graham calls the Blub Paradox as I've
ever seen.



-- 
Steven

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

#99618

On 27/11/2015 01:46, Steven D'Aprano wrote:
> On Thu, 26 Nov 2015 12:52 pm, Ned Batchelder wrote:
>
>> For someone who claims to be interested in language design, you're
>> remarkably dismissive of pretty much the entire industry.  I don't think
>> it's worth the effort to try to change your mind.
>
> In fairness to BartC, I don't think that's malicious or trolling. I think it
> is as pure an example of what Paul Graham calls the Blub Paradox as I've
> ever seen.

"Well, PaulGraham has a very (very) low opinion of OO, mostly because he 
does a lot of stuff that most people haven't been able to do, and he 
says he almost never "resorts" to it. However, more recent posts on LL1 
suggest PaulGraham is coming around. He's starting to be less derogatory 
to OO (and seems to have done a 180 on continuations). No one, not even 
PaulGraham himself, ever said that PaulGraham was immune to the 
BlubParadox. ;) "

http://c2.com/cgi/wiki?BlubParadox

-- 
bartc

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

#99530

BartC <bc@freeuk.com>:
> Clearly a huge amount of programming can be done without having to deal
> with first-class functions (or constructing functions at run-time; that
> sounds fun). (Or without using OOP, another thing I can't stand.)

Even the lowliest code monkeys deal with on-the-fly functions and OOP
nowadays. You can't escape them in C# and Java, for example.

> Some people just don't want to be functional programmers. It is
> elitist to try and make out it that it is that important.
>
> If lots of languages now have functional features, it's more likely to
> be a case of keeping up with the Joneses.

There's some of that. Generics and closures in Java are examples.

However, anonymous classes have been there in Java since the dawn of
days, and they are equally "elitist" as closures.


Marko

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

#99609

On Thu, 26 Nov 2015 12:23 pm, BartC wrote:

> On 26/11/2015 00:31, Steven D'Aprano wrote:

>> In 2015, it's hard to think of any non-obsolete, non-toy language which
>> doesn't treat functions as first-class values, including creating them on
>> the fly. Fortran and C perhaps.
> 
> It's funny then that the vast majority of top-level function definitions
> I see in Python (and import and class statements too) are decidedly
> static.

I can't be held responsible for what code you see.

It is probably true that many, maybe even a majority, of top-level
functions, and methods, are static. So what? That's not the point. The
point is that *more than that is possible*, so when you need the power, you
have it.

Any time you see a function decorator:

@decorate
def function(arg): ...


you're probably seeing a dynamically-generated function. The typical
decorator idiom looks like this:

def decorate(function):
    @functools.wraps(function)
    def inner(arg):
        do stuff
        call the original function
        return the result
    return inner


Lo and behold, the simple @decorate idiom usually hides a function created
on the fly. (That would be the inner function, which is called a closure.)

Any time you see a function factory, chances are good that it involves
dynamic generation of function objects.

Any time you see lambda, you are definitely seeing the dynamic generation of
function objects. If you do any sort of programming involving callbacks
(for example, some GUI toolkits, like Tkinter, make extensive use of
callbacks) you probably will use lambda a lot.

The equivalent to lambda, code blocks, is even more powerful in Ruby, and
Ruby programmers use code blocks *a lot*. So much so that I know at least
one Ruby programmer who considers Python almost unusably primitive and
crippled because it lacks code blocks.

You really should read Paul Graham's essay, "Beating the Averages", and
understand the Blub Paradox. (It's not really a paradox.) It might open
your eyes.

[quote]
As long as our hypothetical Blub programmer is looking down the power
continuum, he knows he's looking down. Languages less powerful than Blub
are obviously less powerful, because they're missing some feature he's used
to. But when our hypothetical Blub programmer looks in the other direction,
up the power continuum, he doesn't realize he's looking up. What he sees
are merely weird languages. He probably considers them about equivalent in
power to Blub, but with all this other hairy stuff thrown in as well. Blub
is good enough for him, because he thinks in Blub.
[end quote]

http://www.paulgraham.com/avg.html


We're all Blub programmers. But some of us are aware that we're Blub
programmers, and when we see "weird languages" with "hairy stuff", we don't
immediately dismiss the possibility that maybe that stuff is powerful and
useful, just because we've never found a use for it.



> The names are declared, but the names are rarely bound to anything else.
> Functions are just called the same boring way they are in C.
> 
> /They might as well be static definitions/.

Sure. And that's probably true for, oh, I don't know, I'll be generous, and
say that 95% of Python functions in use are of a straight-forward
pseudo-static form, using no dynamic features.

But it's the other 5% -- one in twenty -- that *shine*. They're the ones
that do things that you can't do in Pascal or C except with the greatest of
difficulty.

Back when I was an undergrad at uni, I did a course on computational
mathematics. At the time, Pascal was the language of choice at my uni, and
when it came to solving ODEs (Ordinary Differential Equations) we used a
package of Pascal programs to do so.

Because Pascal doesn't have first-class functions, you couldn't pass a
function as an argument to another function. So the ODE solvers used a
hard-coded function as the equation to be solved. So if you wanted to solve
a particular equation, you had to *edit the source code of the program*,
modifying that hard-coded function to match your equation, then re-compile,
and then run the code. You couldn't just type in the equation you wanted to
solve and run the code.

Of course Pascal is Turing Complete, and the solver could have been written
to work that way. It just would have been much, much, much harder.
Something that in a language like Python you can do almost without
thinking:

function(another_function, x, y, z)

would have required hundreds, perhaps thousands or tens of thousands of
lines to do in standard Pascal. You would have had to build up all this
infrastructure for dealing with functions that Python gives you for free.

There's a lot to like about Pascal, but gosh it sure is lacking in power. C
at least has function pointers, which is a step up from Pascal, but still
pretty weak and feeble. If functions are first class values in Python,
Ruby, Lisp and others, they're second class values in C and third class in
Pascal.




-- 
Steven

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

#99635

On 27/11/2015 01:09, Steven D'Aprano wrote:
> On Thu, 26 Nov 2015 12:23 pm, BartC wrote:

[First-class functions]
>> The names are declared, but the names are rarely bound to anything else.
>> Functions are just called the same boring way they are in C.
>>
>> /They might as well be static definitions/.
>
> Sure. And that's probably true for, oh, I don't know, I'll be generous, and
> say that 95% of Python functions in use are of a straight-forward
> pseudo-static form, using no dynamic features.
>
> But it's the other 5% -- one in twenty -- that *shine*. They're the ones
> that do things that you can't do in Pascal or C except with the greatest of
> difficulty.

OK, you're worried about that 5%, I'm more concerned about the other 95%.

I'm not saying you shouldn't have dynamic functions at all, just that 
it's not necessary for 100% to be dynamic.

I understand now that they are dynamic because that is the only 
mechanism that Python has to create any function definition, even the 
boring, static ones.

Together with the ability to subsequently re-bind the function name to 
something else, that's a bit unfortunate because it makes it harder to 
identifier calls to those functions in order to streamline them, or even 
for someone to look at a bit of code and be sure whether that fn(a,b,c) 
is calling the function defined as 'fn' a few hundred lines earlier or 
something else entirely.

(MRAB mentioned Postscript, which also introduces functions using 
executable statements.

However, Postscript was designed to execute code on-the-fly being 
received a character at a time over a printer cable. It had a good excuse!)

> Because Pascal doesn't have first-class functions, you couldn't pass a
> function as an argument to another function. So the ODE solvers used a
> hard-coded function as the equation to be solved. So if you wanted to solve
> a particular equation, you had to *edit the source code of the program*,
> modifying that hard-coded function to match your equation, then re-compile,
> and then run the code. You couldn't just type in the equation you wanted to
> solve and run the code.

Wouldn't Python have the same problem? If the equation to be solved, or 
even the actual function to be executed, is input by the user, then 
doesn't that require whichever one of exec() or eval() it is that 
processes the source code?

> There's a lot to like about Pascal,

It was designed for teaching. The original language would have needed 
tweaking for use in general purpose programming.

> but gosh it sure is lacking in power. C
> at least has function pointers, which is a step up from Pascal, but still
> pretty weak and feeble. If functions are first class values in Python,
> Ruby, Lisp and others, they're second class values in C and third class in
> Pascal.

I think they are more first class in Lisp than they are in most other 
languages including Python. That doesn't stop Python still being jolly 
useful though...

-- 
Bartc

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

#99637

BartC <bc@freeuk.com>:

> I think [functions] are more first class in Lisp than they are in most
> other languages including Python.

Functions in Python and Lisp have the same status.

I would say that Python is one of the many modern Lisp derivatives. What
Python still lacks is:

 * A way to augment the language syntax on the fly. (How could I add an
   "until" statement to Python in my Python application?)

 * A unified syntax for code and data. (Why use braces for dictionaries
   instead of indentation?)


Marko

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

#99481

Laura Creighton <lac@openend.se> writes:

> The great sticking point for the children I am teaching is '*' means
> multiplication. […] that one can swap out a particular convention 'x
> means multiply' and swap in another one '* means multiply' while
> leaving the underlying truth unchanged.

Perhaps it would be easier if you point out that ‘x’ doesn't mean
multiply either, and they've *already* been substituting that symbol
instead of the correct ‘×’ for multiply.

-- 
 \     “Our task must be to free ourselves from our prison by widening |
  `\    our circle of compassion to embrace all humanity and the whole |
_o__)                       of nature in its beauty.” —Albert Einstein |
Ben Finney

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

#99489

Ben Finney <ben+python@benfinney.id.au>:

> Perhaps it would be easier if you point out that ‘x’ doesn't mean
> multiply either, and they've *already* been substituting that symbol
> instead of the correct ‘×’ for multiply.

In my childhood, we always used '·' for the multiplication sign until
senior high school, when the vector product was introduced.

I seem to recall ‘×’ was used in cartesian products already in junior
high.


Marko

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

#99479

On 11/25/2015 5:20 AM, BartC wrote:

> it seems to be more lucrative to write thicker user manuals, and provide
> longer training courses, than to make software simpler.

If that were true, certainly by now the sufficiently thick manual would 
provide crystal clear explanations.  :)

I-don't-think-obfustication-is-the-point-ly y'rs,

Emile

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

#99520

On Thu, 26 Nov 2015 12:20 am, BartC wrote:

> 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 wouldn't try to guess what "most" people would expect. Their expectations
would depend on what exposure they have had with programming languages, if
any, what languages those are, and how well they grok the idea of
simulating code in their own head.



> 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 infinite loop is more sensible, and people would prefer the above
output. Who wants an infinite loop? That's nearly always a bug.

But consider why, bug or no bug, the Python version which leads to an
infinite series should be preferred over the other version. I can think of
at least three reasons why the Python behaviour is objectively better,
despite leading to an unwanted infinite loop in this specific case.

(1) The Python version avoids always making a copy of the (potentially huge)
list before looping over it. That makes the performance of for-loops more
predictable and avoids horrible surprises:

for x in L:
    break

takes the same amount of time to execute whether L has one item or a hundred
billion items. The for-loop *overhead* (as opposed to the cost of the loop
itself) is a fixed, small amount.


(2) The Python version has a cleaner, easier to understand execution model.
Apart from two obvious exceptions (on the left hand side of an assignment,
or following the "del" statement) all uses of the name L have the same
meaning. Whether you write:

    for x in L

    if "foo" in L

    while L

    L + [1, 2]

    len(L)

    L or []

    L.append(42)

or any other expression, all uses of the name L evaluate to the same thing:
the object currently bound to that name. You don't have to try to remember
which uses evaluate to the original object and which make a copy. It is
*never* a copy -- if you want a copy, you can copy it yourself. (Use the
copy module, copy.copy(L), or take a slice, L[:].)

The cost of this is that you are always responsible for making a copy, since
Python won't automatically do it for you (whether you want a copy or not).
But the benefit is that you avoid making unnecessary copies. 

I infer from the line "L append:= i" that your language doesn't always make
a copy (otherwise, how could you modify the original?). That means that
you, the programmer, still has to manage the copying of the list, exactly
the same as we have to do with Python. The difference is, Python doesn't
lure you into a false sense of security by *sometimes* making that copy for
you. The rules are:

"In Python, if you want a copy of the list, make a copy yourself."

versus:

"In BartC's language, if you want a copy of the list, look up the operation
you are about to do to see if it already makes a copy, and if it doesn't,
then make a copy yourself. (Otherwise, you might make two copies.)"


(3) What if you don't want a copy? How does one disable that feature? Or
does your language simply declare that "you can't do that"?

for item in queue:
    process(item)
    if condition: queue.append(something)


What's the most natural equivalent to that code snippet in your language?



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

I'm pretty sure that nobody said the behaviour was obvious in the sense of
predictable to those unfamiliar with the rules of the language. There's
even a FAQ about it.

There's a big difference between *obvious in advance* and *obvious in
hindsight once an explanation is given*.



-- 
Steven

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

#99447

On Wed, Nov 25, 2015 at 11:25 PM, Antoon Pardon
<antoon.pardon@rece.vub.ac.be> wrote:
>> 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.

There is also a big difference between finding that something doesn't
match your expectations and declaring that it is "bizarre", which
implies that it makes no sense *to anyone*. What we've been pointing
out to you is that Python's way *does* make sense - just a different
sense from the one you're expecting.

There are many design decisions in programming languages. I've used
languages that have myriad keywords, multiple levels of keywords (SQL
is a shocking mess in that area), or no keywords at all (in REXX, you
can legally write "if if then then; else else", and it interprets
three of those as structure-defining and three as identifiers). I've
used languages where everything's a statement, even basic arithmetic.
Some languages make you declare your local variables, while others
have you declare your globals instead. These are all viable choices,
and they all make sense. The languages are internally coherent. I
would not call any of them "bizarre", with the possible exception of
DeScribe Macro Language, and even that's not too hard to get your head
around. (I wouldn't want to use it for any sort of general
programming, though. Its sole value is manipulating the DeScribe Word
Processor, and if you were to use it for something else, you'd have to
expand the language lexicon. There's no system of extensibility.)

Expanding on one of those examples, here are three ways that you can
distinguish between local/nonlocal/global variables/names/etc:

/* C++: Declare everything at a specific scope. */
int global_variable = 1;

struct outer_scope
{
    int instance_variable;
    void inner_scope()
    {
        int local_variable = 3;
    }
};

/* PHP: Declare your globals, otherwise they're local. */
$global_variable = 1;
function outer_function()
{
    global $global_variable;
    $local_variable = 2;
    /* I don't trust PHP's nested functions. */
}

# Python: Declare any globals you want to rebind.
global_name = 1
def outer_function():
    nonlocal_name = 2
    def inner_function():
        global global_name
        local_name = 3

There are variations on these, too (like ECMAScript's "declare and
it's function local, else it's an attribute of the global object").
Anyway. Point is, each of these systems is internally consistent, and
in each one, you can explain in a single sentence what the rule is.
Not one of these is bizarre, but I do completely understand that
anyone who has experience with just one of them _would_ find either of
the others confusing at first. "Wait, why do you need to declare this
as global, but not that?" "You're not assigning to that one, so you
don't need to declare it."

If you want to call Python's system "bizarre", you have to show more
than just that your expectations weren't matched by the language. You
have to show that Python lacks internal sense or consistency. You
have, so far, not shown anything of the kind, ergo we are continuing
to insist that Python is NOT bizarre.

ChrisA

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

#99456

Op 25-11-15 om 14:24 schreef Chris Angelico:
> On Wed, Nov 25, 2015 at 11:25 PM, Antoon Pardon
> <antoon.pardon@rece.vub.ac.be> wrote:
>>> 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.
> There is also a big difference between finding that something doesn't
> match your expectations and declaring that it is "bizarre", which
> implies that it makes no sense *to anyone*. What we've been pointing
> out to you is that Python's way *does* make sense - just a different
> sense from the one you're expecting.

I find the above a very defensive attitude. People are mostly not
very accurate in how they put things into words. People tend to
say that something was delicious instead of saying that they
found it delicious. So when someone declares as aspect of python
to be bizarre I interpret that as an indication of what impression
that aspect made on that person instead of some declaration of fact.
So stop feeling attacked because someone found something bizarre.

You also seem to think that bizarre contradicts making sense. It
is entirly possible to understand what is going on and still find
it bizarre that the designers allowed for certain kinds or result.

> If you want to call Python's system "bizarre", you have to show more
> than just that your expectations weren't matched by the language. You
> have to show that Python lacks internal sense or consistency. You
> have, so far, not shown anything of the kind, ergo we are continuing
> to insist that Python is NOT bizarre.

No I don't have to show any such thing. There are things with an internal
sense of consistency that can be found utterly bizarre. I also find it
telling that you go from me talking about someone thinking that what is
going on in a specific aspect of python being bizarre, to regarding 
such a person as calling Python's system "bizarre", as if judging one
aspect is like judging the whole system. 

-- 
Antoon.

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

#99478

On 11/25/2015 4:25 AM, Antoon Pardon wrote:

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

Which I suspect is necessary.

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

That's something I've learned to figure out about any new language I 
pick up -- if parameters are passed by value or by reference, and 
secondly how to invoke a function appropriately for my specific use case.

Unfortunately, there are issues determining if python is in either camp, 
which certainly leads to confusion. see 
http://www.python-course.eu/passing_arguments.php or google "python pass 
by value or reference" for more examples.

Emile

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

#99421

On Wed, Nov 25, 2015 at 7:14 PM, Antoon Pardon
<antoon.pardon@rece.vub.ac.be> wrote:
> 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.

"Oh come on. It's basic arithmetic. You should be able to add 7 and
7... the result's 14!"

"But it's so confusing. Why can't it be 16? It'd be more convenient
for me if it were 16."

"This is just how arithmetic works."

"But it's still confusing!"

At some point, you have to simply accept that this is how the system
works.. or use a different system. (Octal maybe.) If you are
perpetually confused by Python, you need to either learn how Python
works, or use something else.

ChrisA

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

#99423

Chris Angelico <rosuav@gmail.com>:

> At some point, you have to simply accept that this is how the system
> works.. or use a different system. (Octal maybe.) If you are
> perpetually confused by Python, you need to either learn how Python
> works, or use something else.

You are mixing two things: protesting and being confused. Protesting
about a fundamental tenet is of no use, but talking about confusion
might help.

One psychological problem I'm seeing in many answers here is that people
seem to want to defend the honor of Python. It's very religion-like. New
potential converts are welcomed with open arms but when they start to
ask awkward questions, they are treated as suppressive persons.


Marko

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

#99436

On Wed, 25 Nov 2015 07:43 pm, Marko Rauhamaa wrote:

> One psychological problem I'm seeing in many answers here is that people
> seem to want to defend the honor of Python. 

No, your other honour!


(It's an Oglaf reference, and *definitely* not safe for work. I'm not even
going to link to it.)



-- 
Steven

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

#99442

On 25/11/2015 08:32, Chris Angelico wrote:
> On Wed, Nov 25, 2015 at 7:14 PM, Antoon Pardon
> <antoon.pardon@rece.vub.ac.be> wrote:
>> 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.
>
> "Oh come on. It's basic arithmetic. You should be able to add 7 and
> 7... the result's 14!"
>
> "But it's so confusing. Why can't it be 16? It'd be more convenient
> for me if it were 16."
>
> "This is just how arithmetic works."
>
> "But it's still confusing!"
>
> At some point, you have to simply accept that this is how the system
> works.. or use a different system. (Octal maybe.) If you are
> perpetually confused by Python, you need to either learn how Python
> works, or use something else.

What is the purpose of the language, to make things easier for people or 
what? And who is it for?

In other forums I've frequently recommended Python as an easy to learn 
language with a rapid development cycle. That was before I knew it had 
nearly as many quirks and gotchas as C!

That was in preference to other choices which I found difficult and also 
elitist because of the advanced knowledge of CS and mathematics that it 
seemed you were expected to know. (Eg Lisp, which has at least 4 
different ways of comparing for equality. Python only has two that I 
know of. A simple language would have only one, although my own has 
recently graduated from one to two; it's no longer simple!)

One gotcha at least is well known. Where, in a language of the least 
surprises, you might write:

  d1 = date (25,12,2010)
  d2 = d1
  d2.year += 1

You would expect d1 and d2 to represent a period one year apart. In 
Python, they would both be the later date.

OK, so both names are bound to the same object-value. So then you try this:

a = 10
b = a
b += 1

'+=' is an 'in-place add', so you might expect different semantics from 
'b = b+1'. But no, a isn't changed (disappointingly!).

Then, from the point of view of a beginner, you have two distinct ways 
of representing a list of objects: a tuple and a list. Exactly why there 
have to be two is never really made clear beyond the inadequate 
explanation that one is immutable and the other mutable.

OK, but now I have to continuously think about whether this 
multiple-set-of-objects is going to be a tuple or a list, or something 
else entirely (my date example above I think needs to be a class in 
Python, so that's a third way of doing things. Plus there is something 
called a 'set' that I haven't played with yet).

 > or use something else.

Python isn't as bad as some languages, but it's well on the way. But is 
there anything simpler around that is also well-supported?

-- 
Bartc

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

#99445

BartC <bc@freeuk.com>:

> That was in preference to other choices which I found difficult and
> also elitist because of the advanced knowledge of CS and mathematics
> that it seemed you were expected to know.

Python is not a toy. It is a tool for advanced programmers.

Mathematics has barely any touching point, but yes, solid CS fluency is
required to be a productive software developer regardless of the
programming language.

Is a plumber an elitist, when he prefers to use tools I wouldn't know
how to operate?

> One gotcha at least is well known. Where, in a language of the least
> surprises, you might write:
>
>  d1 = date (25,12,2010)
>  d2 = d1
>  d2.year += 1
>
> You would expect d1 and d2 to represent a period one year apart. In
> Python, they would both be the later date.

No elitism or expertise would help you "expect" any outcome. I wouldn't
even expect d2 to have a field called "year". That's why you read the
specification.

> Then, from the point of view of a beginner, you have two distinct ways
> of representing a list of objects: a tuple and a list. Exactly why
> there have to be two is never really made clear beyond the inadequate
> explanation that one is immutable and the other mutable.

From a functional point of view, there don't have to be two separate
concepts. The immutability of tuples is also just a design choice.

However, tuples are a way to represent records, groupings of related
values, where the semantics of each value is determined by its position
in the tuple. The members in a tuple are typically of different data
types.

Lists are collections of values. Typically, each member of list is of
the same type.

Tuples are handy because they allow you to treat multiple values as a
single value. Also, they are syntactically analogous to tuples in
mathematics so chances are you have encountered them in elementary
school. Finally, they are similar to function arguments, allowing you to
return multiple values the same way you pass multiple values to the
function.

> Python isn't as bad as some languages, but it's well on the way. But
> is there anything simpler around that is also well-supported?

My "simpler" is different from your "simpler". Even C# has a lot of
advanced concepts, as maybe even Fortran does nowadays.

My own recommendation would be Scheme, but it is even more "elitist"
than Python.


Marko

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

#99449

On 25/11/2015 13:06, Marko Rauhamaa wrote:
> BartC <bc@freeuk.com>:

>> Then, from the point of view of a beginner, you have two distinct ways
>> of representing a list of objects: a tuple and a list. Exactly why
>> there have to be two is never really made clear beyond the inadequate
>> explanation that one is immutable and the other mutable.

> However, tuples are a way to represent records, groupings of related
> values, where the semantics of each value is determined by its position
> in the tuple. The members in a tuple are typically of different data
> types.

Using tuples in the same way that other languages implement records is 
going to be difficult if you can't change the values of the fields!

> My "simpler" is different from your "simpler". Even C# has a lot of
> advanced concepts, as maybe even Fortran does nowadays.
>
> My own recommendation would be Scheme, but it is even more "elitist"
> than Python.

OK, Lisp. (I can't actually tell the difference.)

-- 
Bartc

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

#99453

BartC <bc@freeuk.com>:

> Using tuples in the same way that other languages implement records is
> going to be difficult if you can't change the values of the fields!

Guido could decide tomorrow that tuples are mutable. The decision is
more or less arbitrary, and has to do with dictionary keys, I bet (not a
particularly good reason).

Anyway, Python has two ways to represent records: classes and tuples.
Tuples are nice because they are concise and ad hoc. Often you start
with a scalar value, then turn it into a tuple. After a while your handy
tuple turns out a bit cumbersome to use so you convert it into an actual
class.


Marko

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

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

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

csiph-web