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

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

what does 'a=b=c=[]' do

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

Contents

  what does 'a=b=c=[]' do Eric <einazaki668@yahoo.com> - 2011-12-21 14:25 -0800
    Re: what does 'a=b=c=[]' do Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2011-12-21 18:20 -0500
      Re: what does 'a=b=c=[]' do Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-21 23:48 +0000
        Re: what does 'a=b=c=[]' do Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> - 2011-12-24 19:41 +0100
          Re: what does 'a=b=c=[]' do Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-25 13:16 +0000
      Re: what does 'a=b=c=[]' do Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> - 2011-12-24 19:45 +0100
    Re: what does 'a=b=c=[]' do Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-21 23:44 +0000
      Re: what does 'a=b=c=[]' do Eric <einazaki668@yahoo.com> - 2011-12-22 20:27 -0800
    Re: what does 'a=b=c=[]' do alex23 <wuwei23@gmail.com> - 2011-12-21 16:50 -0800
      Re: what does 'a=b=c=[]' do Rolf Camps <rolf@roce.be> - 2011-12-22 09:51 +0100
        Re: what does 'a=b=c=[]' do alex23 <wuwei23@gmail.com> - 2011-12-22 18:10 -0800
          Re: what does 'a=b=c=[]' do Ian Kelly <ian.g.kelly@gmail.com> - 2011-12-22 19:59 -0700
            Re: what does 'a=b=c=[]' do alex23 <wuwei23@gmail.com> - 2011-12-22 19:40 -0800
              Re: what does 'a=b=c=[]' do Chris Angelico <rosuav@gmail.com> - 2011-12-23 15:25 +1100
              Re: what does 'a=b=c=[]' do Ian Kelly <ian.g.kelly@gmail.com> - 2011-12-22 22:22 -0700
                Re: what does 'a=b=c=[]' do alex23 <wuwei23@gmail.com> - 2011-12-22 22:00 -0800
          Re: what does 'a=b=c=[]' do rusi <rustompmody@gmail.com> - 2011-12-23 00:38 -0800
            Re: what does 'a=b=c=[]' do Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-23 09:39 +0000
              Re: what does 'a=b=c=[]' do rusi <rustompmody@gmail.com> - 2011-12-23 02:22 -0800
                Re: what does 'a=b=c=[]' do Robert Kern <robert.kern@gmail.com> - 2011-12-23 13:10 +0000
                  Re: what does 'a=b=c=[]' do rusi <rustompmody@gmail.com> - 2011-12-23 05:23 -0800
                    Re: what does 'a=b=c=[]' do Robert Kern <robert.kern@gmail.com> - 2011-12-23 13:53 +0000
                      Re: what does 'a=b=c=[]' do rusi <rustompmody@gmail.com> - 2011-12-23 06:57 -0800
                        Re: what does 'a=b=c=[]' do Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-23 15:33 +0000
                          Re: what does 'a=b=c=[]' do rusi <rustompmody@gmail.com> - 2011-12-23 07:59 -0800
            Re: what does 'a=b=c=[]' do Ethan Furman <ethan@stoneleaf.us> - 2011-12-23 00:49 -0800
            Re: what does 'a=b=c=[]' do Chris Angelico <rosuav@gmail.com> - 2011-12-23 20:59 +1100
              Re: what does 'a=b=c=[]' do rusi <rustompmody@gmail.com> - 2011-12-23 02:31 -0800
                Timeout when calling COM objects on Windows Wong Wah Meng-R32813 <r32813@freescale.com> - 2011-12-23 11:20 +0000
                Re: what does 'a=b=c=[]' do Michael Torrie <torriem@gmail.com> - 2011-12-23 10:23 -0700
              Re: what does 'a=b=c=[]' do Neil Cerutti <neilc@norwich.edu> - 2011-12-23 13:10 +0000
                Re: what does 'a=b=c=[]' do Neil Cerutti <neilc@norwich.edu> - 2011-12-23 13:13 +0000
                  Early and late binding [was Re: what does 'a=b=c=[]' do] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-23 15:49 +0000
                    Re: Early and late binding [was Re: what does 'a=b=c=[]' do] Chris Angelico <rosuav@gmail.com> - 2011-12-24 02:55 +1100
                      Re: Early and late binding [was Re: what does 'a=b=c=[]' do] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-23 22:32 +0000
                        Re: Early and late binding [was Re: what does 'a=b=c=[]' do] Chris Angelico <rosuav@gmail.com> - 2011-12-24 09:50 +1100
                          Re: Early and late binding [was Re: what does 'a=b=c=[]' do] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-24 08:11 +0000
                    Re: Early and late binding [was Re: what does 'a=b=c=[]' do] Roy Smith <roy@panix.com> - 2011-12-23 11:15 -0500
                      Re: Early and late binding [was Re: what does 'a=b=c=[]' do] alex23 <wuwei23@gmail.com> - 2011-12-24 05:43 -0800
                    Re: Early and late binding [was Re: what does 'a=b=c=[]' do] Mel Wilson <mwilson@the-wire.com> - 2011-12-23 11:27 -0500
                      Re: Early and late binding [was Re: what does 'a=b=c=[]' do] alex23 <wuwei23@gmail.com> - 2011-12-24 05:52 -0800
                    Re: Early and late binding [was Re: what does 'a=b=c=[]' do] Neil Cerutti <neilc@norwich.edu> - 2011-12-23 17:03 +0000
                      Re: Early and late binding [was Re: what does 'a=b=c=[]' do] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-24 08:25 +0000
                        Re: Early and late binding [was Re: what does 'a=b=c=[]' do] alex23 <wuwei23@gmail.com> - 2011-12-24 06:08 -0800
                          Re: Early and late binding [was Re: what does 'a=b=c=[]' do] Devin Jeanpierre <jeanpierreda@gmail.com> - 2011-12-24 18:25 -0500
                            Re: Early and late binding [was Re: what does 'a=b=c=[]' do] alex23 <wuwei23@gmail.com> - 2011-12-24 16:10 -0800
                              Re: Early and late binding [was Re: what does 'a=b=c=[]' do] Devin Jeanpierre <jeanpierreda@gmail.com> - 2011-12-24 19:32 -0500
                                Re: Early and late binding [was Re: what does 'a=b=c=[]' do] rusi <rustompmody@gmail.com> - 2011-12-24 19:22 -0800
                        Re: Early and late binding [was Re: what does 'a=b=c=[]' do] Lie Ryan <lie.1296@gmail.com> - 2011-12-25 15:12 +1100
                    Re: Early and late binding [was Re: what does 'a=b=c=[]' do] Devin Jeanpierre <jeanpierreda@gmail.com> - 2011-12-23 19:24 -0500
                      Re: Early and late binding [was Re: what does 'a=b=c=[]' do] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-24 08:26 +0000
          Re: what does 'a=b=c=[]' do Ethan Furman <ethan@stoneleaf.us> - 2011-12-23 00:38 -0800
      Re: what does 'a=b=c=[]' do Ethan Furman <ethan@stoneleaf.us> - 2011-12-22 05:20 -0800
      Re: what does 'a=b=c=[]' do Eric <einazaki668@yahoo.com> - 2011-12-22 19:46 -0800
    Re: what does 'a=b=c=[]' do Lie Ryan <lie.1296@gmail.com> - 2011-12-24 21:30 +1100
    Re: what does 'a=b=c=[]' do Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> - 2011-12-24 19:49 +0100

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

