On Sun, 12 May 2013 16:17:02 +0200, Citizen Kant wrote: > Thank you very much for your answers. > > I'm afraid that, at this stage, I must prevent myself from "knowing too > much" about the subject. My idea here is trying to fill the gaps, > mostly, using intuition.
Then you are doomed to failure. Intuition is greatly over-rated. Most of the time, it's just an excuse for prejudice, and a way to avoid understanding. > What I do here is to try to "understand". > That's different from just knowing. Knowledge growth must be consequence > of understanding's increasing. As the scope of my understanding > increases, the more I look for increasing my knowledge. Never vice > versa, because, knowing isn't like to be right, it's just knowing. Define your terms. What do you think "to know" means? What do you think "to understand" means? [...] > But take in account that with "shortening" I > refer to "according to Python's axiomatic parameters". You cannot hypothesis about Python's behaviour in terms of its "axiomatic parameters" unless they know what those axiomatic parameters are. So what do you think Python's "axiomatic parameters" are, and how did you come to that conclusion given that you know virtually nothing about Python? > What's "shorten" > if expressed in Python? For example: I'm plainly aware that the word > "python" looks shorten than "01110000 01111001 01110100 01101000 > 01101111 01101110". But it's shorten just for me and you and maybe for > every single human, not for the computer. You type "python", and the > language (so to speak) thinks "in my opinion you're not being economical > enough coz with this you mean 01110000 01111001 01110100 01101000 > 01101111 01101110", Sheer nonsense, and I don't mean the part where you anthropomorphise Python. (The "intentional stance" is often an excellent way of reasoning about complex systems.) Your premise that Python tries to be "economical" is incorrect. If anything, Python is the opposite: it is often profligate with resources (memory mostly) in order to save the human programmer time and effort. For example, Python dicts and lists may easily be four times as large as they could be (sometimes even bigger), *by design*. A list with 10 items may easily have space for 40 items. This is hardly economical, but it is a good trade-off in order to get better, and more predictable, performance. [...] > Maybe It'd be good if I explain myself a bit more. What I'm trying here > is to grasp Python from the game's abstraction point of view, as if it > were, for example, chess. A lousy analogy. Python is nothing like chess. You might as well try to understand Python as if it were a toothbrush. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
