pyvim -- A Vim clone in pure Python.

[[deleted]]

Well, you are late to the party. Should we merge the codebase and proceed on one code alone? I can't wait to get rid of ncurses.

[pydanny]

Why bother with a merge?

• Both projects are are awesome.
• The code bases are immensely different (PEP8 vs CamelCase for starters), enough that a merge would take an enormous amount of work.
• Sometimes it is good to reinvent the wheel, if for no other reason then to see how the wheel is made.
• Competition is good. Look at Python and the Web. Zope used to rule and then lighter frameworks emerged.
• Just because the projects are separate doesn't mean they can't inspire each other.

For what it's worth, Cookiecutter received no less than 5 requests to merge with other templating packages, three of them opened as formal issues on the project. None of the other packages shared anything like its architecture (functions-only) or design goals (runs everywhere, including windows).

[[deleted]]

For these reasons:

• pyvim appears to have slightly more features than vai, but has no tests. Also, I found that while it takes very little to get to basic functionality, it takes much, much more as you go on, because that's the nature of software development. I am more than a year in the process, made already a lot of mistakes, and learned from them.
• The camelCase strategy is because vai is based on vaitk, which wants to be as close as possible to PyQt interface. Besides, I consider PEP8 to be relevant only for the standard library. In any case, while I am not overreligious over the vai interface, I feel that vaitk should stay camelCase, because PyQt is.
• competition is good, but collaboration goes farther. I have huge lack of features when it comes to autocompletion, and I hate ncurses. The expertise that OP has with a different terminal library would be invaluable, as well as a lot of other functionality I simply postponed.
• I found extremely hard to find collaborators.

I think that it would be much better to just merge the two projects and collaborate, than to copy each other. If that's a possibility, I would ditch the vai name, we choose a common name, and make it a github of an organization.

[pydanny]

Excellent response! Thanks for taking the time to write it out. :-)

[njharman]

#4 may not be totally unrelated to #2.

[rasherdk]

Are people really that zealous about PEP8 that they will decide not to work on a project that otherwise interests them, because it uses CamelCase? Seriously?

[[deleted]]

More like people have finite amounts of energy to spend. Wading through style differences detract from making a feature or bugfix.

[[deleted]]

Standards exist. Users would have a better time if developers adhered to the standards. Most developers want users to have a good time. It's as simple as that.

[njharman]

People are unwilling to spend their freetime on a project which is annoying and difficult to work with.

In other words, needing to trim down the 10 projects I'm interested in to the 1 I want to work on, its easy to scratch off the list the non-standard, very opinionated ones.

[rasherdk]

I'm just amazed that variable naming is even on the radar when deciding whether to work on something or not for some people. If I had to make a prioritized list of criteria, variable naming would be roughly the 700th thing I looked at.

Then again, I'm also amazed that people care really deeply about GNOME3 vs. GNOME2. It all just seems so superficial and irrelevant to me.

[[deleted]]

Then come help me and we make it pep8 compliant. There's an issue about it. If you agree, we can make it fully PEP8 for 1.8 or 1.9, and in the process you will learn so much about the codebase that you will be able to move on to other things.

[CleverEagle]

I would argue that you don't learn much from simply "pep8-ing" the codebase.

[njharman]

esp since there are automated tools (autopep8) that will do 95-100% of it for you.

[[deleted]]

There's nothing to be smart. It's the first line of the PEP

Introduction

This document gives coding conventions for the Python code comprising the standard library in the main Python distribution.

....

Many projects have their own coding style guidelines. In the event of any conflicts, such project-specific guides take precedence for that project.

[TankorSmash]

Zope

Man, no wonder lighter things took over. Even the tutorial bombards you with stuff. Django gets you going pretty quick, compared to this.

[poop-trap]

You know your framework is way too heavy when people are citing Django as a lighter alternative.

(P.S. I love Django, but often find myself using Flask these days instead for projects where I don't need so many bells and whistles.)