#17707 — what does 'a=b=c=[]' do

Is it true that if I want to create an array or arbitrary size such
as:
   for a in range(n):
      x.append(<some function...>)

I must do this instead?
   x=[]
   for a in range(n):
      x.append(<some function...>)

Now to my actual question.  I need to do the above for multiple arrays
(all the same, arbitrary size).  So I do this:
   x=y=z=[]
   for a in range(n):
      x.append(<some function...>)
      y.append(<some other function...>)
      z.append(<yet another function...>)

Except it seems that I didn't create three different arrays, I created
one array that goes by three different names (i.e. x[], y[] and z[]
all reference the same pile of numbers, no idea which pile).

This surprises me, can someone tell me why it shouldn't?  I figure if
I want to create and initialize three scalars the just do "a=b=c=7",
for example, so why not extend it to arrays.  Also, is there a more
pythonic way to do "x=[], y=[], z=[]"?

It's a slick language but I still have trouble wrapping my brain
around some of the concepts.

TIA,
eric

[toc] | [next] | [standalone]

#17708

On Wed, 21 Dec 2011 14:25:17 -0800 (PST), Eric <einazaki668@yahoo.com>
wrote:


>Except it seems that I didn't create three different arrays, I created
>one array that goes by three different names (i.e. x[], y[] and z[]
>all reference the same pile of numbers, no idea which pile).
>
>This surprises me, can someone tell me why it shouldn't?  I figure if
>I want to create and initialize three scalars the just do "a=b=c=7",
>for example, so why not extend it to arrays.  Also, is there a more
>pythonic way to do "x=[], y=[], z=[]"?
>
>It's a slick language but I still have trouble wrapping my brain
>around some of the concepts.
>
	The key one is that lists ([] defines a list, not an array) are
