python.el [was: Kickstarter for Emacs]

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

Re: python.el [was: Kickstarter for Emacs]

[Leo]

On 2012-04-20 09:27 +0800, Fabian Ezequiel Gallina wrote:
> 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).

I use Emacs's python.el exclusively because I need a simple python mode
for syntax highlighting and running the python interpreter with
completion.

I found python.el well written and well integrated with features of GNU
Emacs such as comint, compilation-mode, pdb etc. It has some rough edges
but mainly due to the underlying OS or python interpreter which a new
python mode may have as well. For example, the last time I tried the new
python.el on OSX, it failed miserably. On the face of the list of
features from the new python.el, it seems emacs's python.el already has
most of them.

So I am not terribly interested in a new python.el to replace current
one and bring in all unforeseeable incompatibility problems.

Leo

Re: python.el [was: Kickstarter for Emacs]

[Andreas Röhler]

Am 20.04.2012 03:27, schrieb Fabian Ezequiel Gallina:

[ ... ]

>
> 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.
>
>

Hi Fabian,

indeed your python.el is a very well written, inspiring example of a Python-mode - thanks BTW.

The question left is how to react to the emergence of full-fledged IDE's.

Might it be possible to combine Emacs elegance and flexibility
with state-of-the-art support functions suitable also for Python/Emacs beginners?

Cheers,

Andreas

--
http://launchpad.net/python-mode
http://launchpad.net/s-x-emacs-werkstatt/

Re: python.el [was: Kickstarter for Emacs]

[Neal Becker]

Just gave it a try.  Setup for ipython (using comments in python.el) on
linux/ipython-0.11.

In python shell, attempting tab completion, I get:
Blocking call to accept-process-output with quit inhibited!!