Claudio Grondi wrote:
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
Magnus Lycka wrote:
Claudio Grondi wrote:
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
On Thu, 19 Jan 2006 10:08:38 +0100, Claudio Grondi wrote:
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.
Steven D'Aprano wrote:
On Thu, 19 Jan 2006 10:08:38 +0100, Claudio Grondi wrote:
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
On Sat, 21 Jan 2006 01:12:28 +0100, Claudio Grondi wrote:
Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on
win32 - IDLE 1.1.2
a=[]
a.append(a)
b=[]
b.append(b)
a==b
Traceback (most recent call last):
File pyshell#4, line 1, in -toplevel-
a==b
[Claudio Grondi]
Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit
(Intel)] on win32 - IDLE 1.1.2
a=[]
a.append(a)
b=[]
b.append(b)
a==b
Traceback (most recent call last):
File pyshell#4, line 1, in -toplevel-
a==b
RuntimeError: maximum recursion depth
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 :
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
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],
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
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
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
(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
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
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
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
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
Steve Holden wrote:
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
On Thu, 19 Jan 2006 08:06:50 +0100 in comp.lang.python, Fredrik
Lundh [EMAIL PROTECTED] wrote:
Dave Hansen wrote:
[EMAIL PROTECTED] wrote]
Fuzzyman wrote:
[...]
In this case :
a = ['some string']
b = ['somestring']
a == b
False (probably)
That depends, the C syntax is like this :
On Thu, 19 Jan 2006 10:25:12 +0100
Claudio Grondi [EMAIL PROTECTED] wrote:
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
Steve Holden wrote:
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
On Wed, 18 Jan 2006 17:10:09 +0100
Claudio Grondi [EMAIL PROTECTED] wrote:
or when the objects being members of the list redefine
__eq__ so, that no matter how different they are, the
lists always compare True.
If those objects have redefined __eq__ so that they are all
equal in value to each
On Thu, 19 Jan 2006 14:22:34 +0100
Claudio Grondi [EMAIL PROTECTED] wrote:
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.
I
In article [EMAIL PROTECTED],
Claudio Grondi [EMAIL PROTECTED] wrote:
...
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
On 2006-01-19, Terry Hancock [EMAIL PROTECTED] wrote:
It is precisely this power that makes C such a dangerous
language to program in -- it's what makes it so easy to crash
your program, any other program running on the same machine,
Nonsense. Under Windows 3.0 that may be true, but on any
Claudio Grondi wrote:
The Python tutorial '3.2 The standard type hierarchy' says:
Ellipsis: This type has a single value. There is a single object with
this value. This object is accessed through the built-in name Ellipsis.
It is used to indicate the presence of the ... syntax in a
Grant Edwards wrote:
It is precisely this power that makes C such a dangerous
language to program in -- it's what makes it so easy to crash
your program, any other program running on the same machine,
Nonsense. Under Windows 3.0 that may be true, but on any real
OS, you can't crash any
On 2006-01-19, Fredrik Lundh [EMAIL PROTECTED] wrote:
It is precisely this power that makes C such a dangerous
language to program in -- it's what makes it so easy to crash
your program, any other program running on the same machine,
Nonsense. Under Windows 3.0 that may be true, but on
Dennis Lee Bieber wrote:
On Thu, 19 Jan 2006 17:25:38 +0100, Claudio Grondi
[EMAIL PROTECTED] declaimed the following in comp.lang.python:
Any hints towards enlightenment what this from the geometry known term
'ellipsis' mean in Python? Googling shows, that I am not the first who
Donn Cave wrote:
In article [EMAIL PROTECTED],
Claudio Grondi [EMAIL PROTECTED] wrote:
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
In article [EMAIL PROTECTED],
Claudio Grondi [EMAIL PROTECTED] wrote:
Donn Cave wrote:
...
exactly, value. The realization you just had, that is so valid,
is that it is futile to talk about value, per se. Changing the
word you use will do nothing to improve this.
That's right, but I
On Thu, 19 Jan 2006 17:42:40 -
Grant Edwards [EMAIL PROTECTED] wrote:
On 2006-01-19, Fredrik Lundh [EMAIL PROTECTED]
wrote:
It is precisely this power that makes C such a
dangerous language to program in -- it's what makes
it so easy to crash your program, any other program
On Thu, 19 Jan 2006 19:30:18 +0100
Claudio Grondi [EMAIL PROTECTED] wrote:
Dennis Lee Bieber wrote:
On Thu, 19 Jan 2006 17:25:38 +0100, Claudio Grondi
[EMAIL PROTECTED] declaimed the following in
comp.lang.python:
As shown just above in this thread the code:
a = [1]
a.append(a)
Claudio Grondi wrote:
Dennis Lee Bieber wrote:
On Thu, 19 Jan 2006 17:25:38 +0100, Claudio Grondi
[EMAIL PROTECTED] declaimed the following in comp.lang.python:
Any hints towards enlightenment what this from the geometry known term
'ellipsis' mean in Python? Googling shows, that I am not
On 2006-01-19, Terry Hancock [EMAIL PROTECTED] wrote:
given that it's trivial to create fork bombs and memory
monsters in all those languages, I think you might need
to define the term real OS.
(or do you run all your programs in a virtual sandbox ?)
I guess I never called that sort of
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
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
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'
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
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
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
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
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
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
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,
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] ==
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]
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
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
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
[EMAIL PROTECTED] 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
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,
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
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
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 '=='
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
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)
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,
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.
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']
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
--
http://mail.python.org/mailman/listinfo/python-list
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']
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
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']
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 =
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
Claudio Grondi wrote:
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
On Wed, 18 Jan 2006 17:03:23 +0100 in comp.lang.python, Claudio Grondi
[EMAIL PROTECTED] 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
On 18 Jan 2006 08:41:00 -0800 in comp.lang.python, [EMAIL PROTECTED]
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
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
In article [EMAIL PROTECTED],
Claudio Grondi [EMAIL PROTECTED] 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
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
72 matches
Mail list logo
