Can a simple a==b 'hang' in and endless loop?

[Claudio Grondi]

Claudio Grondi wrote:
[snip..]

Yes, I know about 'is',

but I mean, that it is not possible to use 'is' as replacement for '=='
operator to achieve in Python same behaviour as it is the case in C and
Javascript when comparing values with '=='.
'is' does the C, Javascript job when comparing lists, but I mean it
fails to give fully predictable results when applied to elements of
lists in case there exist duplicate objects with same 'value' i.e. e.g.
there are two different objects storing the integer value 1, what I mean

Hmmm... :
True

Doesn't work with arbitrary longs of course...

I didn't discovered yet myself that even in this simple case
False

Python fails to reuse the long integer object. It would be interesting
to know why, because it seems to be strange, that in case of integers it
does (but not always and I don't know actually when it happens and what
it depends upon). Reusing long integers would make much more sense than
reusing plain integers when considering memory spent on storage.
Hmmm...

So the Java/C '==' operator sometimes works like '==' in Python and
sometimes works like 'is' ? (It switches between equality and identity
depending on the types being compared IIUC).

Yes, this is how I understand it now, with the difference, that Python
adds one additional level of indirection here as there is no plain value
in Python referenced by an identifier, but an object which behaviour
depends ...
From my point of view Javascript/C effect of '==' is consistent where
in Python it's not, but from other long discussions I know, that it
seems to be a matter of taste.
I don't know much enough about Java to speak about it. I know much more
about JScript/Javascript being more like Python is. It is _important to
distinguish_ between Java as a programming language with its VM and
Javascript as an engine working inside dynamic HTML pages (unless one is
on Windows and has the JScript engine available for both purposes:
inside HTML and stand-alone scripting engine).
You write "So the Java/C '==' operator" - I suppose that Java and C
probably differ here, but I'm not sure. Maybe someone else can tell
something about it using a simple example of Java code equivalent to
Python code:
a=[1]
b=[1]
print a==b
print a[0]==b[0]

My understanding is that you can't use '==' in Java to compare strings,
because it is an identity test not an equality test. You have to use a
string method to compare strings. This bites quite a few people...

In Javascript you can do that. Try in an HTML page to write:
<script language=javascript>
s1 = 'abc';
s2 = 'abc';
alert(s1==s2);
s2 = 'bcd';
alert(s1==s2);

Anyway, AFAICT your problem only matters in the abstract (where you are
theoretically comparing objects you haven't specified the type of and
*might* want to use '==' and *might* want to use 'is').

For practical purposes '==' will do what you want, unless you
deliberately create buggy code to cause a problem when you use it...

Unless you can post an example of *non-buggy* code that doesn't behave
how you expect ?

That's not possible, because if the code doesn't behave how I expect, it
will be considered buggy by definition of what buggy code is. So the
problem always is that the programmer haven't understood something right
writing it (unless there is a bug in the Python interpreter itself one
is running into, but this is not the subject here).

I mean, that the more specific the interpretation of code can become
depending on context, the more I have also to know reading a line at the
end of a script about what was written before, making the code more
difficult to read and understand. It is sure a matter of taste if one
likes it that or the other way, but it is important for me to understand
which way it actually is when using or choosing a programming language
for a given kind of task.

The reason why I switched to Python from Microsoft JScript (which is the
dynamic HTML javascript empowered with ActiveX and all Windows specific
things able to write files and do anything Python can do) is the
availability of C code of the scripting engine and the ability to work
cross-platform due to support by using it Python community (member of
which you can find spread over almost any of the various existing
platforms and systems).

Claudio

 

[bonono]

Ok... so I'm now assuming that the information about '==' provided by
the above gentleman *and* that I understand it correctly.

