Though, you still should provide a way to read from file/write into file. I prefer passing "-" or /dev/stdin (/dev/stdout) for that purpose.
Just for the sake of debuggability, if someone would like to debug your script with a debugger/debug prints/debug reads
Why not both? Many of my favorite utilities are stdin/out by default, have file parameters, and will accept '-' to go back to stdin/out.
This is highly useful if you want to allow composition into scripts without forcing users to dynamically build parameters. Meaning, they can use, e.g. `FILE_NAME=${FILE_NAME:-"-"}; some-util --output $FILE_NAME;` and not have to decide whether or not to use the --output parameter in their script.
Shouldn't the title of the article be "500 lines or less - ceval.c written in Python" or "500 lines or less - a python bytecode interpreter written in python"
The original one is just misleading.
It is an interpreter and that's absolutely correct. They could've even said "A vm in Python" because that is a VM, just without JIT etc. The compiler includes a parser usually, but interpreters in the purest sense of the word interpret the semantics of some structure corresponding to the code.
It's not an interpreter of the programming language Python, however. It's a VM for Python bytecode, which is not what most people understand as Python, right?
Hash table realization seems to be harmful with the "no collisions" assumption. That's like writing a red black tree and assuming that insert/delete operations will keep tree balanced so we don't need rotations.
How is it harmful? You really think that somebody who is going to write a red black tree implementation (or similar) is going to use this document as a reference? That'd be like complaining about a high school physics textbook because somebody from Boeing might use it to design a plane.
Some simplifications may actually be harmful to understanding if they throw away key points or introduce logical contradictions.
For a hash table, the general "promise" is that you map a very large space of keys (e.g. all strings) to a very small space of indexes using a simple function. Common sense might tell you that this shouldn't be possible ("how can you put something big into something small?") - and of course actual hash tables solve the conundrum by acknowledging collisions and defining ways to deal with them.
But by saying "let's assume no collisions" the reader is asked to just ignore the logical contradiction instead of solving it. That can lead to frustration in the best case or to serious misconceptions in the worst case.
Of course there is nothing wrong with saying "let's ignore those points for now, I'll explain later". Also I guess it depends very much on the learning style of the reader. But bad simplification can be very annoying for some learners.
>For a hash table, the general "promise" is that you map a very large space of keys (e.g. all strings) to a very small space of indexes using a simple function
Well, AFAICT there is no mention of any of this in the document. No "promise" or any such thing has been said or implied. Please stick to what the author has actually said rather than what you imagine people are thinking about when reading the document.
>. Common sense might tell you that this shouldn't be possible ("how can you put something big into something small?")
No, it doesn't tell me that at all, because that point is not brought up in the document. But is that how you think most people learn? Using common sense?
>But by saying "let's assume no collisions" the reader is asked to just ignore the logical contradiction instead of solving it.
Sure, you think those are the logical contradictions in the readers' minds. Can you actually establish that?
> But bad simplification can be very annoying for some learners.
A list of what is annoying for "some" learners is quite possibly very very large. Lets not....
--
Anyway, we can go down this rabbit hole, but it isn't actually productive, and quite boring to be honest. My point is that every-time someone tries simplify something for beginners, people seem to relish that opportunity to show everyone how "smart" they are about trivial data-structures. Yes, if you want somebody to make an expository article for beginners with the detail of something like TAOCP, then yeah, you're going to be disappointed. But, you can and should learn Newtonian physics, even if its "wrong", before you move on to Einstein.
>Well, AFAICT there is no mention of any of this in the document. No "promise" or any such thing has been said or implied.
I'm not sure you got the parent's comment. What you wrote about is true -- and that's what's wrong with the document. That it doesn't mention such a promise, not it describe an actual hash table implementation (where collisions are inevitable and should be dealt with).
>Please stick to what the author has actually said rather than what you imagine people are thinking about when reading the document.
Again, the problem is that people sticking with "what the author has actually said" will not learn how hash tables actually work.
>No, it doesn't tell me that at all, because that point is not brought up in the document. But is that how you think most people learn? Using common sense?
Now you're just being contradictory to be contradictory. Or trolling.
Yes, people use common sense to learn -- and to understand what they are learning. How is this not obvious?
>Sure, you think those are the logical contradictions in the readers' minds. Can you actually establish that?
I'm a reader, and immediately jumped to see the same logical contradiction.
Not even sure what you're trying to defend exactly. Sloppy examples?
>Again, the problem is that people sticking with "what the author has actually said" will not learn how hash tables actually work.
Huh? People are complaining about the implementation not having collision detection. The author clearly lays out what collisions are, why they are required and also that they need to be dealt with. Did you read the article?
>Yes, people use common sense to learn -- and to understand what they are learning. How is this not obvious?
It would help if you didn't change the context and scope of what I have said. I am not talking about some random topic that you can derive through first principles or common sense or other logical means. To me its obvious you didn't understand what I meant or what I was replying to. Its pointless to argue further and derail the thread.
>Not even sure what you're trying to defend exactly. Sloppy examples?
Not to sound gratuitously rude, but if you don't know what my point is, why not ask me first?
How hard is it to introduce the idea of slots or pidgeonholes that the elements are stuck in, and if there is more than one item there, it is added to a list/collection?
>He's just saying that the hash table is pretty useless if two random keys could access the same memory.
That is already mentioned in the document itself. Also mentioned is that a proper implementation would have to deal with collisions.
As to it being useless.. the value of content is in its explanation of simple concepts, not in some imagined production-quality requirement that people want to assume it must have.
>As to it being useless.. the value of content is in its explanation of simple concepts, not in some imagined production-quality requirement that people want to assume it must have.
The value of an explanation of simple concepts is in their simple AND adequate explanation.
You can cut the implementation details, but can't cut essential properties to simplify, because then you're not explaining the original concept at all.