"mutable". Your "7" is not mutable.

	a = b = c = 7
does the same thing as
	a = b = c = []
which is to define the names "a", "b", and "c", and connects the three
names to the single object (integer 7 or new empty list).

	b = 8
then /disconnects/ the name "b" from the object (empty list or integer
7) and connects the name to an integer 8 object.

	b = [1, 2, 3]
disconnects the name "b" from the object and connects it to a list
object containing three elements.

	b.append("something")
however is going "inside" the object to change what it contains -- the
connection remains the same object however.

>>> a,b,c=[[] for x in range(3)]
>>> a.append(1)
>>> b
[]
>>> c
[]
>>> a
[1]
>>>

	For the amount of typing, it's easier to just do a straight line
tuple unpack

>>> a,b,c = ([],[],[])
>>> a.append(2)
>>> a
[2]
>>> b
[]
>>> c
[]
>>>

-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

#17710

On Wed, 21 Dec 2011 18:20:16 -0500, Dennis Lee Bieber wrote:

> 	For the amount of typing, it's easier to just do a straight line
> tuple unpack
> 
>>>> a,b,c = ([],[],[])

Note that tuples are created by the comma, not the round brackets (or 
parentheses for any Americans reading). So the round brackets there are 
strictly redundant:

a, b, c = [], [], []

The only times you need the brackets around a tuple is to control the 
precedence of operations, or for an empty tuple.


-- 
Steven

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

#17859

Am 22.12.2011 00:48 schrieb Steven D'Aprano:
> On Wed, 21 Dec 2011 18:20:16 -0500, Dennis Lee Bieber wrote:
>
>> 	For the amount of typing, it's easier to just do a straight line
>> tuple unpack
>>
>>>>> a,b,c = ([],[],[])
>
> Note that tuples are created by the comma, not the round brackets (or
> parentheses for any Americans reading). So the round brackets there are
> strictly redundant:
>
> a, b, c = [], [], []
>
> The only times you need the brackets around a tuple is to control the
> precedence of operations, or for an empty tuple.

IBTD:

a=((a, b) for a, b, c in some_iter)
b=[(1, c) for <whatever>]

Without the round brackets, it is a syntax error.


Thomas

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

#17889

On Sat, 24 Dec 2011 19:41:55 +0100, Thomas Rachel wrote:

>> The only times you need the brackets around a tuple is to control the
>> precedence of operations, or for an empty tuple.
> 
> IBTD:
> 
> a=((a, b) for a, b, c in some_iter)
> b=[(1, c) for <whatever>]
> 
> Without the round brackets, it is a syntax error.

