[Python-Dev] PEP 374 (DVCS) now in reST

Nick Coghlan ncoghlan at gmail.com
Sat Jan 24 16:58:37 CET 2009


Aahz wrote:
> On Thu, Jan 22, 2009, Brett Cannon wrote:
>> I have now converted PEP 374
>> (http://www.python.org/dev/peps/pep-0374/) from Google Docs to reST
>> and checked it in. 
> 
> First of all, thanks for providing PEP number, URL, and short title;
> that makes it much easier to keep track of the discussion on list.
> 
> Second, I think it would be good to explicitly mention the option of
> deferring this PEP.  Based on previous discussion, it sounds like there
> are a fair number of people who think that there is a DVCS in Python's
> future, but not now (where "now" means over the next couple of years).

Put me in that category - the switch from CVS to SVN was simple and
obvious because SVN set out to be a better CVS and achieved that goal
admirably. The only major hurdle to adopting it was getting the history
across, and Martin was able to handle that in the end.

The benefits of atomic commits alone were well worth the migration cost.

With the level of development still going on in the DVCS area, I think
this is a time when dragging our feet on making a decision may actually
work to our advantage.

Although if Brett genuinely wants to narrow it down to a two-horse race
at PyCon, then I think the one thing to keep in mind is how well the
chosen tool embodies the Zen of Python (especially "Readability counts"
and "One obvious way to do it"). Core devs *are* core devs at least in
part because we largely like and agree with those design philosophies. I
personally find the command lines for 2 of the presented options quite
pleasant to read, while the examples of using the 3rd make me shudder
the way I do when I'm forced to read or write a Perl script.*

Performance problems can be fixed, but an antithetical design philosophy
is unlikely to make for a good tool fit.

Cheers,
Nick.

* In other words, the examples of using git in the PEP make me want to
run screaming in the opposite direction. However, assuming bzr's
performance issues and line feed handling limitations are addressed by
the time the switch actually happens, I'm currently fairly neutral on
the choice between bzr and hg.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------


More information about the Python-Dev mailing list