Re: A new major-mode for Python

[Fabian Ezequiel Gallina <galli.87@gmail.com>]

2011/2/15 Stefan Monnier <monnier@iro.umontreal.ca>:
>> I have come up with a *new* major-mode[1] for Python
>
> Help!!!
>
> More seriously.  Rather than a new python mode I'm interested in
> a maintainer for our python mode (i.e. someone who will fix bugs in it,
> add new features, and will accept to work with us when we want to make
> changes that he does not like, typically to make it behave in a more
> standard way).
>

At first, I started to hack on python.el, I even integrated it
with ipython. But then I realized lot of things were implemented
in a really complicated manner for a newbie like me and I was
struggling to make it work as I wished.

For instance I never liked the shell integration, and when I tried to
simplify it into something more like python-mode.el, but with the
possibility to launch dedicated shells for files, I found myself
fighting with the code instead of feeling comfortable to build upon
it.

I also felt lot of stuff were not necessary. Mainly the need of an
external python file to interact with the shell (coupling the shell
integration to an specific python version), all jython specific code
and the Bicycle Repairman integration.

It was at that time I started thinking in writing a python mode from
scratch in order to have a *clean* working version of the things I
expected from it. The result is this thing I uploaded to github :)

> So rather than replace our python.el with yours, I offer you to take
> over maintainership of our python.el.  This may sound like a crappy
> offer (why would you maintain some old code you don't like when you
> already have your own that works better, right?), but note that, as
> a maintainer of our python.el, you'll have the opportunity to replace
> pretty much any of "our" code with yours, thus morphing our python.el
> into yours.
>
> Another way to look at it, is that I'm asking you to take a "diff
> old-python.el new-python.el" and cut it into manageable and meaningful
> patches, so it is easier to see that it is moving forward.
>
> Or maybe, what I'm asking really is to merge our python.el with yours.
>

The possibility of being the maintainer is never a crappy offer, but
I'm really scared about the effort we would put into doing the kind of
merge you propose, I can't really see that approach as
productive. (The mode I wrote shares *very little* code with trunk's
python.el)

However since this mode implements the most important features from
python.el I think we can provide some define-obsolete-function-alias,
define-obsolete-variable-alias in order to keep it the most compatible
as possible.

I'm willing to add/re-implement ffap, python-check, skeletons. But I
can't think of a good reason to add Bicycle Repairman again.

When that stuff is done the new python.el would contain all the
features of the previous one while adding an important one:
compatibility with python 3 (even when using the default shell setup)

So in shorter terms what I'm willing to do is:

   1) Re-implement ffap, python-check, add some skeletons

   2) Set several define-obsolete-{variable,function}-alias(es) in
      order to add a some nice compatibility to trunk's python.el

   3) Maintain this stuff :)


What do you think? It still sounds like a bad idea?


Thanks,
-- 
Fabián E. Gallina
http://www.from-the-cloud.com