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

G

Grant Edwards

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 DOS attack "crashing"
another program. If that's the sort of think he's talking
about, those are just as trivial to do do in Python as they are
in C.
 
D

Dennis Lee Bieber

Any hints towards enlightenment what this from the geometry known term
'ellipsis' mean in Python? Googling shows, that I am not the first who

Geometry: singular ellipse, plural ellipses -- sort of a flattened
circle
Punctuation: singular ellipsis -- a mark (typically three ...,
typographically a single character "…") used to represent omitted text.
For example, trimming the middle of a quote, such as:
"Any hints towards ... term 'ellipsis' mean in Python?"

In the case of python, you would have to examine slice notation and
some history...

Unless things have changed, nothing in the core Python language
/uses/ the ellipsis in slicing. It was added, apparently, for use in
numerical extension modules where the ellipsis represent
missing/unspecified array indices in an extended slice.
--
 
C

Claudio Grondi

Dennis said:
Geometry: singular ellipse, plural ellipses -- sort of a flattened
circle
Punctuation: singular ellipsis -- a mark (typically three ...,
typographically a single character "…") used to represent omitted text.
For example, trimming the middle of a quote, such as:
"Any hints towards ... term 'ellipsis' mean in Python?"

In the case of python, you would have to examine slice notation and
some history...

Unless things have changed, nothing in the core Python language
/uses/ the ellipsis in slicing. It was added, apparently, for use in
numerical extension modules where the ellipsis represent
missing/unspecified array indices in an extended slice.

As shown just above in this thread the code:
>>> a = [1]
>>> a.append(a)
>>> a
[1, [...]]
uses it, so it seems, that things have changed.

Claudio
 
C

Claudio Grondi

Donn said:
Aargh, you are so close. The thing you're talking about is,
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 mean, that it could help to avoid confusion
resulting from the fact, that one believes to know the native meaning of
the term 'value' and tries to apply it to Python.

Claudio
 
D

Donn Cave

Donn Cave wrote: ....
That's right, but I mean, that it could help to avoid confusion
resulting from the fact, that one believes to know the native meaning of
the term 'value' and tries to apply it to Python.

There is no confusion, as long as you stay away from futile
analysis of the meaning of value. If you insist on that,
then no alternative word will help you.

Donn Cave, (e-mail address removed)
 
T

Terry Hancock

As shown just above in this thread the code:
a = [1]
a.append(a)
a
[1, [...]]
uses it, so it seems, that things have changed.

No it doesn't. It just uses "...".

That would be like complaining if I wrote an object
representation like:

<MyObject is 2>

that I was "using" the keyword "is" inconsistently. Wrong.
I'm not using it at all -- I'm just using the string "is".

Same above. Although the deeper meaning "an ellipsis shows
an omission" is preserved. The ellipsis in the recursive
definition substitutes for a literal representation which
is conceptually infinite (although due to recursion limits
is really finite).
 
S

Steve Holden

Claudio said:
Dennis said:
Geometry: singular ellipse, plural ellipses -- sort of a flattened
circle
Punctuation: singular ellipsis -- a mark (typically three ...,
typographically a single character "…") used to represent omitted text.
For example, trimming the middle of a quote, such as:
"Any hints towards ... term 'ellipsis' mean in Python?"

In the case of python, you would have to examine slice notation and
some history...

Unless things have changed, nothing in the core Python language
/uses/ the ellipsis in slicing. It was added, apparently, for use in
numerical extension modules where the ellipsis represent
missing/unspecified array indices in an extended slice.


As shown just above in this thread the code:
a = [1]
a.append(a)
a
[1, [...]]
uses it, so it seems, that things have changed.
Nope, that's just a linguistic snafu on my part. In English the term
"ellipsis" describes "..." and means "Omission from a text of one or
more words that are obviously understood but that must be supplied to
make a construction grammatically correct". So I described the three
dots as an ellipsis without reference to its meaning in Python.

I hope this hasn't seriously inconvenienced you. However, it does seem
like you are "looking for trouble" here -- i.e. looking to prove that
Python is broken, when what's actually broken appears to be *your
understanding* of Python.

regards
Steve
 
T

Terry Hancock

I guess I never called that sort of DOS attack "crashing"
another program. If that's the sort of think he's talking
about, those are just as trivial to do do in Python as
they are in C.

But you do agree that you can shoot your dog in the foot
with it, though, I take it? ;-)

Yes, true multitasking operating systems and CPUs that
support them with protected memory spaces are a good thing.
My C experience mostly dates from machines that didn't have
those features.

Cheers,
Terry
 
D

Dennis Lee Bieber

[1, [...]]
uses it, so it seems, that things have changed.
That's not a language syntactic feature, you can't enter

a = [1, [...]]

and have it make sense.