Correction noted.

Nevertheless, the parentheses don't create the tuple, the comma operator 
does.



-- 
Steven

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

#17860

Am 22.12.2011 00:20 schrieb Dennis Lee Bieber:

> 	The key one is that lists ([] defines a list, not an array) are
> "mutable". Your "7" is not mutable.

Strictly spoken, that's only a "side show" where the effect is visible.

The real key concept is that [] creates *one* object which is then 
assigned to the three names. That's the same for mutable and immutable 
objects.

But only the modification which happens on mutable objects turns it into 
a problem.

The rest o your explanation is 100% correct.


Thomas

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

#17709

On Wed, 21 Dec 2011 14:25:17 -0800, Eric wrote:

> Is it true that if I want to create an array or arbitrary size such as:
>    for a in range(n):
>       x.append(<some function...>)

x is not defined, so you will get a NameError unless by some lucky fluke 
something else has created x AND it happens to be a list. Either way, it 
is unlikely to do what you want.


> I must do this instead?
>    x=[]
>    for a in range(n):
>       x.append(<some function...>)

Yes, you should create your lists before trying to append to them.

But you aren't forced to use a for-loop. You can use a list comprehension:

x = [some_function(a) for a in range(n)]

Notice that here you don't need x to pre-exist, because the list comp 
creates a brand new list, which then gets assigned directly to x.


> Now to my actual question.  I need to do the above for multiple arrays
> (all the same, arbitrary size).  So I do this:
>    x=y=z=[]

This creates one empty list object, and gives it three names, x, y and z. 
Every time you append to the list, all three names see the same change, 
because they refer to a single list.

[...]
> Except it seems that I didn't create three different arrays, I created
> one array that goes by three different names (i.e. x[], y[] and z[] all
> reference the same pile of numbers, no idea which pile).

Exactly.

> This surprises me, can someone tell me why it shouldn't? 

Because that's the way Python works. Python is an object-oriented, name 
binding language. This is how OO name binding works: you have a single 
object, with three names bound to it. The above line is short-cut for:

a = []
b = a
c = a

Python does not make a copy of the list unless you specifically instruct 
it to.


> I figure if I
> want to create and initialize three scalars the just do "a=b=c=7", 

That creates a single integer object with value 7, and binds three names 
to it, *exactly* the same as the above.

If you could modify int objects in place, like you can modify lists in 
place, you would see precisely the same effect. But ints are immutable: 
all operations on ints create new ints. Lists are mutable, and can be 
changed in place.

> for
> example, so why not extend it to arrays.  Also, is there a more pythonic
> way to do "x=[], y=[], z=[]"?

Well that literally won't work, you can't separate them by commas. 
Newlines or semicolons will work.

Or: x, y, z = [], [], []

Either is pretty Pythonic.



-- 
Steven

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

#17774

On Dec 21, 5:44 pm, Steven D'Aprano <steve
+comp.lang.pyt...@pearwood.info> wrote:

> Yes, you should create your lists before trying to append to them.
>
> But you aren't forced to use a for-loop. You can use a list comprehension:
>
> x = [some_function(a) for a in range(n)]
>
> Notice that here you don't need x to pre-exist, because the list comp
> creates a brand new list, which then gets assigned directly to x.
>
> > Now to my actual question.  I need to do the above for multiple arrays
> > (all the same, arbitrary size).  So I do this:
> >    x=y=z=[]
>
> This creates one empty list object, and gives it three names, x, y and z.
> Every time you append to the list, all three names see the same change,
> because they refer to a single list.
>
> [...]
>
> > Except it seems that I didn't create three different arrays, I created
> > one array that goes by three different names (i.e. x[], y[] and z[] all
> > reference the same pile of numbers, no idea which pile).
>
> Exactly.
>
> > This surprises me, can someone tell me why it shouldn't?
>
> Because that's the way Python works. Python is an object-oriented, name
> binding language. This is how OO name binding works: you have a single
> object, with three names bound to it. The above line is short-cut for:
>
> a = []
> b = a
> c = a
>
> Python does not make a copy of the list unless you specifically instruct
> it to.
>
> > I figure if I
> > want to create and initialize three scalars the just do "a=b=c=7",
>
> That creates a single integer object with value 7, and binds three names
> to it, *exactly* the same as the above.
>
> If you could modify int objects in place, like you can modify lists in
> place, you would see precisely the same effect. But ints are immutable:
> all operations on ints create new ints. Lists are mutable, and can be
> changed in place.
>
> > for
> > example, so why not extend it to arrays.  Also, is there a more pythonic
> > way to do "x=[], y=[], z=[]"?
>
> Well that literally won't work, you can't separate them by commas.
> Newlines or semicolons will work.
>
> Or: x, y, z = [], [], []
>
> Either is pretty Pythonic.
>
> --
> Steven

