newbie question

[David Wurmfeld]

I am new to python; any insight on the following would be appreciated, even
if it is the admonition to RTFM (as long as you can direct me to a relevant
FM)

Is there a standard approach to enumerated types? I could create a
dictionary with a linear set of keys, but isn't this overkill? There is
afterall a "True" and "False" enumeration for Boolean.

Is there a way to ignore case in string comparisons? I want 'Oranges' to
equal 'oranges' when using the evaluation operator (==). I don't care about
string inequalities (<, >)

If I am compelled to use dictionaries for enumerated types, is there a way
to generate unique keys automatically: something like
"myDict.appendWithAutoKey("Persimmons")"?

Is there a way to overload operators to accommodate an enumeration? For
example,

newFruit = enumerationFruit('Cumquat') #use it like you would use
list()
new = newFruit + 14 # this should throw an exception because of
different types

Finally, (for now at least) consider the following list.

myList = [apple, 13, plum, cherry, 'Spam', tomato, 3.35]

Exactly how does the "for x in myList" work?
If the list is a heterogeneous list of disparate types, the == operator
works fine, independent of type.
For example, (if x == 'spam') evaluates as false if the item in the list is
an integer. But if I try to do this: (if x.__abs()__) throws an exception if
x "pulls" a non integer from the list. Wouldn't you think that an iterative
would have the "sense" to understand that in this limited scope if a method
didn't apply to the iterator just "fail" (i.e. evaluate to False) the
evaluation and move along? Do I have to manually interrogate each iteration
for the proper type before I test?
Think about it; the interpreter has to evaluate disparate types for
equality. How exactly does the it "know" that for this iteration, x is an
integer, and the evaluation (if x == 'spam') is False, and doesn't throw an
exception for a type mismatch?

Thanks in advance for your insight,
David, Melbourne, Florida.

 

[Miki Tebeka]

Hello David,

Is there a standard approach to enumerated types? I could create a
dictionary with a linear set of keys, but isn't this overkill? There is
afterall a "True" and "False" enumeration for Boolean.

