Python for philosophers
Steven D'Aprano
steve+comp.lang.python at pearwood.info
Sun May 12 23:25:30 EDT 2013
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
More information about the Python-list
mailing list