[Python-3000] How to override io.BytesIO and io.StringIO with their optimized C version?

[Matt Nordhoff]

Christian Heimes wrote:
> Martin v. Löwis wrote:
>> I would like to ask the same for any conversion *from* subversion,
>> be it to hg, bzr, git, bk, or ClearCase.
>>
>> So anybody who wants to seriously attempt introducing such a change,
>> please present your PEP. Anybody else, please stand back and watch.
> 
> I also like to some good answers for a bunch of questions.
> 
> What are the benefits and strengths of bzr/git/hg better over svn? What
> problems do the distributed version control systems solve that svn
> doesn't solve.

Intelligent (I'd say "functional", but most people seem to be more
forgiving than me) branching and merging. On merging, they all can merge
two branches together while preserving history. You don't lose history,
and you don't have to keep track of revision numbers for repeated
merges. All you have to do is "$vcs merge" and the VCS will work out
which revisions need to be merged.

On branching, every checkout is really its own branch. (That might sound
complicated, but it's not. If you just want to keep a copy of another
branch, all you have to do is e.g. "hg pull -u" instead of "svn up".)

This means that you don't have to have commit access to the central
server to make your own branch and commit to it. After working
privately, you can publish your branch (also much easier to do than in
svn), or generate a patch-like file, and other people or the central
developers can easily merge your changes, preserving history.

That also means that developers can create tons of small branches
without making a mess of the central server (just their own ;-) ).

Those three also have three different rename handling designs, all more
advanced than svn's basic copy+delete.

(Checkouts being branches, (usually) with the full history downloaded,
also means you can diff or annotate or commit or whatever you want while
offline, useful on a train or whatever.)

> Why should we choose bzr/git/hg over bzr/git/hg?

Mostly (going on their general reputations):

Git is a speed demon, but has a horrible, complicated UI (which has
recently been improving). It's also only recently started to get decent
Windows support.

Bzr has a nice UI and is cross-platform (and has great dumb server
(HTTP, SFTP, FTP) support), but is slow (not a problem on non-huge
projects, and it's getting better).

Hg is cross-platform, almost as fast as git, and with nice UI.

Git is written in C (with some shell scripts and stuff that are being
rewritten in C). Bzr and hg are both written in Python with some C bits
for performance.

(I prefer bzr's UI to hg's. Hg uses more technical and lower-level terms
than really necessary, and bzr doesn't. Not a major problem, though. Hg
might even promote a better understanding of the tool, which would be nice.

Hg also has a simpler UI and tends to have minimal (or no) output, e.g.
you have to supply -v to commit just to get the list of files modified;
by default it outputs nothing.)

> Do the new feature justify the extra burden on the core developers to
> learn a new VCS and new tools?

Once everybody switches to bzr/git/hg, that won't be a problem anymore! :-D

Well, the core developers don't experience one of the main disadvantages
of svn: that non-core developers don't have the ability to make their
own branches or commit. But I would still say that the more branchy and
history-preserving workflow is absolutely worth it.

(Of course, with less technical teams, having to learn even one more
term is practically a deal-breaker. But that shouldn't be a problem
among an FOSS programming language's developers...)

> Does a new VCS come with all the nifty and handy small tools, OS
> integration and IDE integration I like? I definitely don't want to loose
> the explorer integration of tortoisesvn on Windows or meld on Unix. The
> new VCS may have reached version 1.0 but do they come with the rich tool
> set? Although I'm a CLI fetishist I still like a decent GUI for some tasks.

For bzr and hg (and I presume git), not yet. The GUI and tool situation
is getting better all the time, but it still isn't as good as
Subversion. A lot of tools are available now, but they aren't that mature.

> Christian

As a disclaimer, I should say that I'm not a big-time programmer, but I
am a nerd who is very interested in VCSes and does use them. I've also
never used git, but I use both bzr and hg a lot, chat with their
developers on IRC and have even written a few tiny patches.

Err, when did this become a big discussion on VCSes? I didn't really
mean to do that, but I can't resist pushing DVCSes whenever I get the
opportunity. :-P


Ok, I'm really tired of working on this message now. And when I make
changes, I'm just hacking them in without reworking the surrounding text
much. So I'll hit Send now.

I haven't seen a basic, practical, "vs.-svn" sort of introductory
article on DVCSes. I wish there was one, because I'm sure it would sound
better than anything I could come up with. :-P
--