Thanks to you and Dennis for the quick lesson and tips.  Very helpful
and illuminating.

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

#17711

On Dec 22, 8:25 am, Eric <einazaki...@yahoo.com> wrote:
> This surprises me, can someone tell me why it shouldn't?  I figure if
> I want to create and initialize three scalars the just do "a=b=c=7",
> for example, so why not extend it to arrays.

The thing to remember is that everything is an object, and that it's
better to think of variables as labels on an object.

So: a=b=c=7 means that _one_ integer object with the value of 7 can be
referenced using any of the labels a, b or c. x=y=z=[] means that
_one_ empty list can be referenced using x, y or z.

The difference is that the value of a number object _cannot be
changed_ ('immutable') while a list can be modified to add or remove
items ('mutable'). a=10 just reassigns the label a to an integer
object of value 10. x.append("foo") _modifies_ the list referred to by
x, which is the same list known as y & z.

> Also, is there a more pythonic way to do "x=[], y=[], z=[]"?

I'd say that _is_ the most pythonic way, it's very obvious in its
intent (or would be with appropriate names). If it bothers you that
much:

    def listgen(count, default=[]):
        for _ in xrange(count):
            yield default[:]

    x, y, z = listgen(3)

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

#17722

alex23 schreef op wo 21-12-2011 om 16:50 [-0800]:
> On Dec 22, 8:25 am, Eric <einazaki...@yahoo.com> wrote:
> > This surprises me, can someone tell me why it shouldn't?  I figure if
> > I want to create and initialize three scalars the just do "a=b=c=7",
> > for example, so why not extend it to arrays.
> 
> The thing to remember is that everything is an object, and that it's
> better to think of variables as labels on an object.
> 
> So: a=b=c=7 means that _one_ integer object with the value of 7 can be
> referenced using any of the labels a, b or c. x=y=z=[] means that
> _one_ empty list can be referenced using x, y or z.
> 
> The difference is that the value of a number object _cannot be
> changed_ ('immutable') while a list can be modified to add or remove
> items ('mutable'). a=10 just reassigns the label a to an integer
> object of value 10. x.append("foo") _modifies_ the list referred to by
> x, which is the same list known as y & z.
> 
> > Also, is there a more pythonic way to do "x=[], y=[], z=[]"?
> 
> I'd say that _is_ the most pythonic way, it's very obvious in its
> intent (or would be with appropriate names). If it bothers you that
> much:
> 
>     def listgen(count, default=[]):
>         for _ in xrange(count):
>             yield default[:]
> 
>     x, y, z = listgen(3)
> 


I'm afraid it's dangerous to encourage the use of '[]' as assignment to
a parameter in a function definition. If you use the function several
times 'default' always points to the same list. 

	>>> def return_list(list_ = []):
	>>>     return list_
	>>> a_list = return_list()
	>>> a_list
	    []
	>>> a_list.append(3)
	>>> a_list
	    [3]
	>>> b_list = return_list()
	>>> b_list
	>>> [3]   # !!??

	>>> def return_list():
	>>> 	return []
	>>> a_list = return_list()
	>>> a_list
	    []
	>>> a_list.append(3)
	>>> a_list
	    [3]
	>>> b_list = return_list()
	>>> b_list
	>>> []    # OK!