Google for Python + enum.
(A good one is: http://www.norvig.com/python-iaq.html)

Is there a way to ignore case in string comparisons? I want 'Oranges' to
equal 'oranges' when using the evaluation operator (==). I don't care about
string inequalities (<, >)

s1.lower() == s2.lower()

If I am compelled to use dictionaries for enumerated types, is there a way
to generate unique keys automatically: something like
"myDict.appendWithAutoKey("Persimmons")"?

http://docs.python.org/lib/typesmapping.html and "setdefault"

Is there a way to overload operators to accommodate an enumeration? For
example,

newFruit = enumerationFruit('Cumquat') #use it like you would use
list()
new = newFruit + 14 # this should throw an exception because of
different types

http://www.python.org/doc/2.3.4/ref/numeric-types.html

Finally, (for now at least) consider the following list.

myList = [apple, 13, plum, cherry, 'Spam', tomato, 3.35]

Exactly how does the "for x in myList" work?

It binds 'x' in the body of the loop to each item in sequence.

Wouldn't you think that an iterative would have the "sense" to understand
that in this limited scope if a method didn't apply to the iterator just
"fail" (i.e. evaluate to False) the evaluation and move along?

How would it konw that a method don't apply to an object?

Do I have to manually interrogate each iteration
for the proper type before I test?

Yes. Or you can filter the sequence:
for x in [i for i in list if type(i) == type(1)]

Think about it; the interpreter has to evaluate disparate types for
equality. How exactly does the it "know" that for this iteration, x is an
integer, and the evaluation (if x == 'spam') is False, and doesn't throw an
exception for a type mismatch?

Python is strongly type in the sense that each object has a type.
I don't remember exactly how does Python resolve operators and methods, but
if it's can't find one for == it'll return False (IMO).

Bye.

 

[Nick Coghlan]

I am new to python; any insight on the following would be appreciated, even
if it is the admonition to RTFM (as long as you can direct me to a relevant
FM)

Your questions are esoteric enough that, even though the relevant information
*is* in the FM, RTFM would be a really slow and painful way to learn it. . .

Is there a standard approach to enumerated types? I could create a
dictionary with a linear set of keys, but isn't this overkill?

The problem is that enumerated types get used for so many different things that
it isn't easy to come up with One Obvious Way To Do It.

A fairly simple version:

Py> class Enum(object):
.... def __init__(self, attrs):
.... for num, attr in enumerate(attrs):
.... setattr(self, attr, num)
.... self._values = attrs
.... def get_name(self, value):
.... return self._values[value]
....
Py> Fruit = Enum(["apple", "banana", "pear"])
Py> Fruit.pear
2
Py> Fruit.banana
1
Py> Fruit.apple
0
Py> Fruit.get_name(0)
'apple'
Py> Fruit.get_name(1)
'banana'
Py> Fruit.get_name(2)
'pear'
Py> Fruit.get_name(3)
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "<stdin>", line 7, in get_name
IndexError: list index out of range

A more complete answer can be found at the link Miki gave:
http://www.norvig.com/python-iaq.html (look for Enumerated Types)

(Don't get too concerned about some of the other things Peter says on the rest
of that page - the more glaring omissions he mentions have been addressed for
Python 2.4)

There is
afterall a "True" and "False" enumeration for Boolean.

True/False isn't actually an enumeration - they're special objects for boolean
values (i.e. "True is 1" and "False is 0" both return False)

Is there a way to ignore case in string comparisons? I want 'Oranges' to
equal 'oranges' when using the evaluation operator (==). I don't care about
string inequalities (<, >)

The standard way is to invoke the string .lower() method, and compare the forced
lowercase versions instead.

If I am compelled to use dictionaries for enumerated types, is there a way
to generate unique keys automatically: something like
"myDict.appendWithAutoKey("Persimmons")"?

The enumerate() function is generally the easiest way to get hold of a unique
index for each item in a sequence.

Is there a way to overload operators to accommodate an enumeration? For
example,

newFruit = enumerationFruit('Cumquat') #use it like you would use
list()
new = newFruit + 14 # this should throw an exception because of
different types

Certainly - Python allows almost all operations to be overridden (id() is the
only one I can think of that is off limits!)

Again, Miki already pointed you in the right direction:
http://www.python.org/doc/2.4/ref/specialnames.html

(I'd advise *against* inheriting from int or long though - trying to prevent the
base type from leaking through the API is a serious PITA)

Finally, (for now at least) consider the following list.

myList = [apple, 13, plum, cherry, 'Spam', tomato, 3.35]

Exactly how does the "for x in myList" work?

The specified operation is applied to each item in the sequence. The behaviour
on heterogenous types will depend on the exact operation and how it handles type
differences.

evaluation and move along? Do I have to manually interrogate each iteration
for the proper type before I test?

It depends on the operation - checking the type can work, as can looking for an
appropriate attribute:

[abs(x) for x in myList if hasattr(x, "__abs__")]

Think about it; the interpreter has to evaluate disparate types for
equality. How exactly does the it "know" that for this iteration, x is an
integer, and the evaluation (if x == 'spam') is False, and doesn't throw an
exception for a type mismatch?

Easy: if the types are different, the objects are almost certainly different, so
the interpreter applies that rule as the default.

It *is* possible to alter that determination though:
Py> from decimal import Decimal
Py> Decimal(1) == int(1)
True
Py> type(Decimal(1))
<class 'decimal.Decimal'>
Py> type(int(1))
<type 'int'>

The reason your __abs__ example blows up is because the relevant attribute is
missing for string objects - and there's nothing the interpreter can do about
that. If you don't care, you need to tell the interpreter so (using either
hasattr() or try/except)

Cheers,
Nick.

 

[Dan Bishop]

