/brz/remove-bazaar

To get this branch, use:
bzr branch http://gegoxaren.bato24.eu/bzr/brz/remove-bazaar

« back to all changes in this revision

Viewing changes to doc/python.txt

  • Committer: Martin Pool
  • Date: 2005-06-28 03:02:31 UTC
  • Revision ID: mbp@sourcefrog.net-20050628030231-d311e4ebcd467ef4
Merge John's import-speedup branch:

                                                                                         
  777 John Arbash Meinel <john@arbash-meinel.com>       Sun 2005-06-26 22:20:32 -0500
      revision-id: john@arbash-meinel.com-20050627032031-e82a50db3863b18e
      bzr selftest was not using the correct bzr

  776 John Arbash Meinel <john@arbash-meinel.com>       Sun 2005-06-26 22:20:22 -0500
      revision-id: john@arbash-meinel.com-20050627032021-c9f21fde989ddaee
      Add was using an old mutter

  775 John Arbash Meinel <john@arbash-meinel.com>       Sun 2005-06-26 22:02:33 -0500
      revision-id: john@arbash-meinel.com-20050627030233-9165cfe98fc63298
      Cleaned up to be less different

  774 John Arbash Meinel <john@arbash-meinel.com>       Sun 2005-06-26 21:54:53 -0500
      revision-id: john@arbash-meinel.com-20050627025452-4260d0e744edef43
      Allow BZR_PLUGIN_PATH='' to negate plugin loading.

  773 John Arbash Meinel <john@arbash-meinel.com>       Sun 2005-06-26 21:49:34 -0500
      revision-id: john@arbash-meinel.com-20050627024933-b7158f67b7b9eae5
      Finished the previous cleanup (allowing load_plugins to be called twice)

  772 John Arbash Meinel <john@arbash-meinel.com>       Sun 2005-06-26 21:45:08 -0500
      revision-id: john@arbash-meinel.com-20050627024508-723b1df510d196fc
      Work on making the tests pass. versioning.py is calling run_cmd directly, but plugins have been loaded.

  771 John Arbash Meinel <john@arbash-meinel.com>       Sun 2005-06-26 21:32:29 -0500
      revision-id: john@arbash-meinel.com-20050627023228-79972744d7c53e15
      Got it down a little bit more by removing import of tree and inventory.

  770 John Arbash Meinel <john@arbash-meinel.com>       Sun 2005-06-26 21:26:05 -0500
      revision-id: john@arbash-meinel.com-20050627022604-350b9773ef622f95
      Reducing the number of import from bzrlib/__init__.py and bzrlib/branch.py

  769 John Arbash Meinel <john@arbash-meinel.com>       Sun 2005-06-26 20:32:25 -0500
      revision-id: john@arbash-meinel.com-20050627013225-32dd044f10d23948
      Updated revision.py and xml.py to include SubElement.

  768 John Arbash Meinel <john@arbash-meinel.com>       Sun 2005-06-26 20:03:56 -0500
      revision-id: john@arbash-meinel.com-20050627010356-ee66919e1c377faf
      Minor typo

  767 John Arbash Meinel <john@arbash-meinel.com>       Sun 2005-06-26 20:03:13 -0500
      revision-id: john@arbash-meinel.com-20050627010312-40d024007eb85051
      Caching the import

  766 John Arbash Meinel <john@arbash-meinel.com>       Sun 2005-06-26 19:51:47 -0500
      revision-id: john@arbash-meinel.com-20050627005147-5281c99e48ed1834
      Created wrapper functions for lazy import of ElementTree

  765 John Arbash Meinel <john@arbash-meinel.com>       Sun 2005-06-26 19:46:37 -0500
      revision-id: john@arbash-meinel.com-20050627004636-bf432902004a94c5
      Removed all of the test imports of cElementTree

  764 John Arbash Meinel <john@arbash-meinel.com>       Sun 2005-06-26 19:43:59 -0500
      revision-id: john@arbash-meinel.com-20050627004358-d137fbe9570dd71b
      Trying to make bzr startup faster.

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.