Re: Another round of questions

[Jean Abou Samra]

Hi,
Le 16/05/2020 à 20:02, David Kastrup a écrit :
> Valentin Villenave <address@hidden> writes:
>
> > On 5/16/20, Werner LEMBERG <address@hidden> wrote:
> > > IMHO only bugfixes should be applied to `musicxml2ly` since `xml2ly`
> > > covers much more of MusixXML (and will, AFAIK, also eventually support
> > > its successor, MNX).
> > Huh.  xml2ly has very different requirements than musicxml2ly and is
> > (AFAICS) unlikely to ever be integrated into LilyPond.  Anecdotally, I
> > have encountered several cases where musicxml2ly turned to provide
> > much more useful output than xml2ly (but that was a couple of years
> > ago, maybe its development has sped up since then).
> >
> > Plus, since we’re discussing python-based tools, there are a few
> > useful functions being developed in python-ly (as part of
> > Frescobaldi), which share a bit more DNA with musicxml2ly than with
> > anything else.  So I wouldn’t count musicxml2ly out just yet.
> Personally, I see nothing wrong with maintaining tools while they are
> used and distributed.  In a corporate setting, alloting large amounts of
> resources into a part of the tool set that has a perspective to be
> replaced in the course of a corporate development makes of course little
> sense.
>
> We aren't there.  We have no timetable for a replacement or its
> viability, and so I don't see the point in discouraging contributors
> from making fixes to what will continue for an indeterminate time to be
> part of the tool set useful for achieving objectives.

Thank you all for your replies. Based on that information, I decide to 
dive into the code, and we'll see what I can improve in it. My concern 
was about the possible replacement being planned and pending (I told 
myself it could have been delayed by the transition to GitLab), but if 
it is still to be discussed wether a replacement is tangible, then I 
will step into musicxml2ly with the rest. I'm unlikely to implement 
stunning features anyway. My goal is rather to adapt it to Python 3, and 
thus make it more maintainable by simplifying many parts of the code 
that can be rewritten elegantly using constructs and standard modules 
appeared in later versions of Python. Also, I consider it an investment 
for a future when I would be done with the very exacting part of my 
curriculum I'm currently in, and depending on many factors, I might 
start contributing more seriously (but that's not for right now, really).

Best,

Jean Abou Samra