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

[mh]

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

 

[Paul McNett]

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

 

[mh]

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!

 

[James Mills]

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

 

[Paul McNett]

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

 

[Patrick Maupin]

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

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

 

[Terry Reedy]

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.

 

[Ken Starks]

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]

 

[Roy Smith]

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.

 

[Steven D'Aprano]

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

 

[Roy Smith]

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.

 

[Mensanator]

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

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

 

[Paul McNett]

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

These are comparing different types.

True

I try this and get:

TypeError: first arument must be callable


Paul

 

[Fredrik Lundh]

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>

 

[Roy Smith]

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