It's an optimization performed during the conversion to a printable
representation of something the runtime has determined never ends, in
which case the ... means just what it does in regular typography: the
contents have been omitted from the text. Otherwise you'd get an
infinite series that looks like:

[1, [1, [1, [1, ... (I have to use them to indicate that I've omitted
the rest of the never-ending sequence) ]]]]
--
 
G

Grant Edwards

But you do agree that you can shoot your dog in the foot
with it, though, I take it? ;-)

Oh, definitely. And with C++ you can blow the poor creature's
leg entirely off.
Yes, true multitasking operating systems and CPUs that support
them with protected memory spaces are a good thing. My C
experience mostly dates from machines that didn't have those
features.

Though it doesn't make writing a correct program much easier, a
real OS mitigates to a large extent the damage you can do with
C. That said, I only write in C when Python isn't a choice.
 
M

Magnus Lycka

Claudio said:
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?

I think I understand what you mean. In e.g. C you have variables
with values. A variable is a location in memory where you can place
values of a certain type.

This "world-view" doesn't fit if you want to understand Python.

You always have three "thingies" in Python, instead of the two in
C. In C terminology you could say that you always use void pointers
in Python. (Of course, it's not as bad as it sounds, because of
all runtime checks and memory management etc, but you know that.)

So, in Python you have references, objects and content.

Sometimes the reference is just a slot in a container, e.g. if you
have "[0]" in your code, the list contains a reference to an
integer object with the content 0.

I think most people consider "value" and "content" to be synonyms,
but from the perspective of a variable name in the source code,
e.g. "a='hello'", there is always one level of indirection, since
there is always a pointer in between (and you can get that with
"id(a)").

The Python manuals refer to the names in Python programs (such as
"a" in "a=1") as variables, but some think that it's better to
call them "names" or "references", since they lack properties many
people associate with variables, for instance type.

If I return to C lingo again, datastructures in Python are always
made with malloc, and it's just these datastructures on the heap
that contain interesting values (or contents if you prefer that).

In C, pointers are particular types, and you can create pointer
chains that have an arbitrary length. Python don't have pointers.
You always get one level of idirection automatically, and the
referencing and derefencing is handled automatically. If you want
to chain data structures you can easily do that with containers
such as lists, or with classes you define yourself.

I don't think there are really any controversies concerning values
though. It's the content of the malloced datastructure. It's not
as ovbiously available in Python as in C, but it's still meaningful
to talk about it.

Then we get to the case of comparision operators in Python, such
as == and > etc. For simple types, they are used to compare the
values/contents of the compared objects in a fairly obvious way.
For containers such as list, Python declares that two lists are
equal if they have the same number of elements, and a pair-wise
comparision of all elements compare equal. E.g. ([a,b] == [c,d])
== (a==c and b==d). For classes you define, you get to decide
yourself how to implement comparisions.

This freedom in how to compare things shouldn't really influence
your view on values in Python. Values aren't defined through the
comparision operator.

One fundamental difference between C and Python is that C is a low
level language where you can directly access and manipulate the
computer memory. Python is a high level language where you can't
to that. You are limited to more abstract operations. I can see
how that makes thing feel more fuzzy. It's a bit like a car with
the hood welded shut. Also, Python is more flexible and customizable.
The comparision operators aren't hardwired to some basic machine
language instructions, their behaviour is defined in your code. It's
like fly-by-wire in modern airplanes. When the pilot pulls a lever,
it doesn't directly cause a rudder to move on a wing, it tells the
steering computer where the plane should go, and the computer decides
what rudders to move, and how much. That doesn't mean that it's
pointless to discuss rudders in modern airplanes.
 
C

Claudio Grondi

Magnus said:
Claudio said:
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?


I think I understand what you mean. In e.g. C you have variables
with values. A variable is a location in memory where you can place
values of a certain type.

This "world-view" doesn't fit if you want to understand Python.

You always have three "thingies" in Python, instead of the two in
C. In C terminology you could say that you always use void pointers
in Python. (Of course, it's not as bad as it sounds, because of
all runtime checks and memory management etc, but you know that.)

So, in Python you have references, objects and content.

Sometimes the reference is just a slot in a container, e.g. if you
have "[0]" in your code, the list contains a reference to an
integer object with the content 0.

I think most people consider "value" and "content" to be synonyms,
but from the perspective of a variable name in the source code,
e.g. "a='hello'", there is always one level of indirection, since
there is always a pointer in between (and you can get that with
"id(a)").

The Python manuals refer to the names in Python programs (such as
"a" in "a=1") as variables, but some think that it's better to
call them "names" or "references", since they lack properties many
people associate with variables, for instance type.

If I return to C lingo again, datastructures in Python are always
made with malloc, and it's just these datastructures on the heap
that contain interesting values (or contents if you prefer that).

