[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.python

Returning values from function to Python shell/IPython

Karlo Lozovina

3/9/2008 3:56:00 PM

Hi all!

I have a runTest() function inside my module, which sets up and initializes
lots of objects and performs some basic tests on them. Usually (from
IPython) I just write `run my_module.py`, and then `runTest()`. But
sometimes I would like to manually twiddle with objects runTest creates. Is
there any way I can "return" all those objects local to runTest(), and have
them available in IPython (or ordinary Python shell)?

Thanks...


P.S.
I know I can do it from a:

if __name__ == '__main__':
# lots of object initialization...

and then have all those objects available in the interpreter.

--
Karlo Lozovina -- Mosor
5 Answers

Jorge Vargas

3/9/2008 4:32:00 PM

0

On Sun, Mar 9, 2008 at 9:56 AM, Karlo Lozovina <_karlo_@mosor.net> wrote:
> Hi all!
>
> I have a runTest() function inside my module, which sets up and initializes
> lots of objects and performs some basic tests on them. Usually (from
> IPython) I just write `run my_module.py`, and then `runTest()`. But
> sometimes I would like to manually twiddle with objects runTest creates. Is
> there any way I can "return" all those objects local to runTest(), and have
> them available in IPython (or ordinary Python shell)?

well after all it's a function so the only ways you can get things out
of it are:
- return a dict with all the objects
- use global (very messy)
- use a decorator to do either of the above.


on the other hand have you consider using a proper test package?
instead of inspecting the objects manually from the shell you could
make it all automatic. with assert statements. you could use the std.
python testing modules http://docs.python.org/lib/develo... or
something less verbosed like nose
http://code.google.com/p/py...
>
> Thanks...
>
>
> P.S.
> I know I can do it from a:
>
> if __name__ == '__main__':
> # lots of object initialization...
>
> and then have all those objects available in the interpreter.
>
> --
> Karlo Lozovina -- Mosor
> --
> http://mail.python.org/mailman/listinfo/p...
>

Karlo Lozovina

3/9/2008 5:08:00 PM

0

Jorge Vargas wrote:

> well after all it's a function so the only ways you can get things out
> of it are:
> - return a dict with all the objects
> - use global (very messy)
> - use a decorator to do either of the above.

Messy, all of those... :(.

> on the other hand have you consider using a proper test package?
> instead of inspecting the objects manually from the shell you could
> make it all automatic. with assert statements. you could use the std.
> python testing modules http://docs.python.org/lib/develo... or
> something less verbosed like nose

Usually, I'm using standard Python testing modules, but sometimes that is
just an overkill. Sometimes I like to do 'exploratory programming',
especially in the early phases of development - create a bunch of objects I
want to play with and do that from IPython. Only way I found out to
somewhat automate this procedure is to have a function that creates all of
the test objects, and then raises an exception at the end. IPython starts
ipdb, so I can work with the objects the function created (without copying
them back to the shell). But this somehow looks too hack-ish for me, so I
was wondering if there was an alternative...

Anyway, thanks for your answer ;).

--
Karlo Lozovina -- Mosor

Jorge Vargas

3/9/2008 5:37:00 PM

0

On Sun, Mar 9, 2008 at 11:07 AM, Karlo Lozovina <_karlo_@mosor.net> wrote:
> Jorge Vargas wrote:
>
> > well after all it's a function so the only ways you can get things out
> > of it are:
> > - return a dict with all the objects
> > - use global (very messy)
> > - use a decorator to do either of the above.
>
> Messy, all of those... :(.
>
>
> > on the other hand have you consider using a proper test package?
> > instead of inspecting the objects manually from the shell you could
> > make it all automatic. with assert statements. you could use the std.
> > python testing modules http://docs.python.org/lib/develo... or
> > something less verbosed like nose
>
> Usually, I'm using standard Python testing modules, but sometimes that is
> just an overkill. Sometimes I like to do 'exploratory programming',
> especially in the early phases of development - create a bunch of objects I
> want to play with and do that from IPython. Only way I found out to
> somewhat automate this procedure is to have a function that creates all of
> the test objects, and then raises an exception at the end. IPython starts
> ipdb, so I can work with the objects the function created (without copying
> them back to the shell). But this somehow looks too hack-ish for me, so I
> was wondering if there was an alternative...
>
ohhh if that is the case then what you are doing seems to be the
optimal. Just have module lvl code ran the testing in fact I don't
even put those into the if __name__, the reason is that this is just
temp testing that will later become real unit testing, and will never
hit a production app. it gives you the most flexibility.
> Anyway, thanks for your answer ;).
>
welcome
>
>
> --
> Karlo Lozovina -- Mosor
> --
> http://mail.python.org/mailman/listinfo/p...
>

Aaron Brady

3/9/2008 11:52:00 PM

0

> >  > well after all it's a function so the only ways you can get things out
> >  > of it are:
> >  > - return a dict with all the objects
> >  > - use global (very messy)
> >  > - use a decorator to do either of the above.
>
> >  Messy, all of those... :(.
>
> >  > on the other hand have you consider using a proper test package?
> >  > instead of inspecting the objects manually from the shell you could
> >  > make it all automatic. with assert statements. you could use the std.
> >  > python testing moduleshttp://docs.python.org/lib/developm...
> >  > something less verbosed like nose
>
> >  Usually, I'm using standard Python testing modules, but sometimes that is
> >  just an overkill. Sometimes I like to do 'exploratory programming',
> >  especially in the early phases of development - create a bunch of objects I
> >  want to play with and do that from IPython. Only way I found out to
> >  somewhat automate this procedure is to have a function that creates all of
> >  the test objects, and then raises an exception at the end. IPython starts
> >  ipdb, so I can work with the objects the function created (without copying
> >  them back to the shell). But this somehow looks too hack-ish for me, so I
> >  was wondering if there was an alternative...
>
> ohhh if that is the case then what you are doing seems to be the
> optimal. Just have module lvl code ran the testing in fact I don't
> even put those into the if __name__, the reason is that this is just
> temp testing that will later become real unit testing, and will never
> hit a production app. it gives you the most flexibility.

While you're at it, can you call up prior source, and edit it? BASIC
had line numbers:

10 def f( a ):
20 return a+ 1

>>> 15 print( a )

10 def f( a ):
15 print( a )
20 return a+ 1

>>> 15 print( a )

10 def f( a ):
15 print( a )
20 return a+ 1

'''Interactives could some day have this too:'''

>>> edit f
Object f opened in editor
>>> close
Object f written back. Elapsed time 5 minutes.
>>>

Gabriel Genellina

3/10/2008 5:08:00 AM

0

On 9 mar, 20:51, castiro...@gmail.com wrote:

> While you're at it, can you call up prior source, and edit it?  BASIC
> had line numbers:
>
> 10 def f( a ):
> 20   return a+ 1
>
> >>> 15 print( a )

Not so easy. The current CPython implementation assumes that once an
object is allocated, it is never moved to another memory location. If
doing that were allowed, all the object references had to be updated,
or another level of indirection would be required, and neither
alternative looks very promising.
The reload function tries to reuse the module object itself, but its
contents are destroyed and recreated. Maybe for some simple changes
like the above the *same* function object could be re-utilized, but
not in the general case.

--
Gabriel Genellina