shoebot python module, importing module

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

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



--
Kursad Karatas
http://portfolio.plecxus.com/

_______________________________________________
Shoebot-devel mailing list
[hidden email]
http://lists.tinkerhouse.net/listinfo.cgi/shoebot-devel-tinkerhouse.net
Reply | Threaded
Open this post in threaded view
|

Re: shoebot python module, importing module

ricardo lafuente
On 06/22/2010 08:31 PM, Kursad Karatas wrote:
> 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?

> 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

>
> $ 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
>
>
>

_______________________________________________
Shoebot-devel mailing list
[hidden email]
http://lists.tinkerhouse.net/listinfo.cgi/shoebot-devel-tinkerhouse.net
Reply | Threaded
Open this post in threaded view
|

Re: shoebot python module, importing module

Kursad Karatas
On 6/22/2010 6:08 PM, ricardo lafuente wrote:

> On 06/22/2010 08:31 PM, Kursad Karatas wrote:
>> 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?
>
>> 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
>
>>
>> $ 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?


_______________________________________________
Shoebot-devel mailing list
[hidden email]
http://lists.tinkerhouse.net/listinfo.cgi/shoebot-devel-tinkerhouse.net
Reply | Threaded
Open this post in threaded view
|

Re: shoebot python module, importing module

ricardo lafuente
On 06/23/2010 02:18 AM, Kursad Karatas wrote:
> 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('.'))

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

This link is outdated -- where did you find 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?

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?
_______________________________________________
Shoebot-devel mailing list
[hidden email]
http://lists.tinkerhouse.net/listinfo.cgi/shoebot-devel-tinkerhouse.net
Reply | Threaded
Open this post in threaded view
|

Re: shoebot python module, importing module

Dave Crossland
Administrator
On 23 June 2010 10:59, ricardo lafuente <[hidden email]> wrote:
> 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
[hidden email]
http://lists.tinkerhouse.net/listinfo.cgi/shoebot-devel-tinkerhouse.net
Reply | Threaded
Open this post in threaded view
|

Re: shoebot python module, importing module

Stuart Axon
> From: Dave Crossland <[hidden email]>

> To: [hidden email]
> 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 <
> href="mailto:[hidden email]">[hidden email]> wrote:
> 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.



     
_______________________________________________
Shoebot-devel mailing list
[hidden email]
http://lists.tinkerhouse.net/listinfo.cgi/shoebot-devel-tinkerhouse.net
Reply | Threaded
Open this post in threaded view
|

Re: shoebot python module, importing module

Kursad Karatas
In reply to this post by Dave Crossland
On 06/23/2010 05:01 AM, Dave Crossland wrote:

> On 23 June 2010 10:59, ricardo lafuente<[hidden email]>  wrote:
>    
>> 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
> [hidden email]
> 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.


_______________________________________________
Shoebot-devel mailing list
[hidden email]
http://lists.tinkerhouse.net/listinfo.cgi/shoebot-devel-tinkerhouse.net
Reply | Threaded
Open this post in threaded view
|

Re: shoebot python module, importing module

Stuart Axon


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


     
_______________________________________________
Shoebot-devel mailing list
[hidden email]
http://lists.tinkerhouse.net/listinfo.cgi/shoebot-devel-tinkerhouse.net
Reply | Threaded
Open this post in threaded view
|

Re: shoebot python module, importing module

Kursad Karatas
On 6/25/2010 6:14 AM, Stuart Axon wrote:

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


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
[hidden email]
http://lists.tinkerhouse.net/listinfo.cgi/shoebot-devel-tinkerhouse.net
Reply | Threaded
Open this post in threaded view
|

Re: shoebot python module, importing module

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 ----

> From: Kursad Karatas <[hidden email]>
> To: [hidden email]
> Sent: Fri, June 25, 2010 6:11:01 PM
> Subject: Re: [shoebot-devel] shoebot python module, importing module
>
> On 6/25/2010 6:14 AM, Stuart Axon wrote:
>
>  
>
>>  
>> 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.
>>
>>
>>    
> 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.
>
>
>      
>
>
>  


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

> href="mailto:[hidden email]">[hidden email]
http://lists.tinkerhouse.net/listinfo.cgi/shoebot-devel-tinkerhouse.net


     
_______________________________________________
Shoebot-devel mailing list
[hidden email]
http://lists.tinkerhouse.net/listinfo.cgi/shoebot-devel-tinkerhouse.net