I only use python3 so I don't know how these things work in other
versions.

No problem in your function since you yield a copy, but I've already
seen long threads about this.

I would change your function to (Python3.x):

	def empty_lists(count):
	    for _ in range(count):
		yield []


Regards,

Rolf
	

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

#17766

On Dec 22, 6:51 pm, Rolf Camps <r...@roce.be> wrote:
> I'm afraid it's dangerous to encourage the use of '[]' as assignment to
> a parameter in a function definition. If you use the function several
> times 'default' always points to the same list.

I appreciate the concern, but adding a default argument guard would
not only obscure the code. It's irrelevant, as you recognise, because
no matter what, it's going to make copies of the default argument.

You know what the say about foolish consistencies :)

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

#17768

On Thu, Dec 22, 2011 at 7:10 PM, alex23 <wuwei23@gmail.com> wrote:
> On Dec 22, 6:51 pm, Rolf Camps <r...@roce.be> wrote:
>> I'm afraid it's dangerous to encourage the use of '[]' as assignment to
>> a parameter in a function definition. If you use the function several
>> times 'default' always points to the same list.
>
> I appreciate the concern, but adding a default argument guard would
> not only obscure the code. It's irrelevant, as you recognise, because
> no matter what, it's going to make copies of the default argument.

It's only irrelevant in the immediate context of the code you posted.
But when Joe Novice sees your code and likes it and duplicates it a
million times without receiving any warning about it, he's eventually
going to write a function that modifies its default list argument, and
he'll be in for a nasty surprise when he does.

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

#17771

On Dec 23, 12:59 pm, Ian Kelly <ian.g.ke...@gmail.com> wrote:
> It's only irrelevant in the immediate context of the code you posted.
> But when Joe Novice sees your code and likes it and duplicates it a
> million times

I'm sorry, but I'm not going to modify my coding style for the sake of
bad programmers.

The context is _important_. Why should I guard against default
argument mutability when its not going to occur in the function body?

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

#17773

On Fri, Dec 23, 2011 at 2:40 PM, alex23 <wuwei23@gmail.com> wrote:
> I'm sorry, but I'm not going to modify my coding style for the sake of
> bad programmers.

And there, folks, you have one of the eternal dilemmas. The correct
decision depends on myriad factors; if you're writing code to go into
the documentation as an example, you want it to be able to handle
idiots hacking on it - but on the other hand, that same situation
demands simplicity, which is why a lot of examples omit huge slabs of
error checking.

ChrisA

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

#17775

On Thu, Dec 22, 2011 at 8:40 PM, alex23 <wuwei23@gmail.com> wrote:
> On Dec 23, 12:59 pm, Ian Kelly <ian.g.ke...@gmail.com> wrote:
>> It's only irrelevant in the immediate context of the code you posted.
>> But when Joe Novice sees your code and likes it and duplicates it a
>> million times
>
> I'm sorry, but I'm not going to modify my coding style for the sake of
> bad programmers.

Nobody is asking you to modify your coding style.  The request is that
you not throw it up as an example without mentioning the important
caveats.

Also, novice programmer == bad programmer?

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

#17776

On Dec 23, 3:22 pm, Ian Kelly <ian.g.ke...@gmail.com> wrote:
> Nobody is asking you to modify your coding style.  The request is that
> you not throw it up as an example without mentioning the important
> caveats.

No, 100% no. It's not my responsibility to mention every potentially
relevant gotcha when providing example code.

> Also, novice programmer == bad programmer?

If they're wholly learning how to code by throwaway examples on
mailing lists, then yes. Object mutability is a _major_ aspect of
Python; I'm simply not going to inject an essay explaining what that
implies every time I choose to use a mutable default argument.

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

#17782

