← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/python.txt

  • Committer: Tarmac
  • Author(s): Vincent Ladeuil
  • Date: 2017-01-30 14:42:05 UTC
  • mfrom: (6620.1.1 trunk)
  • Revision ID: tarmac-20170130144205-r8fh2xpmiuxyozpv
Merge  2.7 into trunk including fix for bug #1657238 [r=vila]

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/python.txt
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 weird 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.