Python Is Moving From Mercurial To GitHub

[phoronix]

Phoronix: Python Is Moving From Mercurial To GitHub

For those that didn't hear, Python developers will be abandoning their Mercurial-based repository and development workflow in favor of using a Git repository via GitHub...

http://www.phoronix.com/scan.php?page=news_item&px=Python-Moves-To-GitHub

[bonob]

The linked post and mailing list announcement are about choosing GitHub rather than GitLab, not Git rather than Mercurial. Anyone would have a link to the results of that previous discussion?

[caligula]

Which one is faster, git or pypy compiled mercurial?

[bug77]

Which one is faster, git or pypy compiled mercurial?

Like all engineering things, I expect the answer is each will be faster than the other for selected tasks.
Fwiw, speed was the last thing I was thinking about when using git. It's entirely possible that it chokes on humongous projects, but for what I needed, git has always responded instantly (aside from synchronizing with upstream, but I guess that's more up to the network).

[TheBlackCat]

The linked post and mailing list announcement are about choosing GitHub rather than GitLab, not Git rather than Mercurial. Anyone would have a link to the results of that previous discussion?

Most of the rationale is in PEP-481. As for the discussion, just read the mailing list archives. This discussion is basically the entire point of the mailing list from what I can see.

[Akka]

Which one is faster, git or pypy compiled mercurial?

I suppose everything performance critical is already written in c.

According to github 34% of the codebase of git is written in shell script

[SystemCrasher]

Whoa, what a punch in the face for mercurial users...

[SystemCrasher]

I suppose everything performance critical is already written in c.

According to github 34% of the codebase of git is written in shell script

Sure, there is plenty of auto-completion for shell, etc, etc. Yet, most things are in C. And if you end up rewriting most of python crap in C in some twisted, halfassy way, "python powered" starts to sound like "VB.NET powered", lol.

Whatever, python sucks. Python 2 and 3 are not compatible. Actually, python 2 subversions aren't fully compatible either. To make it even better, there're some halfassy "faster" implementations which are supporting only subset of features. Great example of clusterfucked programming language, where you're doomed to rewrite code every year, or maybe two.

Then, rapid development usually happens to be detrimental for program quality. So at the end of day, most python stuff is bugged crap plagued by performance, stability and usability problems. Whatever, it took place of VB.NET in Linux.

[caligula]

Sure, there is plenty of auto-completion for shell, etc, etc. Yet, most things are in C. And if you end up rewriting most of python crap in C in some twisted, halfassy way, "python powered" starts to sound like "VB.NET powered", lol.

Whatever, python sucks. Python 2 and 3 are not compatible. Actually, python 2 subversions aren't fully compatible either. To make it even better, there're some halfassy "faster" implementations which are supporting only subset of features. Great example of clusterfucked programming language, where you're doomed to rewrite code every year, or maybe two.

Then, rapid development usually happens to be detrimental for program quality. So at the end of day, most python stuff is bugged crap plagued by performance, stability and usability problems. Whatever, it took place of VB.NET in Linux.

People are constantly porting C programs to pure Python to slow them down. For example https://github.com/jonathanslenders/pymux/

Their rationale:

"Tmux is written in C, which is obviously faster than Python. This is noticeable when applications generate a lot of output. Where tmux is able to give fast real-time output for, for instance find / or yes, pymux will process the output slightly slower, and in this case render the output only a few times per second to the terminal. Usually, this should not be an issue. If it is, Pypy should provide a significant speedup."

"It also proves that Python is a good tool to create terminal applications."

"The big advantage of using Python and prompt_toolkit is that the implementation of new features becomes very easy."

[caligula]

Whoa, what a punch in the face for mercurial users...

It's kind of logical that people switch to a single version control system. You can collaborate more easily and there's really no need to have such fragmentation. I think mercurial was quite nice, but it's slow and memory hungry. It might work for smaller projects, but I wouldn't do Linux kernel development with it.

Haskell developers also switched to git from darcs. Some reasons listed here https://ghc.haskell.org/trac/ghc/wiki/DarcsEvaluation. Haskell is better performing language than Python, but I think Darcs was among the first DVCS systems and the algorithms aren't as practical.

GNU arch and bzr also lost the battle. Ubuntu probably wanted to stick with bzr to force vendor lock-in, but now they're also losing the battle just like their attempts at X replacement (Mir), systemd replacement (upstart), etc. will fail.