Broken python-model.el

[Brian Donovan]

Hi All,

I just compiled Python 2.3.2 on my local machine as an upgrade from 2.2.
This appears to have broken my python-mode.el in emacs. When I try to
"Execute Buffer" Ctl-c Ctl-c I get:

Wrong type argument: sequencep, cpython

Any Ideas?

[John J. Lee]

Brian Donovan <jo**@doe.com > writes:

I just compiled Python 2.3.2 on my local machine as an upgrade from 2.2.
This appears to have broken my python-mode.el in emacs. When I try to
"Execute Buffer" Ctl-c Ctl-c I get:

Wrong type argument: sequencep, cpython

Any Ideas?

Did you download the version from the python-mode sourceforge project?
If not, try that.
John

[Peter Milliken]

John, the sourceforge project doesn't have any released files - beware
unreleased files :-).

I downloaded and tried the python-mode.el file you can access through the
CVS repository (version 4.40) - no wonder there has been no releases!

Initial impressions is that I will re-download the 4.6 version available
from the python web-site. One of the annoying things that hits you right in
the face (and this is terribly unfair to the sourceforge team working on
it! - it hasn't been released after all :-)) is the "blind" fontification of
what are believed to be Python keywords by the authors.

This list includes words such as "Exception" , "ord", "self" plus a host of
others. So variables that I have such as "swimrecord " has the "ord" portion
font coloured differently from the rest of the string, "ChildException " has
the "Exception" differently coloured than the "Child" portion, "self" is a
different colour from the rest of the variable usage i.e. self.Name has
"self" and "Name" colourised differently - extremely annoying and *not* what
I expect the authors want to achieve! Certainly not what I want in an edit
session! :-)

So Brian might be better off trying to patch his python-mode.el rather than
download the tip of what is at sourceforge :-)

However, I use python-mode.el (4.6) which is available from
http://www.python.org/emacs/python-mode/ - I have Python 2.3.2 installed and
have no problems with C-c C-c. So perhaps Brian should check his version of
python-mode.el against that one?

Peter

"John J. Lee" <jj*@pobox.co m> wrote in message
news:87******** ****@pobox.com. ..

Brian Donovan <jo**@doe.com > writes:

I just compiled Python 2.3.2 on my local machine as an upgrade from 2.2. This appears to have broken my python-mode.el in emacs. When I try to
"Execute Buffer" Ctl-c Ctl-c I get:

Wrong type argument: sequencep, cpython

Any Ideas?

Did you download the version from the python-mode sourceforge project?
If not, try that.
John

[Skip Montanaro]

Brian> I just compiled Python 2.3.2 on my local machine as an upgrade
Brian> from 2.2. This appears to have broken my python-mode.el in
Brian> emacs. When I try to "Execute Buffer" Ctl-c Ctl-c I get:

Brian> Wrong type argument: sequencep, cpython

What version of python-mode and Emacs are you using? What is the value of
py-default-interpreter? I just tried C-c C-c in a Python buffer with
version 4.40 and XEmacs 21.5beta9 and it worked fine for me.

Skip

[Thomas Heller]

Skip Montanaro <sk**@pobox.com > writes:

Brian> I just compiled Python 2.3.2 on my local machine as an upgrade
Brian> from 2.2. This appears to have broken my python-mode.el in
Brian> emacs. When I try to "Execute Buffer" Ctl-c Ctl-c I get:

Brian> Wrong type argument: sequencep, cpython

What version of python-mode and Emacs are you using? What is the value of
py-default-interpreter? I just tried C-c C-c in a Python buffer with
version 4.40 and XEmacs 21.5beta9 and it worked fine for me.

I also get the above error when the file begins with

#!/usr/bin/env

on Windows. XEmacs 21.4 (patch 13), python-mode 4.29.

Removing this line fixes it.

Thomas

[Thomas Heller]

Thomas Heller <th*****@python .net> writes:

Skip Montanaro <sk**@pobox.com > writes:

Brian> I just compiled Python 2.3.2 on my local machine as an upgrade
Brian> from 2.2. This appears to have broken my python-mode.el in
Brian> emacs. When I try to "Execute Buffer" Ctl-c Ctl-c I get:

Brian> Wrong type argument: sequencep, cpython

What version of python-mode and Emacs are you using? What is the value of
py-default-interpreter? I just tried C-c C-c in a Python buffer with
version 4.40 and XEmacs 21.5beta9 and it worked fine for me.
I also get the above error when the file begins with

#!/usr/bin/env

Make this
#!/usr/bin/env python
of course.
on Windows. XEmacs 21.4 (patch 13), python-mode 4.29.

Removing this line fixes it.

Thomas

[Skip Montanaro]

Peter> Initial impressions is that I will re-download the 4.6 version
Peter> available from the python web-site. One of the annoying things
Peter> that hits you right in the face (and this is terribly unfair to
Peter> the sourceforge team working on it! - it hasn't been released
Peter> after all :-)) is the "blind" fontification of what are believed
Peter> to be Python keywords by the authors.

Peter> This list includes words such as "Exception" , "ord", "self" plus
Peter> a host of others. So variables that I have such as "swimrecord "
Peter> has the "ord" portion font coloured differently from the rest of
Peter> the string, "ChildException " has the "Exception" differently
Peter> coloured than the "Child" portion, "self" is a different colour
Peter> from the rest of the variable usage i.e. self.Name has "self" and
Peter> "Name" colourised differently - extremely annoying and *not* what
Peter> I expect the authors want to achieve! Certainly not what I want
Peter> in an edit session! :-)

That's a feature I added recently. It's intended to highlight variables
which might be shadowing builtins. Eventually, it should be a
user-configurable feature. I checked in a fix to the "trailing builtin"
problem a couple days ago. Have you tried that yet?

Skip

[Skip Montanaro]

Brian> Wrong type argument: sequencep, cpython

Thomas> I also get the above error when the file begins with

Thomas> #!/usr/bin/env

Thomas> on Windows. XEmacs 21.4 (patch 13), python-mode 4.29.
Thomas> Removing this line fixes it.

Yeah, I can see where that would cause problems.
(py-choose-shell-by-shebang) really needs to see a valid #! line. I'll see
if I can figure out a way to worm around this sort of breakage.

Skip