shoebot python module, importing module

[Kursad Karatas]

Hi


I have a local vectorlib that I have written. It is neither in the
Python path nor in Env. It resides where the sbot file is. This is the
error I am getting. I assume that sbot does not like local libraries?

Also the wiki page about importing Sbot as a ptyhon module is missing, I
wanted to try as a standard Python app.

$ sbot -w Boids_v001.bot

Traceback (most recent call last):
File "/usr/local/bin/sbot", line 193, in <module>
bot=options.bot)
File "/usr/local/bin/sbot", line 77, in run_window
win = ShoebotWindow(script, server, port, varwindow, go_fullscreen, bot)
File
"/usr/local/lib/python2.6/dist-packages/shoebot/gui/gtk_window.py", line
37, in __init__
self.drawingarea = ShoebotDrawingArea(self, self.bot)
File
"/usr/local/lib/python2.6/dist-packages/shoebot/gui/gtk_drawingarea.py",
line 51, in __init__
self.bot.run()
File "/usr/local/lib/python2.6/dist-packages/shoebot/core/bot.py",
line 356, in run
exec source_or_code in self.namespace
File "shoebot_code", line 1, in <module>
ImportError: No module named VectorLib

thanks

[ricardo lafuente]

Post by Kursad Karatas
Hi
I have a local vectorlib that I have written. It is neither in the
Python path nor in Env. It resides where the sbot file is. This is the
error I am getting. I assume that sbot does not like local libraries?

It should! Do you have the VectorLib.py file where the shoebot script is
located?

Post by Kursad Karatas
Also the wiki page about importing Sbot as a ptyhon module is missing, I
wanted to try as a standard Python app.

you mean this one?
http://wiki.shoebot.net/HOWTO/Python_Module

Post by Kursad Karatas
$ sbot -w Boids_v001.bot
File "/usr/local/bin/sbot", line 193, in<module>
bot=options.bot)
File "/usr/local/bin/sbot", line 77, in run_window
win = ShoebotWindow(script, server, port, varwindow, go_fullscreen, bot)
File
"/usr/local/lib/python2.6/dist-packages/shoebot/gui/gtk_window.py", line
37, in __init__
self.drawingarea = ShoebotDrawingArea(self, self.bot)
File
"/usr/local/lib/python2.6/dist-packages/shoebot/gui/gtk_drawingarea.py",
line 51, in __init__
self.bot.run()
File "/usr/local/lib/python2.6/dist-packages/shoebot/core/bot.py",
line 356, in run
exec source_or_code in self.namespace
File "shoebot_code", line 1, in<module>
ImportError: No module named VectorLib
thanks

[Kursad Karatas]

Post by ricardo lafuente

Post by Kursad Karatas
Hi
I have a local vectorlib that I have written. It is neither in the
Python path nor in Env. It resides where the sbot file is. This is the
error I am getting. I assume that sbot does not like local libraries?

It should! Do you have the VectorLib.py file where the shoebot script
is located?

Post by Kursad Karatas
Also the wiki page about importing Sbot as a ptyhon module is missing, I
wanted to try as a standard Python app.

you mean this one?
http://wiki.shoebot.net/HOWTO/Python_Module

Post by Kursad Karatas
$ sbot -w Boids_v001.bot

Bizarre then. The Vectorlib is in where the sbot file is. I will try
adding to the sytem path for test. if it does not work out I will send
you the lib. It is just a simple .py file

I meant this one.
http://shoebot.net/shoebot/Docs/PythonModule

Thanks for the other link,that would do it.

Btw are there plans to get around multiple "globals" variables
declarations inside setup, draw() etc methods? I understand that it is a
work around but I wonder if there is a more elegant solution?

[ricardo lafuente]

Post by Kursad Karatas
Bizarre then. The Vectorlib is in where the sbot file is. I will try
adding to the sytem path for test. if it does not work out I will send
you the lib. It is just a simple .py file

Odd; anyways, you can add the current path to sys.path in the beginning
of your script and then it should definitely work:

import sys, os
sys.path.append(os.path.abspath('.'))

Post by Kursad Karatas
I meant this one.
http://shoebot.net/shoebot/Docs/PythonModule

This link is outdated -- where did you find it?

Post by Kursad Karatas
Btw are there plans to get around multiple "globals" variables
declarations inside setup, draw() etc methods? I understand that it is a
work around but I wonder if there is a more elegant solution?

You're right, it's quite the hassle when teaching this to newcomers and
want to avoid any nitty-gritty regarding language mechanics.

I kind of like the idea of doing away with the need for global
declarations; on the other hand, we would then begin to drift away from
being "real" Python into a kind of sugar-on-top-of-Python, which i'm not
that sure about...

Maybe running setup() and draw() inside the bot namespace would fix
this? Any ideas?

[Dave Crossland]

we would then begin to drift away from being "real" Python into a kind of
sugar-on-top-of-Python, which i'm not that sure about...

I believe teaching people full python syntax (with this kind of
limitation) is important.

[Stuart Axon]

Sent: Wed, June 23, 2010 11:01:25 AM
Subject: Re: [shoebot-devel] shoebot python module, importing module
On 23 June 2010 10:59, ricardo lafuente <
we would then
begin to drift away from being "real" Python into a kind of
sugar-on-top-of-Python, which i'm not that sure about...

I believe

teaching people full python syntax (with this kind of

limitation) is

important.

+1 This... otherwise we'd introduce an inconsistency: once people
added their own defs they'd hit this.

It might be worth showing this in a tutorial though.

[g***@public.gmane.org]

