[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

--
Mark Harrison
Pixar Animation Studios

[Paul McNett]

[e-mail] 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

[mh]

Paul McNett <[e-mail]:

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

[James Mills]

On Fri, Aug 29, 2008 at 9:28 AM, Paul McNett <[e-mail]:

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"

[Paul McNett]

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

[Patrick Maupin]

On Aug 28, 6:35*pm, "James Mills" <[e-mail]>
wrote:

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]

[e-mail] 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.

[Ken Starks]

[e-mail] 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]

[Roy Smith]

Terry Reedy <tj*****@udel.eduwrote:

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.

[Grant Edwards]

On 2008-08-29, Roy Smith <ro*@panix.comwrote:

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!

[Steven D'Aprano]

On Thu, 28 Aug 2008 16:28:03 -0700, Paul McNett wrote:

[e-mail] 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

[Roy Smith]

In article <QO******************************@posted.visi>,
Grant Edwards <gr****@visi.comwrote:

On 2008-08-29, Roy Smith <ro*@panix.comwrote:

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]

On Aug 29, 10:11*am, Roy Smith <[e-mail]:

In article <[e-mail]>,
*Grant Edwards <[e-mail]:

On 2008-08-29, Roy Smith <[e-mail]:

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?

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

- Show quoted text -

[Paul McNett]

Steven D'Aprano wrote:

On Thu, 28 Aug 2008 16:28:03 -0700, Paul McNett wrote:

>[e-mail] 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

[Fredrik Lundh]

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>

[Roy Smith]

In article <ma*************************************@python.or g>,
Fredrik Lundh <fr*****@pythonware.comwrote:

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 :-)