I am new to python; any insight on the following would be appreciated, even
if it is the admonition to RTFM (as long as you can direct me to a relevant

http://www.python.org/doc/

Is there a standard approach to enumerated types? I could create a
dictionary with a linear set of keys, but isn't this overkill? There is
afterall a "True" and "False" enumeration for Boolean.

If you're lazy, you can just use ints, like the "calendar" module did
for the weekday names:

MONDAY = 0
TUESDAY = 1
WEDNESDAY = 2
THURSDAY = 3
FRIDAY = 4
SATURDAY = 5
SUNDAY = 6

This can be more concisely written as:

MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY, SATURDAY, SUNDAY =
xrange(7)

If you want an enumeration like bool where printing an enumeration
value prints its name instead of the int, you can do something like:

class Weekday(int):
_NAMES = ('Monday', 'Tuesday', 'Wednesday', 'Thursday', 'Friday',
'Saturday', 'Sunday')
def __repr__(self):
return Weekday._NAMES[self]

# Monday = Weekday(0); Tuesday = Weekday(1); etc.
for i, dayName in enumerate(Weekday._NAMES):
globals()[dayName] = Weekday(i)

If you'd rather refer to the names as, e.g., "Weekday.Monday", you can
use setattr(Weekday, dayName, Weekday(i))

If you have multiple enum classes to write, you can do:

def enum(*names):
class Enum(int):
_NAMES = names
def __repr__(self):
return Enum._NAMES[self]
for i, name in enumerate(names):
setattr(Enum, name, Enum(i))
return Enum

Weekday = enum('Monday', 'Tuesday', 'Wednesday', 'Thursday', 'Friday',
'Saturday', 'Sunday')
Sex = enum('Female', 'Male')

Is there a way to ignore case in string comparisons? I want 'Oranges' to
equal 'oranges' when using the evaluation operator (==). I don't care about
string inequalities (<, >)

s1.lower() == s2.lower()

If I am compelled to use dictionaries for enumerated types, is there a way
to generate unique keys automatically: something like
"myDict.appendWithAutoKey("Persimmons")"?

Is there a way to overload operators to accommodate an enumeration?

There's a way to overload operators for any class, not just
enumerations. See http://docs.python.org/ref/specialnames.html, and
pay special attention to section 3.3.7. For operations that don't make
sense, you can "return NotImplemented" or "raise TypeError()"

Finally, (for now at least) consider the following list.

myList = [apple, 13, plum, cherry, 'Spam', tomato, 3.35]

Exactly how does the "for x in myList" work?

It works as if you had written:

for _i in xrange(len(myList)):
x = myList(_i)
....

If the list is a heterogeneous list of disparate types, the == operator
works fine, independent of type.
For example, (if x == 'spam') evaluates as false if the item in the list is
an integer. But if I try to do this: (if x.__abs()__) throws an

exception

It should always raise an exception. Perhaps you meant "if abs(x)", in
which case you can just write "if x", which is equivalent in any class
that correctly implements __abs__ and __nonzero__. If you meant to
test whether x.__abs__ exists, you can use "if hasattr(x, '__abs__')".

if
x "pulls" a non integer from the list. Wouldn't you think that an iterative
would have the "sense" to understand that in this limited scope if a method
didn't apply to the iterator just "fail" (i.e. evaluate to False) the

evaluation and move along?

No, for the same reason that 17 + 'x' should not just evaluate to False
and move along.

Do I have to manually interrogate each iteration
for the proper type before I test?

If the operations you want to use don't apply to all of your data, then
they probably shouldn't be in the same list.

Think about it; the interpreter has to evaluate disparate types for
equality. How exactly does the it "know" that for this iteration, x is an
integer,

Because type(x) == int.

and the evaluation (if x == 'spam') is False,

It looks for the methods __eq__ and __cmp__ for the left-side object,
in that order. If neither is implemented, it looks at the right side.

and doesn't throw an exception for a type mismatch?

Originally, for technical reasons, comparisions couldn't throw
exceptions at all, which is why the built-in types define meaningless
comparisons like

2004 < 'spam' 1
[] < {}

0

For ==, the reasoning is that equality implies comparibility, and
contrapositively, if two objects aren't even comparable they aren't
equal.

 

[Diez B. Roggisch]

It works as if you had written:

for _i in xrange(len(myList)):
x = myList(_i)

No, as this implies that the variable has to support random access using
indices. But all that's required is the iterable-interface beeing supported
- by calling __iter__ and .next() on the resulting object.

 

[Keith Dart]

I am new to python; any insight on the following would be appreciated, even
if it is the admonition to RTFM (as long as you can direct me to a relevant
FM)

Is there a standard approach to enumerated types? I could create a
dictionary with a linear set of keys, but isn't this overkill? There is
afterall a "True" and "False" enumeration for Boolean.

Not a standard one, but here's what I use:

class Enum(int):
__slots__ = ("_name")
def __new__(cls, val, name):
v = int.__new__(cls, val)
v._name = str(name)
return v
def __str__(self):
return self._name
def __repr__(self):
return "%s(%d, %r)" % (self.__class__.__name__, self, self._name)
def __cmp__(self, other):
if isinstance(other, int):
return int.__cmp__(self, other)
if type(other) is str:
return cmp(self._name, other)
raise ValueError, "Enum comparison with bad type"

class Enums(list):
def __init__(self, *init):
for i, val in enumerate(init):
if issubclass(type(val), list):
for j, subval in enumerate(val):
self.append(Enum(i+j, str(subval)))
elif isinstance(val, Enum):
self.append(val)
else:
self.append(Enum(i, str(val)))
def __repr__(self):
return "%s(%s)" % (self.__class__.__name__, list.__repr__(self))



-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Keith Dart <[email protected]>
public key: ID: F3D288E4
=====================================================================

 

[Doug Holton]

I am new to python; any insight on the following would be appreciated, even
if it is the admonition to RTFM (as long as you can direct me to a relevant
FM)

Is there a standard approach to enumerated types? I could create a
dictionary with a linear set of keys, but isn't this overkill? There is
afterall a "True" and "False" enumeration for Boolean.

To actually answer your question, no, there is no standard for enums in
python. There are custom hacks for it that you can search for.

Boo, a programming language that is virtually identical to python, does
have standard enums:

enum Color:
Red
Green
Blue

See http://boo.codehaus.org/

In fact, since not many seem to be aware of its existence, I encourage
everyone here to check out boo as an alternative to python.

Is there a way to ignore case in string comparisons? I want 'Oranges' to
equal 'oranges' when using the evaluation operator (==). I don't care about
string inequalities (<, >)

No, not with the == operator, unless you use:
s1.lower() == s2.lower()

Visual Basic is the only language I am aware of that has
case-insensitive strings.

Finally, (for now at least) consider the following list.

myList = [apple, 13, plum, cherry, 'Spam', tomato, 3.35]

Exactly how does the "for x in myList" work?
If the list is a heterogeneous list of disparate types, the == operator
works fine, independent of type.
For example, (if x == 'spam') evaluates as false if the item in the list is
an integer. But if I try to do this: (if x.__abs()__) throws an exception if
x "pulls" a non integer from the list. Wouldn't you think that an iterative
would have the "sense" to understand that in this limited scope if a method
didn't apply to the iterator just "fail" (i.e. evaluate to False) the
evaluation and move along? Do I have to manually interrogate each iteration
for the proper type before I test?
Think about it; the interpreter has to evaluate disparate types for
equality. How exactly does the it "know" that for this iteration, x is an
integer, and the evaluation (if x == 'spam') is False, and doesn't throw an
exception for a type mismatch?

Because python is a strongly typed. If you want to perform a type
specific operation like abs() or string.lower(), but the object's type
may not be the right type, then you have to check its type first.

In boo, we have an "isa" operator for this purpose:

if x isa string:
....

or:
for item in myList:
given typeof(item):
when string:
print item.ToLower()
when int:
print Math.Abs(item)

 

[Peter Hansen]

Boo, a programming language that is virtually identical to python, ...
See http://boo.codehaus.org/

In fact, since not many seem to be aware of its existence, I encourage
everyone here to check out boo as an alternative to python.

Why? If it's virtually identical, why would anyone bother even
visiting that site? ;-)

