I've been tied up for a while and have not had time to participate in Wesnoth development for some time. Heck, I still have lots of changes pending in my local git repository. I have no idea if they still even make sense, especially given this line of thought. So please excuse my tardiness in response. The exchange is lengthy in both number of emails and length of comments so I've simply not had time to read the entire thread. If I'm offering comments which have already been addressed, please ignore them.
Before I offer my comments, please understand I am very pro-Python. I have minor Python related contributions to to Python's core libraries and PostgreSQL's Python, and Wesnoth's Python implementation. I have ported python to vxWorks and I really enjoying coding in Python. In fact, I have previously suggested moving various parts to Python on IRC. Now that we all know I'm a card carrying member of the Python community, please keep this in mind as I offer additional comments below. On Fri, 2009-01-02 at 12:34 -0500, Eric S. Raymond wrote: > 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. > This is a real double edged sword. I was a significant code contributor to OpenRPG. The project is entirely written in Python. Part of the attraction OpenRPG had to gamers was the fact it was accessible via Python. While this certainly cast a much wider developer net, it also brought in many, many poor quality contributions. In this case, poor quality means, lacking or inaccurate comments, poor structure, poor maintainability, poor flow control. It became a real kludge-fest. So yes, use of Python certainly does cast a wider net but the call of "code guardian" is also heightened. This role becomes all the more important because as others have already pointed out, subtle runtime bugs can become downright problematic. > > 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. > Python's introspection capabilities really makes debugging easy - so long as bugs are not obscured via exception handling. Even complex problems can be diagnosed. Because stack traces are now readily available, bugs can actually be fixed without the need to reproduce. Because of this, proper error handling strategies become very important. Of course this means certain classes of bugs can also be automatically reported allowing for pro-active bug elimination. > > 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. > To set the record straight, memory leaks are readily possible in Python. Let me say that again. You can leak memory in Python. Doubly so if language bindings are used. The GC only collects memory which is referenced counted. Circular references can be problematic. and are not collected by the GC. Use of weak references help for these of types of situations but IMO, that narrows the net of would-be developers and this requires understand of reference counted resources, circular references, etc. To specifically avoid memory leaks with language binds, I strongly urge you to look at the various binding options. Use of the low-level Python C-extension interface is very prone to these types of bugs. Options such as SWIG and Boost.Python, and the plethora of other options, not only tend to reduce tedious maintenance but also help reduce memory and crash related bugs common to use of the Python C-extension interface. > > 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. > Agreed. Contrary to the assertion to which ESR replied, code changes are rare. Users using new major versions of python may require code changes but that's a different issues. Minor Python releases specifically attempt to maintain code compatibility. Furthermore, Python natively supports parallel python installations so distros which natively support a different version of python can still install the supported version of python without issue or contention to their system. Lastly, I'll also through out there Python requires doing things the Python-way. Contrary to common assumption, knowing the python syntax does not mean your able to create performant python code. On the other hand, for 32-bit systems, Psyco is a Python JIT and is able to significantly increase the performance of various code structures at the expense of memory. Trade offs are configurable through the Psyco API. For some constructs, Psyco can create huge performance boosts. Typically I've seen 2-4x performance boost to applications. The exact boost is completely dependent on the nature of the code. -- Greg Copeland <[email protected]>
_______________________________________________ Wesnoth-dev mailing list [email protected] https://mail.gna.org/listinfo/wesnoth-dev
