As he said, it’s to follow Python convention.
@jamestwebber Per PEP 278, files do not implement the “universal new line” convention; the interpreter does. Whatever line ending the file is given from the OS or editor, the interpreter converts. This is outside the purview of this PEP and is unnecessary.
Now one can force a newline by adding the escape \n to the file, since \n in a string literal is converted appropriately to the OS-specific line ending by the interpreter by default unless explicitly turned off.
Everyone is more than welcome to disagree with me, naturally; that is the wonderful aspect of our community discussions.
My claim is this:
Had \n not been in the PEP, there would be no difference. It is superfluous and does not need to be there. It serves no purpose and and cannot be enforced at the file level in the first place. I’m fact, the only conceivable way it could would be to do exactly what I did: add a string literal \n to the file, which is interpreted in an OS-agnostic way by the Python interpreter as a newline, but ironically this fails with mypy.
I pray I’m misreading the tone of the responses from others, but I feel I am being considered “stupid” for “misunderstanding something so blatantly obvious,” which naturally is upsetting, and “only Linux users are worthy.” To reiterate, I’m not saying this is what is literally being said. This is simply my interpretation of the comments, which makes me feel unwelcome. If my responses have seemed “snippy”, then I apologize. It is due to my inability to read tone from text.
I thank all of you for the provided clarifications. I now know how to make this work, which is great, and quite frankly that’s all I need for myself. However, I was hoping to help others by recommending we remove \n from the PEP. As far as effort goes, I can’t think of anything more minimal, but more to the point I fail to see it serving any purpose by being there at all in the first place. Maybe there is a file editor out there that does not add new lines to the end of files, but why should that stop a type checker from reading the file at at all? This is why I’ve been harping on the purpose of it.
At any rate, I am beaten by overwhelming consensus, to which I concede. Thank you for the discussion. I have no doubt the majority of you are utterly annoyed by me at this point (to put it lightly), so I will end this battle.
Again, thank you all for your clarifications and your help. Despite my own personal frustrations, this conversation was very useful to me.
4 Likes
I agree with you that this is not obvious and warranted the discussion.
I agree with GvR’s assessment that the intention probably was for the file contents to match the Python pattern (?m)\Apartial\n\Z.
However I think I agree with you that the strict requirement of \n at the end seems unnecessary (not to mention thorny in the case of Windows line endings), and it seems like the Mypy developers agree as well.
Perhaps the PEP could be amended to state that the file contents should match the Python regex (?m)\Apartial(?:\r\n|\n)?\Z. Or even more liberally, (?m)\A\s*partial\s*\Z.
The “be liberal in what you accept” principle in my opinion doesn’t mean that you should expect implementations to accept off-spec inputs. Rather, you should try to make the spec itself liberal, to whatever extent makes sense. Otherwise you really have two specs: the official strict de jure spec that nobody uses, and the unofficial undocumented liberal de facto spec that people actually use.
2 Likes
FWIW (I only skimmed this thread but…) your responses did not seem “snippy” to me; the responses of others sometimes did – just a little --, but I wouldn’t attach too much value to that. When my brother in law was visiting from Redneck Land, we drove past MIT, and he commented: “MIT - biggest concentration of nerds in the world.” He was wrong. The largest concentration is found in forums like this 
1 Like