In C, pointers are particular types, and you can create pointer
chains that have an arbitrary length. Python don't have pointers.
You always get one level of idirection automatically, and the
referencing and derefencing is handled automatically. If you want
to chain data structures you can easily do that with containers
such as lists, or with classes you define yourself.

I don't think there are really any controversies concerning values
though. It's the content of the malloced datastructure. It's not
as ovbiously available in Python as in C, but it's still meaningful
to talk about it.

Then we get to the case of comparision operators in Python, such
as == and > etc. For simple types, they are used to compare the
values/contents of the compared objects in a fairly obvious way.
For containers such as list, Python declares that two lists are
equal if they have the same number of elements, and a pair-wise
comparision of all elements compare equal. E.g. ([a,b] == [c,d])
== (a==c and b==d). For classes you define, you get to decide
yourself how to implement comparisions.

This freedom in how to compare things shouldn't really influence
your view on values in Python. Values aren't defined through the
comparision operator.

One fundamental difference between C and Python is that C is a low
level language where you can directly access and manipulate the
computer memory. Python is a high level language where you can't
to that. You are limited to more abstract operations. I can see
how that makes thing feel more fuzzy. It's a bit like a car with
the hood welded shut. Also, Python is more flexible and customizable.
The comparision operators aren't hardwired to some basic machine
language instructions, their behaviour is defined in your code. It's
like fly-by-wire in modern airplanes. When the pilot pulls a lever,
it doesn't directly cause a rudder to move on a wing, it tells the
steering computer where the plane should go, and the computer decides
what rudders to move, and how much. That doesn't mean that it's
pointless to discuss rudders in modern airplanes.

I welcome what you wrote as you seem to get some understanding of what I
am intending to tell. From what you have written I am not 100% sure if
you are already there, or you are only close to what I mean, so lets try
to clarify it.
I am happy to see the term 'content' as it express much better what is
stored in an object, because 'content' is a quite general term and
therefore it is no problem to say it can be any of value, function,
class, operator, type etc.

So I see the Python terminology resolved using following hierarchy of
terms:

- on the top level there is a name called in Python terms _identifier_
being a substitute for a reference to a Python object.
- one lever deeper referenced by an identifier is a Python _object_ with
all the functionality and data it represent. All this what makes an
object i.e. various kind of data stored in it, functions, classes,
types, etc. provided is called Python object content, short _content_.
- one level deeper, in the object itself they may be various data stored
as integer values, strings, etc. . An object can, but need not to hold
any data which can be one single _value_ or more of them. The values an
object holds can be but need not to be used for exposing them, i.e. some
values can be 'hidden' from being present in an object and used only for
internal object purposes.

Let's summarize providing following rough draft of hierarchy of terms:

identifier ->(dereferencing)->object->(is container for)->content->(is a
superordinate concept covering one or more of)->value, function, class,
type, object, etc.

Any comments, refinements, corrections, adjustments?

Claudio
 
S

Steven D'Aprano

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.

Why would you want to?
To my knowledge this is not possible to achieve in C, but is probably
achievable in Python.

I doubt it.

The closest I can think of is something like this:


a = []
a.append(a)
b = []
b.append(b)
a == b

which I'm told used to cause an endless loop in early versions of Python,
but now simply returns True.
 
C

Claudio Grondi

Steven said:
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.


Why would you want to?

To my knowledge this is not possible to achieve in C, but is probably
achievable in Python.


I doubt it.

The closest I can think of is something like this:


a = []
a.append(a)
b = []
b.append(b)
a == b

which I'm told used to cause an endless loop in early versions of Python,
but now simply returns True.

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 exceeded in cmp
Claudio
 
S

Steven D'Aprano

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 exceeded in cmp

Works for me:


Python 2.3.3 (#1, May 7 2004, 10:31:40)
[GCC 3.3.3 20040412 (Red Hat Linux 3.3.3-7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
a = []
a.append(a)
b = []
b.append(b)
a == b
True


Maybe IDLE is playing silly buggers, or perhaps Python 2.4.2 has a bug.
 
T

Tim Peters

[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 exceeded in cmp

|[Steven D'Aprano]
Works for me:

Under a different version of Python, though.
Python 2.3.3 (#1, May 7 2004, 10:31:40)
[GCC 3.3.3 20040412 (Red Hat Linux 3.3.3-7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
a = []
a.append(a)
b = []
b.append(b)
a == b
True


Maybe IDLE is playing silly buggers, or perhaps Python 2.4.2 has a bug.

It's neither. From the NEWS file for Python 2.4a1:

"""
- Python no longer tries to be smart about recursive comparisons.
When comparing containers with cyclic references to themselves it
will now just hit the recursion limit. See SF patch 825639.
"""
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top