But I suspect you mean that the syntax of the language is virtually
identical, while probably there are some significant differences.
Maybe in the richness of its standard library? Or the size of
its community? Or something else....

-Peter

 

[Doug Holton]

Why? If it's virtually identical, why would anyone bother even
visiting that site? ;-)

But I suspect you mean that the syntax of the language is virtually
identical, while probably there are some significant differences.
Maybe in the richness of its standard library? Or the size of
its community? Or something else....

 

[Luis M. Gonzalez]

Why? If it's virtually identical, why would anyone bother even
visiting that site? ;-)

But I suspect you mean that the syntax of the language is virtually
identical, while probably there are some significant differences.
Maybe in the richness of its standard library? Or the size of
its community? Or something else....

The difference is that it runs on the .NET frmework (and Mono).
So instead of using the python standard libraries, you use the .NET
ones.
Regarding its syntax, it is very similar to Python. However the
language is statically typed, not dynamic.
Anyway, you don't have to declare types too often, because it uses a
very good type inference system.
For all those reasons, Boo has very good performance.
In theory, it's performance is equal to C# or any other .NET compliant
language, but it is still in phase of development (although quite
usable for many tasks).

So I guess it has many characteristics that make it a very interesting
language for any python fan. And for those concerned with speed and
performance, it is god send.

 

[Peter Hansen]

The difference is that it runs on the .NET frmework (and Mono).
So instead of using the python standard libraries, you use the .NET
ones.
Regarding its syntax, it is very similar to Python. However the
language is statically typed, not dynamic.
Anyway, you don't have to declare types too often, because it uses a
very good type inference system.
For all those reasons, Boo has very good performance.
In theory, it's performance is equal to C# or any other .NET compliant
language, but it is still in phase of development (although quite
usable for many tasks).

So I guess it has many characteristics that make it a very interesting
language for any python fan. And for those concerned with speed and
performance, it is god send.

As one uninterested so far in .NET, and not concerned primarily
with speed, and concerned definitely with maturity and stability,
and not in the least interested in static typing, I thank you
for saving me the time investigating further.

"Virtually identical" indeed.

-Peter

 

[Doug Holton]

"Virtually identical" indeed.

As noted on the website that I've pointed out to you multiple times now,
the syntax of boo is indeed virtually identical to python. The
functionality however, is more like C#.

 

[Peter Hansen]

As noted on the website that I've pointed out to you multiple times now,
the syntax of boo is indeed virtually identical to python. The
functionality however, is more like C#.

Sadly your second post hasn't reached my news server, which is
quite flaky. Fortunately (checking Google Groups), I see it
added nothing of substance, as it merely points to the site again,
without addressing my comments about how syntactical similarity
or even identity doesn't justify the term "virtually identical",
which implies that in all respects one thing is essentially
identical to another.

And given that Boo is *not* virtually identical to Python*,
pointing it out to a self-proclaimed newbie with a question
about enums seems like nothing more than an ill-chosen
moment to do a little proselytizing. Why not just start
a thread about Boo and point it out to those of us who
have never heard of it? That wouldn't raise any hackles...

-Peter

* Boo appears to be well-described by its own home page,
which reads roughly "Boo is a new object-oriented statically
typed language for the [CLI] with a python-inspired syntax
and a special focus on language and compiler extensibility".
Not surprisingly, it doesn't include the phrase "virtually
identical to Python" anywhere.

 

