merging python-mode.el and python.el

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

merging python-mode.el and python.el

Dave Love-2
There is talk in the python-mode.el and on the web site of merging it
with python.el.  I hope people realize that can only be done in
accordance with the GPL licence of python.el -- i.e. one way -- although
it doesn't seem useful anyhow.  There's already been an attempt to put
python.el code into python-mode.el contrary to the licence via a bug
report, and I'm concerned that it doesn't happen any more (unless
python-mode.el's licence is changed, obviously).

It's not clear to me what's in python-mode.el that would be useful to
put in python.el, although I've only skimmed the current version.
Anyway the main raison d'être for python.el was that we couldn't get
copyright papers for python-mode.el for inclusion in Emacs (and I won't
put unassigned code in my version).  Also, python-mode.el changes for
Emacs weren't accepted, so I wrote an intentionally incompatible mode to
minimize confusion and ease maintenance.
_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

Re: merging python-mode.el and python.el

Skip Montanaro-3

    Dave> Anyway the main raison d'être for python.el was that we couldn't
    Dave> get copyright papers for python-mode.el for inclusion in Emacs

Funny that.  The FSF paperwork mavens have failed several times (at least
three that I'm aware of) to get paperwork to me for my signature.  The one
time they got the paperwork to me I signed and returned immediately.  They
still didn't get it.  Based on my own personal experience I don't think you
can lay all the blame on the folks who have contributed to python-mode.el.

    Dave> It's not clear to me what's in python-mode.el that would be useful
    Dave> to put in python.el...

A lot of people like pdbtrack.  The python-mode project also includes bits
Emacs Lisp and Python code to interface with Pymacs.  I believe both are
unique to the python-mode project.

Skip
_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

Re: merging python-mode.el and python.el

fbe2
In reply to this post by Dave Love-2
Dave,

Please forgive me for asking, what may seem to you to be, a dumb
question. But I'm not a lawyer and my brain is not formatted with
whatever structure it needs to understand legal stuff. But, it was my
understanding, based on my readings of rms' stuff, that 'free' software
is free so that people who care to can change the code. More, they can
distribute this altered code to all and sundry as long it remains
'free'.  After all, Dave, we're not doing anything that you haven't
done. Here's the first few lines from the python-mode-map variable from
*your* python.el code:

(defvar python-mode-map
  (let ((map (make-sparese-keymap)))
;; Mostly taken from python-mode.el     <<<<<<<==============!!!!!
   (define-key map ":" 'python-electric-colon)
    ....

Also, here's one of your comments from the 'inferior-python-mode' section:
;; Fixme: This should inherit some stuff from `python-mode', but I'm
;; not sure how much: at least some keybindings, like C-c C-f;
;; syntax?; font-locking, e.g. for triple-quoted strings?

Our 'merge' effort isn't different in any way from the spirit of your
comments in your own code, nyet?

Secondly, it seems as if your main objections center around the question
of which mode will be included in distributions of GNU Emacs. And you
aren't going to include anything in Emacs which hasn't been legally
assigned to FSF, which I can understand. But it also sounds like you are
saying that any software 'borrowed' from some GNU Emacs 'assigned' code
can't be distributed unless it is also assigned to the FSF. Am I
misunderstanding you?

Also, on a personal note, I couldn't care less whether the python mode
that I use is the officially distributed one or not. I kind of  like the
idea of python.org distributing a python-mode, much in the same spirit
as, say, the IEEE distributes it's own IEEEtrans.cls for those who want
to use LaTeX to write IEEE papers. This is common in organizations that
want their publications formatted a special way. There's no real reason
why GNU should have to write a python mode (or a ruby mode, or a mode
for any new language that comes down the pike). It seems more natural
for python (or ruby or...) folk to do so.

As things stand now, both python-mode.el and python.el need work. Both
have good stuff and bad stuff, imo. I know you agree with this, based on
comments you yourself have made, (e.g. in the comments you make in the
python.el header section you say that python-mode.el is "not well
maintained. " Ok, if you think that's so, then you can't reasonably
object to an effort to maintain and upgrade it. As far as your code
goes, the number of your 'fixme's speak for itself.)

I'm wondering what the rms of 25 years ago would say if a lot of legal
wrangling and copyright issues were standing in the way of a handful of
programmers trying to get together to improve some code which they use
all the time? AFAIK, Dave, that's all that's going on here, just some
geeks trying to write a better tool.  At the top of my own wish list for
this project is your help. Is that out of the question, tovarisch?

Beverley Eyre



Dave Love wrote:

> There is talk in the python-mode.el and on the web site of merging it
> with python.el.  I hope people realize that can only be done in
> accordance with the GPL licence of python.el -- i.e. one way -- although
> it doesn't seem useful anyhow.  There's already been an attempt to put
> python.el code into python-mode.el contrary to the licence via a bug
> report, and I'm concerned that it doesn't happen any more (unless
> python-mode.el's licence is changed, obviously).
>
> It's not clear to me what's in python-mode.el that would be useful to
> put in python.el, although I've only skimmed the current version.
> Anyway the main raison d'être for python.el was that we couldn't get
> copyright papers for python-mode.el for inclusion in Emacs (and I won't
> put unassigned code in my version).  Also, python-mode.el changes for
> Emacs weren't accepted, so I wrote an intentionally incompatible mode to
> minimize confusion and ease maintenance.
> _______________________________________________
> Python-mode mailing list
> [hidden email]
> http://mail.python.org/mailman/listinfo/python-mode
>
>  
_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

Re: merging python-mode.el and python.el

Barry Warsaw
In reply to this post by Dave Love-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Jan 18, 2009, at 4:29 PM, Dave Love wrote:

> There is talk in the python-mode.el and on the web site of merging it
> with python.el.  I hope people realize that can only be done in
> accordance with the GPL licence of python.el -- i.e. one way --  
> although
> it doesn't seem useful anyhow.  There's already been an attempt to put
> python.el code into python-mode.el contrary to the licence via a bug
> report, and I'm concerned that it doesn't happen any more (unless
> python-mode.el's licence is changed, obviously).
>
> It's not clear to me what's in python-mode.el that would be useful to
> put in python.el, although I've only skimmed the current version.
> Anyway the main raison d'être for python.el was that we couldn't get
> copyright papers for python-mode.el for inclusion in Emacs (and I  
> won't
> put unassigned code in my version).  Also, python-mode.el changes for
> Emacs weren't accepted, so I wrote an intentionally incompatible  
> mode to
> minimize confusion and ease maintenance.

While technically the python-mode.el file does not have  GPL license  
on it, we've tried many times in the past to assign copyright so that  
it /could/ have such a license on it, and even be owned by the FSF.  
It's long been pulled out of the Python distribution so it needn't  
(and in fact doesn't) have a PSF license on it.  Tim and I have both  
assigned copyright in our changes to the FSF.  I think Ken did too, as  
he was the author of pdb-track among other good code in python-
mode.el.  I'm not sure about Skip.  Looking at the committer line from  
'bzr log' (which should include the svn history), that should just  
about cover it, though there may be contributions described in  
comments that need to be looked at.

I believe there should be no reason why python-mode.el could not be  
released under the GPL, probably even with a copyright FSF.  If there  
are a few contributors who need to be tracked down to get assignments  
from, that shouldn't be difficult.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSXQAR3EjvBPtnXfVAQJQsgP+OP/z9ZVs5Q4Ha5A7gkNGr3oDb+FFobKW
r4Q2NxW1BjVg/B15Iq/u68gI4KjH76IquvdQt0u5mHSoKCYvdKyGB1Ibdpuav7M5
pphwRUfmJaKDCVd4zvxD3jXuVOZW896RImnsALPdvn+X5Ff4/fB8TOfleVHrCbn+
EttPfswKUGw=
=8mGQ
-----END PGP SIGNATURE-----
_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

Re: merging python-mode.el and python.el

Andreas Röhler-2
In reply to this post by Dave Love-2
Dave Love wrote:
> There is talk in the python-mode.el and on the web site of merging it
> with python.el.  I hope people realize that can only be done in
> accordance with the GPL licence of python.el -- i.e. one way -- although
> it doesn't seem useful anyhow.

Hi Dave,

I'm glad to see your posting.
Already wanted to ask about the diff to python-mode.el you put onto emacs-wiki.
Somehow this diff --thanks btw-- contradicts your
arging here, don't it?

 There's already been an attempt to put

> python.el code into python-mode.el contrary to the licence via a bug
> report, and I'm concerned that it doesn't happen any more (unless
> python-mode.el's licence is changed, obviously).
>
> It's not clear to me what's in python-mode.el that would be useful to
> put in python.el, although I've only skimmed the current version.
> Anyway the main raison d'être for python.el was that we couldn't get
> copyright papers for python-mode.el for inclusion in Emacs (and I won't
> put unassigned code in my version).  Also, python-mode.el changes for
> Emacs weren't accepted,

Ok, thats the answer to my question.

so I wrote an intentionally incompatible mode

that's human...

 to
> minimize confusion and ease maintenance.

A different approach might always be of interest at least.
> _______________________________________________

Is python.el now included in FSF Emacs? AFAIK not, for the kind of reasoning above.
IMHO that legalizing is a never ending sad story. It might end as a tragic story
 for all Emacsen and GPL alike.

Please let us contribute free code to free software.

Let's enjoy all Emacsen peacefully and assist each other as much as possible.

Andreas Röhler




_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

Re: merging python-mode.el and python.el

Andreas Röhler-2
In reply to this post by Barry Warsaw
Barry Warsaw wrote:

> On Jan 18, 2009, at 4:29 PM, Dave Love wrote:
>
>> There is talk in the python-mode.el and on the web site of merging it
>> with python.el.  I hope people realize that can only be done in
>> accordance with the GPL licence of python.el -- i.e. one way -- although
>> it doesn't seem useful anyhow.  There's already been an attempt to put
>> python.el code into python-mode.el contrary to the licence via a bug
>> report, and I'm concerned that it doesn't happen any more (unless
>> python-mode.el's licence is changed, obviously).
>
>> It's not clear to me what's in python-mode.el that would be useful to
>> put in python.el, although I've only skimmed the current version.
>> Anyway the main raison d'être for python.el was that we couldn't get
>> copyright papers for python-mode.el for inclusion in Emacs (and I won't
>> put unassigned code in my version).  Also, python-mode.el changes for
>> Emacs weren't accepted, so I wrote an intentionally incompatible mode to
>> minimize confusion and ease maintenance.
>
> While technically the python-mode.el file does not have  GPL license on
> it, we've tried many times in the past to assign copyright so that it
> /could/ have such a license on it, and even be owned by the FSF.  It's
> long been pulled out of the Python distribution so it needn't (and in
> fact doesn't) have a PSF license on it.  Tim and I have both assigned
> copyright in our changes to the FSF.  I think Ken did too, as he was the
> author of pdb-track among other good code in python-mode.el.  I'm not
> sure about Skip.  Looking at the committer line from 'bzr log' (which
> should include the svn history), that should just about cover it, though
> there may be contributions described in comments that need to be looked at.
>
> I believe there should be no reason why python-mode.el could not be
> released under the GPL, probably even with a copyright FSF.  If there
> are a few contributors who need to be tracked down to get assignments
> from, that shouldn't be difficult.
>
> -Barry
>

Hi Barry,

I didn't sign code to FSF and probably will not. The reasons I already declared on
FSF-list and towards RMS.

Will not make it up here, unless you ask me to.

As you approved my tiny peace of code, but not merged AFAIS,
should I keep a separate branch on lp?

Cheers

Andreas Röhler



_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

Re: merging python-mode.el and python.el

Barry Warsaw
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Jan 19, 2009, at 4:48 AM, Andreas Roehler wrote:

> I didn't sign code to FSF and probably will not. The reasons I  
> already declared on
> FSF-list and towards RMS.

Do you have a pointer to that discussion?

> Will not make it up here, unless you ask me to.
>
> As you approved my tiny peace of code, but not merged AFAIS,
> should I keep a separate branch on lp?

Please do that for now, until we resolve any legal issues that Dave is  
bringing up.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSXSFo3EjvBPtnXfVAQIS+gP+MI6XdhGay+tz/jhs2RswxP8yGljPYuX4
9NVzWZBOmWNTsod/iDKXOzZfrITN9T94dCrLo9fkj3A1tf4Sax/Y8HJjgrzEJQIP
NDvYD9y1kSheNpbS9NjLjiJGT4eiUfSUyP5C9k/EIQzst6fRXzMAbe4s8zRpTDWG
0ydfmtiH9RU=
=eLGM
-----END PGP SIGNATURE-----
_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

Re: merging python-mode.el and python.el

Andreas Röhler-2
Barry Warsaw wrote:
> On Jan 19, 2009, at 4:48 AM, Andreas Roehler wrote:
>
>> I didn't sign code to FSF and probably will not. The reasons I already
>> declared on
>> FSF-list and towards RMS.
>
> Do you have a pointer to that discussion?
>

Raised my concerns at several occasions. The most comprehensive is here:

.fsf.europe.discussion/2006-03/msg00007.html

It titled:

Do Not Ask The Butcher To Protect The Lamb:

And starts with:

GPLv3 - Further Step Towards An Orwellian Society?:

Remarks On Software Licensing.

No-one should use a right against an other one, if he
hadn't a harm caused by this violation, even if the
other one violated his right.

The reason is, that rights - and laws denying or
granting them - are no values by them-self, but derived
from the interest to live in peace and without harm.

If there is no harm, you should not start a legal
strive. Respectively: if there are big harms and some
minor - to say mince - one, you should address the big
harm, not the mince, not to lose your creditability.

....

So far some quotation.

>> Will not make it up here, unless you ask me to.
>
>> As you approved my tiny peace of code, but not merged AFAIS,
>> should I keep a separate branch on lp?
>
> Please do that for now, until we resolve any legal issues that Dave is
> bringing up.

OK. Did Dave tell you, which patch he is addressing as a violation?

Hope people don't get frustrated and restrain from contributing.
There are still some nice things to do for python-mode IMHO.

Andreas Röhler

>
> -Barry
>
_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

Re: merging python-mode.el and python.el

Dave Love-2
In reply to this post by Skip Montanaro-3
"[hidden email]" <[hidden email]> writes:

> Based on my own personal experience I don't think you
> can lay all the blame on the folks who have contributed to python-mode.el.

Who's laying blame?  There wasn't much point in me pursuing any other
authors without an assignment for Barry's code, but it's now moot.

If you're having trouble with copyright assignments, and don't get
anywhere with the clerk, rms would probably like to know.

>     Dave> It's not clear to me what's in python-mode.el that would be useful
>     Dave> to put in python.el...
>
> A lot of people like pdbtrack.

Maybe, but it shouldn't be in Python mode, per my commentary.  Something
like that clearly shouldn't be done there and more-or-less duplicated in
N other modes with inferior interpreters.  (Actually, there is a bunch
of stuff left in python.el that shouldn't be there, and would have been
abstracted over similar modes if I'd had the chance, but at least some
of that required modifications to Emacs.)

> The python-mode project also includes bits
> Emacs Lisp and Python code to interface with Pymacs.  I believe both are
> unique to the python-mode project.

$ grep -i pymacs python-mode.el
$ grep -i pymacs python.el
(autoload 'pymacs-load "pymacs" nil t)
          (pymacs-load "bikeemacs" "brm-") ; first line of normal recipe

When I wrote python.el, as far as I could tell it had a superset of
features of the old mode which, as an experienced maintainer, I thought
should or had to be there (as opposed to things like generalized Eldoc
support, symbol completion, Capitalized Words mode, &c, and things which
violate Emacs requirements for keybindings and things).
_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

Re: merging python-mode.el and python.el

Dave Love-2
In reply to this post by Andreas Röhler-2
Andreas Roehler <[hidden email]> writes:

> Somehow this diff --thanks btw-- contradicts your
> arging here, don't it?

No, but what's that got to do with FSF copyright?

> so I wrote an intentionally incompatible mode
>
> that's human...

Mainly engineering as far as I'm concerned.

> Is python.el now included in FSF Emacs? AFAIK not, for the kind of
> reasoning above.

Please check, if you don't know.

> Please let us contribute free code to free software.

What??  I've spent a lot of effort encouraging and facilitating that,
even before the term was invented, and I've learnt to take legalities
seriously -- apart from maintaining GNU software.  If you have an
argument with someone over doing anything you like with my Emacs code,
it's with the FSF.  They hold the copyright, as it says in the notice.
_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

Re: merging python-mode.el and python.el

Dave Love-2
In reply to this post by Barry Warsaw
Barry Warsaw <[hidden email]> writes:

> While technically the python-mode.el file does not have  GPL license  
> on it, we've tried many times in the past to assign copyright so that  
> it /could/ have such a license on it, and even be owned by the FSF.

Like I just posted elsewhere (?), we -- I think at least three people at
different times -- tried to get proper paperwork for Emacs, and I gave
up when it seemed we weren't going to get paperwork from your then (or
former?) employer.  I don't know whether I can find the mail at this
remove, and I don't want to spend time looking.  I'm not questioning
your willingness, obviously; you had multiple assignments on file, and
it was clear it wasn't in your control.  I wasn't aware you'd tried and
failed (apart from that) and, as far as I remember, at that time we were
proactive in seeking assignments.

That's only relevant to copying _into_ Emacs, though, not out of it.

> though there may be contributions described in  
> comments that need to be looked at.

Indeed (or not described anywhere).

> I believe there should be no reason why python-mode.el could not be  
> released under the GPL, probably even with a copyright FSF.  If there  
> are a few contributors who need to be tracked down to get assignments  
> from, that shouldn't be difficult.

I'm not exactly a beginner in that area, unfortunately, and I wouldn't
bank on it; re-implementation is often a better bet.  Now that there's
support for, and in, Emacs, I think the issue is moot.
_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

Re: merging python-mode.el and python.el

Dave Love-2
In reply to this post by fbe2
Beverley Eyre <[hidden email]> writes:

> But, it was my
> understanding, based on my readings of rms' stuff, that 'free' software
> is free so that people who care to can change the code.

Partly, yes.

> More, they can distribute this altered code to all and sundry as long
> it remains 'free'.

You should re-read rms, and read the GPL and probably the licensing area
of the GNU web site.

> After all, Dave, we're not doing anything that you haven't
> done.

I've never knowingly (or even inadvertently, as far as I know) violated
a free software licence -- rms' archetype here -- which is what you seem
to be advocating,

> Here's the first few lines from the python-mode-map variable from
> *your* python.el code:
>
> (defvar python-mode-map
>   (let ((map (make-sparese-keymap)))
> ;; Mostly taken from python-mode.el     <<<<<<<==============!!!!!
>    (define-key map ":" 'python-electric-colon)
>     ....

You're arguing interfaces are copyrightable??  (In which case
python-mode.el would have a problem.)  Even if I copied a significant
amount of code directly -- which I didn't, unless you want to argue
against legal advice and case law -- the python-mode.el licence would
allow me.

> Also, here's one of your comments from the 'inferior-python-mode' section:
> ;; Fixme: This should inherit some stuff from `python-mode', but I'm
> ;; not sure how much: at least some keybindings, like C-c C-f;
> ;; syntax?; font-locking, e.g. for triple-quoted strings?

I've no idea what that's about -- objecting to me calling the function
`python-mode'?

> Our 'merge' effort isn't different in any way from the spirit of your
> comments in your own code, nyet?

The words `apples' and `oranges' come to mind.  If you want to argue
copyright, you should consult a lawyer, like rms does.  (I'm not a
lawyer, but I hope what I say is consistent with the FSF's legal advice;
if not, I'd like to be corrected with a proper reference.)

> Secondly, it seems as if your main objections center around the question
> of which mode will be included in distributions of GNU Emacs.

No.

> And you
> aren't going to include anything in Emacs which hasn't been legally
> assigned to FSF, which I can understand. But it also sounds like you are
> saying that any software 'borrowed' from some GNU Emacs 'assigned' code
> can't be distributed unless it is also assigned to the FSF. Am I
> misunderstanding you?

Yes, you are misunderstanding.  You merely need to abide by the licence.
The FSF publishes guides to such things.  I think it's all under
<URL:http://www.gnu.org/licensing>.

> There's no real reason why GNU should have to write a python mode (or
> a ruby mode, or a mode for any new language that comes down the
> pike).

Indeed, and `GNU' didn't write it, or ask me to.

> It seems more natural for python (or ruby or...) folk to do so.

I'm sorry I'm not in your club, but I think understanding Emacs is most
important thing for contributing language support (assuming the language
is sufficiently well-defined and it doesn't require large amounts of
non-Emacs support code).  `Python folk' haven't supported recent Emacs
-- as opposed to XEmacs -- or even the latest version of Python as far
as I can tell.  That's perfectly OK, just as me doing it is.

> As things stand now, both python-mode.el and python.el need work. Both
> have good stuff and bad stuff, imo.

I'll probably at least fix clear bugs and omissions (apart from XEmacs
support) in python.el that I hear about.  I'll also listen to
_well-informed_ opinion about possible mis-features.

> I know you agree with this, based on
> comments you yourself have made, (e.g. in the comments you make in the
> python.el header section you say that python-mode.el is "not well
> maintained. "

It says `[...] maintained for _Emacs_'.

> Ok, if you think that's so, then you can't reasonably
> object to an effort to maintain and upgrade it.

Please don't put words in my mouth.  All I'm actually objecting to is
potential copyright violation.  If you insist on copying code from Emacs
in violation of the licence, you'll end up on the wrong side of the FSF
`compliance lab' (ugh).

> As far as your code
> goes, the number of your 'fixme's speak for itself.)

The number doesn't say anything per se, even if they are all mine that
you're looking at.

> I'm wondering what the rms of 25 years ago would say if a lot of legal
> wrangling and copyright issues were standing in the way of a handful of
> programmers trying to get together to improve some code which they use
> all the time?

That's a pretty bizarre thing to lecture me about.

--
Copyleft (Ɔ) All rights reversed.  — Don Hopkins
_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

Re: merging python-mode.el and python.el

Barry Warsaw
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Jan 27, 2009, at 8:17 PM, Dave Love wrote:

> I'm sorry I'm not in your club, but I think understanding Emacs is  
> most
> important thing for contributing language support (assuming the  
> language
> is sufficiently well-defined and it doesn't require large amounts of
> non-Emacs support code).  `Python folk' haven't supported recent Emacs
> -- as opposed to XEmacs -- or even the latest version of Python as far
> as I can tell.  That's perfectly OK, just as me doing it is.

python-mode.el works fine in Emacs and XEmacs and it supports at least  
up to Python 2.6 quite well.  There's some question I think about how  
well it syntax highlights Python 3.0 but it should format the code  
correctly.

I also think that python-mode.el feels more natural to Python  
programmers, but I have only anecdotal evidence for that.  Just last  
week I had a colleague ask me why Emacs wasn't working the way he  
wanted while editing his Python code.  I made a wild guess and pointed  
him to python-mode.el and it solved his problem.  That's happened to  
me several times when Emacs users don't realize that they have a  
different Python mode.

Ultimately, it does a disservice to Python programmers, Emacs users  
and XEmacs users to have multiple versions of this major mode.  Let's  
agree that everyone involved have the right intention to improve the  
situation, but if the legal framework makes this impossible then so be  
it.  I'm willing (and able) to do what I can to clarify my ownership  
in the code, but if that doesn't actually help, I'll stop worrying  
about it, at least until this topic comes up again in another 10 years.

I still propose we GPLv3 python-mode.el.  Thus if we cannot merge, we  
will simply continue to develop python-mode.el separately, educate  
users as to the differences, and let them decide which they prefer.  
With a GPLv3 python-mode.el we can all borrow from each other.

Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSX/YD3EjvBPtnXfVAQKYfQQAjsyJy8kB+4icLg8B97cwT4oo9Hjnc+AL
1mEsvkynss3/XycoXr4r7suBqqa7/2AlrhfrN9QQk+pMWe31Cp1rUrLQYrRYW9HN
cu+CKvNOIJXwHouss3lZ5leyc+SFRFXpjt+Thof5DROG91APNO08mdEVisN47HsZ
ImohGu7iOSQ=
=6YBh
-----END PGP SIGNATURE-----
_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

Re: merging python-mode.el and python.el

Jeff Bauer
Barry Warsaw wrote:
> I also think that python-mode.el feels more natural to Python
> programmers, but I have only anecdotal evidence for that.  Just last
> week I had a colleague ask me why Emacs wasn't working the way he wanted
> while editing his Python code.  I made a wild guess and pointed him to
> python-mode.el and it solved his problem.  That's happened to me several
> times when Emacs users don't realize that they have a different Python
> mode.

Yes, I was one of those who wondered why Python didn't feel right in
Emacs until I realized there were multiple versions.  It's a subjective
thing, but no less important for that.

> I still propose we GPLv3 python-mode.el.  Thus if we cannot merge, we
> will simply continue to develop python-mode.el separately, educate users
> as to the differences, and let them decide which they prefer.  With a
> GPLv3 python-mode.el we can all borrow from each other.

+1

Jeff Bauer
Rubicon, Inc.
_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

Re: merging python-mode.el and python.el

Dave Love-2
In reply to this post by Barry Warsaw
Barry Warsaw <[hidden email]> writes:

> python-mode.el works fine in Emacs

Maybe now -- I haven't checked closely -- but it didn't when I tried to
fix it, and people are now trying to incorporate Emacs-specific
features.  I found the issues actually using it originally, and others
did according to Debian bug reports.

> I also think that python-mode.el feels more natural to Python  
> programmers, but I have only anecdotal evidence for that.

Doubtless, but Emacs isn't just for Python programmers, and surely modes
should be consistent.  I rely (modulo a few historical things which
should be fixed) on the same conventions if I'm hacking Python as, say,
Fortran, sh, or Lisp.  In fact, part of the idea of the new mode was to
figure out what more to abstract over similar modes.

If people don't like the conventions or want things which break other
code, they can customize and distribute the customizations, of course.
(Custom theme support may help.)  I'd hope they'd try to understand the
general conventions, though, and not cause confusion over them.

> Ultimately, it does a disservice to Python programmers, Emacs users  
> and XEmacs users to have multiple versions of this major mode.

I'm not sure about that, but it's hardly the only thing that's different
from XEmacs...

> Let's agree that everyone involved have the right intention to improve
> the situation,

I don't doubt your intentions -- sorry if it seems otherwise.  It's a
different matter for someone else if they don't respect the FSF's
copyright, for instance, and that's presumably mutual.

> I still propose we GPLv3 python-mode.el.  Thus if we cannot merge, we  
> will simply continue to develop python-mode.el separately, educate  
> users as to the differences, and let them decide which they prefer.  
> With a GPLv3 python-mode.el we can all borrow from each other.

Fine.  That solves the basic problem of copying code from Emacs in
accordance with the licence -- e.g. with appropriate copyright notices
-- but I'm sure you'll keep an eye on that.

Happy hacking.
_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

Re: merging python-mode.el and python.el

Barry Warsaw
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Feb 1, 2009, at 1:26 PM, Dave Love wrote:

> Doubtless, but Emacs isn't just for Python programmers, and surely  
> modes
> should be consistent.

That's pretty much a universal design decision across all of software,  
isn't it?  python.el takes one approach, python-mode.el takes a  
different one.  I've been a X/Emacs user for probably close to 25  
years and python-mode.el does not feel unnatural to me, even if it has  
some unorthodox coding conventions.

> I rely (modulo a few historical things which
> should be fixed) on the same conventions if I'm hacking Python as,  
> say,
> Fortran, sh, or Lisp.  In fact, part of the idea of the new mode was  
> to
> figure out what more to abstract over similar modes.

Sure, all valid approaches, although there's an important difference  
in aims between python.el and python-mode.el.  The former only cares  
about Emacs compatibility.  The latter cares about both Emacs and  
XEmacs compatibility.  In many cases the abstraction are different  
enough as to make refactoring a challenge.

> If people don't like the conventions or want things which break other
> code, they can customize and distribute the customizations, of course.
> (Custom theme support may help.)  I'd hope they'd try to understand  
> the
> general conventions, though, and not cause confusion over them.

Sure, but there's another difference.  python-mode.el has been around  
for a very long time and its users for the most part like the way it  
works.  As someone who would likely begin to curse his own fingers, I  
don't think we should break that backwards compatibility in python-
mode.el.

>> Let's agree that everyone involved have the right intention to  
>> improve
>> the situation,
>
> I don't doubt your intentions -- sorry if it seems otherwise.  It's a
> different matter for someone else if they don't respect the FSF's
> copyright, for instance, and that's presumably mutual.

Of course.

I certainly appreciate the arguments that Andreas and Beverley make as  
to copyright.  I have my own opinions on that subject both as a FLOSS  
developer and musician.  But this isn't an effective forum for  
changing either the FSF's stance, nor US or international law on the  
matter, so I believe we must adapt to the regime under which we live,  
and take the fight to the forums where such change can actually be  
affected.

>> I still propose we GPLv3 python-mode.el.  Thus if we cannot merge, we
>> will simply continue to develop python-mode.el separately, educate
>> users as to the differences, and let them decide which they prefer.
>> With a GPLv3 python-mode.el we can all borrow from each other.
>
> Fine.  That solves the basic problem of copying code from Emacs in
> accordance with the licence -- e.g. with appropriate copyright notices
> -- but I'm sure you'll keep an eye on that.

Cool.
Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCUAwUBSYcUgHEjvBPtnXfVAQI16AP3d62FgQ3YTFmpReFPG6X5a1udkj0Uas/d
9DwWOtXT/PZ4+f5MmwuhIO/Ehx3+rlbL3BFwYYHeQgVfgx+LudRZT7zi+A64KhG1
TzhGWCfSPED7DsP0HsDGZDaXuGcWkm/PEWkEi0fvqet5alaOkDi4SA7KTmNijINT
G0yCdQajsg==
=m+IZ
-----END PGP SIGNATURE-----
_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode