In the process of learning about some deeper details of Python I am
curious if it is possible to write a 'prefix' code assigning to a and b
something special, so, that Python gets trapped in an endless loop in a
line with:
if a==b: print 'OK'
I mean, it would be of much help to me on my way to understanding Python
to know how such prefix code leading to an endless loop can look like
and if it is eventually not possible to write such code, to know why it
is not possible?
My own first rough idea was to create generators which never end and use
them in the '==' comparison, but I have not well understood how to write
and use generators yet, so I expect from studying this special case to
come to some enlightenment.
Claudio
73  4525 
Claudio Grondi wrote: In the process of learning about some deeper details of Python I am
curious if it is possible to write a 'prefix' code assigning to a and b
something special, so, that Python gets trapped in an endless loop in a
line with:
if a==b: print 'OK'
I mean, it would be of much help to me on my way to understanding Python
to know how such prefix code leading to an endless loop can look like
since == can be overridden by the objects involved, == can do anything: http://docs.python.org/ref/customization.html
__lt__ __div__ F __gt__
Claudio Grondi wrote: In the process of learning about some deeper details of Python I am
curious if it is possible to write a 'prefix' code assigning to a and b
something special, so, that Python gets trapped in an endless loop in a
line with:
if a==b: print 'OK'
I mean, it would be of much help to me on my way to understanding Python
to know how such prefix code leading to an endless loop can look like
and if it is eventually not possible to write such code, to know why it
is not possible?
My own first rough idea was to create generators which never end and use
them in the '==' comparison, but I have not well understood how to write
and use generators yet, so I expect from studying this special case to
come to some enlightenment.
Well, you could try this: class thing:
... def __eq__(self, other):
... return other == self
... a = thing()
b = thing()
a == b
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "<stdin>", line 3, in __eq__
File "<stdin>", line 3, in __eq__
File "<stdin>", line 3, in __eq__
...
File "<stdin>", line 3, in __eq__
File "<stdin>", line 3, in __eq__
RuntimeError: maximum recursion depth exceeded
Was that what you meant? Or something more like:
class thing:
... def __eq__(self, other):
... import time; time.sleep(1000000)
... a = thing()
b = thing()
a == b
regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/
Steve Holden wrote: Claudio Grondi wrote:
In the process of learning about some deeper details of Python I am
curious if it is possible to write a 'prefix' code assigning to a and
b something special, so, that Python gets trapped in an endless loop
in a line with:
if a==b: print 'OK'
I mean, it would be of much help to me on my way to understanding
Python to know how such prefix code leading to an endless loop can
look like and if it is eventually not possible to write such code, to
know why it is not possible?
My own first rough idea was to create generators which never end and
use them in the '==' comparison, but I have not well understood how to
write and use generators yet, so I expect from studying this special
case to come to some enlightenment.
Well, you could try this:
>>> class thing: ... def __eq__(self, other):
... return other == self
... >>> a = thing()
>>> b = thing()
>>> a == b Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "<stdin>", line 3, in __eq__
File "<stdin>", line 3, in __eq__
File "<stdin>", line 3, in __eq__
...
File "<stdin>", line 3, in __eq__
File "<stdin>", line 3, in __eq__
RuntimeError: maximum recursion depth exceeded >>>
Was that what you meant? Or something more like:
>>> class thing: ... def __eq__(self, other):
... import time; time.sleep(1000000)
... >>> a = thing()
>>> b = thing()
>>> a == b
regards
Steve
Thanks for the quick reply.
I see, that I have overseen, that as Fredrik also stated, one can
directly manipulate __eq__() as the easiest way to achieve what I
requested.
To explain why I am not happy with it, I will try here to give some more
background information. Sorry for not doing it directly, but as already
stated I have forgot about the possibility to use __eq__().
In Python the built in '==' operator (when not manipulated in own code)
behaves not as the '==' operator e.g. in C or Javascript, because it
iterates over arrays (i.e. lists) doing many comparisons instead of
comparing only two 'values'. Coming from C or Javascript one would
expect '==' to compare the 'pointers' to the arrays and not to iterate
over all elements of the lists.
With the solution to the question above I intended to have an example of
Python code which outcome is an endless loop and the problem causing it
very hard to find if one thinks in terms of C or Javascript when
considering lists (as arrays) and the function of '==' operator.
Claudio
Claudio Grondi wrote:
[snip..] Thanks for the quick reply.
I see, that I have overseen, that as Fredrik also stated, one can
directly manipulate __eq__() as the easiest way to achieve what I
requested.
To explain why I am not happy with it, I will try here to give some more
background information. Sorry for not doing it directly, but as already
stated I have forgot about the possibility to use __eq__().
In Python the built in '==' operator (when not manipulated in own code)
behaves not as the '==' operator e.g. in C or Javascript, because it
iterates over arrays (i.e. lists) doing many comparisons instead of
comparing only two 'values'. Coming from C or Javascript one would
expect '==' to compare the 'pointers' to the arrays and not to iterate
over all elements of the lists.
In Python the equality operator ('==') compares values. For sequence
and mapping type objects this can be a (relatively) expensive
operation.
You are probably looking for the identity operator which just
(effectively) compares pointers ('is').
a is b
does more what you would expect.
This is a better system than the ones you describe. :-)
All the best,
Fuzzyman
http://www.voidspace.org.uk/python/index.shtml
With the solution to the question above I intended to have an example of
Python code which outcome is an endless loop and the problem causing it
very hard to find if one thinks in terms of C or Javascript when
considering lists (as arrays) and the function of '==' operator.
Claudio
Claudio Grondi wrote: Steve Holden wrote:
Claudio Grondi wrote:
In the process of learning about some deeper details of Python I am
curious if it is possible to write a 'prefix' code assigning to a and
b something special, so, that Python gets trapped in an endless loop
in a line with:
if a==b: print 'OK'
I mean, it would be of much help to me on my way to understanding
Python to know how such prefix code leading to an endless loop can
look like and if it is eventually not possible to write such code, to
know why it is not possible?
My own first rough idea was to create generators which never end and
use them in the '==' comparison, but I have not well understood how to
write and use generators yet, so I expect from studying this special
case to come to some enlightenment.
Well, you could try this:
>>> class thing:
... def __eq__(self, other):
... return other == self
... >>> a = thing()
>>> b = thing()
>>> a == b
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "<stdin>", line 3, in __eq__
File "<stdin>", line 3, in __eq__
File "<stdin>", line 3, in __eq__
...
File "<stdin>", line 3, in __eq__
File "<stdin>", line 3, in __eq__
RuntimeError: maximum recursion depth exceeded >>>
Was that what you meant? Or something more like:
>>> class thing:
... def __eq__(self, other):
... import time; time.sleep(1000000)
... >>> a = thing()
>>> b = thing()
>>> a == b
regards
Steve
Thanks for the quick reply.
I see, that I have overseen, that as Fredrik also stated, one can
directly manipulate __eq__() as the easiest way to achieve what I
requested.
To explain why I am not happy with it, I will try here to give some more
background information. Sorry for not doing it directly, but as already
stated I have forgot about the possibility to use __eq__().
In Python the built in '==' operator (when not manipulated in own code)
behaves not as the '==' operator e.g. in C or Javascript, because it
iterates over arrays (i.e. lists) doing many comparisons instead of
comparing only two 'values'. Coming from C or Javascript one would
expect '==' to compare the 'pointers' to the arrays and not to iterate
over all elements of the lists.
With the solution to the question above I intended to have an example of
Python code which outcome is an endless loop and the problem causing it
very hard to find if one thinks in terms of C or Javascript when
considering lists (as arrays) and the function of '==' operator.
If your assertiona about C and Java are correct you would, of course,
describing a deficiency of those languages, where a variable refers to a
reserved area of storage intended to hold a value of a specific type (or
a specific uinion of types).
To the Python user C and Java appear to be confusing "equality" with
"identity". The == operator in C, certainly, compares identity (whether
of values or of pointers to structured values). Frankly I don't choose
to remember enough Java to determine the correctness of your assertion
in that language.
In Python a name is intended to be bound as a reference to an object of
any type whatsoever (the type pf the object is stored as a part of the
value). Equality is generally defined as "has the same value", hence the
ability to define it specifically for user-defined types.
In Python you test for "is the same object" with the "is" operator. As in a = {1:2, 3:4}
b = {1:2, 3:4}
a == b
True a is b
False
regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/
Fuzzyman wrote: Claudio Grondi wrote:
[snip..]
Thanks for the quick reply.
I see, that I have overseen, that as Fredrik also stated, one can
directly manipulate __eq__() as the easiest way to achieve what I
requested.
To explain why I am not happy with it, I will try here to give some more
background information. Sorry for not doing it directly, but as already
stated I have forgot about the possibility to use __eq__().
In Python the built in '==' operator (when not manipulated in own code)
behaves not as the '==' operator e.g. in C or Javascript, because it
iterates over arrays (i.e. lists) doing many comparisons instead of
comparing only two 'values'. Coming from C or Javascript one would
expect '==' to compare the 'pointers' to the arrays and not to iterate
over all elements of the lists.
In Python the equality operator ('==') compares values. For sequence
and mapping type objects this can be a (relatively) expensive
operation.
You are probably looking for the identity operator which just
(effectively) compares pointers ('is').
a is b
does more what you would expect.
This is a better system than the ones you describe. :-)
All the best,
Fuzzyman
http://www.voidspace.org.uk/python/index.shtml
With the solution to the question above I intended to have an example of
Python code which outcome is an endless loop and the problem causing it
very hard to find if one thinks in terms of C or Javascript when
considering lists (as arrays) and the function of '==' operator.
Claudio
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
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?
Claudio
Steve Holden wrote: Claudio Grondi wrote:
Steve Holden wrote:
Claudio Grondi wrote:
In the process of learning about some deeper details of Python I am
curious if it is possible to write a 'prefix' code assigning to a
and b something special, so, that Python gets trapped in an endless
loop in a line with:
if a==b: print 'OK'
I mean, it would be of much help to me on my way to understanding
Python to know how such prefix code leading to an endless loop can
look like and if it is eventually not possible to write such code,
to know why it is not possible?
My own first rough idea was to create generators which never end and
use them in the '==' comparison, but I have not well understood how
to write and use generators yet, so I expect from studying this
special case to come to some enlightenment.
Well, you could try this:
>>> class thing:
... def __eq__(self, other):
... return other == self
...
>>> a = thing()
>>> b = thing()
>>> a == b
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "<stdin>", line 3, in __eq__
File "<stdin>", line 3, in __eq__
File "<stdin>", line 3, in __eq__
...
File "<stdin>", line 3, in __eq__
File "<stdin>", line 3, in __eq__
RuntimeError: maximum recursion depth exceeded
>>>
Was that what you meant? Or something more like:
>>> class thing:
... def __eq__(self, other):
... import time; time.sleep(1000000)
...
>>> a = thing()
>>> b = thing()
>>> a == b
regards
Steve
Thanks for the quick reply.
I see, that I have overseen, that as Fredrik also stated, one can
directly manipulate __eq__() as the easiest way to achieve what I
requested.
To explain why I am not happy with it, I will try here to give some
more background information. Sorry for not doing it directly, but as
already stated I have forgot about the possibility to use __eq__().
In Python the built in '==' operator (when not manipulated in own
code) behaves not as the '==' operator e.g. in C or Javascript,
because it iterates over arrays (i.e. lists) doing many comparisons
instead of comparing only two 'values'. Coming from C or Javascript
one would expect '==' to compare the 'pointers' to the arrays and not
to iterate over all elements of the lists.
With the solution to the question above I intended to have an example
of Python code which outcome is an endless loop and the problem
causing it very hard to find if one thinks in terms of C or Javascript
when considering lists (as arrays) and the function of '==' operator.
If your assertiona about C and Java are correct you would, of course,
describing a deficiency of those languages, where a variable refers to a
reserved area of storage intended to hold a value of a specific type (or
a specific uinion of types).
To the Python user C and Java appear to be confusing "equality" with
"identity". The == operator in C, certainly, compares identity (whether
of values or of pointers to structured values). Frankly I don't choose
to remember enough Java to determine the correctness of your assertion
in that language.
In Python a name is intended to be bound as a reference to an object of
any type whatsoever (the type pf the object is stored as a part of the
value). Equality is generally defined as "has the same value", hence the
ability to define it specifically for user-defined types.
In Python you test for "is the same object" with the "is" operator. As in
>>> a = {1:2, 3:4}
>>> b = {1:2, 3:4}
>>> a == b True >>> a is b False >>>
regards
Steve
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.
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.
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.
It appears to me, that the whole subject of what an identifier in 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?
From what I know about Python up to now, the problem with the 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.
Claudio
Claudio Grondi wrote:
[...] 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
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.
Perhaps you could try again in English? :-) Sorry, that's a very complex
sentence and it isn't clear what yo mean.
In C, of course, a == b requires that a and b be of compatible types and
that they have the same value. This means that if they are pointers they
must point to the same thing (which is exactly what "is" tests for).
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?
No more than there is in C or, presumably, Java.
If you want to test for identity, use "is". If you want to test for
equality, use "==". Of you want to test for something else, kindly
explain what you want to test for.
regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/
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... :
a = 1
b = 1
a is b
True
Doesn't work with arbitrary longs of course...
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?
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).
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...
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 ?
All the best,
Fuzzyman
http://www.voidspace.org.uk/python/index.shtml
Claudio
Claudio Grondi wrote: Steve Holden wrote:
[snip..] 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.
You're saying that C and Java get round that problem by sometimes
defining value to mean 'the memory address and object is stored at'.
That hardly seems to clarify what value *really* means, and can lead to
some interesting confusions.
Anyway - for the basic datatypes 'value' seems quite clear. It's only
not clear what this might mean in user defined classes - where value
means whatever you define it to mean.
By overloading the comparison and rich comparison methods of user
defined classes, you have the opportunity to *precisely* define the
meaning of value...
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.
Can you provide an example to clarify what you mean ?
All the best,
Fuzzyman http://www.voidspace.org.uk/python/index.shtml
Steve Holden wrote: Claudio Grondi wrote:
[...]
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 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.
Perhaps you could try again in English? :-) Sorry, that's a very complex
sentence and it isn't clear what yo mean.
Here in English ;-) :
a=[1]
.... many other statements here ...
b=[1]
a is b # False
a == b # True
a[0] is b[0] # unpredictable(?)
a[0] == b[0] # True
so a C, Javascript equivalent '==' operator (called here e.g. 'xx')
should in case of code above _always_ give:
a xx b # False
a[0] xx b[0] # True
what becomes only possible if the object holding the integer value 1 is
created only once when a=[1] and reused when executing b=[1].
Claudio
In C, of course, a == b requires that a and b be of compatible types and
that they have the same value. This means that if they are pointers they
must point to the same thing (which is exactly what "is" tests for).
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?
No more than there is in C or, presumably, Java.
If you want to test for identity, use "is". If you want to test for
equality, use "==". Of you want to test for something else, kindly
explain what you want to test for.
regards
Steve
Claudio Grondi wrote:
[snip..]> > Perhaps you could try again in English? :-) Sorry, that's a
very complex sentence and it isn't clear what yo mean. Here in English ;-) :
a=[1]
... many other statements here ...
b=[1]
a is b # False
a == b # True
a[0] is b[0] # unpredictable(?)
a[0] == b[0] # True
so a C, Javascript equivalent '==' operator (called here e.g. 'xx')
should in case of code above _always_ give:
a xx b # False
a[0] xx b[0] # True
what becomes only possible if the object holding the integer value 1 is
created only once when a=[1] and reused when executing b=[1].
So you're *really* saying that you want this :
a = 1
b = 1
a == b
False
??????
WTF
Fuzzyman
http://www.voidspace.org.uk/python/index.shtml
Claudio
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.
All the best,
Fuzzyman http://www.voidspace.org.uk/python/index.shtml
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.
I don;t understand why you say 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).
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.
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.
It appears to me, that the whole subject of what an identifier in 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?
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.
From what I know about Python up to now, the problem with the 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.
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.
regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/
Fuzzyman wrote: Claudio Grondi wrote: Steve Holden wrote:
[snip..] 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.
You're saying that C and Java get round that problem by sometimes
defining value to mean 'the memory address and object is stored at'.
That hardly seems to clarify what value *really* means, and can lead to
some interesting confusions.
Anyway - for the basic datatypes 'value' seems quite clear. It's only
not clear what this might mean in user defined classes - where value
means whatever you define it to mean.
I don't know much about Java but in C, I fail to see any confusion.
There is no such thing as user defined classes nor operator overload.
bon...@gmail.com wrote: Fuzzyman wrote: Claudio Grondi wrote: Steve Holden wrote:
[snip..] 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.
You're saying that C and Java get round that problem by sometimes
defining value to mean 'the memory address and object is stored at'.
That hardly seems to clarify what value *really* means, and can lead to
some interesting confusions.
Anyway - for the basic datatypes 'value' seems quite clear. It's only
not clear what this might mean in user defined classes - where value
means whatever you define it to mean.
I don't know much about Java but in C, I fail to see any confusion.
There is no such thing as user defined classes nor operator overload.
You may fail to see the confusion, but feel free to add to it ;-)
The above gentleman is asserting that in *Python* the term value has no
meaning.
I asserted in response : Anyway - for the basic datatypes 'value' seems quite clear. It's only
not clear what this might mean in user defined classes - where value
means whatever you define it to mean.
All the best,
Fuzzyman http://www.voidspace.org.uk/python/index.shtml
Claudio Grondi wrote: 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: class A:
.... def __eq__(self, other):
.... return False
.... a = A()
a == a
False
If you eliminate the possibility of writing the above code, you probably
don't have Python any more (or possibly many other very dynamic
languages either).
-Peter
Fuzzyman wrote: The above gentleman is asserting that in *Python* the term value has no
meaning.
I don't know what he meant and don't want to get into that
value/reference/object thingy discussion as it would be a never ending
thing. I just want to say that '==' in C is very clear to me, whether
it is as useful(correct) as in python or C++ or other higher level
language is another issue. But what would be the interesting confusion
that you envision ?
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 Java, comparing strings using '==' compares for identity not
equality (IIUC), giving *plenty* of room for confusion.
All the best,
Fuzzyman http://www.voidspace.org.uk/python/index.shtml
Fuzzyman wrote: 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... :
>>> a = 1
>>> b = 1
>>> a is b True
Doesn't work with arbitrary longs of course...
I didn't discovered yet myself that even in this simple case
a = 1L
b = 1L
a is b
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...
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?
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);
</script>
and see the True/False in the raised message boxes.
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
Fuzzyman wrote: 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.
Fuzzyman wrote: 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
All the best,
Fuzzyman
http://www.voidspace.org.uk/python/index.shtml
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
Claudio Grondi wrote: 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 ?
Claudio Grondi wrote: 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:
1 == 1.0
True 2.0 == 2
True 3L == 3
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>
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)
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
Incorrectly using Python syntax for a C example of course :-)
All the best,
Fuzzyman
http://www.voidspace.org.uk/python/index.shtml
Peter Hansen wrote: Claudio Grondi wrote: 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
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
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 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)
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>
Fredrik Lundh 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)
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>
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.
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).
>>> 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.
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 appears to me, that the whole subject of what an identifier in
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?
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.
From what I know about Python up to now, the problem with the 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.
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
regards
Steve
Claudio Grondi wrote:
------------------------------------------------------------------------
Subject:
Re: Can a simple a==b 'hang' in and endless loop?
From:
Claudio Grondi <cl************@freenet.de>
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.
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). >>> 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. 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?
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.
It appears to me, that the whole subject of what an identifier in
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?
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.
As we often abbreviate it: names in Python are always references.
From what I know about Python up to now, the problem with the
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.
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?
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
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/
On Wed, 18 Jan 2006 17:03:23 +0100 in comp.lang.python, Claudio Grondi
<cl************@freenet.de> wrote:
[...] a = 1L
b = 1L
a is b
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
--
Change is inevitable, progress is not.
On 18 Jan 2006 08:41:00 -0800 in comp.lang.python, bo****@gmail.com
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. 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
--
Change is inevitable, progress is not.
On Wed, 18 Jan 2006 15:29:24 +0100, Claudio Grondi 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.
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.
1 == 1
True 4.7 == 1
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.
--
Steven.
In article <dq**********@newsreader3.netcologne.de>,
Claudio Grondi <cl************@freenet.de> wrote:
.... 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, do**@u.washington.edu
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>
Fredrik Lundh wrote: 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
Claudio Grondi wrote: 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.
Why are you comparing C behaviour to Python behaviour?
What is the point of the discussion?
--
Steven.
Steven D'Aprano wrote: Claudio Grondi wrote:
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.
Why are you comparing C behaviour to Python behaviour? What is the point
of the discussion?
The point is to find a way to create in Python two indentifiers a and b
without manipulating any of the __eq__ and to __eq__ related functions
in a way, that the simple
if a==b: print 'a==b'
statement results in an endless loop.
To my knowledge this is not possible to achieve in C, but is probably
achievable in Python.
Claudio
Steven D'Aprano wrote: On Wed, 18 Jan 2006 15:29:24 +0100, Claudio Grondi 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.
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?
My problem is, that I don't know if it is possible and if yes how to
overwrite the __eq__() methods of the built-in types.
With not built-in types I can do:
class classWithWeirdEqualityBehaviour:
def __init__(self, value)
self.value = value
def __eq__(self, other):
return False
a = classWithWeirdEqualityBehaviour(1)
b = classWithWeirdEqualityBehaviour(1)
a==b # gives False
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.
1 == 1
True
4.7 == 1
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.
The question here is, if this a handicap or a welcome feature?
From the one side I am glad that Python cares about memory allocation
for me, but on the other side I have trouble to accept, that I have no
direct access to the memory area where data are stored in order to
manipulate them. Having this possibility would enormously speed up some
conversions, because it were possible to get them down to a redefinition
of the data structure without being forced to loop over the actual
content or use a special extension library written in C for doing that.
Claudio
Claudio Grondi wrote: Steven D'Aprano wrote:
Claudio Grondi wrote:
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.
Why are you comparing C behaviour to Python behaviour? What is the point
of the discussion?
The point is to find a way to create in Python two indentifiers a and b
without manipulating any of the __eq__ and to __eq__ related functions
in a way, that the simple
if a==b: print 'a==b'
statement results in an endless loop.
To my knowledge this is not possible to achieve in C, but is probably
achievable in Python.
So finally we understand what you are looking for (though not why ...).
a = [1]
a.append(a)
a
[1, [...]]
b = [1]
b.append(b)
a == b
Traceback (most recent call last):
File "<stdin>", line 1, in ?
RuntimeError: maximum recursion depth exceeded in cmp
Is this what you seek? Not quite "an endless loop", but probably as
close as you are going to get given the necessariliy recursive data
structures required to induce it.
regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/
Claudio Grondi wrote: Steven D'Aprano wrote:
[...]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.
The question here is, if this a handicap or a welcome feature?
A welcome feature, absolutely no doubt about it.
From the one side I am glad that Python cares about memory allocation
for me, but on the other side I have trouble to accept, that I have no
direct access to the memory area where data are stored in order to
manipulate them. Having this possibility would enormously speed up some
conversions, because it were possible to get them down to a redefinition
of the data structure without being forced to loop over the actual
content or use a special extension library written in C for doing that.
Well, if this isn't a case of premature optimization I've never seen
one. You apparently haven't yet written a single line of your
appliction, yet you are already concerned about its efficiency.
1. First, make it work.
2. Then, if it doesn;t work fast enough, make it work faster.
regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/
(If I understand correctly...)
The reason he is looking for it, is in order to assert that Python
'comparison' is broken.
Part of this is because of his assertation that the term 'value' has no
meaning in Python.
He bases this on the fact that Java and C define 'value' to mean the
pointer when the object is mutable.
In fact Python defines value much more clearly. Value is *obviously*
type dependent. (This is why in Python you can implement your own
comparison methods).
For integers and floats, Python defines the value to be the numerical
value.
For strings it defines it to be the contents of the string.
For mutable objects it defines it to be the contents of the object, if
the object types are the same. i.e. [1] == [1], [1] != (1,)
For user defined classes, you are able to build your own definition of
value into the object - this doesn't prevent stupidity.
Python doesn't have a comparison operator analagous to his reference
languages - but IMHO Python is better here. He can achieve what he
wants by subclassing the built in datatypes and overriding the
comparison methods to behave as he desires.
All the best,
Fuzzyman http://www.voidspace.org.uk/python/index.shtml
Steve Holden wrote: Claudio Grondi wrote:
Steven D'Aprano wrote:
Claudio Grondi wrote:
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.
Why are you comparing C behaviour to Python behaviour? What is the
point of the discussion?
The point is to find a way to create in Python two indentifiers a and
b without manipulating any of the __eq__ and to __eq__ related
functions in a way, that the simple
if a==b: print 'a==b'
statement results in an endless loop.
To my knowledge this is not possible to achieve in C, but is probably
achievable in Python.
So finally we understand what you are looking for (though not why ...).
I will intentionally not elaborate here about the why, as my experience
with this thread has already shown, that this is not only not helpful in
getting the answer to the actual question, but results in 'hiding' the
goal to the reader which needs to be revealed as it gets lost in the
explanation. >>>
>>> a = [1]
>>> a.append(a)
>>> a [1, [...]] >>>
>>> b = [1]
>>> b.append(b)
>>> a == b Traceback (most recent call last):
File "<stdin>", line 1, in ?
RuntimeError: maximum recursion depth exceeded in cmp >>>
Is this what you seek? Not quite "an endless loop", but probably as
close as you are going to get given the necessariliy recursive data
structures required to induce it.
Wow! I haven't got this evil idea myself yet (even if as I understand
there is no problem to achieve similar thing also in C), so I have
learned a bit more about Python again. Am I right supposing, that this
becomes possible because the .append() goes not that far to try to
generate the actual list (getting trapped in the endless loop) and only
lets the second list element point to the object with the list itself.
The trouble with it becomes apparent later when working with such bad
defined list as it is the case when applying the '==' operator to it.
Thank you for sharing this with me, but again ...
this is still _not_ what I am looking for, because Python detects here
the problem and throws an exception. What I am looking for is an endless
loop where there is no any response from Python about a problem.
Claudio
Claudio Grondi wrote: Steve Holden wrote:
Claudio Grondi wrote:
Steven D'Aprano wrote:
Claudio Grondi wrote:
>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.
Why are you comparing C behaviour to Python behaviour? What is the
point of the discussion?
The point is to find a way to create in Python two indentifiers a and
b without manipulating any of the __eq__ and to __eq__ related
functions in a way, that the simple
if a==b: print 'a==b'
statement results in an endless loop.
To my knowledge this is not possible to achieve in C, but is probably
achievable in Python.
So finally we understand what you are looking for (though not why ...).
I will intentionally not elaborate here about the why, as my experience
with this thread has already shown, that this is not only not helpful in
getting the answer to the actual question, but results in 'hiding' the
goal to the reader which needs to be revealed as it gets lost in the
explanation.
>>>
>>> a = [1]
>>> a.append(a)
>>> a
[1, [...]] >>>
>>> b = [1]
>>> b.append(b)
>>> a == b
Traceback (most recent call last):
File "<stdin>", line 1, in ?
RuntimeError: maximum recursion depth exceeded in cmp >>>
Is this what you seek? Not quite "an endless loop", but probably as
close as you are going to get given the necessariliy recursive data
structures required to induce it.
Wow! I haven't got this evil idea myself yet (even if as I understand
there is no problem to achieve similar thing also in C), so I have
learned a bit more about Python again. Am I right supposing, that this
becomes possible because the .append() goes not that far to try to
generate the actual list (getting trapped in the endless loop) and only
lets the second list element point to the object with the list itself.
The trouble with it becomes apparent later when working with such bad
defined list as it is the case when applying the '==' operator to it.
Thank you for sharing this with me, but again ...
Yes, clearly Python is able to create recursive data structures of this
type, just as C and Java are. As you can see when the interpreter prints
the representation of such lists, the __repr__() method does indeed
detect such recursion and places ellipses ("...") in the output to
indicate it.
When you say "Python goes not so far as to try to generate the actual
list" you reveal a misunderstanding about Python. The interpreter
responds to the statement
a.append(a)
just as it responds to every other append() method call: it adds a new
item to the list and binds (i.e. stores a reference to) the argument (in
this case the list as itself) to that new item. No special cases are
required here, this is what the interpreter always does.
this is still _not_ what I am looking for, because Python detects here
the problem and throws an exception. What I am looking for is an endless
loop where there is no any response from Python about a problem.
Ah, I see. So you want Python to be a worse language than it actually
is. I don't think you are going to find what you are looking for.
regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/
Claudio Grondi wrote:
[snip..] Wow! I haven't got this evil idea myself yet (even if as I understand
there is no problem to achieve similar thing also in C), so I have
learned a bit more about Python again. Am I right supposing, that this
becomes possible because the .append() goes not that far to try to
generate the actual list (getting trapped in the endless loop) and only
lets the second list element point to the object with the list itself.
I think you've got this.
a = []
Here a is a reference to a list object.
a.append(a)
As mentioend previously - you pass around references (names), not
values.
Here you've put a reference to the list object a as the first member of
the list a.
The trouble with it becomes apparent later when working with such bad
defined list as it is the case when applying the '==' operator to it.
Thank you for sharing this with me, but again ...
this is still _not_ what I am looking for, because Python detects here
the problem and throws an exception. What I am looking for is an endless
loop where there is no any response from Python about a problem.
Loops tend to be caused by function or method calls - so they add
frames to the stack and get detected as recursion.
All the best,
Fuzzyman
http://www.voidspace.org.uk/python/index.shtml
Claudio
Fuzzyman wrote: (If I understand correctly...)
The reason he is looking for it, is in order to assert that Python
'comparison' is broken.
a bit this way, but why formulate it with such a negative touch?
Lets understand it more as looking for a way to get a deep understanding
of the concept behind the Python '==' operator (and many other things
related to it) and a way to explain it to a C programmer (because it
differs from the concept he knows from C). If it should turn out, that
there is some inconsistency in the Python concept it will become
apparent why and then it can be discussed further or even lead to a PEP
and everyone here will profit from this. If it turns out that there is
no inconsistency, one more Python user (i.e. me :-) ) will get deep
understanding of this Python concept and maybe can help others seeking
same enlightenment.
Part of this is because of his assertation that the term 'value' has no
meaning in Python.
This seems to me still to be true, but lets postpone the discussion of
it (which should first give a definition what 'value' means in Python)
and about if it makes sense to use this term to describe something which
is far away from the common understanding of it to another thread and a
later time when I get even more clear picture about it as it is the case
now.
He bases this on the fact that Java and C define 'value' to mean the
pointer when the object is mutable.
I base it on the fact, that a value is what is actually stored in memory
in a data structure which can be reached used a name (i.e. an
identifier). This way of understanding what value means allows to
distinguish between memory content (the value) and memory address
(represented by the name of the variable). The concept of the pointer in
C does not change the meaning of the term value, because there is a
value a pointer has (i.e. there is data in memory addressed by the
variable name which is the pointer) and that this value means here an
address is another beer (leading to much confusion when learning to work
with pointers in C).
By the way: please don't mix Javascript and Java - these are two totally
different things. Java is a programming language you can compile for a
Java VM, Javascript is the interpreted scripting language used for
scripting of HTML where its Windows version JScript is a full featured
scripting engine like Python is. I haven't mentioned Java as I know only
very little about it, I have mentioned Javascript (JScript) I am much
more experienced with.
In fact Python defines value much more clearly. Value is *obviously*
type dependent. (This is why in Python you can implement your own
comparison methods).
For integers and floats, Python defines the value to be the numerical
value.
For strings it defines it to be the contents of the string.
For mutable objects it defines it to be the contents of the object, if
the object types are the same. i.e. [1] == [1], [1] != (1,)
For user defined classes, you are able to build your own definition of
value into the object - this doesn't prevent stupidity.
Python doesn't have a comparison operator analagous to his reference
languages - but IMHO Python is better here. He can achieve what he
wants by subclassing the built in datatypes and overriding the
comparison methods to behave as he desires.
You seem here to try to give a definition of the term 'value' for
Python. If I understand it right, the definition of the term can't be
generally given for many reasons. It depends at least on type and in
advanced usage it can be arbitrary defined or changed.
That is why I mean, that it makes no sense to talk in Python about
value. I see not much sense in taking existing term in order to redefine
it for a new context - the result is always increase of confusion. Let
give it another name in order to know, that it must be defined for the
context it is used before it becomes meaningful.
Any suggestions?
Claudio This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Paul Wistrand |
last post by:
I'm hoping that someone can quickly tell me of way to make my concole app
pause for a set duration before contining in an infinite loop (e.g. solution
to 100% cpu problem).
Thanks
|
by: Bev in TX |
last post by:
We are using Visual Studio .NET 2003. When using that compiler, the
following example code goes into an endless loop in the "while" loop when the
/Og optimization option is used:
#include...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
| |
