python.el [was: Kickstarter for Emacs]

[Fabian Ezequiel Gallina]

Hi all,

So it seems there is a ever repeating cycle with 'all python modes are
buggy', 'why they don't just merge?', 'What does this mode have better
than this one?', 'I want to use them all at the same time!', etc as
the main subjects.

Let me explicitly state: None of them are the subject of my work on
python.el, except for the first point (and that's a personal point of
view).

I've been a user of all of them and decided to create another one
after trying to understand them, patching them and finally getting
angry and frustrated (and again this *may* be related to my own
stupidity rather than a failure of the modes).

With python.el I did something for myself[0] (at first) because I
needed a python mode that works out of the box and provides minimal
but robust stuff. I don't need it to be an Eclipse contender, nor a
full fledged IDE, nor having it integrated with ropemacs and pymacs
out of the box and do fancy introspection and re-factoring. I needed
simple, robust stuff (indentation, shell and navigation) for a simple,
robust language (for my every day work).

When I saw the amount of issues related to the python modes merging
and stuff I decided it would be a good way to release what I had at
the time. I always admired Emacs as a piece of software and I though
my contribution would benefit it (and from my standpoint it did, at
least for a fair amount of users). Unfortunately after that, I found
out the amount of discussion, "fanatism" and discrepancies put
in each mode (that includes copyright details too). Please, notice
that I'm not a new contender on this old discussion, I went my own way
to satisfy my work needs (and latter it turned out many people
preferred the work I did over the existing stuff).

My python.el is different on purpose, it contains NO XEmacs
compatibility code, the names are the way they are on purpose and the
whole mode tries to follow a style and be consistent so it's easy to
follow the code. It even defined new ways to interact with the shell
(with no external file dependencies, per buffer shells, with py2k and
3k support and even iPython with a couple of setqs), do pdbtracking
(just with a simple comint output filter) and have Virtualenv support
with just setting a variable (many of this stuff now reflected on
python-mode.el, which I consider the merge of all python mode stuff
that ever happened).

My objective with python.el is to keep it clean, keep it
reliable, make it follow the Emacs standards and keep it the way
it is. I know the other modes and I don't want it to follow them
or get closer (for better or worst, this mode is what it is, and
if it's good that's everyone personal call), I want it to provide
the fundamental stuff you would use on a bare Emacs installation
and make it work out of the box with no external dependencies or
difficulties. I like to think of it as a framework for the user for his
python editing needs rather than a IDE itself.

As a final note I'll always agree on adding fundamental missing
functionality (as I did with skeletons, python-check and ffap after
releasing it) and of course adding defcustoms for fixed behavior that
doesn't follow someone's preference (and I have this as a #1 priority
when I get my hands on the merging this weekend).

If any package maintainer (of trunk or external) needs help
porting current trunk's python.el code to mine know that I'm
eager to help in any place where my insight may be needed. I
prefer to do that rather than polluting the code with obsolete
aliases everywhere, and I really think that for the most cases
the changes should be pretty straightforward.



[0] http://lists.gnu.org/archive/html/emacs-devel/2011-02/msg00655.html


PS: I really hope we can move forward on the python-mode discussions
once for good.

Regards,
Fabián E. Gallina