The only confusion in C (which doesn't have classes) is that two list
(like) objects can't be tested by value - only identity.

In C, they are compared(the '==' operator) byte by byte, I don't know
if you interpret that as by value or identity.

 

[Claudio Grondi]

Oops... my misreading, sorry.

The reason that, in Python, short ints have the same identity is not
fickle - it's just True. Python creates a new reference (pointer) to
the same object.

You're saying you want one comparison operator that for :

a=[1]
... many other statements here ...
b=[1]

gives the result :

a xx b # False
a[0] xx b[0] # True

What you're saying is that you don't consider a and b equal when they
are container objects of the same type, with the same contents. That's
very counter intuitive.

As also the fact, that when
a = [1,2.0,3L]
b = [1.0,2,3 ]
a==b # gives True
even if the objects in the lists are actually different,
or when the objects being members of the list redefine __eq__ so, that
no matter how different they are, the lists always compare True.

Claudio

 

[Fuzzyman]

I'm not familiar with the C basic datatypes - I assume it has an array
or list like object.

Would it contain a sequence of poitners to the members ? In which case
they would only be equal if the pointers are the same.

In this case :

a = ['some string']
b = ['somestring']
a == b
False (probably)

Incorrectly using Python syntax for a C example of course

All the best,

Fuzzyman
http://www.voidspace.org.uk/python/index.shtml

 

[Fredrik Lundh]

As also the fact, that when
a = [1,2.0,3L]
b = [1.0,2,3 ]
a==b # gives True
even if the objects in the lists are actually different,

they all compare equal:

True

or when the objects being members of the list redefine __eq__ so, that
no matter how different they are, the lists always compare True.

wow. followups to comp.lang.funny.snake.farm

</F>

 

[bonono]

As also the fact, that when
a = [1,2.0,3L]
b = [1.0,2,3 ]
a==b # gives True
even if the objects in the lists are actually different,
or when the objects being members of the list redefine __eq__ so, that
no matter how different they are, the lists always compare True.

Can't you use "a is b" in this case to test for what you want ?

 

[Fredrik Lundh]

I'm not familiar with the C basic datatypes - I assume it has an array
or list like object.

Would it contain a sequence of poitners to the members ? In which case
they would only be equal if the pointers are the same.

In this case :

a = ['some string']
b = ['somestring']
a == b
False (probably)

the "value" of a C array is the address of its first argument. two separate
arrays will never compare equal, no matter what they contain.

(C programs tend to use various "cmp" functions to compare stuff; it's up
to the programmer to keep track of how to compare things...)

</F>

 

[Fuzzyman]

I'm not familiar with the C basic datatypes - I assume it has an array
or list like object.

Would it contain a sequence of poitners to the members ? In which case
they would only be equal if the pointers are the same.

In this case :

a = ['some string']
b = ['somestring']
a == b
False (probably)

Oops... definitely False unless it is corrected to :

a = ['some string']
b = ['some string']
a == b
False (probably)

All the best,


Fuzzyman
http://www.voidspace.org.uk/python/index.shtml

 

[Fuzzyman]

So you're no longer wanting to test for equality (as Fredrik has
pointed out).

All the best,

Fuzzyman
http://www.voidspace.org.uk/python/index.shtml

 

[Fuzzyman]

but I mean, that it is not possible to use 'is' as replacement for '=='
operator to achieve in Python same behaviour as it is the case in C and
Javascript when comparing values with '=='.
'is' does the C, Javascript job when comparing lists, but I mean it
fails to give fully predictable results when applied to elements of
lists in case there exist duplicate objects with same 'value' i.e. e.g.
there are two different objects storing the integer value 1, what I mean
can happen when there is enough other code between the Python code lines
assigning the integer value 1 to a list element or any other identifier.
Or is there in Python a 100% reliable mechanism assuring, that there is
one and _only one_ object carrying a given 'value' (at least for the
built in types as integer, long integer, string, float) and if this
value is to be assigned to a list element or any other literal the
already existing object (if any) will be found and used/referenced?

I think you fundamentally can't get what you want here. It would be
quite possible to implement an optimization on the == operator in Python
which checked whether two items were identical (i.e. "is", the same as
comparing their addresses). This would do just what C is doing in the
case of comparing two lists which are the same, but then the following
code could not be written:
[snip..]

