Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Supported by

[solved] Python inline scripts: Global functions

edited July 2015 in OpenSesame

Is it possible to declare, say, a function or a class (or an instantiation thereof) -- or indeed any kind of Python variable -- at the beginning of an experiment that then persists for the duration? That is, rather than redeclaring the function/whatever every time you need to use it.

Say I have this theoretical inline script near the beginning of my experiment:

def myCustomFunction(foo):
  print foo

class myClass(object):
  # definitions...

Can I then refer to myCustomFunction or myClass in subsequent inline scripts? If so, are there any OpenSesame "best practices" to follow regarding namespacing (insofar as Python allows)?

Thanks,

C

Comments

  • edited July 2015

    I think I've answered this myself. (Apologies for the asynchrony: I'm not able to experiment with OpenSesame while at work!)

    If you define functions or classes (or whatever) in the prepare section of an inline script item, they will still be in scope in subsequent inline script items (for both their prepare and run phases).

    This is pretty handy, but it does mean introducing global state, which is a bit of an engineering faux pas! One could namespace custom functions using the @staticmethod decorator to get around that:

    class myMethods(object):
      @staticmethod
      def doSomethingCool():
        # something cool
    

    Then use in subsequent inline scripts as myMethods.doSomethingCool() (without having to instantiate an object).

    Alternatively, you could create a module in your file pool and import it:

    import imp
    myModule = imp.load_source('myModule', exp.get_file('myModuleSource.py'))
    

    Hopefully this will be useful to others :)

  • edited 10:44AM

    Thanks for sharing!

    If you define functions or classes (or whatever) in the prepare section of an inline script item, they will still be in scope in subsequent inline script items (for both their prepare and run phases).

    Yes indeed. All inline_script items use the same Python workspace, or, in Python speak, they share a globals dict.

    This is pretty handy, but it does mean introducing global state, which is a bit of an engineering faux pas! One could namespace custom functions using the @staticmethod decorator to get around that.

    That works, but it's purely aesthetics. But I agree that for complex experiments it can make sense to use this kind of conceptual (but non-functional) modularization.

    Alternatively, you could create a module in your file pool and import it.

    That might actually make a nice plug-in ... I can see how this would come in handy for many people.

    Cheers!
    Sebastiaan

Sign In or Register to comment.