[Edu-sig] Visual Programming in Python?

[Jeff Sandys]

...
Ian Bicking wrote:
> As to the merits of Logo as a language and Python as a language, 
> I'm not sure.  Logo is grammatically simpler.  Generally it is 
> more insulated from the underlying implementation.  It isn't 
> burdened with ideas like "good software engineering".

I will respectively disagree with your comments, but arguements 
about these points would be counterproductive.

>Jeff Sandys wrote:
>> What I would like to see in a turtle environment comes from 
>> StarLogo ( http://education.mit.edu/starlogo/ ).  StarLogo has 
>> multiple turtles, the turtles can inherit methods to make new 
>> turtle classes, and the background also has methods for its cells, 
>> implementing Conway's Life only takes several lines.  ...
>> 
>> I think that creating a StarPython, with Python syntax, would be 
>> ... valuable ...
>
> That's hard, or maybe easy.
>
> With CPython, something like StarPython is hard. The kind of 
> concurrency it does isn't practical with OS threads.  Maybe with 
> Greenlets, though I must admit I don't understand them.
> ...

Why?  StarLogo is written in Java, I do not believe that it is 
threaded.  Threads would be nice but I don't think they are 
necessary to create StarLogo functionality in Python.

>> Python would be easier to teach if it had clearer error messages. 
>> ...
>
> Error messages are indeed hard.  It's easier when you have a 
> clear idea of system and user code.  In a typical Logo 
> implementation where the library is implemented in a language 
> other than Logo, it's easy to tell what is inside and outside -- 
> everything in Logo belongs to the programmer, everything not in 
> Logo belongs to the system.  In Python it is not so easy, 
> especially because errors often bubble up from deep in system 
> code, and you actually have to inspect the system code to 
> understand what it means in the context of your code.  As an 
> example, 
>
> shutil(None, 'tmp'):
>
> Traceback (most recent call last):
>    File "<stdin>", line 1, in ?
>    File "/usr/lib/python2.4/shutil.py", line 81, in copy
>      copyfile(src, dst)
>    File "/usr/lib/python2.4/shutil.py", line 41, in copyfile
>      if _samefile(src, dst):
>    File "/usr/lib/python2.4/shutil.py", line 31, in _samefile
>      return os.path.samefile(src, dst)
>    File "/usr/lib/python2.4/posixpath.py", line 218, in samefile
>      s1 = os.stat(f1)
> TypeError: coercing to Unicode: need string or buffer, NoneType found
> 
> Sigh.  It's not like hiding that traceback can make that error 
> more understandable.  I really don't know how to resolve that.
> 
> Though it definitely is possible to trim exceptions down.  For 
> instance, not to show code that is part of the standard library 
> (or at least filter that out unless explicitly expanded).  That 
> won't make the exception make sense (coerce to Unicode?! talk 
> about obscure), but at least it will better highlight the 
> problem code.

How would you attack this problem to get a Logo like error message,
"shutil didn't like None as an input"?  I would be interested in
contributing to an errors for beginners project.

Thanks -- Jeff Sandys

 



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com