Hello everyone.

On Monday, April 4th at 18:00, the Jerusalem Linux Club will gather to hear a talk about GarlicSim given by its creator, Ram Rachum. The talk will be held in the computer farm at Shprinzak, classroom 1, in the Givat Ram campus.

(Apologies for whoever already got this message from another source.)

## The lecture ##

GarlicSim is a Pythonic framework for computer simulations. More info about it can be found here:

http://garlicsim.org/

GarlicSim is a platform for writing, running and analyzing simulations. It is general enough to handle simulations from many fields: Physics, game theory, epidemic spread, electronics, etc. GarlicSim's goal is to let people build and run simulations with as little technical work as possible.

We're going to see a few cool simulations and speak about what simulations from different fields have in common with each other. Ram will talk about the goals and the design of GarlicSim, and his plans for the project's future.

Slides:

http://garlicsim.org/presentation.pdf

Attendance is free and everyone is invited.

Hello folks,

I want to let people who write GarlicSim simpacks write an `__init__.py` module like this:

    '''

    This is the simpack's docstring.

    

    Bla bla bla.

    '''

    

    name = 'Name of the simpack'

    

    tags = ['list', 'of', 'simpack-tags']

    

    __version__ = '0.9.3'

And I want GarlicSim to be able to get all of these things: The docstring, the name, the tags and the version. And I want to show them in this widget. But I want to do it without importing the module, because `__init__.py` might import the entire package which can be heavy. (I want to do this process for many heavy simpacks.)

We can assume that the user doesn't do anything computationally trickier then a simple literal assignment.

I heard that the `ast` module does things like this. But, I also want to be able to do this process on compiled files, e.g. `__init__.pyc` or `__init__.pyo`, and I don't know how to do this with the `ast` module.

Can the `ast` module do this on both source and compiled files? How is it done? Otherwise, is there a more fitting tool than `ast`?

(By the way, if anyone cares, I have recently open-sourced GarlicSim's GUI, so now GarlicSim is completely open-source.)

Thanks,

Ram.

Hello folks,

I want to let people who write GarlicSim simpacks write an `__init__.py` module like this:

    '''

    This is the simpack's docstring.

    

    Bla bla bla.

    '''

    

    name = 'Name of the simpack'

    

    tags = ['list', 'of', 'simpack-tags']

    

    __version__ = '0.9.3'

And I want GarlicSim to be able to get all of these things: The docstring, the name, the tags and the version. And I want to show them in this widget. But I want to do it without importing the module, because `__init__.py` might import the entire package which can be heavy. (I want to do this process for many heavy simpacks.)

We can assume that the user doesn't do anything computationally trickier then a simple literal assignment.

I heard that the `ast` module does things like this. But, I also want to be able to do this process on compiled files, e.g. `__init__.pyc` or `__init__.pyo`, and I don't know how to do this with the `ast` module.

cool-RR wrote:

Hello folks,

I want to let people who write GarlicSim simpacks write an `__init__.py` module like this:

    '''

    This is the simpack's docstring.

    

    Bla bla bla.

    '''

    

    name = 'Name of the simpack'

    

    tags = ['list', 'of', 'simpack-tags']

    

    __version__ = '0.9.3'

And I want GarlicSim to be able to get all of these things: The docstring, the name, the tags and the version. And I want to show them in this widget. But I want to do it without importing the module, because `__init__.py` might import the entire package which can be heavy. (I want to do this process for many heavy simpacks.)

We can assume that the user doesn't do anything computationally trickier then a simple literal assignment.

I heard that the `ast` module does things like this. But, I also want to be able to do this process on compiled files, e.g. `__init__.pyc` or `__init__.pyo`, and I don't know how to do this with the `ast` module.

Why on earth would you want to do this on .pyc or .pyo files? Do you want to support source-less simpacks?

If you can ensure that __init__.py is available, you can pick the lines from the file which include the doc-string and assignments quite easily, and execute them in a dummy environment to get the values. You can fall back to importing the package if this fails.

Mangling __import__ temporarily might work, sounds like a hack I would prefer to avoid. And theoretically __init__.py can include other heavy code. And you could break stuff if __init__.py assumes that the imports work in a way that returning a mock object breaks.

Do you have a really good reason not to make the writer of a simpack responsible for making __init__.py quick to import? Then you can optimize only if a real need arises.

Mangling __import__ temporarily might work, sounds like a hack I would prefer to avoid. And theoretically __init__.py can include other heavy code. And you could break stuff if __init__.py assumes that the imports work in a way that returning a mock object breaks.

Definitely not pretty. But can you come up with an example of how it would be broken? I think most such examples would be pretty contrived and not something that's likely to be written in real life.

Do you have a really good reason not to make the writer of a simpack responsible for making __init__.py quick to import? Then you can optimize only if a real need arises.

I personally believe that `__init__.py` should import important stuff from the package, and not only in simpacks but in general in Python packages.

Mangling __import__ temporarily might work, sounds like a hack I would prefer to avoid. And theoretically __init__.py can include other heavy code. And you could break stuff if __init__.py assumes that the imports work in a way that returning a mock object breaks.

Definitely not pretty. But can you come up with an example of how it would be broken? I think most such examples would be pretty contrived and not something that's likely to be written in real life.

Even something as simple as this would break (if not in the import statement, then later):
from some_package.some_module import some_thing

Do you have a really good reason not to make the writer of a simpack responsible for making __init__.py quick to import? Then you can optimize only if a real need arises.

I personally believe that `__init__.py` should import important stuff from the package, and not only in simpacks but in general in Python packages.

Then perhaps such metadata shouldn't be kept in __init__.py in the first place? 

- Tal

On Sat, Apr 16, 2011 at 8:40 AM, Tal Einat <taleinat <at> gmail.com> wrote:

Then perhaps such metadata shouldn't be kept in __init__.py in the first place? 

That would definitely be an easy solution: Tell simpack writers to have a file "metadata.txt" or whatever. But I find it less elegant. I believe that almost every Python package (or module or function or class) should have a docstring, so if I'll have to maintain the simpack description in both places (docstring and "metadata.txt"), I'll be breaking DRY.

Also, people who are not experienced with distutils may have to spend some "quality time" with it to make it package the "metadata.txt" file with their code. As Guido said, "I'd like not to have such a newbie trap lying around."

On Sat, Apr 16, 2011 at 4:37 PM, cool-RR <cool-rr <at> cool-rr.com> wrote:

On Sat, Apr 16, 2011 at 8:40 AM, Tal Einat <taleinat <at> gmail.com> wrote:

Then perhaps such metadata shouldn't be kept in __init__.py in the first place? 

That would definitely be an easy solution: Tell simpack writers to have a file "metadata.txt" or whatever. But I find it less elegant. I believe that almost every Python package (or module or function or class) should have a docstring, so if I'll have to maintain the simpack description in both places (docstring and "metadata.txt"), I'll be breaking DRY.

Also, people who are not experienced with distutils may have to spend some "quality time" with it to make it package the "metadata.txt" file with their code. As Guido said, "I'd like not to have such a newbie trap lying around."

Then perhaps have them write the metadata in a metadata.py file, and execfile it in __init__.py? Then you can just execfile the metadata.py file if you want just the metadata.

- Tal