rump...@web.de: > Eventually the "rope" data structure (that the compiler uses heavily) > will become a proper part of the library:
Ropes are a complex data structure, that it has some downsides too. Python tries to keep its implementation too simple, this avoids lot of troubles (and is one of the not much visible design ideas that have determined the success of Python). -------- I've seen that in Nimrod the following names are the same one: justaname JustAName just_a_name just__aname Justaname So like Pascal (and unlike Python/C) it doesn't tell apart names just on the base of their case (this is positive for newbie programmers, they usually use the convention of natural written language where 'Hello' and 'hello' are the same word, they need some time to learn the case-sensitivity). Nimrod also seems to ignore underscores inside names, seeing them as blanks. Some languages ignore underscores inside number literals, but I have never seen a language ignoring them into names too. In a class if you have a method like: change_table_color Isn't much good to also have a method named: changeTableColor Good programming practice tells you to avoid names that can be confused (as 'chop' and 'chomp' in the string functions of D Phobos lib). To avoid that most languages adopt a convention, so for example in Python the change_table_color is the only used name, Java uses changeTableColor, etc. Such conventions solve most of such problems. So I don't know how much I like this design detail of Nimrod. In Python you often see code like: node = Node() Sometimes in a case-sensitive language I'd like to have a compilation warning switch that tells me that in a namespace there are two or more names that differ only on character case or underscore count. This may help avoid some bugs. A language may even enforce this as a syntax error, so you have to write things like: n = Node() Or: anode = Node() Bye, bearophile -- http://mail.python.org/mailman/listinfo/python-list