What you could do is define a subclass of list that compared for
identity rather than comparing the contents of the list.

Alternatively you could test the contents by identity.

All the best,

Fuzzyman
http://www.voidspace.org.uk/python/idnex.shtml

 

[bonono]

I'm not familiar with the C basic datatypes - I assume it has an array
or list like object.

Would it contain a sequence of poitners to the members ? In which case
they would only be equal if the pointers are the same.

In this case :

a = ['some string']
b = ['somestring']
a == b
False (probably)

Incorrectly using Python syntax for a C example of course

That depends, the C syntax is like this :

char *a="hello";
char *b="hello";

assert(a==b);

// true, the compiler knows the two hello are the same and assign the
same address(sort of id() in python) to a and b

But the following is not

char *a="hello";
char *b="_hello";
char *c=b+1;

assert(a==c); //false, even the content they point to are the same

However, string in the above are not basic types of C and if you want
to compare the value(like comparing integer), you need to use function
like strcmp() which again compare byte by byte in the above example and
give true.

 

[Fuzzyman]

I'm not familiar with the C basic datatypes - I assume it has an array
or list like object.

Would it contain a sequence of poitners to the members ? In which case
they would only be equal if the pointers are the same.

In this case :

a = ['some string']
b = ['somestring']
a == b
False (probably)

the "value" of a C array is the address of its first argument. two separate
arrays will never compare equal, no matter what they contain.

(C programs tend to use various "cmp" functions to compare stuff; it's up
to the programmer to keep track of how to compare things...)

Thanks.

Fuzzy

</F>

 

[Claudio Grondi]

Steve Holden wrote:
[...]

The problem here is, that I mean, that in Python it makes no sense to
talk about a value of an object, because it leads to weird things when
trying to give a definition what a value of an object is.

I don;t understand why you say that.

