|| ||David White <dave-AT-whitevine.net>|
|| ||Ivan Illarionov <ivan.illarionov-AT-gmail.com>|
|| ||Re: 1.7 design direction and the great Python shift|
|| ||Sun, 04 Jan 2009 13:08:23 -0800|
|| ||dev-talk <wesnoth-dev-AT-gna.org>|
|| ||Article, Thread
On Sun, 2009-01-04 at 15:47 +0300, Ivan Illarionov wrote:
> On Sun, Jan 4, 2009 at 7:22 AM, David White <firstname.lastname@example.org> wrote:
> > I personally tend to be of the view that for a project like Wesnoth,
> > using dynamic typing extensively will be much more problematic. I am not
> > sure of any programs that are large (i.e. teams of 5+ coders, developed
> > over years) and have GUI's that are written in any dynamically typed
> > languages, but I would enjoy hearing of them if anyone has any examples.
> Few examples:
Actually, the Mozilla Firefox model is the kind of thing that I think we
*should* be looking at with Python.
As far as I understand it, the project was originally entirely C++, with
could be used for more and more functionality, and as they found how
useful this was, they extended it to more and more parts of the project.
I think think is exactly the kind of model we should use for Wesnoth.
Python is already used for the AI. That could be improved to actually
make it usable, and then Python could be used to solve real problems
with the game. For instance, people have complained about how the random
maps generated are not balanced. If we supported random map generation
using Python, perhaps we could easily make map generators that were
better balanced, or support symmetric random map generation better.
Likewise, everyone loves Wesnoth's add-on server, but it has a small
parade of outstanding feature requests. If the server and client portion
were both re-written in Python, perhaps these feature requests could be
I'm going to be really honest: you're presenting yourself in entirely
the wrong way to the project. I don't think very many people care much
to hear "this code here should be in Python because it is better for it
than C++!!!" What we'd much prefer to hear is, "I implemented this
really cool feature which our users will love, and oh yeah...the
implementation is in Python."
If features implemented in this way are successful and usable and
robust, other developers will take note. Code you write in one part of
the project that is useful will be reused in other parts.
Under promise and over deliver. I have heard of scores of people in
Wesnoth's history that have said they were going to do something, and
then nothing ever came of it. Make small changes. Build confidence and
momentum slowly. Gain developer trust.
Finally, I will make one thing clear, so that neither you or anyone else
wastes effort unnecessarily: Software development projects -- whether
Open Source or closed source -- do not accept large, multi-thousand line
patches from previously unknown contributors. It is simply not done,
regardless of the reason for the patch.
Doing so would be far too dangerous for the project. If I found another
project at my workplace and decided to send them a small useful patch,
it would probably be welcomed. If I sent them a 3000 line change, it
would be rejected out of hand, regardless of the functionality it
introduced. This is simply the way software development works.
In the same way, Wesnoth has never, and will never accept large,
multi-thousand line patches, regardless of the reason for the patch.
Developers who are interested in making large contributions to Wesnoth
should make small, useful changes, have them accepted by the development
community, gain the confidence of the development community, obtain SVN
access, and then continue to make small changes to begin with, evolving
Wesnoth in a direction that is embraced by other developers.
> Komodo IDE uses Python as a main language on top of Mozilla engine.
> Sketch/Skencil/SK3 is a family of open-source vector drawing programs
> written in Python almost entirly.
to post comments)