Everything good about Python except GUI IDE?

[Steven D'Aprano]

On Mon, 29 Feb 2016 01:26 am, Chris Warrick wrote:

>> git is a *collaborative* tool and should work when the other party is
>> using notepad.
> 
> What should git do if someone saves, say, Ruby code as a .py file?
> Should it rename it? Or should it figure out an equivalent snippet of
> Python?

Don't be ridiculous. That's completely over the top.

It isn't asking too much for version control systems to *not care* about
line ending changes. Who cares if the file changes from \n to \r \r\n? It
shouldn't matter, or at least, it shouldn't matter much.

> You probably have some rules in your project such as “Code must be
> written in Python” 

In one of my Python projects, I have (as well as various .py files) an R
script and a Gnumeric spreadsheet. In another Python project, I have a
couple of bash scripts. In nearly every one of my repos, I have plain text
files that don't contain Python code. Should the VCS refuse to track them
because they don't contain Python code? Of course not.

If I open a Python file in my editor, accidentally or deliberately change
the content to Ruby code, save and commit, then the VCS obviously should
track the changes because they are actual changes.

But if I open a Python file in my editor, accidentally or deliberately
change the line endings from \n to \r, save and commit, then it is a
weakness and limitation of the current generation of VCSs that they will
treat this as "every line has changed". Or worse, "10,000 lines have
collapsed to a single line containing \r characters".

Changing line endings is neither a structural nor a semantic change to the
content of the file. It's effectively metadata, not data. The Python
interpreter doesn't care which line ending you use. Neither will decent
text editors. If some tools, like git, do, then that's a weakness of git,
not a feature. Changing the permissions on a 10,000 line file doesn't give
you a 10,000 line diff, and neither should changing the line ending.

Your VCS absolutely should track line ending changes. In a perfect world, we
should never care about the line ending, but so long as there are users and
tools that cannot transparently deal with one line ending or another, there
may be times were we do care about line endings, and therefore want to
run "git blame" to find out which idiot changed the line ending of my file
to \r. But that should be treated as a metadata change, not a change to the
content. I know it isn't "really" metadata, it's "actually" content, but
regardless, it should be *treated* as metadata.

Who is the boss here? The user of the tool, or the tool?



-- 
Steven