[Steve Holden]

I am new to python; any insight on the following would be appreciated,
even if it is the admonition to RTFM (as long as you can direct me to
a relevant FM)

Is there a standard approach to enumerated types? I could create a
dictionary with a linear set of keys, but isn't this overkill? There
is afterall a "True" and "False" enumeration for Boolean.

To actually answer your question, no, there is no standard for enums in
python. There are custom hacks for it that you can search for.

Boo, a programming language that is virtually identical to python, does
have standard enums:

enum Color:
Red
Green
Blue

See http://boo.codehaus.org/

In fact, since not many seem to be aware of its existence, I encourage
everyone here to check out boo as an alternative to python.

Is there a way to ignore case in string comparisons? I want 'Oranges'
to equal 'oranges' when using the evaluation operator (==). I don't
care about string inequalities (<, >)

No, not with the == operator, unless you use:
s1.lower() == s2.lower()

Visual Basic is the only language I am aware of that has
case-insensitive strings.

Finally, (for now at least) consider the following list.

myList = [apple, 13, plum, cherry, 'Spam', tomato, 3.35]

Exactly how does the "for x in myList" work?
If the list is a heterogeneous list of disparate types, the ==
operator works fine, independent of type.
For example, (if x == 'spam') evaluates as false if the item in the
list is an integer. But if I try to do this: (if x.__abs()__) throws
an exception if x "pulls" a non integer from the list. Wouldn't you
think that an iterative would have the "sense" to understand that in
this limited scope if a method didn't apply to the iterator just
"fail" (i.e. evaluate to False) the evaluation and move along? Do I
have to manually interrogate each iteration for the proper type before
I test?
Think about it; the interpreter has to evaluate disparate types for
equality. How exactly does the it "know" that for this iteration, x is
an integer, and the evaluation (if x == 'spam') is False, and doesn't
throw an exception for a type mismatch?

Because python is a strongly typed. If you want to perform a type
specific operation like abs() or string.lower(), but the object's type
may not be the right type, then you have to check its type first.

In boo, we have an "isa" operator for this purpose:

if x isa string:
....

or:
for item in myList:
given typeof(item):
when string:
print item.ToLower()
when int:
print Math.Abs(item)

It appears you should read your own remarks from the "Web forum (made by
python)" thread

whereas-my-ego-couldn't-be-smaller-ly yr's - steve

 

[Luis M. Gonzalez]

And given that Boo is *not* virtually identical to Python*,
pointing it out to a self-proclaimed newbie with a question
about enums seems like nothing more than an ill-chosen
moment to do a little proselytizing. Why not just start
a thread about Boo and point it out to those of us who
have never heard of it? That wouldn't raise any hackles...

By the way, are you a moderator of this mailing list?
I'm asking you because I use to read your daily posts giving guidlines
on how to post, what to say or what not to say, and I wonder if this is
your role in this group. Is it?

 

[Steve Holden]

By the way, are you a moderator of this mailing list?
I'm asking you because I use to read your daily posts giving guidlines
on how to post, what to say or what not to say, and I wonder if this is
your role in this group. Is it?

Yes. And I'm the guy who answers questions about him

Seriously, the role Peter played in this thread is undertaken by many
members of the group. They are usually the ones who've been around
c.l.py for a long-ish time, and know "the rules" (which, since we don't
have a FAQ, are entirely unwritten).

By and large we like to run a civil list, and politely pointing out what
appear to be transgressions is the best way to keep things that way. You
probably realize that c.l.py isn't a moderated newsgroup.

regards
Steve

 

[Luis M. Gonzalez]

Steve,

I didn't want to be agressive at all. Although now that I read again my
post, it seems a little bit harsh...
But I see that very often in this list, some replies show much of
intolerance and very little politeness.
And in my oppinion, this is one of these cases.

