Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #41829 > unrolled thread

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

Back to article view | Back to comp.lang.python

Contents

  How to define "exec" method on a class object? Get syntax error due to built in command Kyle <stalkernew@gmail.com> - 2013-03-25 13:28 -0700
    Re: How to define "exec" method on a class object? Get syntax error due to built in command Chris Angelico <rosuav@gmail.com> - 2013-03-26 07:43 +1100
    Re: How to define "exec" method on a class object? Get syntax error due to built in command Kyle <stalkernew@gmail.com> - 2013-03-26 11:13 -0700
      Re: How to define "exec" method on a class object? Get syntax error due to built in command Ethan Furman <ethan@stoneleaf.us> - 2013-03-26 11:36 -0700
      Re: How to define "exec" method on a class object? Get syntax error due to built in command Chris Angelico <rosuav@gmail.com> - 2013-03-27 05:43 +1100
        Re: How to define "exec" method on a class object? Get syntax error due to built in command Kyle <stalkernew@gmail.com> - 2013-03-26 12:24 -0700
          Re: How to define "exec" method on a class object? Get syntax error due to built in command Chris Angelico <rosuav@gmail.com> - 2013-03-27 06:39 +1100
            Re: How to define "exec" method on a class object? Get syntax error due to built in command Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-03-26 23:19 +0000
              Re: How to define "exec" method on a class object? Get syntax error due to built in command Chris Angelico <rosuav@gmail.com> - 2013-03-27 12:27 +1100

#41829 — How to define "exec" method on a class object? Get syntax error due to built in command

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

[toc] | [next] | [standalone]

#41830

On Tue, Mar 26, 2013 at 7:28 AM, Kyle <stalkernew@gmail.com> wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#41934

On Monday, March 25, 2013 4:28:34 PM UTC-4, Kyle wrote:
> 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)
> 
> ...
> 
> }

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.

[toc] | [prev] | [next] | [standalone]

#41938

On 03/26/2013 11:13 AM, Kyle wrote:
> On Monday, March 25, 2013 4:28:34 PM UTC-4, Kyle wrote:
>> 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)
>>
>> ...
>>
>> }
>
> 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'.  :)

--
~Ethan~

[toc] | [prev] | [next] | [standalone]

#41939

On Wed, Mar 27, 2013 at 5:13 AM, Kyle <stalkernew@gmail.com> wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#41944

On Mar 26, 2:43 pm, Chris Angelico <ros...@gmail.com> wrote:
> On Wed, Mar 27, 2013 at 5:13 AM, Kyle <stalker...@gmail.com> wrote:
> > 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

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.

[toc] | [prev] | [next] | [standalone]

#41945

On Wed, Mar 27, 2013 at 6:24 AM, Kyle <stalkernew@gmail.com> wrote:
> On Mar 26, 2:43 pm, Chris Angelico <ros...@gmail.com> wrote:
>> On Wed, Mar 27, 2013 at 5:13 AM, Kyle <stalker...@gmail.com> wrote:
>> > 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
>
> 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

[toc] | [prev] | [next] | [standalone]

#41963

On Wed, 27 Mar 2013 06:39:24 +1100, Chris Angelico wrote:

> On Wed, Mar 27, 2013 at 6:24 AM, Kyle <stalkernew@gmail.com> wrote:
>> On Mar 26, 2:43 pm, Chris Angelico <ros...@gmail.com> wrote:
>>> On Wed, Mar 27, 2013 at 5:13 AM, Kyle <stalker...@gmail.com> wrote:
>>> > 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
>>
>> 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. 

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.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#41972

On Wed, Mar 27, 2013 at 10:19 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Wed, 27 Mar 2013 06:39:24 +1100, Chris Angelico wrote:
>> 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.

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

ChrisA

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web