How to define "exec" method on a class object? Get syntax error dueto built in command

[Kyle]

I am using swig to generate our CLI for TCL and Python. In this CLI, we have a subcommand "exec" that is failing to compile in the python case. There seems to be some built-in python command "exec" which is giving a syntax error in the .py file generated by swig when I try to import it:

def exec(*args): return _wbt_daemon.dm_cli_exec(*args)
^
SyntaxError: invalid syntax

I don't really want to change the CLI commands or make them different between languages. Is there any way to define a method called "exec" on a class?It would be executed as obj.exec() so I don't see why it should conflict with the built in "exec" command.

class dm_cli(_object):
__swig_setmethods__ = {}
__setattr__ = lambda self, name, value: _swig_setattr(self, dm_cli, name, value)
__swig_getmethods__ = {}
__getattr__ = lambda self, name: _swig_getattr(self, dm_cli, name)
def __init__(self): raise RuntimeError, "No constructor defined"
....
def exec(*args): return _wbt_daemon.dm_cli_exec(*args)
....
}

 

[Chris Angelico]

I am using swig to generate our CLI for TCL and Python. In this CLI, we have a subcommand "exec" that is failing to compile in the python case. There seems to be some built-in python command "exec" which is giving a syntax error in the .py file generated by swig when I try to import it:

def exec(*args): return _wbt_daemon.dm_cli_exec(*args)

In Python 2, exec is a keyword, so you can't do that. In Python 3,
exec is simply a built-in function, so it'd work fine. Technically you
can get around the problem in 2.x with setattr/getattr, but that may
not really be all that useful...

def _exec(*args): return _wbt_daemon.dm_cli_exec(*args)
....

setattr(dm_cli,"exec",dm_cli._exec)

Tested on 2.6 for Windows (I really ought to get myself a 2.7, maybe
when 2.7.4 gets released I'll grab it).

ChrisA

 

[Kyle]

I am using swig to generate our CLI for TCL and Python. In this CLI, we have a subcommand "exec" that is failing to compile in the python case. There seems to be some built-in python command "exec" which is giving a syntax error in the .py file generated by swig when I try to import it:



def exec(*args): return _wbt_daemon.dm_cli_exec(*args)

^

SyntaxError: invalid syntax



I don't really want to change the CLI commands or make them different between languages. Is there any way to define a method called "exec" on a class? It would be executed as obj.exec() so I don't see why it should conflictwith the built in "exec" command.



class dm_cli(_object):

__swig_setmethods__ = {}

__setattr__ = lambda self, name, value: _swig_setattr(self, dm_cli,name, value)

__swig_getmethods__ = {}

__getattr__ = lambda self, name: _swig_getattr(self, dm_cli, name)

def __init__(self): raise RuntimeError, "No constructor defined"

...

def exec(*args): return _wbt_daemon.dm_cli_exec(*args)

...

}

Thanks for the suggestion. Looks like we currently use 2.3.4.

This still wouldn't solve the problem because now the user would need to call something like getattr(wbt, "exec")(<args>) instead of wbt.exec(<args>)like all the other commands.

I think the easiest thing for me to do would be to just change the command name from exec to something else.

 

[Ethan Furman]

Thanks for the suggestion. Looks like we currently use 2.3.4.

This still wouldn't solve the problem because now the user would need to call something like getattr(wbt, "exec")(<args>) instead of wbt.exec(<args>) like all the other commands.

I think the easiest thing for me to do would be to just change the command name from exec to something else.

Yeah, that's unfortunate.

I suggest 'execute'.

 

[Chris Angelico]

Thanks for the suggestion. Looks like we currently use 2.3.4.

This still wouldn't solve the problem because now the user would need to call something like getattr(wbt, "exec")(<args>) instead of wbt.exec(<args>) like all the other commands.

I think the easiest thing for me to do would be to just change the command name from exec to something else.

...... that's pretty ancient. Any chance you can upgrade at least to 2.7.3?

ChrisA

 

[Kyle]

..... that's pretty ancient. Any chance you can upgrade at least to 2.7.3?

ChrisA

Unfortunately, while I could update my machine, there's no guarantee
others would have the same version--the 2.3.4 seems to be the default
on our machines and in the automount dirs.

 

[Chris Angelico]

Unfortunately, while I could update my machine, there's no guarantee
others would have the same version--the 2.3.4 seems to be the default
on our machines and in the automount dirs.

I strongly recommend upgrading. 2.3.4 dates back to 2004, that's
roughly a decade of bug fixes and feature enhancements behind the
times. 2.7.3 is the latest 2.x release, and most likely your code will
run unchanged on it; if you can switch to 3.3.0 (the latest 3.x
release), that would actually fix your exec problem, for what that's
worth. (Moving to 3.3.0 would be a much bigger change, though, and one
that's likely to require code edits.)

It's a good thing Python has neither the number nor breadth of
security vulnerabilities as Windows; you're using something nearly as
old as an unpatched Windows XP, no service packs, no Windows Update,
nothing... no sane systems administrator would let you put that on the
internet. It may not be suicidal like that, but it's still ten years'
worth of updates you're missing out on!

ChrisA

 

[Steven D'Aprano]

I strongly recommend upgrading. 2.3.4 dates back to 2004, that's roughly
a decade of bug fixes and feature enhancements behind the times.

Python 2.3 is still supported by Red Hat, at least if you have paid for
extended support. In principle at least, Red Hat will be providing
security fixes for 2.3.

2.7.3
is the latest 2.x release, and most likely your code will run unchanged
on it; if you can switch to 3.3.0 (the latest 3.x release), that would
actually fix your exec problem, for what that's worth. (Moving to 3.3.0
would be a much bigger change, though, and one that's likely to require
code edits.)

If the OP's code uses string exceptions:

raise "an error occurred"

they will need to be replaced before migrating to 2.7.

 

[Chris Angelico]

Python 2.3 is still supported by Red Hat, at least if you have paid for
extended support. In principle at least, Red Hat will be providing
security fixes for 2.3.

Oh, I thought they only supported 2.4. My bad. Still, there's ten
years of feature improvements, even if not security patches.

ChrisA