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

[Barry Warsaw]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Dec 28, 2007, at 9:30 AM, Matt Nordhoff wrote:

> 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).

In fact, my /personal/ opinion is that Bazaar is fast enough for  
nearly all daily uses.  I've not done benchmarking myself, but the  
numbers I've seen make Bazaar performance at least on par with  
Mercurial these days (some operations are faster, some are slower, but  
all seem in the ballpark and acceptable).  Specific subjective  
performance will depend on lots of factors of course, but I don't  
think the knock on Bazaar's performance is really true any more.

For the Bazaar project's take on a comparison between the major dvcs  
players, see:

http://bazaar-vcs.org/BzrWhy

> 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.

I would definitely agree.  Putting aside the dvcs wars for now, I  
think moving /to/ a dvcs for Python would be a huge win both for core  
developers and the rest of the community.  I won't speak for any other  
dvcs, but I do not think an experienced svn user would have any  
trouble switching to bzr after a day or so of use.

For core developers, I'd say the major benefits include cheap and  
functional branching (I agree with you here Matt! :), simple and fully  
functional disconnected use, great merging, and many options for  
sharing changing (e.g. bundling branch diffs in an email).

For non-core developers it's a huge win because a dvcs democratizes  
the development process.  You don't have to beg a core developer to  
get your patch in.  You can easily track the official mainlines and  
publish your own first class branches.  I kind of envision a scenario  
where non-core devs can promote their ideas in fully functional  
branches rather than a disconnected set of patches.

Giving that kind of power to everyone is worth a little bit of  
disruption I think.

>> 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.

I'm not so sure about that.  Although I'm a pure CLI-ster, my  
understanding is that bzr has GUI tools for gtk and other GUIs.

> 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

I know what you mean!  Moving to a dvcs can be a life altering event  
for a developer :).

> 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

 From the bzr perspective:

http://bazaar-vcs.org/BzrVsSvn

Cheers,
- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iQCVAwUBR3U08XEjvBPtnXfVAQIIrgP/Xi46nhqSG7KpjzMkgFqFlB3KcWyvzTo5
ciSCAF+rwbvApwbUQbWwAH/MjJAafq9KIzugKqXPVDieU0uzG6OAaVVtfu7C3IMT
pgtRvf4CBiQLX7uWfaKRKV+HMXrN9s06mcs11zZ6aE+mdyQdQrKtEL31tStqlIJ4
2ZG9cvk+lfg=
=aaYq
-----END PGP SIGNATURE-----