The same problem on my side. I don't understand, why you don't
understand why I am saying that :-( .

It seems, that in Python there is a lack of operator able to compare
values as it is the case in C and Javascript, simply because in Python
there are no really such things as values, so there is no need to
compare them.

That is simply incorrect. The expression a == b is true under
well-defined circumstances usually referred to as "a and b having the
same value". There *are* such things as values. Presumably since you
know about "is", you also know about "id()". In C Python the id() of an
object is simply its memory address, though that isn't how id() is
defined. The fact remains that each object's id() must be unique at any
point in time (though id()s can be reused).

See. Two different objects with the same value, so they compare equal.

Perhaps the difference you are having problems understanding arises
because Python also defines equality for complex objects.

lst1 = [a, b]
lst2 = [b, a]
lst1 == lst2 True

Unlike C there is no need to compare each element of the lists:
list.__eq__() automatically iterates over the items of the list, and
returns True only if all pairwise comparisons return True.

The higher level of abstraction/indirection in Python results in
making the concepts of 'value', 'having a value' or 'comparing values'
useless, where it helps in C to express the difference between address
and content at that address and to distinguish between the information
telling _what_ is stored in memory and the information about _where_
it is stored.

Well in Python each name in a namespace, and each attribute of an
object, and each item in a sequence or a mapping, is a reference to a
value. Where the value is stored is completely irrelevant, and addresses
are only available as an implementation detail in CPython. You can test
if two references are to the same object using "is", which you already
know. In other words

a is b is exactly id(a) == id(b)

Obviously "a is b" implies "a == b", whereas the converse is not true.

Obviously not, see code below:
<PythonCode>
print """
class classWithAlwaysFalseComparison:
def __eq__(self, other):
return False
a = classWithAlwaysFalseComparison()
b = a
"""
class classWithAlwaysFalseComparison:
def __eq__(self, other):
return False
a = classWithAlwaysFalseComparison()
b = a
print 'a is b is %s, but a == b is %s'%(a is b, a==b)
</PythonCode>
<PythonCode-Output>
class classWithAlwaysFalseComparison:
def __eq__(self, other):
return False
a = classWithAlwaysFalseComparison()
b = a

a is b is True, but a == b is False
</PythonCode-Output>

That is, where the intuitive reasoning fails in Python, right?
Do you understand _now_, why I was saying what you don't understand why
I was saying it?

It may so appear to you, but that doesn't make it the case. The reason
for the overly-long discussion is that people insist on picking the
smallest details to bits and arguing over small semantic differences
that are irrelevant to getting programs working.

I have an idea that the people who wrote and maintain the interpreter
find these concepts quite comprehensible, and I don't have any problem
myself. I suspect you are externalising your confusion.

I am not confused myself today and I was not confused at the time I have
posted my own reply "Re: Is 'everything' a refrence or isn't it?" to the
appropriate thread, but in between I become aware of the fact, that my
understanding of Python on 2006-01-04 when I wrote my reply and today
changed to a much deeper and gave me more insight into the
behind-the-scenes and the major concepts behind Python.
Interesting in this context is the fact, that nobody felt that time the
need to correct my notion that Python identifiers have no values in
sense of terms used in C as I wrote:
"""
if you write
for i in lst:
then the identifier i 'points' to values in lst, but else as in C
where you can use a pointer to change the value it points to by
assigning to *i or where you can use a reference to change a value it
references, in Python you don't change a value of i because i is an
identifier and therefore has no value in sense of C - it is only a name
used to reach a value.
"""
What I would like to change in this text above today is the phrase:
"i is an identifier and therefore has no value in sense of C - it is
only a name used to reach a value."
to
"i is an identifier and therefore has no value in sense of C - it is
only a name used to reach a Python object."
in order to get out of the hassle the concept of 'value' causes in Python.

Well, you really are making something extraordinarily easy much more
difficult than it needs to be. I don't even really understand why you
need a written definition of "what a value is", come to that.

Why don't you write some C that you thing it would be difficult to
rewrite it Python?

There really is no need to be so obsessive about where things are
stored. It simply doesn't matter in a language with no pointer types.

It is probably true, that it doesn't much matter when writing Python
code when one do not understand how Python works internally. The rare
practical cases of getting into trouble because of lack of such
understanding can be easily overcome by performing some testing or
asking in the comp.lang.python .
As I see, the question is here, if it is worth the effort to try to
change the way people speak about Python and understand what Python code
does in order to avoid this rare cases of getting into trouble?

By the way, after I have explained the why behind my question, the focus
of this thread has moved, so, that my genuine question has been
forgotten in the mess of the responses. It seems, that it is not
necessary an advantage to tell about the background of the question
asked. I should probably consider it asking next question in order to
avoid an unnecessary not subject related flood of responses.

Claudio

 

[Steve Holden]

>
> ------------------------------------------------------------------------
>
> Subject:
> Re: Can a simple a==b 'hang' in and endless loop?
> From:
> Claudio Grondi <[email protected]>
> Date:
> Wed, 18 Jan 2006 19:59:12 +0100
>
> Newsgroups:
> comp.lang.python
>
>
> Steve Holden wrote:
>

>> Claudio Grondi wrote:
>>

>>> Steve Holden wrote:

>>
>>
>>
>> [...]
>>

>>> The problem here is, that I mean, that in Python it makes no sense

to talk about a value of an object, because it leads to weird things
when trying to give a definition what a value of an object is.

>
>
> The same problem on my side. I don't understand, why you don't

understand why I am saying that :-( .

>

compare values as it is the case in C and Javascript, simply because in
Python there are no really such things as values, so there is no need to
compare them.well-defined circumstances usually referred to as "a and b having the
same value". There *are* such things as values. Presumably since you
know about "is", you also know about "id()". In C Python the id() of an
object is simply its memory address, though that isn't how id() is
defined. The fact remains that each object's id() must be unique at any
point in time (though id()s can be reused).

>>

>> >>> a = 10987
>> >>> b = 10987
>> >>> id(a) >> 4866328
>> >>> id(b) >> 4866340
>> >>> a == b >> True
>> >>>

>>
>> See. Two different objects with the same value, so they compare equal.
>>
>> Perhaps the difference you are having problems understanding arises because Python also defines equality for complex objects.
>>

>> >>> lst1 = [a, b]
>> >>> lst2 = [b, a]
>> >>> lst1 == lst2 >> True
>> >>>

>>
>> Unlike C there is no need to compare each element of the lists:

list.__eq__() automatically iterates over the items of the list, and
returns True only if all pairwise comparisons return True.making the concepts of 'value', 'having a value' or 'comparing values'
useless, where it helps in C to express the difference between address
and content at that address and to distinguish between the information
telling _what_ is stored in memory and the information about _where_ it
is stored.object, and each item in a sequence or a mapping, is a reference to a
value. Where the value is stored is completely irrelevant, and addresses
are only available as an implementation detail in CPython. You can test
if two references are to the same object using "is", which you already
know. In other words

>
>
> Obviously not, see code below:
> <PythonCode>
> print """
> class classWithAlwaysFalseComparison:
> def __eq__(self, other):
> return False
> a = classWithAlwaysFalseComparison()
> b = a
> """
> class classWithAlwaysFalseComparison:
> def __eq__(self, other):
> return False
> a = classWithAlwaysFalseComparison()
> b = a
> print 'a is b is %s, but a == b is %s'%(a is b, a==b)
> </PythonCode>
> <PythonCode-Output>
> class classWithAlwaysFalseComparison:
> def __eq__(self, other):
> return False
> a = classWithAlwaysFalseComparison()
> b = a
>
> a is b is True, but a == b is False
> </PythonCode-Output>
>
> That is, where the intuitive reasoning fails in Python, right?
> Do you understand _now_, why I was saying what you don't understand why I was saying it?
>

Yes. It's a bit like complaining that you bought a gun and you now
realised it can kill people. Python is a language for "consenting
adults": you can use its introspection capabilities to creat
non-intuituve results.
Python represents and if there is such thingy as 'value' in Python, is
not perfectly well understood even by Python experts programming also in
many other languages and therefore the vital differences in concepts
behind Python and e.g. C/C++ is only poorly documented . What else would
be the reason for the over-long discussion in the "Is 'everything' a
refrence or isn't it?" thread in this newsgroup?reason for the overly-long discussion is that people insist on picking
the smallest details to bits and arguing over small semantic differences
that are irrelevant to getting programs working.interpreter find these concepts quite comprehensible, and I don't have
any problem myself. I suspect you are externalising your confusion.

>
>
>
> I am not confused myself today and I was not confused at the time I

have posted my own reply "Re: Is 'everything' a refrence or isn't it?"
to the appropriate thread, but in between I become aware of the fact,
that my understanding of Python on 2006-01-04 when I wrote my reply and
today changed to a much deeper and gave me more insight into the
behind-the-scenes and the major concepts behind Python.

> Interesting in this context is the fact, that nobody felt that time

the need to correct my notion that Python identifiers have no values in

> """
> if you write
> for i in lst:
> then the identifier i 'points' to values in lst, but else as in C

where you can use a pointer to change the value it points to by
assigning to *i or where you can use a reference to change a value it
references, in Python you don't change a value of i because i is an
identifier and therefore has no value in sense of C - it is only a name
used to reach a value.

> """
> What I would like to change in this text above today is the phrase:
> "i is an identifier and therefore has no value in sense of C - it is

only a name used to reach a value."

> to
> "i is an identifier and therefore has no value in sense of C - it is

only a name used to reach a Python object."

> in order to get out of the hassle the concept of 'value' causes in Python.
>

As we often abbreviate it: names in Python are always references.
concept of 'value' in Python is, that it depends ... and it depends on
so many things, that it is hard to give any general valid statement
about it without writing an entire chapter full of details and special
cases.difficult than it needs to be. I don't even really understand why you
need a written definition of "what a value is", come to that.stored. It simply doesn't matter in a language with no pointer types.

>
>
> It is probably true, that it doesn't much matter when writing Python

code when one do not understand how Python works internally. The rare
practical cases of getting into trouble because of lack of such
understanding can be easily overcome by performing some testing or
asking in the comp.lang.python .

> As I see, the question is here, if it is worth the effort to try to

change the way people speak about Python and understand what Python code
does in order to avoid this rare cases of getting into trouble?

>

Precision is alwayds welcome, but sometimes practical discussions
require a certain imprecision simply to allow discussions to move
forward. Goodwill on both sides is always helpful.

> By the way, after I have explained the why behind my question, the

focus of this thread has moved, so, that my genuine question has been
forgotten in the mess of the responses. It seems, that it is not
necessary an advantage to tell about the background of the question
asked. I should probably consider it asking next question in order to
avoid an unnecessary not subject related flood of responses.

>

c.l.py can be a bit like that!

regards
Steve

 

[Dave Hansen]

On Wed, 18 Jan 2006 17:03:23 +0100 in comp.lang.python, Claudio Grondi

[...]

False

Python fails to reuse the long integer object. It would be interesting
to know why, because it seems to be strange, that in case of integers it
does (but not always and I don't know actually when it happens and what
it depends upon). Reusing long integers would make much more sense than
reusing plain integers when considering memory spent on storage.
Hmmm...

I suspect it's a matter of practicality beating purity. Consider

a = 1L
b = 10L
... much code ...
c = b/5
... more code ...
d = c * 3
... still more code ...
e = a * 6
... and now the question ...
print d is e

Do you really want the interpreter, on each long integer assignment
operation (5 in the above example), to find all the long integer
objects, perform a comparison, and re-use objects that compare equal?

Or would you rather the "is" operator alias "==" for longs?

Are either of these options really useful?

Regards,
-=Dave

 

[Dave Hansen]

I'm not familiar with the C basic datatypes - I assume it has an array
or list like object.

Would it contain a sequence of poitners to the members ? In which case
they would only be equal if the pointers are the same.

In this case :

a = ['some string']
b = ['somestring']
a == b
False (probably)

Incorrectly using Python syntax for a C example of course

That depends, the C syntax is like this :

char *a="hello";
char *b="hello";

assert(a==b);

// true, the compiler knows the two hello are the same and assign the
same address(sort of id() in python) to a and b

No. The C standard says the compiler is _allowed_ to re-use character
literal constants, but is not _required_ to do so. So it may be true,
or maybe not, depedning ont he compiler (and, probably, the options
used in its invocation).

But the following is not

char *a="hello";
char *b="_hello";
char *c=b+1;

assert(a==c); //false, even the content they point to are the same

Ditto. The compiler is allowed to re-use the end of "_hello" to
implement "hello", in which case a == b+1, so a==c.

Just to confuse matter slightly, if you change the declarations to
something like

char a[] = "hello";
char b[] = "_hello";
char c[] = "hello";

then a, b, and c are three different strings in three different
locations. Always. In this case, the user is allowed to write code
like

a[0] = 'j';

to change the first string to "jello" without affecting the other
strings.

The essential difference is that in the first two cases, you're
declaring _pointers_ to char, and initializing them to point to string
constants, while in the second case, you're declaring _arrays_ of
char, and setting their initial value using a special initialization
syntax.

However, string in the above are not basic types of C and if you want
to compare the value(like comparing integer), you need to use function
like strcmp() which again compare byte by byte in the above example and
give true.

Yes, indeed.

Regards,
-=Dave

 

[Donn Cave]

It is probably true, that it doesn't much matter when writing Python
code when one do not understand how Python works internally. The rare
practical cases of getting into trouble because of lack of such
understanding can be easily overcome by performing some testing or
asking in the comp.lang.python .
As I see, the question is here, if it is worth the effort to try to
change the way people speak about Python and understand what Python code
does in order to avoid this rare cases of getting into trouble?

Yes and no, mostly no.

The problem is that Python supports a lot of tricks and
gimmicks, and while each one of them was added with the
firmest conviction that it was a useful and important
feature, taken together they make what should be simple,
very complicated.

The ability to make __eq__ return a nonsensical value seems
to be the present example. To be excruciatingly thorough,
an introduction to Python ought to account for this exception,
because in this case we can't predict in principle what "=="
means. But this thorough introduction would not only be
confusing and unproductive, it would also inappropriately
confer some kind of legitimacy on absurd uses of __eq__.
It really is better to ignore this feature, except for the
occasional post on c.l.p. where we can use to shock and
horrify anyone who thought Python was really a simple language.

So this belongs in a different category from, say, lists and
dicts as default arguments. That is a natural usage, where
__eq__ is sort of a perversion if you will, and a Python
programmer should know about it.

Donn Cave, (e-mail address removed)

 

[Steven D'Aprano]

The problem here is, that I mean, that in Python it makes no sense to
talk about a value of an object, because it leads to weird things when
trying to give a definition what a value of an object is.

Python object: 1
The value of that Python object: the int 1

Python object 4.7
The value of that Python object: the float 4.7

Python object "abc"
The value of that Python object: a string consisting of characters a, b
and c.

Python object [1, 4.7, "abc"]
The value of that Python object: a list containing objects 1, 4.7 and "abc".


Where's the problem?

It seems, that in Python there is a lack of operator able to compare
values as it is the case in C and Javascript, simply because in Python
there are no really such things as values, so there is no need to
compare them.

False

Works for me.

The higher level of abstraction/indirection in Python results in making
the concepts of 'value', 'having a value' or 'comparing values' useless,
where it helps in C to express the difference between address and
content at that address and to distinguish between the information
telling _what_ is stored in memory and the information about _where_ it
is stored.

In Python, you never care _where_ anything is stored. The id() function
returns the unique ID of an object, which as an implementation detail may
be the actual memory address, but that's just an implementation detail. In
any case, given a memory address, you can't do anything with that
knowledge.

 

[Fredrik Lundh]

I'm not familiar with the C basic datatypes - I assume it has an array
or list like object.

Would it contain a sequence of poitners to the members ? In which case
they would only be equal if the pointers are the same.

In this case :

a = ['some string']
b = ['somestring']
a == b
False (probably)

Incorrectly using Python syntax for a C example of course

That depends, the C syntax is like this :

char *a="hello";
char *b="hello";

assert(a==b);

// true, the compiler knows the two hello are the same and assign the
same address(sort of id() in python) to a and b

No. The C standard says the compiler is _allowed_ to re-use character
literal constants, but is not _required_ to do so.

I could have sworn that fuzzyman's example contained a literal string in
an array, and an array comparision, so why are you talking about com-
paring string literals ? a compiler for which

char* a[] = { "some string" };
char* b[] = { "some string" };

...

if (a == b)
printf("True\n");

prints True is definitely broken.

</F>

 

[Claudio Grondi]

Dave Hansen wrote:

Fuzzyman wrote:

I'm not familiar with the C basic datatypes - I assume it has an array
or list like object.

Would it contain a sequence of poitners to the members ? In which case
they would only be equal if the pointers are the same.

In this case :

a = ['some string']
b = ['somestring']
a == b
False (probably)

Incorrectly using Python syntax for a C example of course


That depends, the C syntax is like this :

char *a="hello";
char *b="hello";

assert(a==b);

// true, the compiler knows the two hello are the same and assign the
same address(sort of id() in python) to a and b

No. The C standard says the compiler is _allowed_ to re-use character
literal constants, but is not _required_ to do so.

I could have sworn that fuzzyman's example contained a literal string in
an array, and an array comparision, so why are you talking about com-
paring string literals ? a compiler for which

char* a[] = { "some string" };
char* b[] = { "some string" };

...

if (a == b)
printf("True\n");

prints True is definitely broken.

</F>

Exactly this is what Python does under the hood when writing
a = "some string"
b = "some string"
where a and b are actually, in terms of C, pointer to Python object data
structures which provide strings as arrays where it is possible to say
a[0], but ... if here
if(a==b):
print "True"
_does not_ print True, the Python engine is definitely broken.

Claudio