f



[1,2,3] exactly same as [1,2,3,] ?

x=[1,2,3]
and
x=[1,2,3,]

are exactly the same, right?

I'm generating some python data, and it's less error prone
to not treat the last element specially, but I want to be
sure I'm generating an equivalent data structure.

Many TIA!
Mark

-- 
Mark Harrison
Pixar Animation Studios
0
mh68 (75)
8/28/2008 11:19:50 PM
comp.lang.python 77058 articles. 6 followers. Post Follow

15 Replies
851 Views

Similar Articles

[PageSpeed] 4

mh@pixar.com wrote:
> x=[1,2,3]
> and
> x=[1,2,3,]
> 
> are exactly the same, right?

When confronted with this type of question, I ask the interpreter:

{{{
mac:~ pmcnett$ python
Python 2.5.2 (r252:60911, Feb 22 2008, 07:57:53)
[GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> [1,2,3] == [1,2,3,]
True
}}}

Paul
0
p6779 (151)
8/28/2008 11:28:03 PM
Paul McNett <p@ulmcnett.com> wrote:
> When confronted with this type of question, I ask the interpreter:
>  >>> [1,2,3] == [1,2,3,]
> True

Well I guess that's a pretty authoritative answer... thanks!

-- 
Mark Harrison
Pixar Animation Studios
0
mh68 (75)
8/28/2008 11:31:15 PM
On Fri, Aug 29, 2008 at 9:28 AM, Paul McNett <p@ulmcnett.com> wrote:
> When confronted with this type of question, I ask the interpreter:
>
> {{{
> mac:~ pmcnett$ python
> Python 2.5.2 (r252:60911, Feb 22 2008, 07:57:53)
> [GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
>>>> [1,2,3] == [1,2,3,]
> True
> }}}

I must point out though that although they contain
the same elements/data, they are not the same
object/instance.

{{{
#!python
>>> x = [1, 2, 3]
>>> y = [1, 2, 3]
>>> id(x)
3083095148L
>>> id(y)
3082953324L
>>> x == y
True
}}}

If you view the documentation for a list:
{{{
#!sh
$ pydoc list
}}}

list's have an __eq__ that is used to compare the
equality of 2 lists.

cheers
James


-- 
--
-- "Problems are solved by method"
0
prologic (409)
8/28/2008 11:35:10 PM
James Mills wrote:
> I must point out though that although they contain
> the same elements/data, they are not the same
> object/instance.

True, but the OP wanted equality:

 > I want to be
 > sure I'm generating an equivalent data structure.

Paul
0
p6779 (151)
8/28/2008 11:40:40 PM
On Aug 28, 6:35=A0pm, "James Mills" <prolo...@shortcircuit.net.au>
wrote:
> I must point out though that although they contain
> the same elements/data, they are not the same
> object/instance.
>
> {{{
> #!python
>
> >>> x =3D [1, 2, 3]
> >>> y =3D [1, 2, 3]
> >>> id(x)
> 3083095148L
> >>> id(y)
> 3082953324L
> >>> x =3D=3D y
> True
> }}}

Umm, yeah, but that's true of ANY two mutable objects you create, and
has absolutely nothing to do with whether the syntax which generated
the list contains a trailing comma or not.  To wit:

>>> [1,2,3] is [1,2,3]
False

Regards,
Pat
0
pmaupin (107)
8/29/2008 12:22:27 AM

mh@pixar.com wrote:
> x=[1,2,3]
> and
> x=[1,2,3,]
> 
> are exactly the same, right?

Yes, so you can write something like either your second example or

l = [
   kjasldfjs,
   kjsalfj,
   ksjdflasj,
]

and insert items without worrying about leaving out the comma (less of a 
problem with 'horizontal' list), or delete the last line and not have to 
worry about deleting the comma on the line before.

0
tjreedy (5460)
8/29/2008 5:43:06 AM
mh@pixar.com wrote:
> x=[1,2,3]
> and
> x=[1,2,3,]
> 
> are exactly the same, right?
> 
> I'm generating some python data, and it's less error prone
> to not treat the last element specially, but I want to be
> sure I'm generating an equivalent data structure.
> 
> Many TIA!
> Mark
> 
 >>> x=[1,2,3,]
 >>> repr(x)
[1,2,3]

0
straton (140)
8/29/2008 9:09:20 AM
Terry Reedy <tjreedy@udel.edu> wrote:
> Yes, so you can write something like either your second example or
> 
> l = [
>    kjasldfjs,
>    kjsalfj,
>    ksjdflasj,
> ]
> 
> and insert items without worrying about leaving out the comma (less of a 
> problem with 'horizontal' list), or delete the last line and not have to 
> worry about deleting the comma on the line before.

Exactly.  This is one of those little pieces of syntactic sugar which makes 
python so nice to work with.  The alternative is (in C, for example) 
abominations like this:

const char* l[] = {"foo"
                 , "bar"
                 , "baz"
                 };

and even those are not quite as good because you still have to special-case 
the first entry.
0
roy (2295)
8/29/2008 2:15:06 PM
On 2008-08-29, Roy Smith <roy@panix.com> wrote:

> Exactly.  This is one of those little pieces of syntactic
> sugar which makes python so nice to work with.  The
> alternative is (in C, for example) abominations like this:
>
> const char* l[] = {"foo"
>                  , "bar"
>                  , "baz"
>                  };
>
> and even those are not quite as good because you still have to
> special-case the first entry.

It's probably a spec violation, but I've never seen a C
compiler that objected to a comma after the last item in an
initializer list.  (At least not at the warning levels I use,
which tend to be on the picky side.)

-- 
Grant Edwards                   grante             Yow! There's enough money
                                  at               here to buy 5000 cans of
                               visi.com            Noodle-Roni!
0
grante (5416)
8/29/2008 2:45:00 PM
On Thu, 28 Aug 2008 16:28:03 -0700, Paul McNett wrote:

> mh@pixar.com wrote:
>> x=[1,2,3]
>> and
>> x=[1,2,3,]
>> 
>> are exactly the same, right?
> 
> When confronted with this type of question, I ask the interpreter:
> 
> {{{
> mac:~ pmcnett$ python
> Python 2.5.2 (r252:60911, Feb 22 2008, 07:57:53) [GCC 4.0.1 (Apple
> Computer, Inc. build 5363)] on darwin Type "help", "copyright",
> "credits" or "license" for more information.
>  >>> [1,2,3] == [1,2,3,]
> True
> }}}



Putting on my pedantic hat...

In this case you're right about the two lists being the same, and I'm a 
great believer in checking things in the interactive interpreter, but you 
need to take care. Just because two objects compare as equal doesn't 
*necessarily* mean they are the same:


>>> 1.0 == 1
True
>>> 1.0 == decimal.Decimal('1.0')
False
>>> 1.0 == float(decimal.Decimal('1.0'))
True
>>> collections.defaultdict(999) == {}
True



-- 
Steven
0
steve9679 (1985)
8/29/2008 2:59:48 PM
In article <QOCdnfa_yarxliXVnZ2dnUVZ_i2dnZ2d@posted.visi>,
 Grant Edwards <grante@visi.com> wrote:

> On 2008-08-29, Roy Smith <roy@panix.com> wrote:
> 
> > Exactly.  This is one of those little pieces of syntactic
> > sugar which makes python so nice to work with.  The
> > alternative is (in C, for example) abominations like this:
> >
> > const char* l[] = {"foo"
> >                  , "bar"
> >                  , "baz"
> >                  };
> >
> > and even those are not quite as good because you still have to
> > special-case the first entry.
> 
> It's probably a spec violation, but I've never seen a C
> compiler that objected to a comma after the last item in an
> initializer list.  (At least not at the warning levels I use,
> which tend to be on the picky side.)

Yowza, you're right (at least for the one case I tried).  This must be a 
new development (where "new development" is defined as, "It wasn't legal in 
the original K&R C I learned when I was a pup").

Still, I have seem people do that in code.
0
roy (2295)
8/29/2008 3:11:41 PM
On Aug 29, 10:11=A0am, Roy Smith <r...@panix.com> wrote:
> In article <QOCdnfa_yarxliXVnZ2dnUVZ_i2dn...@posted.visi>,
> =A0Grant Edwards <gra...@visi.com> wrote:
>
>
>
>
>
> > On 2008-08-29, Roy Smith <r...@panix.com> wrote:
>
> > > Exactly. =A0This is one of those little pieces of syntactic
> > > sugar which makes python so nice to work with. =A0The
> > > alternative is (in C, for example) abominations like this:
>
> > > const char* l[] =3D {"foo"
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0, "bar"
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0, "baz"
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0};
>
> > > and even those are not quite as good because you still have to
> > > special-case the first entry.
>
> > It's probably a spec violation, but I've never seen a C
> > compiler that objected to a comma after the last item in an
> > initializer list. =A0(At least not at the warning levels I use,
> > which tend to be on the picky side.)
>
> Yowza, you're right (at least for the one case I tried). =A0This must be =
a
> new development (where "new development" is defined as, "It wasn't legal =
in
> the original K&R C I learned when I was a pup").

That's the difference between a specification and
an implementation, isn't it?

>
> Still, I have seem people do that in code.- Hide quoted text -
>
> - Show quoted text -

0
mensanator (1210)
8/29/2008 6:10:17 PM
Steven D'Aprano wrote:
> On Thu, 28 Aug 2008 16:28:03 -0700, Paul McNett wrote:
> 
>> mh@pixar.com wrote:
>>> x=[1,2,3]
>>> and
>>> x=[1,2,3,]
>>>
>>> are exactly the same, right?
>> When confronted with this type of question, I ask the interpreter:
>>
>> {{{
>> mac:~ pmcnett$ python
>> Python 2.5.2 (r252:60911, Feb 22 2008, 07:57:53) [GCC 4.0.1 (Apple
>> Computer, Inc. build 5363)] on darwin Type "help", "copyright",
>> "credits" or "license" for more information.
>>  >>> [1,2,3] == [1,2,3,]
>> True
>> }}}
> 
> 
> 
> Putting on my pedantic hat...
> 
> In this case you're right about the two lists being the same, and I'm a 
> great believer in checking things in the interactive interpreter, but you 
> need to take care. Just because two objects compare as equal doesn't 
> *necessarily* mean they are the same:

True.

>>>> 1.0 == 1
> True
>>>> 1.0 == decimal.Decimal('1.0')
> False
>>>> 1.0 == float(decimal.Decimal('1.0'))
> True

These are comparing different types.


>>>> collections.defaultdict(999) == {}
> True

I try this and get:

TypeError: first arument must be callable


Paul
0
p6779 (151)
8/29/2008 7:41:28 PM
Roy Smith wrote:

> Yowza, you're right (at least for the one case I tried).  This must be a 
> new development (where "new development" is defined as, "It wasn't legal in 
> the original K&R C I learned when I was a pup").

the C 89 grammar appears to be:

     initializer:
         assignment-expression
         { initializer-list }
         { initializer-list , }

     initializer-list:
         designation-opt initializer
         initializer-list , designation-opt initializer

so a trailing comma has been allowed for around twenty years.

</F>

0
fredrik2101 (5275)
8/30/2008 3:04:44 PM
In article <mailman.276.1220108706.3487.python-list@python.org>,
 Fredrik Lundh <fredrik@pythonware.com> wrote:

> Roy Smith wrote:
> 
> > Yowza, you're right (at least for the one case I tried).  This must be a 
> > new development (where "new development" is defined as, "It wasn't legal in 
> > the original K&R C I learned when I was a pup").
> 
> the C 89 grammar appears to be:
> 
>      initializer:
>          assignment-expression
>          { initializer-list }
>          { initializer-list , }
> 
>      initializer-list:
>          designation-opt initializer
>          initializer-list , designation-opt initializer
> 
> so a trailing comma has been allowed for around twenty years.
> 
> </F>

C89 came out about 10 years after I first learned C :-)
0
roy (2295)
8/30/2008 3:17:25 PM
Reply: