On Fri, Jan 02, 2009 at 12:34:16PM -0500, Eric S. Raymond wrote: > Mark de Wever <[email protected]>: > > I think such a big move should be agreed by all current core devs and > > should be considered carefully. Why do you think Wesnoth will attract > > more developers if it's a Python project? > > Because Python is a significantly easier language to write in, there > are more people able and willing to code in Python than in C/C++. The > intersection of that set with the set of people interested in Wesnoth > can be expected to be larger.
Can be expected yes, but I'm sure there are several players who are also C++ coders and do not contribute. We hoped by allowing AIs to be written in Python we would attract more people who wanted to help writing AIs and that was no big success. > > I have worked with Python and to be honest I'm not really thrilled. My > > biggest problem with Python is the type safety. I had some code that > > 'compiled' without problem but at runtime it had a hard crash due to > > invalid types. This kind of problem doesn't happen in C++ since it won't > > compile. > > Instead we have core dumps, which are much more difficult to diagnose > because you can't use C++ itself to do introspection on them. At > equivalent skill levels, the advantage is all with Python here - that > is, you have to know a great deal about using gdb to read the. > entrails of a core dump before you can accomplish things a person > debugging Python can do with barely a thought. > > I have 26 years of experience as a C programmer. Before that I wrote > a lot of LISP, which had the same absence of type safety as Python and > similar capability for introspection. There are sometimes good > reasons to code in C but due to my prior LISP experience I have never > considered "type safety" to be among them -- it's a bad substitute for > being explicit about your invariants and data semantics, what Eiffel > fans call "programming by contract". > > C/C++ programmers tend to reason poorly about this because in their culture > there is major confusion between two different roles for static typing > (1) as a way of doing resource allocation in a universe of fixed-extent > objects, (2) as a sort of backhanded implicit way of declaring invariants. > In LISP, or Python, you don't need to do (1) at all, and you handle (2) > by writing contract tests that throw exceptions. This was a better way > in LISP thirty years ago, and it's a better way in Python today. My problem is that in Python I had a few times I made a stupid error in a codepath which normally not executed. So when that code was executed the program died. The C++ compiler would have caught this silly errors. I'm well aware that in C++ you can also make errors which terminate the program ;-) > > I don't believe somebody can learn a new language and be fluent in it in > > four days. For a project as large as Wesnoth, one should be quite > > familiar with the language to code efficiently, which will take much > > longer as four days. > > Actually, I lied. It was more like two days :-). Read my detailed account > here: http://www.linuxjournal.com/article/3882 Sorry but I can't believe you were as efficient in Python as in C after just 2 or 4 days of coding. > > The Python bindings we currently use are ref counted, so if somebody > > fails there the garbage collection will fail and you still have a memory > > leak. > > Yes, detectable with valgrind. Still a big improvement on core dumps -- > and an argument for moving more code fully into Python rather than less. Memory leaks in C++ can also be detected by valgrind. Your argument was that with Python there would be no memory leaks. > > > I think we should review and decide whether we want to move to Python > > before discussing when to merge. > > That's the discussion we're having now, isn't it? I just like to discuss first whether we want it and whether to code looks good before planning how to integrate it. > > > Some other concerns I have: > > Is Python available on all platforms we support. > > Answer: Yes. We know this from experience with the Python AIs. We don't know, since the Python AI can be disabled. > > Version dependency; Python has a new version every x months which often > > needs to change existing code. I know Python has tools to do that, but > > how can we support different versions of Python with one 'binary' > > without an ifdef hell. IMO we need to support several functions since > > most Linux distros ship different versions of Python. > > The way you can know this is *extremely* unlikely to be a problem is > that we've never has a bug report in either our Python AIs or our WML > support tools that was traceable to a Python version change. We had some problem with certain people still using Python 2.3 with some Python AI changes IIRC Blind Oracle wanted to make. > 3.x really is a disruptive change, but 2.x will be maintained and > supported for the foreseeable future on our target platforms. I'm more concerned with us having to maintain two versions of some code due to incompatibilities. -- Regards, Mark de Wever aka Mordante/SkeletonCrew _______________________________________________ Wesnoth-dev mailing list [email protected] https://mail.gna.org/listinfo/wesnoth-dev