I don't know what Doug Holton did to get such a lesson of posting
rules, since I think his comments were expressed in a propper way and
they were definetely python related.
This is not the first time it happens. A couple of times I suffered
myself this kind of attitudes and I chose to keep quiet for the sake of
peace, but I think it's time to point out some limits to those who act
as self-entitled moderators.
Being a moderator is ok, but not being a bouncer.

Regards,
Luis

 

[Steve Holden]

Steve,

I didn't want to be agressive at all. Although now that I read again my
post, it seems a little bit harsh...
But I see that very often in this list, some replies show much of
intolerance and very little politeness.
And in my oppinion, this is one of these cases.

I don't know what Doug Holton did to get such a lesson of posting
rules, since I think his comments were expressed in a propper way and
they were definetely python related.
This is not the first time it happens. A couple of times I suffered
myself this kind of attitudes and I chose to keep quiet for the sake of
peace, but I think it's time to point out some limits to those who act
as self-entitled moderators.
Being a moderator is ok, but not being a bouncer.

Well, you are certainly just as entitled to express your opinion as
Peter and I are, and I think we are pretty much managing to maintain a
civilized tone.

Intolerance and impoliteness are actively discouraged on
comp.lang.python, and I suspect one of the ways this happens is by
people ignoring what sometimes seems like flame bait.

Peter is fairly well-known on the group as someone whose Python chops
are undeniable, and he's been known to be very helpful with newcomers.
He's probably just feeling a bit cranky as the hockey season revs up ...

regards
Steve

 

[Stephen Waterbury]

Steve,

I didn't want to be agressive at all. Although now that I read again my
post, it seems a little bit harsh...
But I see that very often in this list, some replies show much of
intolerance and very little politeness.
And in my oppinion, this is one of these cases.

I don't know what Doug Holton did to get such a lesson of posting
rules, since I think his comments were expressed in a propper way and
they were definetely python related.
This is not the first time it happens. A couple of times I suffered
myself this kind of attitudes and I chose to keep quiet for the sake of
peace, but I think it's time to point out some limits to those who act
as self-entitled moderators.
Being a moderator is ok, but not being a bouncer.

Luis,

As a disinterested observer, I would like to go on record as
disagreeing with your entire assessment of this situation. I
found Peter Hansen's response to Doug Holton quite appropriate.

I also disagree with your perception that "very often on this
list, some replies show much of intolerance and very little
politeness." I think c.l.py is one of the more civil lists
going.

Steve Waterbury
(Yet another Steve)

 

[Luis M. Gonzalez]

Steve and Steve N°2,

I agree with Steve N°1 that we are all entitled to express our
oppinions, and this is the way it should be.
I don't want to give the impression that I have something personal
against anyone here, and I agree that this list is quite civilized, but
again, I'm basing my comments in previous posts, not only this one.

For example, if someone says something like:

And given that Boo is *not* virtually identical to Python*,
pointing it out to a self-proclaimed newbie with a question
about enums seems like nothing more than an ill-chosen
moment to do a little proselytizing.

I get the impression that if the topic raised is not of interest of
this person, it shouldn't be mentioned in this list at all.
What about the others? I found this comment very interesting. I don't
like when someone else comes up and invites the poster to shut up.
Let's see another comment:

Why not just start
a thread about Boo and point it out to those of us who
have never heard of it? That wouldn't raise any hackles...

By the way, Doug already started this topic, as suggested by Peter,
some time ago. And if you search this thread, you'll see how it
finished... he was invited to move the thread to another mailing list.

I remember also another occasion where I dared to say that Python is
slow, and all I got was an onrush of flames.
I wanted to discuss about pypy, starkiller, ironpython, and other
exciting ongoing projects... but it was imposible, everybody seemed to
be very offended and it was impossible to get the thread back on track.
This is what I call intolerance.
Usually, those people are always the same ones.

Anyway, I don't want to make a big deal of this. I just expressed my
oppinion.
If I offended someone, please accept my most sincere apologies.
Regards,
Luis