Ed Singleton wrote: > Is it obvious to a newbie what the difference between mappings and > "not-mappings", and is it obvious exactly what is and isn't a mapping? > > Should it be necessary to "know" python before it becomes easy to use?
QOTW! (You are joking, aren't you? :) I can undestand how people can turn a bit defensive when some people who are more skilled in programming than in diplomacy basically tells the confused that they are ignorant and should just learn the language. On the other hand, I think that Art Siegel said it very well: "My ability to grok Python to any extent, from that starting point, was based on an understanding that it was my responsibility to come to Python, not it to me." (Actually, that's a much better QOTW! It gives me flashbacks from a book I once read, http://www.amazon.com/gp/product/0060958324 ) There are just a few statements in Python. Some of them should really have been functions (print and exec) but anyway, they are still few enough to learn. There are also a few ways to get inside composite objects, x.y, x[y], x[y:z]. These things are among the most fundamental in Python. If luminaries like Fredrik Lundh and Raymond Hettiger tells you that things should be done in a certain way, it's really just silly to argue further. I've programmed Python since 1996, but if these guys tell me I'm wrong, I won't bother to argue. If I don't understand their position, I'll try to study the subject further, and I might ask them to clarify, but I'll assume that they are right. That assumption has worked so far for me. There are warts and quirks in Python, everybody will agree to that, but Python is *not* Perl. A basic motto has always been to avoid synonyms, to try to provide as few ways to do one thing, rather than to provide as many ways, as possible. This has proven very successful in making Python easy to learn and use. The opposite approach has made Perl into the favourite programimng language among people who think that "if the program was difficult to write, it should be difficult to read as well!" When you can't transfer one approach from one type to another, there is a reason for that. A few times it might be due to some obscure practical aspect of the implementation, but most of the time, it's completely intentional, and finding these aspects of Python, learning why they are the way they are, and embracing the language rather than trying to fight it, is actually very rewarding. Tuples aren't just immutable lists--they have different purposes beyond that. Ordereded and unordered collections are conceptually different. Neither call-by-referece nor call-by-value describes parameter passing in Python well, the clue lies in understanding how assignments and objects work, and you need to understand the difference between mutable and immutable objects etc. There are a number of fundamental concepts that you need to understand to really use Python well. Python works very smoothly, and you can do a lot of productive work with it even if you don't know these things, but in time you'll trip over them, and as you do, you need to grok these concepts to get further. Asking for some syntactic change or some convenience method so that you can get a little further without understanding the fundamental concept isn't the way to get beyond these little stumbling blocks. It's a bit as if you call the design department of your car manufacturer and tell them how they should redesign the suspension since it was so bumpy when you drove around with flat tires. Saying that it's too much to ask that you keep the tires filled with the right amount of air won't meet much sympathy. -- http://mail.python.org/mailman/listinfo/python-list
