Please rename to eliminate confusion between this package and ev3dev-lang-python

[WasabiFan]

Currently, this repo is called ev3dev-lang-python-alt and the package is ev3dev. Because this isn't part of the ev3dev-lang project, I'd like to ask you to rename the repo to something that doesn't include ev3dev-lang and update the package name to correspond as well to eliminate any confusion. We had a discussion about namespaces/package names in ev3dev/ev3dev-lang#133 and will be normalizing ours to ev3dev-lang to make it clear that it is not directly part of ev3dev. As this module is not built into ev3dev nor is it part of ev3dev-lang, the name of this one should be something that clearly distinguishes it. This also includes renaming the ev3dev directory.

On a related note, the packaging for this repo currently references the official ev3dev-lang python binding here. This should also be updated to not conflate this project and others' modules.

I think that it would be great to focus our combined efforts on ev3dev-lang-python, and we'd love PRs, bug reports and suggestions; but if this repo is going to be discoverable and easily confused with the other project without clear distinction I think it is a detriment to the ev3dev community as a whole.

[EricPobot]

I understand your point.

The various naming has been chosen this way since it was a proposal for a different way of implementing the original thing, hence the choice I made to keep the original names for the package and other things.

to make it clear that it is not directly part of ev3dev

Not really true.

If you take a closer look at the sources, you'll see that a quite significant part of the original code is here and untouched. The only thing I've changed in depth is the autogen based code, replaced by a hand-made architecture of classes I found better. Even after giving the autogen method several chances to convince me, it failed to. IMHO it imposes too many limitations and constraints on the way the implementer would like to do his job, because it tend to limit the freedom to some common denominator of the features of targeted languages (e.g. multiple inheritance is not accessible, and in some cases it can provide a smart model). At the end of the day, it becomes more a hassle than a pleasure to use. If it was not the case, why do you think I would have been incited to do such a move ;-) ?

You could argue that it doesn't matter to the user of the binding layer. And you would be perfectly right. But for the moment, its seems that bindings are still work in progress and I was willing to contribute at this precise level. Hence my initial attempt to work with the installed approach... and my gut feeling after trying.

I think that it would be great to focus our combined efforts on ev3dev-lang-python

It was my one and only objective when proposing this alternate vision of the problem. Unfortunately for me, I didn't succeed in convincing the team. This is the life ;-)

and we'd love PRs, bug reports and suggestions

Anyway, I deduce from you request that is has been chosen to discard my proposal. I would have appreciated some discussion on the thread I've opened which publishing it, at least to show that people had given it a look and to comment on what they found. Deep silence instead :-/

But even if accept and respect the decision, you'll understand that chances are that I'll be more inclined to invest my spare time into pushing my own vision ahead than contributing to a track which I wanted to divert from :-)

Maybe I'll contribute in the future to some higher level layer on top of the Python binding, if its API converges towards something I'm pleased with.

To come back to your initial request, I'll just drop my repository for the moment. It will be simpler this way.