Mark de Wever <[email protected]>: > On Fri, Jan 02, 2009 at 10:19:26AM -0500, Eric S. Raymond wrote: > > Sirp agreed in principle on IRC with moving the Wesnoth codebase > > towards Python many months ago, basically in order to attract a larger > > population of developers - because, even though Sirp doesn't > > particularly *like* Python, he knows it's more accessible than C++. > > 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. > 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. > 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 > 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. > 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? > Some other concerns I have: > Is Python available on all platforms we support. Answer: Yes. We know this from experience with the Python AIs. > 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. In general, unless you're talking the difference between 2.x and 3.x, the differences are not enough to matter to us. The last time a Python 2.x version change had the sort of ripple effect you're worrying about was years ago, pre-Wesnoth, when true lexical scoping was introduced. 3.x really is a disruptive change, but 2.x will be maintained and supported for the foreseeable future on our target platforms. -- <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a> _______________________________________________ Wesnoth-dev mailing list [email protected] https://mail.gna.org/listinfo/wesnoth-dev
