From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Fabian Ezequiel Gallina Newsgroups: gmane.emacs.devel Subject: Re: A new major-mode for Python Date: Wed, 16 Feb 2011 03:46:47 -0300 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1297838865 29685 80.91.229.12 (16 Feb 2011 06:47:45 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 16 Feb 2011 06:47:45 +0000 (UTC) Cc: Emacs-Devel devel To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 16 07:47:41 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PpbAq-0002ZE-Ix for ged-emacs-devel@m.gmane.org; Wed, 16 Feb 2011 07:47:40 +0100 Original-Received: from localhost ([127.0.0.1]:60113 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PpbAA-0007bO-2H for ged-emacs-devel@m.gmane.org; Wed, 16 Feb 2011 01:46:58 -0500 Original-Received: from [140.186.70.92] (port=35170 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PpbA4-0007Zi-1J for emacs-devel@gnu.org; Wed, 16 Feb 2011 01:46:53 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PpbA0-0002No-Qq for emacs-devel@gnu.org; Wed, 16 Feb 2011 01:46:51 -0500 Original-Received: from mail-yi0-f41.google.com ([209.85.218.41]:64613) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PpbA0-0002Ne-KF for emacs-devel@gnu.org; Wed, 16 Feb 2011 01:46:48 -0500 Original-Received: by yia25 with SMTP id 25so508958yia.0 for ; Tue, 15 Feb 2011 22:46:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=bkEhiDPn6zCCW6PP72AlkXCTdyxYRF7PIx2bukPg1GU=; b=Un1wqFMMhaUUcbneexxCyBJpZAb8aBFThUhQ7YU2UeLYNoqqFPyatT5DTNdenLvR+N iUj7Tc956B89GTbTCl55F9p20Rqy1IbtZEuRQr3MKh/rsXz3pLxpEtvf7lkjSqtN5Y6R 1mlB06Cm0YVJQM+zI8K2JMBAbslb8IYae03A4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=H848WsAYbRg6LI/G/OEJUQStBuqj77NmU4TcaPmi+ACXv3b3LxD4YazFSjh8XPb0UC Cm7FxwSS392mE7yEv7NmC7Ah0qdt3PzIH8EAT7xS/IkT4NjHFjaohdV6zK4sVcYWclLc HKjBNNE7V37OMnWmumL2GGdT1eEP4L/1oRQ7g= Original-Received: by 10.90.90.18 with SMTP id n18mr284688agb.101.1297838807617; Tue, 15 Feb 2011 22:46:47 -0800 (PST) Original-Received: by 10.90.75.6 with HTTP; Tue, 15 Feb 2011 22:46:47 -0800 (PST) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.218.41 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:136093 Archived-At: 2011/2/15 Stefan Monnier : >> I have come up with a *new* major-mode[1] for Python > > Help!!! > > More seriously. =A0Rather 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. =A0This 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, --=20 Fabi=E1n E. Gallina http://www.from-the-cloud.com