... 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 _______________________________________________ Edu-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/edu-sig
