|
6
by mbp at sourcefrog
import all docs from arch |
1 |
Choice of Python |
2 |
---------------- |
|
3 |
||
4 |
This will be written in Python, at least for the first cut, just for |
|
5 |
ease of development -- I think I am at least 2-3 times faster than in |
|
6 |
C or C++, and bugs may be less severe. I am open to the idea of |
|
7 |
switching to C at some time in the future, but because that is |
|
8 |
enormously expensive I want to avoid it until it's clearly necessary. |
|
9 |
Python is also a good platform to handle cross-platform portability. |
|
10 |
||
11 |
Possible reasons to go to C: |
|
12 |
||
13 |
Audience acceptance |
|
14 |
If Linus says "I'd use it if it were written in |
|
15 |
C" that would be persuasive. I think the good developers we want to |
|
16 |
do not consider implementation language as a dominant factor. A few |
|
17 |
related but separate questions are important to them: modest |
|
18 |
dependencies, easy installation, presence in distributions (or as |
|
19 |
packages), active support, etc. A few queries show that Python is |
|
20 |
seen as relatively safe and acceptable even by people who don't |
|
21 |
actually use it. |
|
22 |
||
23 |
Speed |
|
24 |
Having scalable designs is much more important. |
|
25 |
Secondly, we will do most of the heavy lifting in external |
|
26 |
C programs in the first cut, and perhaps move these into native |
|
27 |
libraries later. (Subversion people had trouble in relying on GNU |
|
28 |
diff on legacy platforms and they had to integrate the code eventually.) |
|
29 |
||
30 |
Bindings to other languages |
|
31 |
If we have only a Python interpretation then it can be run as a |
|
32 |
shell script from emacs or similar tools. It can also be natively |
|
33 |
called from Python scripts, which would allow GUI bindings to almost |
|
34 |
every toolkit, and it can possibly be called from Java and |
|
35 |
.NET/Mono. By the time this is |
|
36 |
mature, it's possible that Python code will be able to cross-call |
|
37 |
Perl and other languages through Parrot. |
|
38 |
There should be enough options there to support a good |
|
39 |
infrastructure there of additional tools. |
|
40 |
If it was necessary to provide a C API that can perhaps be wrapped around a |
|
41 |
Python library. |
|
42 |
||
43 |
Reuse of tla code |
|
44 |
That may be useful, if there are substantial sections that approach |
|
45 |
or meet our goals for both design and implementation (e.g. being |
|
46 |
good to use from a library.) |
|
47 |
||
48 |
This does not necessarily mean doing the whole thing in C; we could |
|
49 |
call out to tla or could wrap particular bits into libraries. |
|
50 |
||
51 |
||
52 |
---- |
|
53 |
||
54 |
Erik Bågfors: |
|
55 |
||
56 |
However, I think it's very important that a VCS can be wrapped in other |
|
57 |
languages so that it can be integrated in IDE's and have tools written |
|
58 |
for them. |
|
59 |
||
60 |
A library written in c would be simple to wrap in other languages and |
|
61 |
therefore could be used from for example monodevelop and friends. I |
|
62 |
really believe this is important for a VCS. |
|
63 |
||
64 |
I agree; this is a more important argument against Python than speed, |
|
65 |
where I think we can be entirely adequate just using smart design. |
|
66 |
But there are some partial answers: |
|
67 |
||
68 |
We can design bzr to be easily called as an external process -- not |
|
69 |
depending on interactive input, having systematically parsed output, |
|
70 |
--format=xml output, etc. This is the only mode CVS supports, and |
|
71 |
people have built many interesting tools on top of it, and it's still |
|
72 |
popular for svn and tla. For things like editor integration this is |
|
73 |
often the easiest way. |
|
74 |
||
75 |
Secondly, there is a good chance of calling into Python from other |
|
76 |
languages. There are projects like Jython, IronPython, Parrot and so |
|
77 |
on that may well fix this. |
|
78 |
||
79 |
Thirdly, we can present a Python library through a C interface; this |
|
80 |
might seem a bit wierd but I think it will work fine. Python is |
|
81 |
easily embeddable; this might be the best way for Windows IDE |
|
82 |
integration. |
|
83 |
||
84 |
Finally, if none of these work, then we can always recode in C, |
|
85 |
treating Python only as a prototype. |
|
86 |
||
87 |
I think working in Python I can develop it at least twice as fast as |
|
88 |
in C, particularly in this early phase where the design is still being |
|
89 |
worked out. Although all other things being equal it might be nice to |
|
90 |
be in pure C, but I don't think it's worth paying that price. |
|
91 |
||
92 |
One of the problems with darcs is that it's such a mess wrapping it. |
|
93 |
||
94 |
Yes. |
|
95 |
||
96 |
---- |
|
97 |
||
98 |
Experiments to date on large trees show that even with little |
|
99 |
optimization, bzr is mostly disk-bound, and the CPU time usage is only |
|
100 |
a few seconds. That supports the position that Python performance |
|
101 |
will be adequate. |