On Dec 23, 7:10 am, alex23 <wuwe...@gmail.com> wrote:
> On Dec 22, 6:51 pm, Rolf Camps <r...@roce.be> wrote:
>
> > I'm afraid it's dangerous to encourage the use of '[]' as assignment to
> > a parameter in a function definition. If you use the function several
> > times 'default' always points to the same list.
>
> I appreciate the concern, but adding a default argument guard would
> not only obscure the code. It's irrelevant, as you recognise, because
> no matter what, it's going to make copies of the default argument.
>
> You know what the say about foolish consistencies :)

Programming languages can have bugs as much as programs can.
A classic example is the precedence table of C which Kernighan or
Ritchie (dont remember which) admitted was wrong.

Likewise function arguments that default to mutable entities is a
known gotcha of python which is best treated as a bug in python. It
should be avoided with the suitable additional circumspection that a
language bug deserves over a program bug.

[Just my rephrasing of what Ian is saying]

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

#17785

On Fri, 23 Dec 2011 00:38:07 -0800, rusi wrote:

> Likewise function arguments that default to mutable entities is a known
> gotcha of python which is best treated as a bug in python.

Nonsense. It is a feature, not a bug.

Some people might argue that it is a mistake, a minor feature which 
allegedly causes more difficulties than benefits. I do not hold with that 
idea. But either way, it is not a bug to be fixed, but a deliberate 
consequence of intended semantics.



-- 
Steven

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

#17795

On Dec 23, 2:39 pm, Steven D'Aprano <steve
+comp.lang.pyt...@pearwood.info> wrote:
> On Fri, 23 Dec 2011 00:38:07 -0800, rusi wrote:
> > Likewise function arguments that default to mutable entities is a known
> > gotcha of python which is best treated as a bug in python.
>
> Nonsense. It is a feature, not a bug.

Tsk Tsk How can python have a bug? And that too on the python mailing
list?

Others however feel differently. See Chris Rebert's
http://mail.python.org/pipermail/python-ideas/2007-January/000073.html
and the links cited there.

>
> Some people might argue that it is a mistake, a minor feature which
> allegedly causes more difficulties than benefits. I do not hold with that
> idea. But either way, it is not a bug to be fixed, but a deliberate
> consequence of intended semantics.

I did not ask or imply that it should be 'fixed', just that language
misfeatures should be treated with extra care.
Windows uses CRLF where Unix uses LF.  Nobody could argue that this
discrepancy is of any use and nobody is about to fix it.

Of course if "bug" means "must-fix-else-unusable" then sure you are
right but then we would not be able to use most of the hardware or
software that we do.

To restate what (I think) Ian is saying:

Exploit language misfeatures cleverly in your code if you want. But
please red-flag them in mailing list posts.

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

#17800

On 12/23/11 10:22 AM, rusi wrote:
> On Dec 23, 2:39 pm, Steven D'Aprano<steve
> +comp.lang.pyt...@pearwood.info>  wrote:
>> On Fri, 23 Dec 2011 00:38:07 -0800, rusi wrote:
>>> Likewise function arguments that default to mutable entities is a known
>>> gotcha of python which is best treated as a bug in python.
>>
>> Nonsense. It is a feature, not a bug.
>
> Tsk Tsk How can python have a bug? And that too on the python mailing
> list?
>
> Others however feel differently. See Chris Rebert's
> http://mail.python.org/pipermail/python-ideas/2007-January/000073.html
> and the links cited there.
>
>>
>> Some people might argue that it is a mistake, a minor feature which
>> allegedly causes more difficulties than benefits. I do not hold with that
>> idea. But either way, it is not a bug to be fixed, but a deliberate
>> consequence of intended semantics.
>
> I did not ask or imply that it should be 'fixed', just that language
> misfeatures should be treated with extra care.

"Bug" means, roughly, "something that should be fixed" not just any "thing that 
has some unwanted consequences". So yes, by calling it a bug you are asking and 
implying just that. If you don't mean that, don't use the word "bug".

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco

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

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

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

csiph-web