Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #98999 > unrolled thread
| Started by | fl <rxjwg98@gmail.com> |
|---|---|
| First post | 2015-11-18 13:08 -0800 |
| Last post | 2015-11-25 03:11 +1100 |
| Articles | 20 on this page of 198 — 24 participants |
Back to article view | Back to comp.lang.python
What is a function parameter =[] for? fl <rxjwg98@gmail.com> - 2015-11-18 13:08 -0800
Re: What is a function parameter =[] for? John Gordon <gordon@panix.com> - 2015-11-18 22:05 +0000
Re: What is a function parameter =[] for? Ian Kelly <ian.g.kelly@gmail.com> - 2015-11-18 15:11 -0700
Re: What is a function parameter =[] for? Grant Edwards <invalid@invalid.invalid> - 2015-11-18 22:33 +0000
Re: What is a function parameter =[] for? fl <rxjwg98@gmail.com> - 2015-11-18 14:38 -0800
Re: What is a function parameter =[] for? Ian Kelly <ian.g.kelly@gmail.com> - 2015-11-18 15:47 -0700
Re: What is a function parameter =[] for? fl <rxjwg98@gmail.com> - 2015-11-18 14:48 -0800
Re: What is a function parameter =[] for? BartC <bc@freeuk.com> - 2015-11-18 23:14 +0000
Re: What is a function parameter =[] for? Chris Angelico <rosuav@gmail.com> - 2015-11-19 10:22 +1100
Re: What is a function parameter =[] for? BartC <bc@freeuk.com> - 2015-11-19 01:41 +0000
Re: What is a function parameter =[] for? Chris Angelico <rosuav@gmail.com> - 2015-11-19 12:59 +1100
Re: What is a function parameter =[] for? BartC <bc@freeuk.com> - 2015-11-19 11:41 +0000
Re: What is a function parameter =[] for? Chris Angelico <rosuav@gmail.com> - 2015-11-19 22:58 +1100
Re: What is a function parameter =[] for? Steven D'Aprano <steve@pearwood.info> - 2015-11-19 23:45 +1100
Re: What is a function parameter =[] for? Ian Kelly <ian.g.kelly@gmail.com> - 2015-11-19 08:42 -0700
Re: What is a function parameter =[] for? Steven D'Aprano <steve@pearwood.info> - 2015-11-22 14:58 +1100
Re: What is a function parameter =[] for? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-11-24 13:38 +0100
Re: What is a function parameter =[] for? Steven D'Aprano <steve@pearwood.info> - 2015-11-25 04:29 +1100
Re: What is a function parameter =[] for? Ben Finney <ben+python@benfinney.id.au> - 2015-11-19 13:08 +1100
Re: What is a function parameter =[] for? Chris Angelico <rosuav@gmail.com> - 2015-11-19 13:15 +1100
Re: What is a function parameter =[] for? Ian Kelly <ian.g.kelly@gmail.com> - 2015-11-18 17:02 -0700
Re: What is a function parameter =[] for? Chris Angelico <rosuav@gmail.com> - 2015-11-19 11:14 +1100
Re: What is a function parameter =[] for? fl <rxjwg98@gmail.com> - 2015-11-18 16:34 -0800
Re: What is a function parameter =[] for? Ian Kelly <ian.g.kelly@gmail.com> - 2015-11-18 17:52 -0700
Re: What is a function parameter =[] for? MRAB <python@mrabarnett.plus.com> - 2015-11-19 01:02 +0000
Re: What is a function parameter =[] for? Ben Finney <ben+python@benfinney.id.au> - 2015-11-19 12:26 +1100
Re: What is a function parameter =[] for? Steven D'Aprano <steve@pearwood.info> - 2015-11-19 22:38 +1100
Re: What is a function parameter =[] for? Steven D'Aprano <steve@pearwood.info> - 2015-11-19 23:19 +1100
Re: What is a function parameter =[] for? BartC <bc@freeuk.com> - 2015-11-19 13:19 +0000
Re: What is a function parameter =[] for? Chris Angelico <rosuav@gmail.com> - 2015-11-20 00:45 +1100
Re: What is a function parameter =[] for? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-11-19 09:05 -0500
Re: What is a function parameter =[] for? Steven D'Aprano <steve@pearwood.info> - 2015-11-20 03:01 +1100
Re: What is a function parameter =[] for? Chris Angelico <rosuav@gmail.com> - 2015-11-20 04:30 +1100
Re: What is a function parameter =[] for? BartC <bc@freeuk.com> - 2015-11-19 17:30 +0000
Re: What is a function parameter =[] for? Chris Angelico <rosuav@gmail.com> - 2015-11-20 04:45 +1100
Re: What is a function parameter =[] for? BartC <bc@freeuk.com> - 2015-11-19 18:19 +0000
Re: What is a function parameter =[] for? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-11-19 18:26 +0000
Re: What is a function parameter =[] for? BartC <bc@freeuk.com> - 2015-11-19 18:50 +0000
Re: What is a function parameter =[] for? Chris Angelico <rosuav@gmail.com> - 2015-11-20 06:09 +1100
Re: What is a function parameter =[] for? BartC <bc@freeuk.com> - 2015-11-19 19:48 +0000
Re: What is a function parameter =[] for? Chris Angelico <rosuav@gmail.com> - 2015-11-20 06:58 +1100
Re: What is a function parameter =[] for? Steven D'Aprano <steve@pearwood.info> - 2015-11-20 11:26 +1100
Re: What is a function parameter =[] for? Ned Batchelder <ned@nedbatchelder.com> - 2015-11-19 16:36 -0800
Re: What is a function parameter =[] for? Laura Creighton <lac@openend.se> - 2015-11-20 02:00 +0100
Re: What is a function parameter =[] for? Ian Kelly <ian.g.kelly@gmail.com> - 2015-11-19 17:59 -0700
Re: What is a function parameter =[] for? Marko Rauhamaa <marko@pacujo.net> - 2015-11-19 20:39 +0200
Re: What is a function parameter =[] for? Ian Kelly <ian.g.kelly@gmail.com> - 2015-11-19 11:42 -0700
Re: What is a function parameter =[] for? Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2015-11-19 18:44 +0000
Re: What is a function parameter =[] for? Chris Angelico <rosuav@gmail.com> - 2015-11-20 06:19 +1100
Re: What is a function parameter =[] for? BartC <bc@freeuk.com> - 2015-11-19 21:21 +0000
Re: What is a function parameter =[] for? Michael Torrie <torriem@gmail.com> - 2015-11-19 15:55 -0700
Re: What is a function parameter =[] for? BartC <bc@freeuk.com> - 2015-11-20 00:11 +0000
Re: What is a function parameter =[] for? Ned Batchelder <ned@nedbatchelder.com> - 2015-11-19 16:27 -0800
Re: What is a function parameter =[] for? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-11-24 14:43 +0100
Re: What is a function parameter =[] for? Chris Angelico <rosuav@gmail.com> - 2015-11-25 01:00 +1100
Re: What is a function parameter =[] for? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-11-24 15:24 +0100
Re: What is a function parameter =[] for? Chris Angelico <rosuav@gmail.com> - 2015-11-25 01:34 +1100
Re: What is a function parameter =[] for? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-11-24 16:01 +0100
Re: What is a function parameter =[] for? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-11-24 16:03 +0100
Re: What is a function parameter =[] for? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-11-24 16:12 +0100
Re: What is a function parameter =[] for? Chris Angelico <rosuav@gmail.com> - 2015-11-25 02:17 +1100
Re: What is a function parameter =[] for? Steven D'Aprano <steve@pearwood.info> - 2015-11-25 04:54 +1100
Re: What is a function parameter =[] for? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-11-24 16:46 +0100
Re: What is a function parameter =[] for? Chris Angelico <rosuav@gmail.com> - 2015-11-25 02:48 +1100
Re: What is a function parameter =[] for? Random832 <random832@fastmail.com> - 2015-11-24 16:28 +0000
Re: What is a function parameter =[] for? Chris Angelico <rosuav@gmail.com> - 2015-11-25 03:38 +1100
Re: What is a function parameter =[] for? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-11-24 17:41 +0100
Re: What is a function parameter =[] for? Ian Kelly <ian.g.kelly@gmail.com> - 2015-11-24 09:56 -0700
Re: What is a function parameter =[] for? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-11-24 18:32 +0100
Re: What is a function parameter =[] for? Ian Kelly <ian.g.kelly@gmail.com> - 2015-11-24 10:53 -0700
Re: What is a function parameter =[] for? Ian Kelly <ian.g.kelly@gmail.com> - 2015-11-24 11:04 -0700
Re: What is a function parameter =[] for? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-11-24 19:45 +0100
Re: What is a function parameter =[] for? Ned Batchelder <ned@nedbatchelder.com> - 2015-11-24 10:54 -0800
Re: What is a function parameter =[] for? Random832 <random832@fastmail.com> - 2015-11-24 19:00 +0000
Re: What is a function parameter =[] for? Steven D'Aprano <steve@pearwood.info> - 2015-11-25 11:34 +1100
Re: What is a function parameter =[] for? Ian Kelly <ian.g.kelly@gmail.com> - 2015-11-24 12:15 -0700
Re: What is a function parameter =[] for? Ian Kelly <ian.g.kelly@gmail.com> - 2015-11-24 12:15 -0700
Re: What is a function parameter =[] for? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-11-24 21:54 +0100
Re: What is a function parameter =[] for? BartC <bc@freeuk.com> - 2015-11-24 21:14 +0000
Re: What is a function parameter =[] for? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-11-24 22:25 +0100
Re: What is a function parameter =[] for? Steven D'Aprano <steve@pearwood.info> - 2015-11-25 11:36 +1100
Re: What is a function parameter =[] for? Chris Angelico <rosuav@gmail.com> - 2015-11-25 11:56 +1100
Re: What is a function parameter =[] for? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-11-25 10:56 +0100
Re: What is a function parameter =[] for? Steven D'Aprano <steve@pearwood.info> - 2015-11-26 04:40 +1100
Re: What is a function parameter =[] for? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-11-25 19:27 +0100
Re: What is a function parameter =[] for? Steven D'Aprano <steve@pearwood.info> - 2015-11-26 11:10 +1100
Re: What is a function parameter =[] for? Ian Kelly <ian.g.kelly@gmail.com> - 2015-11-25 13:39 -0700
Re: What is a function parameter =[] for? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-11-25 22:05 +0100
Re: What is a function parameter =[] for? Chris Angelico <rosuav@gmail.com> - 2015-11-26 09:06 +1100
Re: What is a function parameter =[] for? Ian Kelly <ian.g.kelly@gmail.com> - 2015-11-25 15:38 -0700
Re: What is a function parameter =[] for? Alan Bawden <alan@csail.mit.edu> - 2015-11-25 21:08 -0500
Re: What is a function parameter =[] for? Chris Angelico <rosuav@gmail.com> - 2015-11-26 13:25 +1100
Re: What is a function parameter =[] for? Alan Bawden <alan@csail.mit.edu> - 2015-11-25 23:27 -0500
Re: What is a function parameter =[] for? Dave Farrance <df@see.replyto.invalid> - 2015-11-26 10:34 +0000
Re: What is a function parameter =[] for? Marko Rauhamaa <marko@pacujo.net> - 2015-11-26 12:58 +0200
Re: What is a function parameter =[] for? Dave Farrance <df@see.replyto.invalid> - 2015-11-26 11:12 +0000
Object identity has no necessary connection to memory location (was: What is a function parameter =[] for?) Ben Finney <ben+python@benfinney.id.au> - 2015-11-26 22:24 +1100
Re: Object identity has no necessary connection to memory location (was: What is a function parameter =[] for?) Dave Farrance <df@see.replyto.invalid> - 2015-11-26 11:50 +0000
Re: Object identity has no necessary connection to memory location Ben Finney <ben+python@benfinney.id.au> - 2015-11-27 07:00 +1100
Re: Object identity has no necessary connection to memory location Steven D'Aprano <steve@pearwood.info> - 2015-11-27 13:17 +1100
Re: Object identity has no necessary connection to memory location Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-11-26 21:44 +0000
Re: What is a function parameter =[] for? Chris Angelico <rosuav@gmail.com> - 2015-11-26 22:24 +1100
Re: What is a function parameter =[] for? Marko Rauhamaa <marko@pacujo.net> - 2015-11-26 13:27 +0200
Re: Object identity has no necessary connection to memory location (was: What is a function parameter =[] for?) Chris Angelico <rosuav@gmail.com> - 2015-11-26 22:49 +1100
Re: Object identity has no necessary connection to memory location Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-11-26 13:04 +0100
Re: What is a function parameter =[] for? Steven D'Aprano <steve@pearwood.info> - 2015-11-27 12:34 +1100
Re: What is a function parameter =[] for? Ben Finney <ben+python@benfinney.id.au> - 2015-11-27 12:40 +1100
Re: What is a function parameter =[] for? Steven D'Aprano <steve@pearwood.info> - 2015-11-27 13:44 +1100
Re: What is a function parameter =[] for? MRAB <python@mrabarnett.plus.com> - 2015-11-27 02:56 +0000
Re: What is a function parameter =[] for? Steven D'Aprano <steve@pearwood.info> - 2015-11-27 23:57 +1100
Re: What is a function parameter =[] for? Laura Creighton <lac@openend.se> - 2015-11-27 14:24 +0100
Re: What is a function parameter =[] for? Chris Angelico <rosuav@gmail.com> - 2015-11-28 00:29 +1100
Re: What is a function parameter =[] for? Chris Angelico <rosuav@gmail.com> - 2015-11-27 14:06 +1100
Re: What is a function parameter =[] for? Ben Finney <ben+python@benfinney.id.au> - 2015-11-27 15:56 +1100
Re: What is a function parameter =[] for? Random832 <random832@fastmail.com> - 2015-11-26 23:33 -0500
Re: What is a function parameter =[] for? Ian Kelly <ian.g.kelly@gmail.com> - 2015-11-25 19:46 -0700
Re: What is a function parameter =[] for? Chris Angelico <rosuav@gmail.com> - 2015-11-26 14:02 +1100
Re: What is a function parameter =[] for? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-11-26 09:15 +0100
Re: What is a function parameter =[] for? Ian Kelly <ian.g.kelly@gmail.com> - 2015-11-24 14:33 -0700
Re: What is a function parameter =[] for? Chris Angelico <rosuav@gmail.com> - 2015-11-25 09:09 +1100
Re: What is a function parameter =[] for? Ian Kelly <ian.g.kelly@gmail.com> - 2015-11-19 12:25 -0700
Re: What is a function parameter =[] for? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-11-19 18:20 +0000
Re: What is a function parameter =[] for? Steven D'Aprano <steve@pearwood.info> - 2015-11-20 12:05 +1100
Re: What is a function parameter =[] for? BartC <bc@freeuk.com> - 2015-11-20 11:59 +0000
Re: What is a function parameter =[] for? Ned Batchelder <ned@nedbatchelder.com> - 2015-11-20 04:12 -0800
Re: What is a function parameter =[] for? BartC <bc@freeuk.com> - 2015-11-20 12:39 +0000
Re: What is a function parameter =[] for? Chris Angelico <rosuav@gmail.com> - 2015-11-21 00:04 +1100
Re: What is a function parameter =[] for? Ned Batchelder <ned@nedbatchelder.com> - 2015-11-20 05:30 -0800
Re: What is a function parameter =[] for? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-11-20 08:34 -0500
Re: What is a function parameter =[] for? Random832 <random832@fastmail.com> - 2015-11-20 14:32 +0000
Re: What is a function parameter =[] for? Ian Kelly <ian.g.kelly@gmail.com> - 2015-11-20 09:18 -0700
Re: What is a function parameter =[] for? Steven D'Aprano <steve@pearwood.info> - 2015-11-22 23:01 +1100
Re: What is a function parameter =[] for? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-11-23 12:30 +1300
Re: What is a function parameter =[] for? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-11-24 15:38 +0100
Re: What is a function parameter =[] for? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-11-24 15:34 +0100
Re: What is a function parameter =[] for? Ned Batchelder <ned@nedbatchelder.com> - 2015-11-24 06:50 -0800
Re: What is a function parameter =[] for? Terry Reedy <tjreedy@udel.edu> - 2015-11-24 12:46 -0500
Re: What is a function parameter =[] for? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-11-24 19:27 +0100
Re: What is a function parameter =[] for? Marko Rauhamaa <marko@pacujo.net> - 2015-11-20 14:28 +0200
Re: What is a function parameter =[] for? BartC <bc@freeuk.com> - 2015-11-20 12:53 +0000
Re: What is a function parameter =[] for? Random832 <random832@fastmail.com> - 2015-11-20 14:35 +0000
Re: What is a function parameter =[] for? Steven D'Aprano <steve@pearwood.info> - 2015-11-22 21:06 +1100
Re: What is a function parameter =[] for? Marko Rauhamaa <marko@pacujo.net> - 2015-11-22 14:35 +0200
Re: What is a function parameter =[] for? Ian Kelly <ian.g.kelly@gmail.com> - 2015-11-20 09:16 -0700
Re: What is a function parameter =[] for? Marko Rauhamaa <marko@pacujo.net> - 2015-11-20 18:31 +0200
Re: What is a function parameter =[] for? Chris Angelico <rosuav@gmail.com> - 2015-11-21 03:37 +1100
Re: What is a function parameter =[] for? Ian Kelly <ian.g.kelly@gmail.com> - 2015-11-20 09:39 -0700
Re: What is a function parameter =[] for? Chris Angelico <rosuav@gmail.com> - 2015-11-21 03:24 +1100
Re: What is a function parameter =[] for? Ian Kelly <ian.g.kelly@gmail.com> - 2015-11-20 09:29 -0700
Re: What is a function parameter =[] for? Marko Rauhamaa <marko@pacujo.net> - 2015-11-20 18:41 +0200
Re: What is a function parameter =[] for? Chris Angelico <rosuav@gmail.com> - 2015-11-21 03:36 +1100
Re: What is a function parameter =[] for? Steven D'Aprano <steve@pearwood.info> - 2015-11-22 14:43 +1100
Re: What is a function parameter =[] for? BartC <bc@freeuk.com> - 2015-11-22 13:21 +0000
Re: What is a function parameter =[] for? BartC <bc@freeuk.com> - 2015-11-22 14:28 +0000
Re: What is a function parameter =[] for? Steven D'Aprano <steve@pearwood.info> - 2015-11-23 10:44 +1100
Re: What is a function parameter =[] for? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-11-23 00:04 +0000
Re: What is a function parameter =[] for? BartC <bc@freeuk.com> - 2015-11-23 00:37 +0000
Re: What is a function parameter =[] for? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-11-23 11:32 +0000
Re: What is a function parameter =[] for? Ned Batchelder <ned@nedbatchelder.com> - 2015-11-23 04:05 -0800
Re: What is a function parameter =[] for? Marko Rauhamaa <marko@pacujo.net> - 2015-11-23 14:23 +0200
Re: What is a function parameter =[] for? Chris Angelico <rosuav@gmail.com> - 2015-11-23 11:20 +1100
Re: What is a function parameter =[] for? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-11-23 12:43 +1300
Re: What is a function parameter =[] for? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-11-23 18:47 +1100
Re: What is a function parameter =[] for? BartC <bc@freeuk.com> - 2015-11-23 10:40 +0000
Re: What is a function parameter =[] for? Steven D'Aprano <steve@pearwood.info> - 2015-11-24 00:58 +1100
Re: What is a function parameter =[] for? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-11-24 15:58 +0100
Re: What is a function parameter =[] for? Steven D'Aprano <steve@pearwood.info> - 2015-11-25 04:56 +1100
Re: What is a function parameter =[] for? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-11-24 15:18 +0100
Re: What is a function parameter =[] for? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-11-24 14:48 +0100
Re: What is a function parameter =[] for? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-11-24 12:36 +0100
Re: What is a function parameter =[] for? Chris Angelico <rosuav@gmail.com> - 2015-11-24 23:07 +1100
Re: What is a function parameter =[] for? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-11-24 13:48 +0100
Re: What is a function parameter =[] for? Marko Rauhamaa <marko@pacujo.net> - 2015-11-24 14:57 +0200
Re: What is a function parameter =[] for? Ned Batchelder <ned@nedbatchelder.com> - 2015-11-24 06:18 -0800
Re: What is a function parameter =[] for? BartC <bc@freeuk.com> - 2015-11-24 14:43 +0000
Re: What is a function parameter =[] for? Chris Angelico <rosuav@gmail.com> - 2015-11-25 01:54 +1100
Re: What is a function parameter =[] for? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-11-24 16:10 +0100
Re: What is a function parameter =[] for? Ned Batchelder <ned@nedbatchelder.com> - 2015-11-24 07:27 -0800
Re: What is a function parameter =[] for? Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2015-11-24 17:25 +0000
Re: What is a function parameter =[] for? Ned Batchelder <ned@nedbatchelder.com> - 2015-11-24 09:35 -0800
Re: What is a function parameter =[] for? Marko Rauhamaa <marko@pacujo.net> - 2015-11-24 20:13 +0200
Re: What is a function parameter =[] for? Steven D'Aprano <steve@pearwood.info> - 2015-11-25 05:33 +1100
Re: What is a function parameter =[] for? Marko Rauhamaa <marko@pacujo.net> - 2015-11-24 21:17 +0200
Re: What is a function parameter =[] for? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-11-24 11:27 -0500
Re: What is a function parameter =[] for? Steven D'Aprano <steve@pearwood.info> - 2015-11-25 11:39 +1100
Re: What is a function parameter =[] for? Laura Creighton <lac@openend.se> - 2015-11-25 01:55 +0100
A name refers to an object, an object has a value, equality compares values (was: What is a function parameter =[] for?) Ben Finney <ben+python@benfinney.id.au> - 2015-11-25 13:17 +1100
Re: A name refers to an object, an object has a value, equality compares values Marko Rauhamaa <marko@pacujo.net> - 2015-11-25 08:44 +0200
Re: A name refers to an object, an object has a value, equality compares values Chris Angelico <rosuav@gmail.com> - 2015-11-25 19:27 +1100
Re: What is a function parameter =[] for? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-11-25 10:36 +0100
Re: What is a function parameter =[] for? Jussi Piitulainen <harvest@should.be.invalid> - 2015-11-25 13:39 +0200
Re: What is a function parameter =[] for? Marko Rauhamaa <marko@pacujo.net> - 2015-11-25 14:48 +0200
Re: What is a function parameter =[] for? Chris Angelico <rosuav@gmail.com> - 2015-11-26 00:50 +1100
Re: What is a function parameter =[] for? Marko Rauhamaa <marko@pacujo.net> - 2015-11-25 16:08 +0200
Re: What is a function parameter =[] for? Jussi Piitulainen <harvest@should.be.invalid> - 2015-11-25 17:13 +0200
Re: What is a function parameter =[] for? Marko Rauhamaa <marko@pacujo.net> - 2015-11-25 18:44 +0200
Re: What is a function parameter =[] for? Jussi Piitulainen <harvest@should.be.invalid> - 2015-11-25 20:30 +0200
Re: What is a function parameter =[] for? Steven D'Aprano <steve@pearwood.info> - 2015-11-25 03:11 +1100
Page 2 of 10 — ← Prev page 1 [2] 3 4 … 10 Next page →
| From | Ian Kelly <ian.g.kelly@gmail.com> |
|---|---|
| Date | 2015-11-18 17:02 -0700 |
| Message-ID | <mailman.433.1447891401.16136.python-list@python.org> |
| In reply to | #99010 |
On Wed, Nov 18, 2015 at 4:22 PM, Chris Angelico <rosuav@gmail.com> wrote: > On Thu, Nov 19, 2015 at 10:14 AM, BartC <bc@freeuk.com> wrote: >> So, looking at some source code, a default value for certain types is only >> certain to be that value for the very first call of that function? > > On the contrary, it is certain always to be that exact object. "Certain" may be a bit overly strong. >>> def f(x=42): ... return x ... >>> f() 42 >>> f.__defaults__ = (43,) >>> f() 43
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2015-11-19 11:14 +1100 |
| Message-ID | <mailman.435.1447892092.16136.python-list@python.org> |
| In reply to | #99010 |
On Thu, Nov 19, 2015 at 11:02 AM, Ian Kelly <ian.g.kelly@gmail.com> wrote: > On Wed, Nov 18, 2015 at 4:22 PM, Chris Angelico <rosuav@gmail.com> wrote: >> On Thu, Nov 19, 2015 at 10:14 AM, BartC <bc@freeuk.com> wrote: >>> So, looking at some source code, a default value for certain types is only >>> certain to be that value for the very first call of that function? >> >> On the contrary, it is certain always to be that exact object. > > "Certain" may be a bit overly strong. > >>>> def f(x=42): > ... return x > ... >>>> f() > 42 >>>> f.__defaults__ = (43,) >>>> f() > 43 I'll raise you one. >>> def f(x=42): ... return x ... >>> f() 42 >>> import ctypes >>> ctypes.c_int.from_address(id(43)+ ctypes.sizeof(ctypes.c_size_t) + ctypes.sizeof(ctypes.c_voidp)).value=42 >>> f.__defaults__ = (43,) >>> f() 42 >>> Nothing is certain in Python. And two wrongs can make a... hmm... no, this is not a right. It is not a privilege either. It is a dastardly trick played on people's minds. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | fl <rxjwg98@gmail.com> |
|---|---|
| Date | 2015-11-18 16:34 -0800 |
| Message-ID | <03515f27-fb4c-49f0-9f02-2f5b5a8d16e5@googlegroups.com> |
| In reply to | #99018 |
On Wednesday, November 18, 2015 at 7:15:05 PM UTC-5, Chris Angelico wrote: > On Thu, Nov 19, 2015 at 11:02 AM, Ian Kelly <ian.g.kelly@gmail.com> wrote: > > On Wed, Nov 18, 2015 at 4:22 PM, Chris Angelico <rosuav@gmail.com> wrote: > >> On Thu, Nov 19, 2015 at 10:14 AM, BartC <bc@freeuk.com> wrote: > >>> So, looking at some source code, a default value for certain types is only > >>> certain to be that value for the very first call of that function? > >> > >> On the contrary, it is certain always to be that exact object. > > > > "Certain" may be a bit overly strong. > > > >>>> def f(x=42): > > ... return x > > ... > >>>> f() > > 42 > >>>> f.__defaults__ = (43,) > >>>> f() > > 43 > > I'll raise you one. > > >>> def f(x=42): > ... return x > ... > >>> f() > 42 > >>> import ctypes > >>> ctypes.c_int.from_address(id(43)+ ctypes.sizeof(ctypes.c_size_t) + ctypes.sizeof(ctypes.c_voidp)).value=42 > >>> f.__defaults__ = (43,) > >>> f() > 42 > >>> > > Nothing is certain in Python. And two wrongs can make a... hmm... no, > this is not a right. It is not a privilege either. It is a dastardly > trick played on people's minds. > > ChrisA After I try with list1 = eList(12, [2]) and list1 = eList(12) it gives me new surprises. Even though I delete list1, the subsequent list1 = eList(12) will remember the number of '12' of the previous sequence. This is my new question: What does 'del' do? It does not look like a thorough list deletion from the effect. Thanks, ..................... list1 = eList(12, [2]) list1 Out[57]: [2, 12] list1 = eList(12) list1 Out[59]: [12, 12, 12] list1 = eList(12, [2]) list1 Out[61]: [2, 12] list1 = eList(12, [2]) list1 Out[63]: [2, 12] list1 = eList(12, [2]) list1 Out[65]: [2, 12] list1 = eList(12) list1 Out[67]: [12, 12, 12, 12] list1 = eList(12) list1 Out[69]: [12, 12, 12, 12, 12] list1 = eList(12, [2]) list1 Out[71]: [2, 12] list1 = eList(12) list1 Out[73]: [12, 12, 12, 12, 12, 12] del list1 list1 = eList(12, [2]) list1 = eList(12) list1 Out[77]: [12, 12, 12, 12, 12, 12, 12]
[toc] | [prev] | [next] | [standalone]
| From | Ian Kelly <ian.g.kelly@gmail.com> |
|---|---|
| Date | 2015-11-18 17:52 -0700 |
| Message-ID | <mailman.437.1447894395.16136.python-list@python.org> |
| In reply to | #99019 |
On Wed, Nov 18, 2015 at 5:34 PM, fl <rxjwg98@gmail.com> wrote: > After I try with > > list1 = eList(12, [2]) > > and > > list1 = eList(12) > > it gives me new surprises. Even though I delete list1, the subsequent > list1 = eList(12) > will remember the number of '12' of the previous sequence. This is my new > question: What does 'del' do? It does not look like a thorough list deletion > from the effect. It just deletes the variable list1, i.e. it unbinds the value from the name. It does nothing at all to the list that was bound, as other variables may still be bound to it. The core issue is that the default value of your eList function is always the same list. Assigning that list to a variable and then unassigning it is not going to change that.
[toc] | [prev] | [next] | [standalone]
| From | MRAB <python@mrabarnett.plus.com> |
|---|---|
| Date | 2015-11-19 01:02 +0000 |
| Message-ID | <mailman.438.1447894942.16136.python-list@python.org> |
| In reply to | #99019 |
On 2015-11-19 00:34, fl wrote: > On Wednesday, November 18, 2015 at 7:15:05 PM UTC-5, Chris Angelico wrote: >> On Thu, Nov 19, 2015 at 11:02 AM, Ian Kelly <ian.g.kelly@gmail.com> wrote: >> > On Wed, Nov 18, 2015 at 4:22 PM, Chris Angelico <rosuav@gmail.com> wrote: >> >> On Thu, Nov 19, 2015 at 10:14 AM, BartC <bc@freeuk.com> wrote: >> >>> So, looking at some source code, a default value for certain types is only >> >>> certain to be that value for the very first call of that function? >> >> >> >> On the contrary, it is certain always to be that exact object. >> > >> > "Certain" may be a bit overly strong. >> > >> >>>> def f(x=42): >> > ... return x >> > ... >> >>>> f() >> > 42 >> >>>> f.__defaults__ = (43,) >> >>>> f() >> > 43 >> >> I'll raise you one. >> >> >>> def f(x=42): >> ... return x >> ... >> >>> f() >> 42 >> >>> import ctypes >> >>> ctypes.c_int.from_address(id(43)+ ctypes.sizeof(ctypes.c_size_t) + ctypes.sizeof(ctypes.c_voidp)).value=42 >> >>> f.__defaults__ = (43,) >> >>> f() >> 42 >> >>> >> >> Nothing is certain in Python. And two wrongs can make a... hmm... no, >> this is not a right. It is not a privilege either. It is a dastardly >> trick played on people's minds. >> >> ChrisA > > After I try with > > list1 = eList(12, [2]) > If you pass something into the parameter, the default isn't needed/used. > and > > list1 = eList(12) > You're not passing anything into the parameter, so the default is used. > it gives me new surprises. Even though I delete list1, the subsequent > list1 = eList(12) > will remember the number of '12' of the previous sequence. This is my new > question: What does 'del' do? It does not look like a thorough list deletion > from the effect. > No, "del list1" doesn't delete the list, it deletes the name "list1". The list still exists as the default parameter. A default parameter is evaluated when the function is defined, and that value exists as the default as long as the function exists. If the value is mutable (can be modified), and you modify it, then the function will see that modified value.
[toc] | [prev] | [next] | [standalone]
| From | Ben Finney <ben+python@benfinney.id.au> |
|---|---|
| Date | 2015-11-19 12:26 +1100 |
| Message-ID | <mailman.439.1447896413.16136.python-list@python.org> |
| In reply to | #99019 |
MRAB <python@mrabarnett.plus.com> writes: > On 2015-11-19 00:34, fl wrote: > > What does 'del' do? It does not look like a thorough list deletion > > from the effect. > > No, "del list1" doesn't delete the list, it deletes the name "list1". > The list still exists as the default parameter. More generally, ‘del’ deletes a *reference*. Names are one kind of reference; others include items in a collection such as a dict or set. Deleting a reference *never* affects the value referred to. However, once a value has no more references, the program can no longer access it, so the Python machine is at liberty to delete the value behind the scenes at some future point. > A default parameter is evaluated when the function is defined, and > that value exists as the default as long as the function exists. So, because the function retains a reference to the value, the value remains unaffected when you delete the reference ‘list1’. -- \ “True greatness is measured by how much freedom you give to | `\ others, not by how much you can coerce others to do what you | _o__) want.” —Larry Wall | Ben Finney
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2015-11-19 22:38 +1100 |
| Message-ID | <564db4a5$0$1604$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #99019 |
On Thu, 19 Nov 2015 11:34 am, fl wrote:
> This is my new
> question: What does 'del' do? It does not look like a thorough list
> deletion from the effect.
Of course not. Did you Read The Fine Manual? Or at least use the interactive
help function? At the Python prompt, enter:
help("del")
and you will see an explanation which includes this:
Deletion of a name removes the binding of that name from
the local or global namespace, depending on whether the
name occurs in a ``global`` statement in the same code
block. If the name is unbound, a ``NameError`` exception
will be raised.
Let us try it with the interactive interpreter:
If the name "x" doesn't exist, and you try to delete it, you get an error:
py> del x
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
NameError: name 'x' is not defined
If "x" does exist, and you delete it, the name no longer exists:
py> x = 42
py> print(x)
42
py> del x
py> print(x)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
NameError: name 'x' is not defined
So "del" deletes **names**.
What happens after the name is deleted? Then the garbage collector may run,
and destroy the object that was bound to the name, reclaiming the memory
used. But **only** if the object is safe to destroy, otherwise that would
lead to segmentation faults and memory corruption.
Here we have ONE object with TWO names:
py> a = [1, 2, 3, 4]
py> b = a
py> b.append(999)
py> print(a)
[1, 2, 3, 4, 999]
If we delete one of those names, the other name keeps the list alive:
py> del a
py> print(b)
[1, 2, 3, 4, 999]
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2015-11-19 23:19 +1100 |
| Message-ID | <564dbe6b$0$1610$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #99010 |
On Thu, 19 Nov 2015 10:14 am, BartC wrote:
> On 18/11/2015 22:11, Ian Kelly wrote:
>> The list0 parameter has a default value, which is [], an initially
>> empty list. The default value is evaluated when the function is
>> defined, not when it is called, so the same list object is used each
>> time and changes to the list are consequently retained between calls.
>
> That is really bizarre behaviour.
It is standard early binding behaviour, applied to function defaults.
Early versus late binding crops up in many places when programming:
https://support.microsoft.com/en-us/kb/245115
http://javascript.info/tutorial/binding
https://msdn.microsoft.com/en-us/library/0tcf61s1.aspx
Unfortunately, like many evocative or useful terms in computing, it the term
isn't used consistently. There are at least two related, but distinct, uses
for "early/late binding", and Wikipedia only talks about the *other* one:
https://en.wikipedia.org/wiki/Late_binding
In Python terms, *all* (or nearly all?) name binding (assignment) is
equivalent to C++ late binding, a.k.a. "dynamic dispatch". But Python also
uses early/late binding to refer to when the default object is assigned.
Consider this pair of functions:
def expensive():
# Simulate some expensive calculation or procedure.
time.sleep(100)
return random.randint(1, 6)
def demo(arg=expensive()):
return arg + 1
Now we call the second function four times, without an argument so that the
default value is used:
demo()
demo()
demo()
demo()
What results do you expect?
There are two standard behaviours:
Early binding means that the default value is generated *once*, when the
function `demo` is created. That's expensive, but it only gets used once,
and the default value is now fixed, and can be retrieved almost instantly
in subsequent calls. That's what Python uses.
Late binding means that the default value is generated every time you call
the function. That's expensive, and confusing. Why is the function
parameter list being re-evaluated each time the function is called? Why is
the default value different each time I call the function? Now *that's*
bizarre.
Compared to the weirdness of late binding, Python's early binding makes much
more sense.
Another advantage of early binding is that it involves a consistent
execution model: only the function body is executed when you call the
function, not the function declaration and parameter list.
def demo(arg=expensive()): # declaration, including the parameter list
# function body is indented
Now it is easy to tell which part gets executed when: just look at the
indentation.
Both early and late binding are useful, so which should a language default
to? (Assuming it doesn't offer both.) I think that there is absolutely no
doubt that function defaults should use early binding. The overwhelming
advantage of early binding is this:
- if the language defaults to early binding, it is *easy* for the
programmer to get late binding semantics;
- if the language defaults to late binding, it is *very difficult*
for the programmer to get early binding semantics.
Given early binding, like Python has, it is easy to get late binding
semantics. All you have to do is use a sentinel value, and move the code
you want to execute every time the function is called into the body of the
function. The most common sentinel is None:
def demo(arg=None):
if arg is None:
arg = expensive()
...
Now it is obvious that expensive() will be called each time you call demo()
(with no argument provided), since the call to expensive is inside the
function body.
But let's try going the other way. Suppose function defaults were evaluated
each and every time you called the function. How could you *avoid* the
expense and waste of re-evaluating the default over and over again?
You can't, or at least, not cleanly and easily. The most obvious way is to
use a global variable:
ARG = expensive()
def demo(arg=ARG):
...
This is ... horrible. You are still evaluating the default each time, but at
least it is only a global variable lookup, not an expensive function call.
But the cost is great. Now you have to pollute the module with a global
variable for every function that has a default value. This breaks
encapsulation -- the default value for the function is no longer visible in
the function's declaration, you have to hunt for it through your module.
And what if somebody changes the global, or deletes it?
> So, looking at some source code, a default value for certain types is
> only certain to be that value for the very first call of that function?
When you deal with mutable objects, you have to expect them to mutate. The
whole point of mutability is that their value can change.
If you use a mutable default object, it is still mutable, and can change its
value. If you don't want that, then use an immutable object.
> > The default value is evaluated when the function is
> > defined, not when it is called
>
> Given the amount of pointless dynamic stuff that goes on in Python, I'm
> surprised they've overlooked this one!
>
> It seems simple enough to me to check for a missing parameter, and to
> assign whatever default value was designated ([] in this case). (How
> does the default mechanism work now?)
What "seems" simple is not simple. The function default is not guaranteed to
be a simple literal. Defaults are arbitrarily complex expressions:
def func(a, b=[1, x] + [random.random() for i in range(x**4)]): ...
So you have to store that expression:
[1, x] + [random.random() for i in range(x**4)]
together with enough information to know which scope it will be evaluated
in. And you have to decide: should that be a closure, or a regular function
call? Whichever decision you make, you will make some people unhappy.
There are consequences of your choice:
- Assuming that "x" is a global variable, then making the expression a
closure will mean that the value of x is kept alive, possibly long after
the default value is no longer needed.
- But if you make the expression a non-closure, then the caller is
responsible for ensuring that x is not deleted. If it is deleted, then you
will get a NameError trying to evaluate the default value.
Whichever option you choose, there will be a multitude of people on the
internet telling you that you got it wrong.
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-11-19 13:19 +0000 |
| Message-ID | <n2ki4t$aqj$1@dont-email.me> |
| In reply to | #99053 |
On 19/11/2015 12:19, Steven D'Aprano wrote: > On Thu, 19 Nov 2015 10:14 am, BartC wrote: > Consider this pair of functions: > > > def expensive(): > # Simulate some expensive calculation or procedure. > time.sleep(100) > return random.randint(1, 6) > > > def demo(arg=expensive()): > return arg + 1 > > > Now we call the second function four times, without an argument so that the > default value is used: > > demo() > demo() > demo() > demo() > > What results do you expect? If someone /wants/ expensive() to be called each time, then why not? If they don't, then it seems easy enough to write: demo_default=expensive() def demo(arg=demo_default): ... (As you mention later...) > - if the language defaults to early binding, it is *easy* for the > programmer to get late binding semantics; > > - if the language defaults to late binding, it is *very difficult* > for the programmer to get early binding semantics. I got the impression that Python was a nice, easy language for everyone to use. Not one where you need a Master's degree in CS to understand the nuances of! And to understand why something that is so blindingly obvious doesn't work. > But let's try going the other way. Suppose function defaults were evaluated > each and every time you called the function. How could you *avoid* the > expense and waste of re-evaluating the default over and over again? I use default parameters a lot in other languages. 99% of the time the default value is a constant. And most often that constant is 0, "" or an empty list. You want these very common examples to /just work/ instead of going to lengths trying to explain why they don't. > You can't, or at least, not cleanly and easily. The most obvious way is to > use a global variable: > > ARG = expensive() > > def demo(arg=ARG): > ... > > This is ... horrible. You are still evaluating the default each time, I implement an interpreted language where these calls: demo() demo(ARG) would have exactly the same cost. I understand that Python is very different: at the call-site, the compiler has no idea of the number of arguments a function defines or what the default values might be, or even if it is a function that is being called. But even under those circumstances, I would endeavour to make such a function call as fast as is practical. (That could involve a runtime check on number of parameters, substituting the equivalent of None for missing ones, or whatever default expression has been declared. But here, I am benefiting from my language not being Python which does seem to like making things difficult.) > but at > least it is only a global variable lookup, Maybe you can wrap the entire module inside a function? Other than a bit at the end that calls that function. Does that solve the global lookup problem? > When you deal with mutable objects, you have to expect them to mutate. The > whole point of mutability is that their value can change. That [] doesn't look like an object that could change. It looks like an empty list constructor. You would expect a constructor for an empty list to yield an empty list throughout a program! (As it does, in most other contexts.) You presumably think differently because you have some inside knowledge of how Python works, and know that that [] undergoes a one-time assignment to a local, persistent 'default' variable where it's value can indeed by changed. (Thanks to another Python feature where an assignment is a very shallow copy of an object.) And it is that volatile variable that is the actual default. But not everyone is going to know that. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2015-11-20 00:45 +1100 |
| Message-ID | <mailman.459.1447940722.16136.python-list@python.org> |
| In reply to | #99056 |
On Fri, Nov 20, 2015 at 12:19 AM, BartC <bc@freeuk.com> wrote: > You presumably think differently because you have some inside knowledge of > how Python works, and know that that [] undergoes a one-time assignment to a > local, persistent 'default' variable where it's value can indeed by changed. > (Thanks to another Python feature where an assignment is a very shallow copy > of an object.) And it is that volatile variable that is the actual default. > > But not everyone is going to know that. Correct: We think certain things because we understand how Python behaves. You, too, can join the Inner Circle of Pythonistas; all you have to do is read this (and/or watch the video): http://nedbatchelder.com/text/names1.html ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Dennis Lee Bieber <wlfraed@ix.netcom.com> |
|---|---|
| Date | 2015-11-19 09:05 -0500 |
| Message-ID | <mailman.460.1447941957.16136.python-list@python.org> |
| In reply to | #99056 |
On Thu, 19 Nov 2015 13:19:25 +0000, BartC <bc@freeuk.com> declaimed the
following:
>You presumably think differently because you have some inside knowledge
>of how Python works, and know that that [] undergoes a one-time
>assignment to a local, persistent 'default' variable where it's value
>can indeed by changed. (Thanks to another Python feature where an
>assignment is a very shallow copy of an object.) And it is that volatile
>variable that is the actual default.
>
>But not everyone is going to know that.
If one has not taken time to read the language reference manual and/or
tutorials, one should expect to be taken by surprise.
This behavior has existed in Python from the beginning... That's over
20 years now. It is DOCUMENTED -- in documents that come with every
standard installation of the language, not something one needs to hunt
down. It should not be a surprise to anyone who has taken the time to read
and understand the documentation -- or, at least, has searched the
documentation once they have been surprised (I'll concede that one
read-through at the start may not be sufficient <G>; one may need to
encounter a behavior before the documentation for it makes sense).
Python 2.7 LRM section 7.6 Function Definitions:
"""
Default parameter values are evaluated when the function definition is
executed. This means that the expression is evaluated once, when the
function is defined, and that the same “pre-computed” value is used for
each call. This is especially important to understand when a default
parameter is a mutable object, such as a list or a dictionary: if the
function modifies the object (e.g. by appending an item to a list), the
default value is in effect modified. This is generally not what was
intended. A way around this is to use None as the default, and explicitly
test for it in the body of the function, e.g.:
"""
(and the first sentence is even BOLDED)
But in no way is this "inside knowledge". There is no cabal of folks
hoarding arcana from the rest of the public.
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2015-11-20 03:01 +1100 |
| Message-ID | <564df258$0$1604$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #99056 |
On Fri, 20 Nov 2015 12:19 am, BartC wrote:
> On 19/11/2015 12:19, Steven D'Aprano wrote:
>> On Thu, 19 Nov 2015 10:14 am, BartC wrote:
>
>> Consider this pair of functions:
>>
>>
>> def expensive():
>> # Simulate some expensive calculation or procedure.
>> time.sleep(100)
>> return random.randint(1, 6)
>>
>>
>> def demo(arg=expensive()):
>> return arg + 1
[...]
> If someone /wants/ expensive() to be called each time, then why not? If
> they don't, then it seems easy enough to write:
>
> demo_default=expensive()
> def demo(arg=demo_default):
> ...
>
> (As you mention later...)
Yes, I mentioned it, and you seem to have failed to understand why that is a
horrible solution that causes more problems than it solves.
It breaks encapsulation -- data which belongs to the function has to be
stored outside the function, in a global variable, where just anybody or
anything could come along and modify it or delete it. It pollutes the
namespace -- imagine a module with twenty functions, each function having
four or five arguments that take default values. That's 80 to 100 global
variables, which all need to have unique names.
Yuck.
>> - if the language defaults to early binding, it is *easy* for the
>> programmer to get late binding semantics;
>>
>> - if the language defaults to late binding, it is *very difficult*
>> for the programmer to get early binding semantics.
>
> I got the impression that Python was a nice, easy language for everyone
> to use. Not one where you need a Master's degree in CS to understand the
> nuances of! And to understand why something that is so blindingly
> obvious doesn't work.
Master's degree in CS, ha ha very funny. Not.
You know, for somebody who claims to design and implement your own
languages, you sometimes go to a remarkable effort to claim to be a dummy.
You write your own interpreter, but can't understand early versus late
binding? I don't think so.
I understand that the simplest things can be perplexing if you look at them
the wrong way. But we've explained multiply times now, or at least tried to
explain, that the argument default is a single object. That is blindingly
obvious once you look at it the right way, and it is a nice, clean design.
There's no need to introduce extra modes where code has to be stored away
to be evaluated later (apart from the body of the function itself).
Everything works the same way: assignment always evaluates a result and
binds it to the name, whether that assignment is in a parameter list or
not.
If you insist on thinking about it in terms of how C or Pascal work, of
course you will confuse yourself. The argument default is evaluated when
the function is created, and the resulting object is stored away for later
use, inside the function. That is clean and easy to understand.
I'm not saying that the behaviour with mutable defaults isn't surprising to
somebody coming from a completely different paradigm. I was surprised by it
too, the first time I got bitten. But surprising doesn't equal *wrong*. The
reason it was surprising to me was because I didn't think through the
implications of what I already knew. I knew the default value was
calculated once. I knew that the list was mutable. But I never put 2 and 2
together to get 4.
If you have a list which is created once, and modify it, the second time you
use it, it will be modified. Well duh. In hindsight, I shouldn't have been
surprised. The fact that I was is *my* failure.
It might be surprising the *first* time you see it, because you failed to
think it through. If you modify the object, *naturally* it will be
modified. Or if you failed to understand that the object was created once
and once only.
The interesting thing is, I've seen people write code *in the same program*
which assumed early binding in one function and late binding in another.
*Whichever* choice Python made, their program would have broken in one
place or the other. I don't believe that people have an inherent
expectation of one or the other. I believe that people expect whichever is
more convenient for them at the time, and get disappointed when it doesn't
work.
>> But let's try going the other way. Suppose function defaults were
>> evaluated each and every time you called the function. How could you
>> *avoid* the expense and waste of re-evaluating the default over and over
>> again?
>
> I use default parameters a lot in other languages.
>
> 99% of the time the default value is a constant.
Well, if it's a constant, then (apart from efficiency) early binding and
late binding makes *absolutely no difference*. Watch:
py> def demo_const(x, y=[]):
... return x + len(y)
...
py> demo_const(5)
5
py> demo_const(5)
5
Exactly as you should expect. Where you run into trouble is when the default
value is NOT a constant:
py> def demo_variable(x, y=[]):
... y.append(1)
... return x + len(y)
...
py> demo_variable(5)
6
py> demo_variable(5)
7
py> demo_variable(5)
8
If you modify the value, the value will be modified. Why are you surprised
by this?
> And most often that constant is 0, "" or an empty list.
>
> You want these very common examples to /just work/ instead of going to
> lengths trying to explain why they don't.
Ah, the good-old "I shouldn't have to think to understand programming" model
of programming. Because that works so well.
[...]
> Maybe you can wrap the entire module inside a function? Other than a bit
> at the end that calls that function. Does that solve the global lookup
> problem?
No.
>> When you deal with mutable objects, you have to expect them to mutate.
>> The whole point of mutability is that their value can change.
>
> That [] doesn't look like an object that could change.
Of course it does. It is a list literal, like int literals, float literals,
string literals and the rest. The only difference is that lists are mutable
and ints and strings are not.
> It looks like an
> empty list constructor. You would expect a constructor for an empty list
> to yield an empty list throughout a program! (As it does, in most other
> contexts.)
You could write the function like this:
def test(arg=list()):
...
and it would make no difference. You could write it like this:
def test(arg=list() if isprime(104729) else "Surprise!"):
...
and you would still get the same result. In fact, you could even write it
like this:
if isprime(104729):
def test(arg=[]):
...
else:
def test(arg="Surprise!"):
...
> You presumably think differently because you have some inside knowledge
> of how Python works, and know that that [] undergoes a one-time
> assignment to a local, persistent 'default' variable where it's value
> can indeed by changed. (Thanks to another Python feature where an
> assignment is a very shallow copy of an object.) And it is that volatile
> variable that is the actual default.
Assignments are not copies at all.
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2015-11-20 04:30 +1100 |
| Message-ID | <mailman.471.1447954229.16136.python-list@python.org> |
| In reply to | #99066 |
On Fri, Nov 20, 2015 at 3:01 AM, Steven D'Aprano <steve@pearwood.info> wrote: > You know, for somebody who claims to design and implement your own > languages, you sometimes go to a remarkable effort to claim to be a dummy. > You write your own interpreter, but can't understand early versus late > binding? I don't think so. I'm not sure that's such a fair comparison. Anyone can design a brand-new language, and even implementing one isn't all that hard. If you don't understand other languages, you can certainly create the one that always does what you think most intuitive, right at the instant when you designed/implemented some feature. What's hard is designing a clean language that does what _someone else_ expects. (And that includes yourself in six months.) ChrisA
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-11-19 17:30 +0000 |
| Message-ID | <n2l0s3$5l6$1@dont-email.me> |
| In reply to | #99066 |
On 19/11/2015 16:01, Steven D'Aprano wrote:
> On Fri, 20 Nov 2015 12:19 am, BartC wrote:
> You know, for somebody who claims to design and implement your own
> languages, you sometimes go to a remarkable effort to claim to be a dummy.
> You write your own interpreter, but can't understand early versus late
> binding? I don't think so.
No I don't; so? Maybe my interpreter can do its thing without being
aware that what it's doing has been called 'late binding' or 'early
binding' by someone else.
At least its default values work as expected! (And they can also be
applied to existing external functions. Even C API functions where the
implementation doesn't support these features.
So if an argument is missing, it applies the default I specify in its
place. It's that simple.)
> I understand that the simplest things can be perplexing if you look at them
> the wrong way. But we've explained multiply times now, or at least tried to
> explain, that the argument default is a single object. That is blindingly
> obvious once you look at it the right way, and it is a nice, clean design.
I can understand now how it works as it does. But I still think it is
unintuitive. A language design could have chosen to make it work however
it liked.
> There's no need to introduce extra modes where code has to be stored away
> to be evaluated later (apart from the body of the function itself).
> Everything works the same way: assignment always evaluates a result and
> binds it to the name, whether that assignment is in a parameter list or
> not.
>
> If you insist on thinking about it in terms of how C or Pascal work, of
> course you will confuse yourself. The argument default is evaluated when
> the function is created, and the resulting object is stored away for later
> use, inside the function. That is clean and easy to understand.
>
> I'm not saying that the behaviour with mutable defaults
The whole concept of 'mutable' default is alien to me. A default is just
a convenient device to avoid having to write:
fn(0) or fn("") or fn([])
You just write fn() instead. But it shouldn't come at the cost of
completely different semantics! Because then it can't really be called a
default value at all.
isn't surprising to
> somebody coming from a completely different paradigm. I was surprised by it
> too, the first time I got bitten.
So you didn't bother reading the LRM either!
> py> def demo_const(x, y=[]):
> ... return x + len(y)
> Exactly as you should expect. Where you run into trouble is when the default
> value is NOT a constant:
>
> py> def demo_variable(x, y=[]):
> ... y.append(1)
> ... return x + len(y)
Sorry, what is the default value in each of these? As the first lines of
the defintions look identical apart from the function names.
> ...
> py> demo_variable(5)
> 6
> py> demo_variable(5)
> 7
> py> demo_variable(5)
> 8
>
>
> If you modify the value, the value will be modified. Why are you surprised
> by this?
Which value is being modified? The []?
>> And most often that constant is 0, "" or an empty list.
>>
>> You want these very common examples to /just work/ instead of going to
>> lengths trying to explain why they don't.
>
> Ah, the good-old "I shouldn't have to think to understand programming" model
> of programming. Because that works so well.
It works well when sharing code because not everyone understands things
at the same level.
>> Maybe you can wrap the entire module inside a function? Other than a bit
>> at the end that calls that function. Does that solve the global lookup
>> problem?
>
> No.
Why not?
>
>>> When you deal with mutable objects, you have to expect them to mutate.
>>> The whole point of mutability is that their value can change.
>>
>> That [] doesn't look like an object that could change.
>
> Of course it does.
You've lost me know.
Are you saying that:
a=[]
why sometimes not assign an empty list, because that [] could have been
modified?
It is a list literal, like int literals, float literals,
> string literals and the rest.
Another surprise? Literals by definition can't change:
def fn():
a=[10,20,30]
a.append(999)
I would hope that a is set to [10,20,30] at each entry to the function!
>> You presumably think differently because you have some inside knowledge
>> of how Python works, and know that that [] undergoes a one-time
>> assignment to a local, persistent 'default' variable where it's value
>> can indeed by changed. (Thanks to another Python feature where an
>> assignment is a very shallow copy of an object.) And it is that volatile
>> variable that is the actual default.
>
> Assignments are not copies at all.
if you write A=B then something of B needs to have been copied into A,
even if it's just the reference that B contains. Otherwise it would be
difficult to get A to refer to the same object as B.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2015-11-20 04:45 +1100 |
| Message-ID | <mailman.473.1447955117.16136.python-list@python.org> |
| In reply to | #99074 |
On Fri, Nov 20, 2015 at 4:30 AM, BartC <bc@freeuk.com> wrote:
> The whole concept of 'mutable' default is alien to me. A default is just a
> convenient device to avoid having to write:
>
> fn(0) or fn("") or fn([])
>
> You just write fn() instead. But it shouldn't come at the cost of completely
> different semantics! Because then it can't really be called a default value
> at all.
>
Do you understand the concept of "mutable objects"? Don't even try to
discuss mutable function defaults until you do.
If your language simply has no mutable objects, then sure, it's easy
to understand function defaults! There's no such thing as early or
late binding; in fact, you can even super-late-bind, where you don't
actually call a function until its *return value* is being used (as
long as that function has no side effects). But as soon as objects are
capable of retaining their identities while changing their values, you
need an object model that (a) distinguishes between identity and
value, and (b) allows some definition of early or late binding,
because it *will* matter.
> if you write A=B then something of B needs to have been copied into
> A, even if it's just the reference that B contains. Otherwise it would be
> difficult to get A to refer to the same object as B.
Please, PLEASE, go and read/watch Ned's PyCon talk (the one I linked
you to earlier). Don't post another word on this subject until you
comprehend what he is saying.
ChrisA
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-11-19 18:19 +0000 |
| Message-ID | <n2l3ne$hbp$1@dont-email.me> |
| In reply to | #99076 |
On 19/11/2015 17:45, Chris Angelico wrote:
> On Fri, Nov 20, 2015 at 4:30 AM, BartC <bc@freeuk.com> wrote:
>> The whole concept of 'mutable' default is alien to me. A default is just a
>> convenient device to avoid having to write:
>>
>> fn(0) or fn("") or fn([])
>>
>> You just write fn() instead. But it shouldn't come at the cost of completely
>> different semantics! Because then it can't really be called a default value
>> at all.
>>
>
> Do you understand the concept of "mutable objects"? Don't even try to
> discuss mutable function defaults until you do.
Yes. In the languages I create, pretty much everything is mutable,
provided it can supply an l-value. Constructs such as those for empty
lists ([] in Python, () in mine) aren't l-values.
But it doesn't apply default values. The language is very different
however, because the byte-code compiler always has full knowledge of
functions that are called directly. Then it knows when an argument is
omitted, and can simply substitute the expression used as the default.
> If your language simply has no mutable objects, then sure, it's easy
> to understand function defaults! There's no such thing as early or
> late binding; in fact, you can even super-late-bind, where you don't
> actually call a function until its *return value* is being used (as
> long as that function has no side effects). But as soon as objects are
> capable of retaining their identities while changing their values, you
> need an object model that (a) distinguishes between identity and
> value, and (b) allows some definition of early or late binding,
> because it *will* matter.
>
>> if you write A=B then something of B needs to have been copied into
>> A, even if it's just the reference that B contains. Otherwise it would be
>> difficult to get A to refer to the same object as B.
>
> Please, PLEASE, go and read/watch Ned's PyCon talk (the one I linked
> you to earlier). Don't post another word on this subject until you
> comprehend what he is saying.
I looked through the long article (I don't remember seeing a link to a
video), and followed it up to about 3/4 of the way through, then it got
a bit heavy.
But what is it about my remarks above that isn't right?
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2015-11-19 18:26 +0000 |
| Message-ID | <mailman.476.1447957612.16136.python-list@python.org> |
| In reply to | #99078 |
On 19/11/2015 18:19, BartC wrote:
> On 19/11/2015 17:45, Chris Angelico wrote:
>> On Fri, Nov 20, 2015 at 4:30 AM, BartC <bc@freeuk.com> wrote:
>>> The whole concept of 'mutable' default is alien to me. A default is
>>> just a
>>> convenient device to avoid having to write:
>>>
>>> fn(0) or fn("") or fn([])
>>>
>>> You just write fn() instead. But it shouldn't come at the cost of
>>> completely
>>> different semantics! Because then it can't really be called a default
>>> value
>>> at all.
>>>
>>
>> Do you understand the concept of "mutable objects"? Don't even try to
>> discuss mutable function defaults until you do.
>
> Yes. In the languages I create, pretty much everything is mutable,
> provided it can supply an l-value. Constructs such as those for empty
> lists ([] in Python, () in mine) aren't l-values.
>
> But it doesn't apply default values. The language is very different
> however, because the byte-code compiler always has full knowledge of
> functions that are called directly. Then it knows when an argument is
> omitted, and can simply substitute the expression used as the default.
>
>> If your language simply has no mutable objects, then sure, it's easy
>> to understand function defaults! There's no such thing as early or
>> late binding; in fact, you can even super-late-bind, where you don't
>> actually call a function until its *return value* is being used (as
>> long as that function has no side effects). But as soon as objects are
>> capable of retaining their identities while changing their values, you
>> need an object model that (a) distinguishes between identity and
>> value, and (b) allows some definition of early or late binding,
>> because it *will* matter.
>>
>>> if you write A=B then something of B needs to have been copied into
>>> A, even if it's just the reference that B contains. Otherwise it
>>> would be
>>> difficult to get A to refer to the same object as B.
>>
>> Please, PLEASE, go and read/watch Ned's PyCon talk (the one I linked
>> you to earlier). Don't post another word on this subject until you
>> comprehend what he is saying.
>
> I looked through the long article (I don't remember seeing a link to a
> video), and followed it up to about 3/4 of the way through, then it got
> a bit heavy.
>
> But what is it about my remarks above that isn't right?
>
To summarize, it once again shows that you haven't got the faintest idea
what you're talking about. You're now in a very exclusive club with the
RUE and Nick the Greek, the world's leading webmaster.
--
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]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-11-19 18:50 +0000 |
| Message-ID | <n2l5h7$p1u$1@dont-email.me> |
| In reply to | #99080 |
On 19/11/2015 18:26, Mark Lawrence wrote: > On 19/11/2015 18:19, BartC wrote: >>>> if you write A=B then something of B needs to have been copied into >>>> A, even if it's just the reference that B contains. Otherwise it >>>> would be >>>> difficult to get A to refer to the same object as B. >>> >>> Please, PLEASE, go and read/watch Ned's PyCon talk (the one I linked >>> you to earlier). Don't post another word on this subject until you >>> comprehend what he is saying. > >> But what is it about my remarks above that isn't right? > > To summarize, it once again shows that you haven't got the faintest idea > what you're talking about. But you're not going to tell me what it is I got wrong! I said that Python's "=" does a very shallow copy. And I stated that in A=B, something of B must be copied into A. I (and probably others) would like to know why none of that is correct. But I suspect I'm not wrong. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2015-11-20 06:09 +1100 |
| Message-ID | <mailman.479.1447960192.16136.python-list@python.org> |
| In reply to | #99084 |
On Fri, Nov 20, 2015 at 5:50 AM, BartC <bc@freeuk.com> wrote: > But you're not going to tell me what it is I got wrong! > > I said that Python's "=" does a very shallow copy. And I stated that in A=B, > something of B must be copied into A. > > I (and probably others) would like to know why none of that is correct. But > I suspect I'm not wrong. There's no copying happening. You evaluate the expression `B`, and get back some kind of object (because all expressions in Python evaluate to objects, unless they raise exceptions or in some way don't finish evaluating). The name A then becomes bound to that object. You're not copying a reference; you're simply referencing the result of an expression. PLEASE finish reading Ned's talk. Here's the link again: http://nedbatchelder.com/text/names1.html It is an excellent explanation of the exact points you're confused about. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-11-19 19:48 +0000 |
| Message-ID | <n2l8v7$7tq$1@dont-email.me> |
| In reply to | #99085 |
On 19/11/2015 19:09, Chris Angelico wrote:
> On Fri, Nov 20, 2015 at 5:50 AM, BartC <bc@freeuk.com> wrote:
>> But you're not going to tell me what it is I got wrong!
>>
>> I said that Python's "=" does a very shallow copy. And I stated that in A=B,
>> something of B must be copied into A.
>>
>> I (and probably others) would like to know why none of that is correct. But
>> I suspect I'm not wrong.
>
> There's no copying happening. You evaluate the expression `B`, and get
> back some kind of object (because all expressions in Python evaluate
> to objects, unless they raise exceptions or in some way don't finish
> evaluating). The name A then becomes bound to that object. You're not
> copying a reference; you're simply referencing the result of an
> expression.
OK, so it's just a coincidence that after A=B, id(A) appears to be an
identical copy of id(B)? And which also agrees with my assertions that a
very shallow copy is done, and that some aspect of B is duplicated in A.
> It is an excellent explanation of the exact points you're confused about.
As far I'm concerned I'm not confused by these copying aspects. I said
'very shallow copy', not 'shallow copy' nor 'deep copy' nor just 'copy'.
To me, 'very shallow copy' about sums it up.
While Python byte-code for A=B:
6 LOAD_GLOBAL 0 (b)
9 STORE_GLOBAL 1 (a)
doesn't really disagree with me either as it looks remarkably like any
other basic copy operation of any machine language or byte-code that has
ever been invented.
If you said instead that I'm not using the official jargon then perhaps
you're right. But the right terminology isn't going to make me like
Python's default values any better!
--
Bartc
[toc] | [prev] | [next] | [standalone]
Page 2 of 10 — ← Prev page 1 [2] 3 4 … 10 Next page →
Back to top | Article view | comp.lang.python
csiph-web