Post by Dave Crossland

we would then begin to drift away from being "real" Python into a kind of
sugar-on-top-of-Python, which i'm not that sure about...

I believe teaching people full python syntax (with this kind of
limitation) is important.
_______________________________________________
Shoebot-devel mailing list
http://lists.tinkerhouse.net/listinfo.cgi/shoebot-devel-tinkerhouse.net

To me, it depends. As a user I definetely get sick of declaring global
stuff, and I know that using "global" is not encouraged in the Python
community. If the purpose is to teach Python, I definetely agree, it
should stay as it is. If the purpose of SB is to become a visual digital
arts tool, then I would personally like to see solution to this type of
declarations.

[Stuart Axon]

Post by g***@public.gmane.org
To me, it depends. As a user I definetely get sick of
declaring global stuff, and I know that using "global" is not encouraged in the
Python community. If the purpose is to teach Python, I definetely agree,
it should stay as it is. If the purpose of SB is to become a visual digital arts
tool, then I would personally like to see solution to this type of
declarations.

It would have to be for *all* functions, otherwise it would be confusing.

However if it was for all functions you couldn't have variables of the same
name inside the function.


If variables are available to all functions, then the following code will
break (and any python documentation people lookup will not help either):

def drawsomthing():
for a in range(0, 6):
circle(...)


def drawsomethings():
for a in range(0, 2):
drawsomething()


Or you could just make it available for draw() and setup().. But then
you get the inconsistancy I mentioned and the code below won't work
(and python people won't be able to help either)


w, h = 100, 100
def setup():
size(w, h)

def drawsomething():
translate(w/ 2, h / 2)

def draw():
drawsomething()


The problem is, is that we can either:
- Leave things as they are; people will be bitten by it early and learn to use global
- Keep things consistant, but in effect make all variables 'global'
- Only apply this to draw() and setup(), confusing people with bugs when they try and use their own variables.


Maybe instead we could have a 'hints' module that could be used by shoebot editors to check exceptions and output a hint.
So on NameError, if the variable is available in the bot namespace it could hint that you might want to use global in function xxxx to access variable yyyy.

[Kursad Karatas]

Post by Stuart Axon

Post by g***@public.gmane.org
To me, it depends. As a user I definetely get sick of
declaring global stuff, and I know that using "global" is not encouraged in the
Python community. If the purpose is to teach Python, I definetely agree,
it should stay as it is. If the purpose of SB is to become a visual digital arts
tool, then I would personally like to see solution to this type of
declarations.

translate(w/ 2, h / 2)
drawsomething()
- Leave things as they are; people will be bitten by it early and learn to use global
- Keep things consistant, but in effect make all variables 'global'
- Only apply this to draw() and setup(), confusing people with bugs when they try and use their own variables.
Maybe instead we could have a 'hints' module that could be used by shoebot editors to check exceptions and output a hint.
So on NameError, if the variable is available in the bot namespace it could hint that you might want to use global in function xxxx to access variable yyyy.

I personally think that making all variables global would dangerous, and
applying to draw() and setup() makes sense since they hold a special
place in SB.

Is it possible to make variables defined inside the setup() block become
global variables? At least make them accessible by draw() ? It would be
kind of automating it. In general global variable is not a big deal to
me as a user. it only becomes a clutter when things need to be defined
as global multiple times.

I guess the last resort on the user side is to wrap everyhing inside
another custom Class object. But this might create longer codes than
required in many cases, might be overkill to just go around defining
couple of globals.

[Stuart Axon]

You only need to declare them global in setup() if you want to share them,
I think we can just work this into a tutorial if need be?

''' example '''
def setup():
global a
a = 1

def draw():
''' Prints 1'''
print a



S++



----- Original Message ----

Sent: Fri, June 25, 2010 6:11:01 PM
Subject: Re: [shoebot-devel] shoebot python module, importing module

Post by g***@public.gmane.org
To me, it depends. As a user I definetely get

sick of

Post by g***@public.gmane.org
declaring global stuff, and I know that using "global" is

not encouraged in the

Post by g***@public.gmane.org
Python community. If the purpose is to

teach Python, I definetely agree,

Post by g***@public.gmane.org
it should stay as it is. If the

purpose of SB is to become a visual digital arts

Post by g***@public.gmane.org
tool, then I

would personally like to see solution to this type of
declarations.
def
translate(w/ 2, h / 2)
drawsomething()
The
- Leave things as they are; people
will be bitten by it early and learn to use global
- Keep things
consistant, but in effect make all variables 'global'
- Only apply this
to draw() and setup(), confusing people with bugs when they try and use their
own variables.
Maybe instead we could have a 'hints'
module that could be used by shoebot editors to check exceptions and output a
hint.
So on NameError, if the variable is available in the bot namespace
it could hint that you might want to use global in function xxxx to access
variable yyyy.

I personally think that making all variables

global would dangerous, and

applying to draw() and setup() makes sense since

they hold a special

place in SB.

Is it possible to make variables

defined inside the setup() block become

global variables? At least make them

accessible by draw() ? It would be

kind of automating it. In general global

variable is not a big deal to

me as a user. it only becomes a clutter when

things need to be defined

as global multiple times.

I guess the last

resort on the user side is to wrap everyhing inside

another custom Class

object. But this might create longer codes than

required in many cases, might

be overkill to just go around defining

couple of globals.
--
Kursad

Karatas

http://portfolio.plecxus.com/

_______________________________________________
Shoebot-devel

mailing list

http://lists.tinkerhouse.net/listinfo.cgi/shoebot-devel-tinkerhouse.net