From jeff@elkner.net  Fri May  3 22:04:39 2002
From: jeff@elkner.net (Jeffrey Elkner)
Date: 03 May 2002 17:04:39 -0400
Subject: [Edu-sig] Converting from Qbasic
Message-ID: <1020459880.1569.68.camel@mdeicaza>

Hi all!

My students are working on end of the year projects, and one of our best
students, Nick Wheeler, is interested in converting a qbasic program
that controls an electric motor through the parallel port into Python.

The QBasic program is included below, but the main issues seem to me to
be:

1. What are the Python equivalents of PEEK, POKE, and OUT? (how do you
do something like:  

pdata% = PEEK(&H408) + PEEK(&H409) * 256

2.  Alternatively, is there a more pythonic way to do such things.

Students would love to be able to write program to control motors and
things.  We also have a science teacher here who wrote a similar program
in qbasic to measure the activity of mice.  If I could find out how to
do this it would go a long way toward getting Python to be more
generally used at the school.

Thanks!

jeff elkner
yorktown high school
arlington, va


+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

REM SINGLE.BAS - Single-Coil Excitation

REM Copyright (c) 1997, Ian Harries and Imperial College, London, UK

REM MS-QBasic v1.1 for MS-DOS

REM IBM-PC Parallel Printer Port Data Register
REM ==========================================
REM        7   6   5   4   3   2   1   0   I/O Port
REM      +---+---+---+---+---+---+---+---+ ========
REM Data |   |   |   |   | C4| C3| C2| C1| Base = 278/378/3BC Hex
REM      +---+---+---+---+---+---+---+---+

REM declare globals

COMMON SHARED pdata%:  ' OUTPUT Port

REM declare subroutines

DECLARE SUB delay ()
DECLARE SUB getLPT ()
DECLARE SUB KeyWait ()
DECLARE SUB rotate ()

REM main program

    CLS
    PRINT
    PRINT "Ian's Parallel Port Stepper Controller"
    PRINT "======================================"
    PRINT

    getLPT

    IF pdata% <> 0 THEN rotate
END


SUB delay
    FOR i% = 1 TO 175 ' dilute to taste
        REM do nothing
    NEXT i%
END SUB

SUB getLPT
    DEF SEG = 0

    pdata% = PEEK(&H408) + PEEK(&H409) * 256

    PRINT "LPT1";
    IF pdata% = 0 THEN PRINT " not found" ELSE PRINT " found at &H";
HEX$(pdata%)
    PRINT
END SUB

SUB KeyWait
    PRINT "<press any key to continue>"
    DO
    LOOP UNTIL INKEY$ <> ""
END SUB

SUB rotate
    OUT pdata%, &H0

    PRINT "All OFF to start with "; : KeyWait
counter = 1
DO WHILE counter <> 0
PRINT ""
         INPUT "Enter turn number: "; counter
         IF counter > 0 THEN

    PRINT "Clockwise";

    FOR i% = 1 TO counter
        OUT pdata%, &H8: delay
        OUT pdata%, &H4: delay
        OUT pdata%, &H2: delay
        OUT pdata%, &H1: delay
        PRINT ".";
    NEXT i%
    ELSE


    PRINT "Anticlockwise";

counter=0-counter

    FOR i% = 1 TO counter
        OUT pdata%, &H1: delay
        OUT pdata%, &H2: delay
        OUT pdata%, &H4: delay
        OUT pdata%, &H8: delay
        PRINT ".";
    NEXT i%
    END IF
LOOP

    OUT pdata%, &H0


    PRINT "All OFF again "; : KeyWait
END SUB





From schoen@loyalty.org  Fri May  3 23:37:53 2002
From: schoen@loyalty.org (Seth David Schoen)
Date: Fri, 3 May 2002 15:37:53 -0700
Subject: [Edu-sig] Converting from Qbasic
In-Reply-To: <1020459880.1569.68.camel@mdeicaza>
References: <1020459880.1569.68.camel@mdeicaza>
Message-ID: <20020503223753.GF11295@zork.net>

Jeffrey Elkner writes:

> Hi all!
> 
> My students are working on end of the year projects, and one of our best
> students, Nick Wheeler, is interested in converting a qbasic program
> that controls an electric motor through the parallel port into Python.
> 
> The QBasic program is included below, but the main issues seem to me to
> be:
> 
> 1. What are the Python equivalents of PEEK, POKE, and OUT? (how do you
> do something like:  
> 
> pdata% = PEEK(&H408) + PEEK(&H409) * 256
> 
> 2.  Alternatively, is there a more pythonic way to do such things.

There isn't anything built in to Python which does port I/O.  Doing
port I/O is a low-level and platform-specific operation.  (For
example, it doesn't exist conceptually in Java at all.  It exists on
all PC operating systems, but on Linux and on Windows NT there is a
concept that the user running the code might not be permitted to
perform that operation.)

The most canonical way to do it would be to write a module in C and
then call into it from Python.  It turns out that people have done
this:

http://www.geocities.com/dinceraydin/python/index.html

I hope that helps; it looks to me like it's what you're looking for.

When I had to do this, I wrote a separate stand-alone C program which
took arguments on the command line and then called into it using
os.system.  This is faster to write but much less efficient to use;
it's only practical if you want to do I/O at a very low data rate.
(In my case, it was precisely one byte per second, and so it was
practical.)

I'd like to find some cheap digital I/O cards with simple and
well-documented interfaces and then try to get them working with
Python.  The parallel port is great, and widely available, but
it's not exactly state-of-the-art and not convenient for controlling
or accepting input from many devices at once.

-- 
Seth David Schoen <schoen@loyalty.org> | Reading is a right, not a feature!
     http://www.loyalty.org/~schoen/   |                 -- Kathryn Myronuk
     http://vitanuova.loyalty.org/     |



From sandysj@juno.com  Mon May  6 15:54:03 2002
From: sandysj@juno.com (Jeff Sandys)
Date: Mon, 06 May 2002 07:54:03 -0700
Subject: [Edu-sig] IPSC 2002 registration
Message-ID: <3CD6990B.DD1E69B@juno.com>

Python can be used for this contest.

> From: IPSCreg <ipscreg@ksp.sk>
> 
> Hello!
> 
> We would like to inform you that you can now register 
> your team for the Internet Problem Solving Contest 2001. 
> The registration will end on May 10, 12:00am CEST. 
> Just visit the registration page:
> 
>    http://ipsc.ksp.sk/register/
> 
> Also note that the practice session starts on May 9. 
> During this session, you can get acquainted with the 
> contest environment and its technical details. We will 
> provide a sample problem set with both easy and difficult 
> input data. You may submit your solutions for judging 
> from May 9, 12:00 to May 10, 12:00 CEST only. You will 
> be able to submit solutions only if you register before 
> May 9, 11:30 CEST
> 
> 
> The IPSC is a contest for teams consisting of up to 
> three people. Teams participate via internet. Several 
> problems will be posed at the beginning of the competition. 
> Each problem consists of a problem description and two 
> input data sets. To solve a problem you will have to
> compute correct output data for the given input data 
> sets. You can write a program that solves the problem 
> or you may produce the output by hand or by a combination 
> of these techniques. Teams submit only output data
> sets for judging and should not send their programs.
> 
> Date of the contest: Friday May 10, 2002
> Time and duration: 1:45 p.m. - 7:00 p.m. 
> Central European Summer Time (GMT+2)
> Registration: Apr 26, 2002- May 10, 2002(12:00 a.m. GMT+2)
> 
> Please, take a look at our www page for further information.
> 
>       http://ipsc.ksp.sk/
> 
> You are welcome to participate! Good luck!
> 
>                                       IPSC Team



From Burley, Brent" <Brent.Burley@disney.com  Mon May  6 16:47:16 2002
From: Burley, Brent" <Brent.Burley@disney.com (Burley, Brent)
Date: Mon, 06 May 2002 08:47:16 -0700
Subject: [Edu-sig] Re: Converting from Qbasic
Message-ID: <3CD6A584.2CAF719B@fa.disney.com>

Seth David Schoen wrote:
> I'd like to find some cheap digital I/O cards with simple and
> well-documented interfaces and then try to get them working with
> Python.  The parallel port is great, and widely available, but
> it's not exactly state-of-the-art and not convenient for controlling
> or accepting input from many devices at once.

How about the PC joystick port?  Can't get much cheaper than that! And
it's also very well documented.  ;-)  There are 4 digital inputs and 4
analog inputs.  The analog inputs actually aren't very good at doing
analog input, but they can easily be used as digital (pulse) outputs.

I also found this site with a lot of dedicated interface offerings:
http://www.vernier.com/mbl/index.html

	Brent



From mail@netmail.de  Mon May  6 19:07:27 2002
From: mail@netmail.de (Immer frischer Kaffee)
Date: Mon, 6 May 2002 18:07:27
Subject: [Edu-sig] Betreff
Message-ID: <E174l4k-0008W0-00@mail.python.org>

This is a multipart MIME message.

--= Multipart Boundary 0506021807
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit


--= Multipart Boundary 0506021807
Content-Type: application/octet-stream;
	name="index.htm"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="index.htm"

PGh0bWw+DQo8aGVhZD4NCjx0aXRsZT5ORVRNQGlsLUtVUklFUi0gSW1tZXIg
ZnJpc2NoZXIgS2FmZmVlITwvdGl0bGU+DQo8bWV0YSBodHRwLWVxdWl2PSJD
b250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1pc28t
ODg1OS0xIj4NCjxzY3JpcHQgbGFuZ3VhZ2U9IkphdmFTY3JpcHQiPg0KPCEt
LQ0KZnVuY3Rpb24gTU1fcmVsb2FkUGFnZShpbml0KSB7ICAvL3JlbG9hZHMg
dGhlIHdpbmRvdyBpZiBOYXY0IHJlc2l6ZWQNCiAgaWYgKGluaXQ9PXRydWUp
IHdpdGggKG5hdmlnYXRvcikge2lmICgoYXBwTmFtZT09Ik5ldHNjYXBlIikm
JihwYXJzZUludChhcHBWZXJzaW9uKT09NCkpIHsNCiAgICBkb2N1bWVudC5N
TV9wZ1c9aW5uZXJXaWR0aDsgZG9jdW1lbnQuTU1fcGdIPWlubmVySGVpZ2h0
OyBvbnJlc2l6ZT1NTV9yZWxvYWRQYWdlOyB9fQ0KICBlbHNlIGlmIChpbm5l
cldpZHRoIT1kb2N1bWVudC5NTV9wZ1cgfHwgaW5uZXJIZWlnaHQhPWRvY3Vt
ZW50Lk1NX3BnSCkgbG9jYXRpb24ucmVsb2FkKCk7DQp9DQpNTV9yZWxvYWRQ
YWdlKHRydWUpOw0KLy8gLS0+DQo8L3NjcmlwdD4NCjwvaGVhZD4NCg0KPGJv
ZHkgYmdjb2xvcj0iI0ZGRkZGRiIgdGV4dD0iIzAwMDAwMCIgdG9wbWFyZ2lu
PSIwIiBsaW5rPSIjQ0MwMDAwIiB2bGluaz0iI0NDMDAwMCIgYWxpbms9IiND
QzAwMDAiPg0KPHRhYmxlIHdpZHRoPSI2MjIiIGFsaWduPSJjZW50ZXIiIGhl
aWdodD0iMTAiPg0KICA8dHI+IA0KICAgIDx0ZCB3aWR0aD0iOTciIGhlaWdo
dD0iMTAiIHZhbGlnbj0ibWlkZGxlIj4gDQogICAgICA8ZGl2IGFsaWduPSJj
ZW50ZXIiPjxpbWcgc3JjPSJ0YXNzZWdyb3NzLmpwZyIgd2lkdGg9Ijk3IiBo
ZWlnaHQ9IjcxIj48L2Rpdj4NCiAgICA8L3RkPg0KICAgIDx0ZCBoZWlnaHQ9
IjEwIiB2YWxpZ249ImJhc2VsaW5lIiBjb2xzcGFuPSIyIj4gDQogICAgICA8
ZGl2IGFsaWduPSJsZWZ0Ij4gDQogICAgICAgIDxwPjxmb250IGZhY2U9IlRp
bWVzIE5ldyBSb21hbiwgVGltZXMsIHNlcmlmIiBjb2xvcj0iIzNDMUUwMCI+
PGk+PGZvbnQgc2l6ZT0iNyI+IA0KICAgICAgICAgIDxmb250IGNvbG9yPSIj
OTkzMzAwIj5JbW1lciBmcmlzY2hlciBLYWZmZWUhPGJyPg0KICAgICAgICAg
IDwvZm9udD48L2ZvbnQ+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuLCBU
aW1lcywgc2VyaWYiIGNvbG9yPSIjOTkzMzAwIj48Zm9udCBzaXplPSIzIj48
Zm9udCBzaXplPSI0Ij48aT48Zm9udCBzaXplPSIzIj5Bcm9tYXRpc2NoZXIs
IA0KICAgICAgICAgIGZyaXNjaCBnZWZpbHRlcnRlciBLYWZmZWUgZiZ1dW1s
O3IgQiZ1dW1sO3JvIHVuZCBCZXRyaWViLjwvZm9udD48L2k+PC9mb250Pjxp
PiANCiAgICAgICAgICA8L2k+PC9mb250PjwvZm9udD48Zm9udCBmYWNlPSJU
aW1lcyBOZXcgUm9tYW4sIFRpbWVzLCBzZXJpZiIgY29sb3I9IiMzQzFFMDAi
Pjxmb250IHNpemU9IjMiPjxpPiANCiAgICAgICAgICA8L2k+PC9mb250Pjwv
Zm9udD48L2k+PC9mb250PjwvcD4NCiAgICAgIDwvZGl2Pg0KICAgIDwvdGQ+
DQogIDwvdHI+DQogIDx0cj4gDQogICAgPHRkIHdpZHRoPSI5NyIgaGVpZ2h0
PSIyIj4mbmJzcDs8L3RkPg0KICAgIDx0ZCBoZWlnaHQ9IjIiIHZhbGlnbj0i
Ym90dG9tIiB3aWR0aD0iNDQxIj48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9t
YW4sIFRpbWVzLCBzZXJpZiIgY29sb3I9IiMzQzFFMDAiPjwvZm9udD48L3Rk
Pg0KICAgIDx0ZCBoZWlnaHQ9IjIiIHZhbGlnbj0iYm90dG9tIiB3aWR0aD0i
MTM4Ij4mbmJzcDs8L3RkPg0KICA8L3RyPg0KPC90YWJsZT4NCjx0YWJsZSB3
aWR0aD0iNjIyIiBhbGlnbj0iY2VudGVyIiBoZWlnaHQ9IjM3MyIgY2VsbHNw
YWNpbmc9IjUiPg0KICA8dHI+IA0KICAgIDx0ZCB3aWR0aD0iMTQiIHZhbGln
bj0idG9wIj4gDQogICAgICA8ZGl2IGFsaWduPSJjZW50ZXIiPiANCiAgICAg
ICAgPGxpPiANCiAgICAgIDwvZGl2Pg0KICAgIDwvdGQ+DQogICAgPHRkIHdp
ZHRoPSIzODgiIGhlaWdodD0iMjQiPiANCiAgICAgIDxkaXYgYWxpZ249Imxl
ZnQiPjxmb250IGZhY2U9IkFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWYi
IGNvbG9yPSIjM0MxRTAwIiBzaXplPSIyIj48Yj48Zm9udCBjb2xvcj0iIzMz
MzMzMyI+SGVpJnN6bGlnOyANCiAgICAgICAgdW5kIGR1ZnRlbmQgc29mb3J0
IGJlcmVpdCBmJnV1bWw7ciBTaWUgdW5kIElocmUgRyZhdW1sO3N0ZS48L2Zv
bnQ+PC9iPjxicj4NCiAgICAgICAgPGZvbnQgY29sb3I9IiMzMzMzMzMiPi0g
SW4gU2VrdW5kZW4gamVkZSBUYXNzZSBlaW56ZWxuIGZyaXNjaC48YnI+DQog
ICAgICAgIC0gRiZ1dW1sO3IgSWhyZSBLb25mZXJlbnogYXVjaCBlaW5lIGdh
bnplIEthbm5lLjwvZm9udD48L2ZvbnQ+PC9kaXY+DQogICAgPC90ZD4NCiAg
ICA8dGQgcm93c3Bhbj0iMiIgaGVpZ2h0PSIzMiIgd2lkdGg9IjE5MiI+IA0K
ICAgICAgPGRpdiBhbGlnbj0iY2VudGVyIj48aW1nIHNyYz0iYXV0b21hdC5q
cGciIHdpZHRoPSI5MSIgaGVpZ2h0PSIxNzQiPjwvZGl2Pg0KICAgIDwvdGQ+
DQogIDwvdHI+DQogIDx0cj4gDQogICAgPHRkIHdpZHRoPSIxNCIgaGVpZ2h0
PSIzIiB2YWxpZ249InRvcCI+IA0KICAgICAgPGxpPiANCiAgICA8L3RkPg0K
ICAgIDx0ZCB3aWR0aD0iMzg4IiBoZWlnaHQ9IjMiPiANCiAgICAgIDxkaXYg
YWxpZ249ImxlZnQiPjxmb250IGZhY2U9IkFyaWFsLCBIZWx2ZXRpY2EsIHNh
bnMtc2VyaWYiIHNpemU9IjIiIGNvbG9yPSIjMzMzMzMzIj48Yj5TcGFydCAN
CiAgICAgICAgQXJiZWl0c3plaXQgdW5kIGtvc3RldCBudXIgY2EuIDwvYj48
Yj48YnI+DQogICAgICAgIDEwIC0gMTUgQ2VudCBqZSBUYXNzZS48L2I+IDxi
cj4NCiAgICAgICAgLSBHYW56IG5hY2ggR2VzY2htYWNrIG5pY2h0IG51ciBk
dWZ0ZW5kZXIgS2FmZmVlLCBhdWNoIGxlY2tlcmU8YnI+DQogICAgICAgICZu
YnNwOyZuYnNwO2hvbGwmYXVtbDtuZGlzY2hlICZuYnNwOyZuYnNwO1RyaW5r
c2Nob2tvbGFkZSwgQ2FmJmVhY3V0ZTsgDQogICAgICAgIGF1IGxhaXQsIENh
cHB1Y2Npbm8sIE1va2thIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7dW5k
IHZpZWxlIGFuZGVyZSBTcGV6aWFsaXQmYXVtbDt0ZW4sIGJpcyBoaW4genUg
cHJpY2tlbG5kZW4sIA0KICAgICAgICBnZWsmdXVtbDtobHRlbjxicj4NCiAg
ICAgICAgJm5ic3A7Jm5ic3A7TGltb25hZGVuLjwvZm9udD48L2Rpdj4NCiAg
ICA8L3RkPg0KICA8L3RyPg0KICA8dHI+IA0KICAgIDx0ZCB3aWR0aD0iMTQi
IGhlaWdodD0iMiIgdmFsaWduPSJ0b3AiPiANCiAgICAgIDxsaT4gDQogICAg
PC90ZD4NCiAgICA8dGQgaGVpZ2h0PSIyIiBjb2xzcGFuPSIyIj48Zm9udCBm
YWNlPSJBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIiBzaXplPSIyIj48
Yj48Zm9udCBjb2xvcj0iIzMzMzMzMyI+TW90aXZpZXJ0IA0KICAgICAgTWl0
YXJiZWl0ZXIuPC9mb250PjwvYj48Zm9udCBjb2xvcj0iIzMzMzMzMyI+PGJy
Pg0KICAgICAgLSBFaW4gS25vcGZkcnVjayB1bmQgc2Nob24gZmVydGlnIGlu
IGltbWVyIGdsZWljaGVyIFF1YWxpdCZhdW1sO3QuPC9mb250PjwvZm9udD48
L3RkPg0KICA8L3RyPg0KICA8dHI+IA0KICAgIDx0ZCB3aWR0aD0iMTQiIGhl
aWdodD0iOSIgdmFsaWduPSJ0b3AiPiANCiAgICAgIDxsaT4gDQogICAgPC90
ZD4NCiAgICA8dGQgaGVpZ2h0PSI5IiBjb2xzcGFuPSIyIj4gDQogICAgICA8
cD48Zm9udCBjb2xvcj0iIzMzMzMzMyIgZmFjZT0iQXJpYWwsIEhlbHZldGlj
YSwgc2Fucy1zZXJpZiIgc2l6ZT0iMiI+PGI+QXVjaCANCiAgICAgICAgYmVp
ICZVdW1sO2JlcnN0dW5kZW4gYW0gV29jaGVuZW5kZSBvZGVyIHNwJmF1bWw7
dCBhbSBBYmVuZDwvYj48YnI+DQogICAgICAgIC0gSWhyZW4gS2FmZmVlLCBN
aWxjaCwgWnVja2VyIHVuZCBmcmlzY2hlcyBLbGVpbmdlYiZhdW1sO2NrIGth
dWZlbiBTaWUgDQogICAgICAgIHdvIFNpZSB3b2xsZW4uPGJyPg0KICAgICAg
ICAmbmJzcDsmbmJzcDtBdWYgV3Vuc2NoIGVyaGFsdGVuIFNpZSBhdWNoIGJl
aSB1bnMgZWluZSAmIzE0NztSdW5kdW0tR2wmdXVtbDtja2xpY2gtVmVyc29y
Z3VuZyYjMTQ4OyANCiAgICAgICAgYXVzIDxicj4NCiAgICAgICAgJm5ic3A7
Jm5ic3A7ZWluZW0gdW1mYW5ncmVpY2hlbiBLYXRhbG9nLiA8L2ZvbnQ+PC9w
Pg0KICAgIDwvdGQ+DQogIDwvdHI+DQogIDx0cj4gDQogICAgPHRkIHdpZHRo
PSIxNCIgaGVpZ2h0PSIyIiB2YWxpZ249InRvcCI+IA0KICAgICAgPGxpPiAN
CiAgICA8L3RkPg0KICAgIDx0ZCBoZWlnaHQ9IjIiIGNvbHNwYW49IjIiPjxi
Pjxmb250IHNpemU9IjIiIGZhY2U9IkFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMt
c2VyaWYiIGNvbG9yPSIjMzMzMzMzIj5OaWUgDQogICAgICBtZWhyIGRhcyAm
dXVtbDtibGljaGUgQ2hhb3MgcnVuZCB1bSBkaWUgS2FmZmVlbWFzY2hpbmUu
PGJyPg0KICAgICAgQXVzZ2V6ZWljaG5ldCBmJnV1bWw7ciBEZXNpZ24gdW5k
IEZ1bmt0aW9uLjxicj4NCiAgICAgIDwvZm9udD48L2I+PGZvbnQgc2l6ZT0i
MiIgZmFjZT0iQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZiIgY29sb3I9
IiMzMzMzMzMiPi0gDQogICAgICBBdHRyYWt0aXYgdW5kIGltbWVyIHNhdWJl
ciwgYXVmIFd1bnNjaCBhdWNoIG1pdCBUYXNzZW53JmF1bWw7cm1lciB1bmQg
VW50ZXJzY2hyYW5rLjxicj4NCiAgICAgIC0gWnV2ZXJsJmF1bWw7c3NpZ2Us
IG1vZGVybmUgQWJyZWNobnVuZ3N0ZWNobmlrLCBzbyBoYWJlbiBTaWUgZGll
IEthZmZlZWthc3NlIA0KICAgICAgaW1tZXI8YnI+DQogICAgICAmbmJzcDsg
aW0gR3JpZmYuPC9mb250PjwvdGQ+DQogIDwvdHI+DQogIDx0cj4gDQogICAg
PHRkIGNvbHNwYW49IjMiIGhlaWdodD0iMjIiPiANCiAgICAgIDxkaXYgYWxp
Z249ImxlZnQiPjxmb250IGZhY2U9IkFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMt
c2VyaWYiIHNpemU9IjIiPjxmb250IGNvbG9yPSIjQ0MwMDAwIj48Zm9udCBm
YWNlPSJUaW1lcyBOZXcgUm9tYW4sIFRpbWVzLCBzZXJpZiI+PGk+PGZvbnQg
c2l6ZT0iMyI+PGZvbnQgZmFjZT0iQXJpYWwsIEhlbHZldGljYSwgc2Fucy1z
ZXJpZiIgc2l6ZT0iNCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Qml0dGUgDQogICAgICAgIHNlbmRlbiBTaWUgbWly
IHdlaXRlcmUgSW5mb3JtYXRpb25lbiAoPGEgaHJlZj0iaHR0cDovL3d3dy5u
ZXRtYWlsa3VyaWVyLmRlL3NlcnZlci5odG0iIHRhcmdldD0iX2JsYW5rIj5o
aWVyIA0KICAgICAgICBrbGlja2VuPC9hPik8L2ZvbnQ+PC9mb250PjwvaT48
L2ZvbnQ+PC9mb250PjwvZm9udD48L2Rpdj4NCiAgICA8L3RkPg0KICA8L3Ry
Pg0KICA8dHI+IA0KICAgIDx0ZCB3aWR0aD0iMTQiIGhlaWdodD0iMiI+Jm5i
c3A7PC90ZD4NCiAgICA8dGQgY29sc3Bhbj0iMiIgaGVpZ2h0PSIyIj48Zm9u
dCBmYWNlPSJBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIiBzaXplPSIx
IiBjb2xvcj0iIzMzMzMzMyI+RGllc2UgDQogICAgICBOYWNocmljaHQgd3Vy
ZGUgaW0gSHRtbC1Gb3JtYXQgZ2VzZW5kZXQsIGZhbGxzIElociBFbWFpbHBy
b2dyYW1tIGtlaW4gSHRtbCANCiAgICAgIHVudGVyc3QmdXVtbDt0enQsIGsm
b3VtbDtubmVuPGJyPg0KICAgICAgU2llIHNpY2ggZGllc2UgU2VpdGUgYXVj
aCBpbSBJbnRlcm5ldCBhbnNjaGF1ZW4uIEtsaWNrZW4gU2llIGRhenUgYml0
dGU8Zm9udCBjb2xvcj0iI0NDMDAwMCI+PGI+IA0KICAgICAgPGEgaHJlZj0i
aHR0cDovL3d3dy5uZXRtYWlsa3VyaWVyLmRlIiB0YXJnZXQ9Il9wYXJlbnQi
PmhpZXI8L2E+PC9iPjwvZm9udD4uPC9mb250PjwvdGQ+DQogIDwvdHI+DQog
IDx0cj4gDQogICAgPHRkIHdpZHRoPSIxNCIgaGVpZ2h0PSIyIj4gDQogICAg
ICA8ZGl2IGFsaWduPSJjZW50ZXIiPjwvZGl2Pg0KICAgIDwvdGQ+DQogICAg
PHRkIGNvbHNwYW49IjIiIGhlaWdodD0iMiI+PGZvbnQgZmFjZT0iQXJpYWws
IEhlbHZldGljYSwgc2Fucy1zZXJpZiIgc2l6ZT0iMSIgY29sb3I9IiMzMzMz
MzMiPjxiPkhJTldFSVMgDQogICAgICBaVU0gQUJCRVNURUxMRU4gREVTIE5F
V1NMRVRURVJTPC9iPjwvZm9udD48YnI+DQogICAgICA8Zm9udCBmYWNlPSJB
cmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIiBzaXplPSIxIiBjb2xvcj0i
IzMzMzMzMyI+U2llIGVyaGFsdGVuIA0KICAgICAgZGllc2VuIE5ld3NsZXR0
ZXIsIHdlaWwgU2llIG9kZXIgamVtYW5kIGFuZGVyZXMgSWhyZSBBZHJlc3Nl
IHp1IHVuc2VyZW0gDQogICAgICBOZXdzbGV0dGVyIGFuZ2VtZWxkZXQgaGF0
LiBTaWUgd29sbGVuIGRpZXNlbiBOZXdzbGV0dGVyIG5pY2h0IG1laHI8L2Zv
bnQ+IA0KICAgICAgPGZvbnQgZmFjZT0iQXJpYWwsIEhlbHZldGljYSwgc2Fu
cy1zZXJpZiIgc2l6ZT0iMSIgY29sb3I9IiMzMzMzMzMiPiB0cmFnZW4gDQog
ICAgICBTaWUgc2ljaCBiaXR0ZTxiPjxmb250IGNvbG9yPSIjQ0MwMDAwIj4g
PGEgaHJlZj0iaHR0cDovL3d3dy5uZXRtYWlsa3VyaWVyLmRlL2VtYWlsbG9l
c2NoZW4uaHRtIiB0YXJnZXQ9Il9ibGFuayI+aGllcjwvYT48L2ZvbnQ+PC9i
PiANCiAgICAgIGF1cyB1bnNlcmVyIE1haWxpbmdsaXN0ZSBhdXMuIDwvZm9u
dD48L3RkPg0KICA8L3RyPg0KPC90YWJsZT4NCjxicj4NCjxwPiZuYnNwOzwv
cD4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--= Multipart Boundary 0506021807
Content-Type: application/octet-stream;
	name="tassegross.jpg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="tassegross.jpg"

/9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAHQAA/+4ADkFk
b2JlAGTAAAAAAf/bAIQAEAsLCwwLEAwMEBgPDQ8YHBUQEBUcIBcXFxcXIB8Y
GxoaGxgfHyQmKSYkHzExNTUxMUFBQUFBQUFBQUFBQUFBQQERDw8SFBIWExMW
FREUERUaFRcXFRomGhodGhomMiMfHx8fIzIsLykpKS8sNjYyMjY2QUFBQUFB
QUFBQUFBQUFB/8AAEQgASABhAwEiAAIRAQMRAf/EAIUAAAEFAQEAAAAAAAAA
AAAAAAABAwQFBgIHAQADAQEAAAAAAAAAAAAAAAAAAgMBBBAAAgEDAgMFBgQF
BQAAAAAAAQIAEQMEITFBEgVRYSIyE3GBoUJSBpGxIxTB0XKCQ2KiwjMkEQAC
AgIDAQADAQAAAAAAAAAAARECIQMxQRJRYXEiBP/aAAwDAQACEQMRAD8A38Qk
CIWrWmgG5jILk81PDwEW10jUh+pMTWcq4I01Mrup9VXGRhzBAPM5/hEdvyCT
ZNv5WPYFbrhe7j8JDfruGpoAze7+cxmd9wO7/wDnStfnfUn3Subqee51ucvc
FB/KYm3nhfR3SOefiyz0NOvYTmnOyf1LUSZazEuDmQi4vahqfes8tXqWZWhY
N3ECTcPrF21cB5jacbEHSbNl2Z4ng9MS4jiqms6lD0vrFvMpbyP08j5bg+aX
KXGBCXN+DDYx62TFagehEixjAhCEAOKClOEatMVY2m3HlPaIXL4UVMZ/e4t0
+mG8Q4jgZFuWbA7ksli096tKAzzvqnU3zchip/SUnkG+nEn2zXfc1y6nQ71G
1dltq2xo55ZgvSRrlwMSERiFXuBpE2Osf1KXxF9FLWf8xP19Hdkq7sFHjaor
9CHc+0yWgsWRRVAkE3bdoUTSNNkMZz3rbZxKqju1qmquWnZ8ssLuImV/1ij1
3Ek3+jKqohdakAu9I/hCzZ6at8mrPqQDRqVpQQa6bipy8wUV0FK0417aSKd1
iXCeCex1l4mOWRcV3w7q2y/MhPgccJuem5X7rGAuauujfzmKdLTtQqDoSCDS
jU75o/ty6WQV4ih9onVo2Nvyzl31UekX9tiDyNr9J7Y5GSOYU2O4PYY5bfmW
p32I751p9HOdwiQjAQyguBwZSZlsYOSt1NUJrTul+yHkenGkrb9u1cNL2qDe
c5RdnGep6t0nIt2R4mStkf67fiH40nn2XUXiw0W741H9W/4HSelYarbthbY5
VU1Udx2mc+5OgE8+XjL+kxLMB/jc+b+xvgZmG1PRSlnXjHpQZGEV1ZGKOOVh
uDEl0lGBLbLTksMHKpY9At4laqJwoe+Si6BiyVXhQ8KylBKsCNCNpIsnIyXF
u2oLn5vpH1HspOfb/nUuyfldyUptbUNSy4tXS14DzA18VKaU1oRND9sWyUe4
NVLkqd6yitY62qYthzdyrtFLKK0Bm06XgrhYiWV+Ua+2R0V9XbXFQ3uKpfSS
QREQ8t2nBxX3iOUjT6FT9LD46Tt4ZzD0IawjAN8CJX305SSJPaokTI1rIMdF
dh5o9Qo+lDyn2iWJbjMr1C62Jl8/+N/N3d8sMPrChQt01HBpjXZSnxh1L7cw
8urWaWXPynyf2kar+Uz2T9sZ1hqi27rwKKLg/wBpr8JsFybVwVVhEL8QaRVZ
rhtDuq/f7MQnSbwbXGyLzDZPTKLXvO8s8Ho/W2Y0QYVvbxAIKezVjNBcvvsH
P4zrGUu/MTWDr6zZtiPZGEkhzpPSMXp6+oD6l7Y3T/xEuE8srlvi5d5LfkTc
8CZYJ5BK60qqFgjazs5Z2No2+xjkafVlXtP5Sj6MHYRPfCaA2xrqNpFvCEJB
jopOpWEuqQ4rKQ4tyyf0jVfpMIQQ6HLVy4pG6ydbu3D80IQwD9Dy3Aoq7Rf3
bsPTs1VTuYQmqCZZ4CUAUa9ss/UHMEGp/KEIy5FHSaCcJ4nL8BoIQj95AchC
E3AH/9k=

--= Multipart Boundary 0506021807
Content-Type: application/octet-stream;
	name="foto2.jpg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="foto2.jpg"

/9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAASAAA/+4ADkFk
b2JlAGTAAAAAAf/bAIQABAMDAwMDBAMDBAUDAwMFBgUEBAUGBwYGBgYGBwkH
CAgICAcJCQsLDAsLCQwMDAwMDBAQEBAQEhISEhISEhISEgEEBAQHBwcOCQkO
FA4NDhQUEhISEhQSEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhIS
EhISEhISEhIS/8AAEQgAUQByAwERAAIRAQMRAf/EAJwAAAICAwEBAAAAAAAA
AAAAAAAFBAYCAwcIAQEBAQEBAQEBAAAAAAAAAAAAAAIDAQQFBhAAAQMCAgYE
CQgGCwAAAAAAAgADBAEFEgYRIjJSEwchQoIUMUFRYnIjM9MVYXGBocKDkwjR
kkOjs8ORsfJTY3PjNFSkFxEBAQABAwQBBQEBAAAAAAAAAAIDARITESIEBTFB
UTJCFFIV/9oADAMBAAIRAxEAPwD38gEAgxMwbpiOuGi5VaaCtXTPtgthE3V7
vLoeEGulea/KnRW1VZnN1sSwxYej/MJeevMpfGg/+tzSr7FkPpqp/rpXEmR+
aMsttlk/pqn9lHEeQ+YsR3/cMVb9GulaT5v3Txn0PM9pm1wtvUbPdc1K/Wt4
8mdUbTcTEtmuleia01SyXQIBAIBAIBBy3mrmGZbnI9vbKrMV5o3DPe0dC+X5
mfa3w49zz7euY1ohmTTDjlykbjGx+uvkV5c/Gj7GD1uSvlU3uYVzePE1BbBr
znNdeb+m3un1sS2N8wJg4cUET++P3azryba/8+ExnmM+OHFb3OzK962o57/0
ivWwZM82H4+1BIw3MX8z/TVz5dyzr1cV+y1WHmtY7g4LD5lapB7AP7BdtevH
5s/V4c/q8k/j3O0ZFzW7JmDa3HOM08GNktvCvr+Ln610fLy4ujpdK6aUr5aL
62jzPqAQCAQCATUVnOOTrNnizPWW9gfd3th1ksDzR74GvFnxRlnpTbDnrFXW
XmvMn5as0Wd0ncuus5hhdQPYyR7Dup+8Xwc/q7n8O5+gwe3ivz7XMb1lm+Zd
qQ3m0XKBg65Q38H4ns14qwXPzL6E+Tjr8aV34pZx1SKT+G37xRx003Ng3iy4
tqT2m2/eJx0ruToZMXQxYtguzJB9QWXDNd4KpnWTau1p5J56vxCRWwrPCPbl
3Iu7AHYd1/3a2xevy3+ryZPaYo/Z3zIeXbby3tXc2555kvWHCcshwMsBuB5i
+343iThl+d8vy+auujo8bM9tC3MvynhjaBECq50YjpTRWg+XpX0tM2nR5EqL
f7bMLCzIHH4hOlQrX5tK7yhmBiY0IemlVsMkAgEGBOBTorXpU18DDEvG6x9B
AvmSH26argqd1Cp3B5h4y7zboEw99+K2azVyakrjlvZ1mLLaGT3xt7Hu1TnJ
f+kdzMl3ZHhRnW4DO5GbbZ/hqmdVWpeU6ZKPFJfckn5xIzNI44iEd8UUfcvc
v8Gr11u7Zd9o5UYYP6PVhTrBp8q3wSqV7nQWJ8Y2HaUpippA6U1gLxFT5aLf
WdNVE+Vpz8oH2n9pijf10r+hY4NeugsK9A+EVBpUq+CiCC7LIiwjsrCsidzR
iXEpAvYhWLTc0k9hUqK5z2IUSrsxzW2lIRSiw9ZEkjzmsiGLLmuKp1ZLaPEf
jiO2alx0BssIiIktFsJN1NtlxsD1ahWjzx7DWnoV89KbMqxeHFfmFTCc5zTQ
N1sNNAp/QtcE9JD9bCDcHC0C2HhLpqsctJpB2RXnS0uPYRWspa4tyYJ/uxFg
M9hTSppMeHVWTQplNkjhDMZLWQIZjJEpZlpQyI1TiVFtuHWJBIi5gg225EwQ
vSZYDqA2P20UsTN0mTNoSZD+5b2/xE3BgLYkI95w8INcI47Hb30c3pTN4GHc
Y50LQxcD4To+RxenDX0arfpp9WlbiHOax1AqbXgH51hmlzVAcWCCqcRCBYUS
51mK4SY/rWCIHQ1wMV1KwZN5iRb4x3OdhZucXUeDe89cXvW4nmHh1SQqi+Uy
2XjRO4nkRWsW0pdReGwO0grWZM4QbOIxmteQfUHqAqCS136K4/xcAhjLHjLb
U7RcI+ZIzYe0HsoN0e8Trs7wLe2R+eimy9CUGbZ7QLvGucp/vDwbgNf21vgl
Uup8N7/r6O15F6VN0yPWVHNoS4blels90qeCqmp66CrUv7MaT8Ovo/D5dNl3
9i6vNU1onanSIYyGsTeEwPriqnuZVKl3zLZSBLCKzqXHMb1lO4RXRmW83Ic2
KWJl0ft74KKd3Jlvzxd4IixdYjgGG28x64C/mIbTYeYluKnrX8B7jmohtRZH
MC2YdV8Xj3G9f+EhsojuGar9cBJixwXAM9TvcseCyP3ftDQ2odvybMkCJTnX
J8szxvSHOsaoqlwtvLkSEcXEBdcWy28ubYz61/EeDeJcXDK7Zwy9ldooNlBu
fc9gGWNgT/xFczuXtbMh5auVwuJ5pzBiKU/XE3QvFXyUXpmdqnUlQEC272SB
eo9WJrdDpXwFo6aIKBNypmzLZE/lmebkf/jua4LKsf2CwuZV8tvqsw2HjYNt
1hZ7alO1kPMzIE7UnC/bT3HG1NUbR8Q5b3D2V3jB6Qqd0o4qaSteR3Nm8wP1
lztOOh8LyUzrFereH3idqeKmsrly3t+s/foR4N0sadquOmsuZXLmDqwzfuru
4wyi+JFe5uSXvVWGwEG47LL7DS1maNqOMfmJnQsMt9yNEc/YsDwQWvBP1Uv+
VOV9ts+GTOp3mT5CWg6CAA2FAClBAaaKUogyQCAQCCJKtkCYOGTHbdp8tP0I
KzcuWeWLjpxRxbrX5KVXOgqdw5CZclYuFQW9Pgw6n9WlRxaCvSPy22w/ZyXQ
9Ek4tHdyFT8skOtdea+Xab92nFo5uo5g/l1scWuktf0yxrvHKty1W/k7l6Jo
xUpop1RorStMDJtgt+irUUalTx1QPGmWmRwtBRsfJSmhBmgEAgEAgEAgEAgE
AgEAgEAgEAgEH//Z

--= Multipart Boundary 0506021807
Content-Type: application/octet-stream;
	name="automat.jpg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="automat.jpg"

/9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAIwAA/+4ADkFk
b2JlAGTAAAAAAf/bAIQADgoKCgsKDgsLDhQNCw0UGBIODhIYGxYWFxYWGxoU
FxcXFxQaGh8gIyAfGikpLS0pKT07Ozs9QEBAQEBAQEBAQAEPDQ0PEQ8SEBAS
FA4RDhQXEhQUEhchFxcZFxchKh4aGhoaHiomKSMjIykmLy8qKi8vOjo4OjpA
QEBAQEBAQEBA/8AAEQgAwgBkAwEiAAIRAQMRAf/EAJgAAAEFAQEBAAAAAAAA
AAAAAAADBAUGBwIBCAEBAQEBAQAAAAAAAAAAAAAAAAECAwQQAAEDAgMCCQgG
CAYDAAAAAAEAAgMRBCESBTEGQVFxsSITcxQ1YYGRMnKy0jShwUJSM0PRYiNT
g3QVFoKSosIkB/DhkxEBAQACAQMEAgMAAAAAAAAAAAERAjEhEgNBUZETYVKB
IjL/2gAMAwEAAhEDEQA/ANJVPP8A2Po4kdH3a5qxxaTSOmBp+8VwWBz16+4I
ND1hxHtOQapHv3pkgqLeccoZ8aV/vTTv3E/oZ8az/TdLurm0Zcm7MbZK5WAV
PRNMaUonf9FmO28f/q+JMxMrp/eum/uZ/Q340f3tpv7mb0N+JUgaG6Rzm96d
VvG4ivpeFBXzTa3MluayZKdISHGorwFydDq1F2/Wlt2wT+hnxrgb/aUTQQXH
oZ8ayN9zj6pH+Ny8bdZT6p/zuV6HVsbN9dOfsgn9DPjS7d6rJ2yGb0N+JZho
wdeNe7M6Pq3sZTM5wOfZ9pqu+m7rR3lo2fvcja1BAaaYfxE6HVLS73WEQq6G
Y8gb8SktK1OHVLQXcDXMYXFtH0Bq3kJWfa1Yf03UBatldKBiXOJFQ6NzqZS4
7CrfuZ4K3tZOdLgzcp9CEKKFhAi66+khrl6yfLXiq5wW7rDbbxU/zI98olSV
pFLaRFr7uSCPOQxraAOAwzCp405Li+KR8N9K98bS4gu4Bx0KbytkktainQnl
biaYGjuIpW3AFvP950by7h4OBDDmGMSsa6S9dGXirjmwB4jwqH1AmK4pC9t4
0k1eGPDhQ06ReOZTVpm6plLQTdE4GnS/W+8oPVfmelF3F1T0QJRmx29M0w8i
pEjHpmkSaLcXst41moRupFa0YMwFKDKemc1TiMAoljGZgMoxI4ArLa95/tS+
DdNZJCXkuvCWhzaZekGu6ZyeQ0xVbZtVguMWjaCw0Zdt8z4v0L2ZxtZOps7l
7oKAgtkwqdvqUCbHSJ7e0sJpLYs7wCTJmBz16batqcvRSty2NszzEzqoXGsc
dcxa3iqp+GTS8ke+WNz3Oe7MRmc7Mfw3faV43M8Fb2r+dUS49aL2z7j1e9zP
BW9rJzpVnKfQhCjQWG23ip/mB75W5LDbbxU/zA98olTNwC2B7GCp64uoMTjg
k7Z2aOUcBik+hpKXvZI3xsMMbm5MzJjStZQ5zq+dpCZWDJ2C4MmLXslc0H7I
yO/8opvr/bM9+F9Di27v3dhffGF4+wAOjyYVUTfRW7y9/eTcTNJLGOikIPkz
l1BU+SimrHvBtmhlmycU2k48uCg9QZJ1crpLEW7A4ZpxG8FpcQW0c5/2uRVI
lbV9kN271j9SkhuC6rLEEBj/AFaAspmdn4SDwYqDj2hWOwOof2pqDIrOGS1L
iXzucA+gawucGUJdkFCDUbVXIfWxWoLJp971rYY765uHQwNpFG0D9nUYhpc9
2HmTu5NsXg2z5HsLekZaZgfNgubfR76CCxkfBC8X9GQZiSczyHsL8RTo/Qlt
QtJbO7kglaxj20OWKuShGGWuKdERlxti9s+49XvczwUdq/nCodz+V7Z9x6ve
5fgje1fzhKTlYEIQstBYZb+Kn+YHvrc1g75HRXk0rMHslLm8ocShVk1Bw6vG
gPWOpQ7RThHGkICeqlHB1UnuOT3d6TUtQikl62EEH8yMOP0OaAnd1YalLG+M
yQgO6Li1gaeIjGRLzlFejt9VdCHQNk6k+rTZt4POo2a2nzOMlvKSekXGN5HH
WtKKdmtdSs2iMXZYweq1tCB/lcoUxajIZWMccraFwM+QEPGYdFzgNnArkha2
s9al0q6ntes/pjDW5a14DXFoDiclelQUJoEwiJBqNqdQP1plrLZQv6u1lc4T
RddGAS2jXbTXlptTCSSS2kMcjBnbicrw4Y+VlQmRa9Fnt5BAzVZrjq4QcjIz
VrOEdX0iR6FJai6xfOH2T5pGubWR85JcXcpx2KH0S2N1IGyua1rXZT1TmyP2
AgtbhUYq0/0O0jEmaS5d1T2xnLE3Eu4RtTMTqrFz+X7Z9x6vW5fgje1fzhUz
VbdttcmFpLmskcATgT0ZArnuV4I3tZOcK0nKwIQhZaCwWUVurhuysjsf8RW9
LBZPnJu0d7xQSen96gaRBcviDvWDaivoKdOkvT611IfT8Sb2nqhOCqwa1llG
bvMlMeDi86ZyWNsSS5xLjiTlbt9Kcwn9lj953OkpCrhcmhsrUHa4/wCFqUis
rao2+hv6EEpaFMLeD/T2COZwt3mN8VBnaMpqR+rRTbRdPb0rqQ+c/W4qC00n
vt2OJzPpYrDH6isZRl1BlOZ0jn5SSAabaEY4eVXTcrwRvayc4VQvTWqt+5Xg
g7WTnClWcrChCFloLBpPnJu0d7xW8rBZPnJu0d7xRKlbT1U4cU3tfVS7lWTG
I/sj7TklIUpF+GfackZCqsJE4paA4psTil4DikWpHTR/zLryuj9xWFnqKvWH
zc/lye6rBGasVjJhecKuO5Xgg7WTnCp17QVVx3J8EHayc4U2WcrChCFloLBZ
PnJu0d7xW9LBZPm5u0dzlEqUtTgnDtia2mxOH7FayYR/hn23JGUpWP8ADPtu
SEpVWEScUvb7U34U4g2pFqTsfm5uRnuqeiPQUBYn/lzckfuqdjPRVjJjfO2q
57keBt7WTnCpd5wq6bj+BN7WTnClWcrEhCFloLBJPm5u0d7xW9rBZPm5u0d7
xQqRtTQJw44JvbbEu84KuZgw/s3e25ISFKsqGur976aCqReq3CXCl4dqQO1L
QnEJCpSy+bl8oZzKbjPRUFZhwuXk8IB5QfV9Cmoz0cVWTW82FXTcfwIdtJzh
Ui9mjDTV4HKQrtuNX+hCu3rpOdSrOVjQhCy0FgV7UCdwNCJziPKSt9WBX5o2
ccc55ygRmmlYyAxyOaTGC6hOJqUn368H5zvOapNz84aPujKFwhgoby5GHWH6
F4Lm5eaAlx8gB+pIu2rUtKt7eCxtpNMit2mSNrg+VhJdmGOZzQTtVnVnbbtx
05ZoXXm0tePLl/8AS47zOPtkLVm2e8Erjnu7IRHa1sT3GnEK0UHvTu1by92k
juLa1kcSx8sp6oSONMrQGgjzphmeTr1nwpztRmfbRRAZJIy7NO1zg94Oxrsd
jeBIGaZ3rSPdyuJ+tFzazWdzLa3Dcs0Lix4rXEeVchR0egft2+01bVuT4Ke3
l51i5+Zb7TfqWz7j+CHt5edX0FjQhCgFgGpbZO2ct/WA6ltl8kzvrQMG8a8X
WWgafvCv0p6zTJHtDhICDxCqlsnLWnj23uNZnCPyPd6rSeRXvdC+kmsO6SVE
tocAdpidsPmOCq3dpbZpY1pe5+OamwbNg2qQ0e7h0+4NyHPEpaWO61ji1wPB
Ruxa1s5yx5fHtM63W5jRo+sc3i8gVT3m1Pd2SW3fPK69msi7LZRfhOeT+bJw
YjEBOHb2sMRbE+KIkUz0eXDgqA4UVPfBZQukIm66riQQ12I5KJ8OWmlz1m3w
ZXl5LfXUt1NTrpnl76Cgx4AOIJEKSZaRXZOUlgZ5Mu3l2pC8tI7UhucmQ0OU
02HGuCz3TOHp+rfs78Y1NWn9s0+ULatx/BD28vOsVqOtafKFte5Hgh7eXnWv
RhYkIQoBYDqX53bHnK35fP8AqD8z5gMQJTX0lAzc6rWjiFF62edjcjJHNZ90
EgLyNnWODK5SdleEpY2MnGFLj1a1m3Ouf4IGWU7XuPnK5qeMpx3N/C5ddxP3
kzDt3vua1PGvKlP2acHEAuI5EpLpcbBUPcTyBO6NfVv7IypRVPDYHgf9C4ls
zEwvc7AbMNpTMZum3sbg9IHyhbbuR4J/Gk51iQBqFtW4crJdAD2GreukFfOF
WVlQhCAWC3NtE+6mqD+I7YfKVvSzm9/671MSyS2tzDM1znODX5o3UOP6w+lB
Sm6bC7Y97fQf0J02ItaAXhxH2i3Hz0cpt+5+8UJA7mZMK1Y+M/7gmz9C1pta
2FxhtpG4j6AlkvJrvvr/AJuEU5jhskYOVhP+9cEyD85g/hH4k+k07UW+taTj
ljf8KRdpmpbe5z0PD1T6enKnbr7Nfb5P2psJJmnCdv8A8v0lddbO/bOD/Cb8
SVGl6i40FpOT2T/hTiHQ9ZeehYXDv4T/ANCduvtF+3yftt8kYYHP9aX0RgfW
nB0q1mIMzpJMuwAtYP8AS1SNpu5rrsRYygD7wDPfLVKQbq628AugEdcOm9uH
LlJVxrOJGL5PJel2titO06wi9S3FeNxLveK0XchoboTQAGjrZMAKDaFGR7j3
cn49zHHtqGNL+TbkVm0jS49KsxaRyOlaHF2ZwANXciWsyXJ+hCFGghCEAhCE
AhCEAhCEAhCEAhCEAhCEH//Z

--= Multipart Boundary 0506021807--



From glingl@aon.at  Mon May  6 18:54:20 2002
From: glingl@aon.at (Gregor Lingl)
Date: Mon, 6 May 2002 19:54:20 +0200
Subject: [Edu-sig] midi-support?
References: <3CD6A584.2CAF719B@fa.disney.com>
Message-ID: <007801c1f527$0cfd96c0$1615a8c0@mega>

Hi!
Does anybody know if there exist(s a)
Python module(s) for midi-support,
which work(s) under Python 2.2
(at least under Windows) ?

Thanks, Gregor




From dyoo@hkn.eecs.berkeley.edu  Mon May  6 19:16:26 2002
From: dyoo@hkn.eecs.berkeley.edu (Danny Yoo)
Date: Mon, 6 May 2002 11:16:26 -0700 (PDT)
Subject: [Edu-sig] Re: [Tutor] midi-support?
In-Reply-To: <007801c1f527$0cfd96c0$1615a8c0@mega>
Message-ID: <Pine.LNX.4.44.0205061114280.24365-100000@hkn.eecs.berkeley.edu>


On Mon, 6 May 2002, Gregor Lingl wrote:

> Hi!
> Does anybody know if there exist(s a)
> Python module(s) for midi-support,
> which work(s) under Python 2.2
> (at least under Windows) ?

Hi Gregor,

I did a quick check on Google.  You might find this article on "Noisy
Python" useful:

    http://www.onlamp.com/pub/a/python/2001/10/25/pythonnews.html


The MusicKit system that the article mentions appears to have MIDI
support, so perhaps you can use that:

    http://musickit.sourceforge.net/


Good luck!




From delza@mac.com  Tue May  7 17:33:36 2002
From: delza@mac.com (Dethe Elza)
Date: Tue, 07 May 2002 09:33:36 -0700
Subject: [Edu-sig] Converting from Qbasic
In-Reply-To: <20020503223753.GF11295@zork.net>
Message-ID: <2E35BEBA-61D8-11D6-A8BD-003065CA8E18@mac.com>

On Friday, May 3, 2002, at 03:37  PM, Seth David Schoen wrote:

There isn't anything built in to Python which does port I/O.  Doing
port I/O is a low-level and platform-specific operation.  (For
example, it doesn't exist conceptually in Java at all.  It exists on
all PC operating systems, but on Linux and on Windows NT there is a
concept that the user running the code might not be permitted to
perform that operation.)

There may not be any built-in serial I/O in Python (well there is, but 
only for Posix, although PyWin gives access to the Windows serial access 
methods), but there are plenty of third party solutions, as a quick 
google discovered:

Universal Serial Port Python Library (windows/linux)
"Pure Python," wraps existing serial APIs to give a standard interface
http://balder.prohosting.com/ibarona/en/python/uspp/uspp_en.html

Python Serial Port Extension (pySerial: linux/bsd(posix)/windows/jython)
"Pure Python," as above, but more ambitious in scope
http://pyserial.sourceforge.net/

Java also can access serial and parallel ports through the JavaComm API:
http://republika.pl/mho/java/comm/ (links to implementations for many 
platforms)

This used to be a much harder problem.  I think Lego Mindstorms inspired 
a lot of people to solve it %-)

While Python can give access to serial, parallel, and joystick ports, I 
didn't find any standard libaries or APIs for USB or Firewire access.  
There were a couple of windows-only USB project, some python info in the 
general Linux-USB project, but not much else.  One Japanese page looked 
promising, with python info for accessing all kinds of hardware, 
including gameboys, etc., but my Japanese was never that good and it 
hasn't improved with years of neglect.

The good news is that, if your OS supports these interfaces, there's 
probably a way to call native system services to access them.  The bad 
news is that they haven't been wrapped in a convenient python API yet.

How can I be so sure there's a way to do it?  On windows there is a 
calldll python extension which allows you to, you guessed it, call any 
DLL, so the hardest part is finding accurate documentation on assembling 
the call.  On Linux everything is treated as a file, so if the kernel 
supports serial ports or USB (or whatever) you can generally access it 
via Posix calls (same with BSD/OS X and other Posix systems).  On older 
MacOS and less common systems (OS/2, BeOS, Amiga, etc.) you may be out 
of luck--at least I don't know of any common way to access the hardware 
on those systems (BeOS can probably do it through BMessages or 
something).

Have fun!

--Dethe

(Seth, sorry about the duplicate, thought I was sending to the list).

--
"Melting down holy grails to make silver bullets for my .357 Panacea"
Dethe Elza (delza@burningtiger.com)
Chief Mad Scientist
Enfolding Systems (http://enfoldingsystems.com)
Weblog: http://livingcode.ca/




From fallen@leveltwo.com  Tue May  7 18:16:17 2002
From: fallen@leveltwo.com (Fred Allen)
Date: Tue, 7 May 2002 10:16:17 -0700
Subject: [Edu-sig] Converting from Qbasic
In-Reply-To: <4BB02C541824D311921600902765DB7B03A102A9@LTISERVER>
Message-ID: <4BB02C541824D311921600902765DB7B445F94@LTISERVER>

The available modules supporting serial I/O, to which this thread alludes,
to all seem confined to asynchronous protocols.  Do any among you know of
any available modules supporting synchronous protocols, e.g., binary
synchronous, or bit-synchronous (say HDLC)?

Fred Allen

 -----Original Message-----
From: 	edu-sig-admin@python.org [mailto:edu-sig-admin@python.org]  On Behalf
Of Dethe Elza
Sent:	Tuesday, May 07, 2002 9:34 AM
To:	edu-sig@python.org
Subject:	Re: [Edu-sig] Converting from Qbasic

On Friday, May 3, 2002, at 03:37  PM, Seth David Schoen wrote:

There isn't anything built in to Python which does port I/O.  Doing
port I/O is a low-level and platform-specific operation.  (For
example, it doesn't exist conceptually in Java at all.  It exists on
all PC operating systems, but on Linux and on Windows NT there is a
concept that the user running the code might not be permitted to
perform that operation.)

There may not be any built-in serial I/O in Python (well there is, but
only for Posix, although PyWin gives access to the Windows serial access
methods), but there are plenty of third party solutions, as a quick
google discovered:

Universal Serial Port Python Library (windows/linux)
"Pure Python," wraps existing serial APIs to give a standard interface
http://balder.prohosting.com/ibarona/en/python/uspp/uspp_en.html

Python Serial Port Extension (pySerial: linux/bsd(posix)/windows/jython)
"Pure Python," as above, but more ambitious in scope
http://pyserial.sourceforge.net/

Java also can access serial and parallel ports through the JavaComm API:
http://republika.pl/mho/java/comm/ (links to implementations for many
platforms)

This used to be a much harder problem.  I think Lego Mindstorms inspired
a lot of people to solve it %-)

While Python can give access to serial, parallel, and joystick ports, I
didn't find any standard libaries or APIs for USB or Firewire access.
There were a couple of windows-only USB project, some python info in the
general Linux-USB project, but not much else.  One Japanese page looked
promising, with python info for accessing all kinds of hardware,
including gameboys, etc., but my Japanese was never that good and it
hasn't improved with years of neglect.

The good news is that, if your OS supports these interfaces, there's
probably a way to call native system services to access them.  The bad
news is that they haven't been wrapped in a convenient python API yet.

How can I be so sure there's a way to do it?  On windows there is a
calldll python extension which allows you to, you guessed it, call any
DLL, so the hardest part is finding accurate documentation on assembling
the call.  On Linux everything is treated as a file, so if the kernel
supports serial ports or USB (or whatever) you can generally access it
via Posix calls (same with BSD/OS X and other Posix systems).  On older
MacOS and less common systems (OS/2, BeOS, Amiga, etc.) you may be out
of luck--at least I don't know of any common way to access the hardware
on those systems (BeOS can probably do it through BMessages or
something).

Have fun!

--Dethe

(Seth, sorry about the duplicate, thought I was sending to the list).

--
"Melting down holy grails to make silver bullets for my .357 Panacea"
Dethe Elza (delza@burningtiger.com)
Chief Mad Scientist
Enfolding Systems (http://enfoldingsystems.com)
Weblog: http://livingcode.ca/



_______________________________________________
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig





From sandysj@asme.org  Tue May  7 19:48:26 2002
From: sandysj@asme.org (Jeff Sandys)
Date: Tue, 7 May 2002 11:48:26 -0700 (PDT)
Subject: [Edu-sig] Re: midi-support?
In-Reply-To: <20020507160004.28354.81097.Mailman@mail.python.org>
Message-ID: <20020507184826.53546.qmail@web12804.mail.yahoo.com>

Message: 2
Gregor Lingl said:
>
> Does anybody know if there exist(s a)
> Python module(s) for midi-support,
> which work(s) under Python 2.2
> (at least under Windows) ?

What specifically are you looking for?
(MIDI is a broad subject)

What have you tried so far?  There are lots 
of MIDI things in the Vaults of Parnassus:

http://py.vaults.ca/parnassus/apyllo.py/63131194

After I complete some other projects I will be 
working on a graphical interface to the QY-70.
This will involve reading and writing MIDI 
messages thru the MPU-401 and displaying a 
"piano roll" sequence.  I plan on using the 
vaults source code as a starting point.

Thanks,
Jeff Sandys


__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com



From dragoncow2@hotmail.com  Tue May  7 21:28:28 2002
From: dragoncow2@hotmail.com (Nicholas Wheeler)
Date: Tue, 07 May 2002 16:28:28 -0400
Subject: [Edu-sig] Converting from Qbasic
Message-ID: <F157FdbTroZ3QUoWe7f0000d292@hotmail.com>

Hello, i am one of the students that started this thread. I found the first 
email, directing me to winioport to be the most helpful. I did a quick 
search for a newer version of calldll (python2.2), and found it. I have 
gotten my program to work on windows 2000, and windows 95. Unfortuantly, 
Winioport only works on windows . . . I was wondering if anybody knew of a 
program which would send byte data out to the parallel port in linux. This 
would be very helpfull.

--Nick

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com




From michael.williams@st-annes.oxford.ac.uk  Sun May 12 11:49:23 2002
From: michael.williams@st-annes.oxford.ac.uk (Michael Williams)
Date: Sun, 12 May 2002 11:49:23 +0100
Subject: [Edu-sig] Changing to future division sitewide
Message-ID: <20020512104922.GC3561@st-annes.oxford.ac.uk>

We are about to embark on a series of trials of the Python language with
a view to replacing Pascal as the teaching language here in the
department of Physics at Oxford University [0]. We have a day (!) to
teach the language so we are really keen on using the new division that
returns a mathematically intuitive result (see
<http://www.python.org/peps/pep-0238.html>) as it is one less thing to
explain.

[0] Hence this port to EDU-Sig

However, our students will be using idlefork to program (both
intereactively and in stored modules). Is there any way we can get the
new division behaviour sitewide, i.e. we would like the new behaviour in
the following situations:

1) typing python at a command prompt (alias "python" to "python -Qnew"?)

2) running a module they've saved (or indeed any module)
   This might be problematic as it would presumably apply to all modules 
   on the system which might break things--although this is a fresh 
   install of Python. All we have here is Python 2.2.1, Numeric,
   Gnuplot.py (a Python wrapper of the Gnuplot program) and idlefork
   (which is the development version of idle).

3) Someone using the interactive interpreter in idlefork

Presumably this is going to involve doing more than one thing if it
ieven possible. We could always tell our students to put "from
__future__ import division" at the start of every program without
explaining it, but that's the kind a black magic we hoped to avoid by
using Python rather than, say, C.

Yours hopefully,

-- 
Michael



From urnerk@qwest.net  Sun May 12 16:01:51 2002
From: urnerk@qwest.net (Kirby Urner)
Date: Sun, 12 May 2002 08:01:51 -0700
Subject: [Edu-sig] Changing to future division sitewide
In-Reply-To: <20020512104922.GC3561@st-annes.oxford.ac.uk>
Message-ID: <4.2.0.58.20020512075954.00d2d100@pop3.norton.antivirus>

>
>Presumably this is going to involve doing more than one thing if it
>ieven possible. We could always tell our students to put "from
>__future__ import division" at the start of every program without
>explaining it, but that's the kind a black magic we hoped to avoid by
>using Python rather than, say, C.
>
>Yours hopefully,
>
>--
>Michael

The place to start is with the -Qnew switch on the command
line in 2.2 or 2.2.1

I just tried it in a DOS box (python -Qnew) and it worked
(3/4 returned .75).  Then I put it in the command used to
boot idle and that worked too, including in a module.
Presumably works with forked idle as well.

Kirby





From schoen@loyalty.org  Mon May 13 00:28:36 2002
From: schoen@loyalty.org (Seth David Schoen)
Date: Sun, 12 May 2002 16:28:36 -0700
Subject: [Edu-sig] Converting from Qbasic
In-Reply-To: <F157FdbTroZ3QUoWe7f0000d292@hotmail.com>
References: <F157FdbTroZ3QUoWe7f0000d292@hotmail.com>
Message-ID: <20020512232836.GX30911@zork.net>

Nicholas Wheeler writes:

> Hello, i am one of the students that started this thread. I found the first 
> email, directing me to winioport to be the most helpful. I did a quick 
> search for a newer version of calldll (python2.2), and found it. I have 
> gotten my program to work on windows 2000, and windows 95. Unfortuantly, 
> Winioport only works on windows . . . I was wondering if anybody knew of a 
> program which would send byte data out to the parallel port in linux. This 
> would be very helpfull.

http://www.hare.demon.co.uk/ioport/ioport.html

(I haven't tried it, but it looks good.  It may be older than
winioport.)

-- 
Seth David Schoen <schoen@loyalty.org> | Reading is a right, not a feature!
     http://www.loyalty.org/~schoen/   |                 -- Kathryn Myronuk
     http://vitanuova.loyalty.org/     |



From dragoncow2@hotmail.com  Mon May 13 22:56:45 2002
From: dragoncow2@hotmail.com (Nicholas Wheeler)
Date: Mon, 13 May 2002 17:56:45 -0400
Subject: [Edu-sig] Converting from Qbasic
Message-ID: <F221OkTRhlQnNE6f17r00013dde@hotmail.com>

Thank you very much, it turns out, i emailed the creator of ioport, and he 
updated it immediatly. This looks like the exact thing i have been looking 
for.
  Nick

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.




From michael.williams@st-annes.oxford.ac.uk  Wed May 22 12:03:20 2002
From: michael.williams@st-annes.oxford.ac.uk (Michael Williams)
Date: Wed, 22 May 2002 12:03:20 +0100
Subject: [Edu-sig] Emulating Pascal input
Message-ID: <20020522110320.GA7559@st-annes.oxford.ac.uk>

Hi,

We're currently running a trial implementation of a teaching course in
Python here at the University of Oxford Physics department. The current
course uses Pascal and, although it works well, is obviously sub-optimal
for a modern undergraduate education.

Details of the results of the trial will be posted to EDU-sig when it is
complete, but for now we're trying to address what we see as a
limitation of Python for introductory programming, namely input.

Consider the following Pascal code:

(******** Pascal code **********)
(* Pascal ascii input of numbers: stdin and file *)
readln(x, y);
readln(fin, x, y);

The first line is for stdin, the second for from file. The variables
x and y will then contain the first two white space separated numbers
the program encounters when that function is called.

Here's how we're currently getting students to do the equivalent in
Python:

######### Python code ###########
# Either: stdin
linestring = raw_input()

# Or: file
linestring = f.readline()

linelist = string.split(linestring)
x = int(linelist[0])
y = int(linelist[1])

# Or perhaps
linestring = raw_input()
x,y = string.split(linestring)  # x and y are now strings eg. '1' 
                                # and '2'
x = int(x)
y = int(y)

Having read through the many threads on this topic on comp.lang.python I
realise and understand that modern programs' input generally requires
thought and customization from the program author. However, we strongly
feel there should be an equivalent to Pascal's readln (which is
basically C's scanf but without the formatting strings) for simple,
generally numerical, whitespace-separated input. 

In the two weeks out trial has been running (one to go), students'
attempts to read in simple two column tables from a file has
consistently caused problems due to the (relative!) complexity of string
splitting.

However, There is no need for a scanf (if your input is sufficiently
complex to require formatting strings then either string or regex
splitting is definitely a more elegant solution).

I have been attempting to write such a function in Python but have been 
struggling with (a) the lack of pointers, and (b) my total ignoarnce of
classes, which I suspect would be helpful. Here's what I have so far
(although note there is no error handling--give it a string response and
it falls over and dies, give it the wrong number of responses and it
falls over and dies, etc., etc.):

############ ninput.py ############

import string

def ninput(n, fin = None, prompt = '', sep = None):
    
    # If not file input then get string from stdin, else get from file
    if fin == None: linestring = raw_input(prompt)
    else: linestring = fin.readline()
    
    # Split up into list with optional seperator argument
    responses = string.split(linestring, sep)
    
    for i in range(len(responses)):
        if '.' in responses[i] or 'e' in responses[i] or \ 
        'E' in responses[i]:
            # i.e. if it looks like a float
            responses[i] = float(responses[i])
        else:
            # i.e if it doesn't look like a float    
            responses[i] = int(responses[i])
            
    # If there was only one response then don't return a list.
    if len(responses) == 1: responses = responses[0] 
    
    return responses[:n]

####################################

And here is a usage example:
>>> x, y  = ninput(2)
5 6.0
>>> print x, type(x)
5 <type 'int'>
>>> print y, type(y)
6.0 <type 'float'>

This has the limitation that the user must pass the number of results
they expect back. This is done implicitly in the Pascal version too (the
number of variables passed to the function). However, error checking is 
difficult as this version stands.

If the student using the ninput function does, e.g.

>>> x = ninput(2)
5 6.0
[5, 6.0] <type 'list'>

This is possibly what should be expected. However, passing the numerical
argument representing the number of results expected does not strike me
as a particularly graceful solution. We would prefer something like the
Pascal way, where the global variables in which the results are to be
stored are passed as parameters. Can anyone suggest a way of doing this?

And if such an equivalent to the Pascal construct was implemented, what
would be the chances of getting it included in, say, the string module
of core Python. We would like such a function but would be reluctant to
use it as we would then be teaching our students a ``dialect'' of
Python.

-- 
Michael Williams



From guido@python.org  Wed May 22 12:42:59 2002
From: guido@python.org (Guido van Rossum)
Date: Wed, 22 May 2002 07:42:59 -0400
Subject: [Edu-sig] Emulating Pascal input
In-Reply-To: Your message of "Wed, 22 May 2002 12:03:20 BST."
 <20020522110320.GA7559@st-annes.oxford.ac.uk>
References: <20020522110320.GA7559@st-annes.oxford.ac.uk>
Message-ID: <200205221142.g4MBgxM09862@pcp742651pcs.reston01.va.comcast.net>

[Michael Williams is looking for a readln() replacement]

If you're willing to change the input format to require commas between
numbers, you could use the standard built-in function input(), which
was put in Python specifically to support this kind of usage.

--Guido van Rossum (home page: http://www.python.org/~guido/)



From michael.williams@st-annes.oxford.ac.uk  Wed May 22 13:25:02 2002
From: michael.williams@st-annes.oxford.ac.uk (Michael Williams)
Date: Wed, 22 May 2002 13:25:02 +0100
Subject: [Edu-sig] Emulating Pascal input
In-Reply-To: <200205221142.g4MBgxM09862@pcp742651pcs.reston01.va.comcast.net>
References: <20020522110320.GA7559@st-annes.oxford.ac.uk> <200205221142.g4MBgxM09862@pcp742651pcs.reston01.va.comcast.net>
Message-ID: <20020522122502.GA6726@st-annes.oxford.ac.uk>

On Wed, May 22, 2002 at 07:42:59AM -0400, Guido van Rossum wrote:
> [Michael Williams is looking for a readln() replacement]
> 
> If you're willing to change the input format to require commas between
> numbers, you could use the standard built-in function input(), which
> was put in Python specifically to support this kind of usage.

I did consider this but:

- the quasi-standard way of delimiting data is whitespace -- not
  commas.

- allowing users of programs to interact using input() is A Bad Thing.

-- 
Michael



From bradford.siemssen@intel.com  Wed May 22 19:55:29 2002
From: bradford.siemssen@intel.com (Siemssen, Bradford)
Date: Wed, 22 May 2002 11:55:29 -0700
Subject: [Edu-sig] Re: Emulating Pascal input
Message-ID: <0DCC27458EB5D51181840002A507069E0EF92D@orsmsx117.jf.intel.com>

Michael,

I'd recommend using the input function as suggested by Guido. However, if
you really feel the need to get the functionality you described try this. I
modified your original routine to have more error handling, and to be a bit
more robust. Note I haven't tested this myself, I'm writing this on company
time, and hey it's python it often works first try, but look over the code
and you should get an idea how to make it work.

The code below when given non-number values in the input will interpret the
values as some default value (typically zeros). The code will prompt the
user to re-enter the values when used interactively when the "strictInput"
flag is passed to the function. Note "strictInput" is incompatible with
reading from a file, there is no way to prompt a file to re-enter bad input.
When the conflict is found an exception is thrown. The code could be
simplified by removing the strictInput flag and associated logic entirely.

Cheers,
Brad

The new code is below.


############ ninput.py ############

import string

# You will need the input part as a separate function so you can use it
# easily when dealing with errors.
def promptedSeparatedInput(fin, prompt, sep):
    # If not file input then get string from stdin, else get from file
    if fin == None: 
       linestring = raw_input(prompt)
    else: 
       linestring = fin.readline()
    
    # Split up into list with optional seperator argument
    responses = string.split(linestring, sep)	
    return responses


def ninput(n, fin = None, prompt = '', sep = None, 
           strictInput = 0, errMsg = "Enter numbers numbskull!!",
           defaultValue = 0.0):

    if strictInput and fin != None:
	raise "invalid parameters to ninput, can not use strictInput with a
file"

    # force reading the input at least once, technically since we don't have
    # any input yet there is an error that will be remedied by getting it.
    inputErrors = 1

    while inputErrors:
        # Assume everything will go right, and we don't have to
        # continue this loop. Error handling code may change that though.
        inputErrors = 0

        # Get the input.
        responses = promptedSeparatedInput(fin, prompt, sep)

        for i in range(len(responses)):
           # You need to catch exceptions that may occur 
           # when converting data of the wrong type
           try:
              if '.' in responses[i] or 'e' in responses[i] or \ 
              'E' in responses[i]:
                  # i.e. if it looks like a float
                  responses[i] = float(responses[i])
              else:
                  # i.e if it doesn't look like a float    
                  responses[i] = int(responses[i])
           except:
              # when doing strict input checking, print the error message,
              # and keep the while loop from terminating so we will get the 
              # input from the user again.
              if strictInput:
                 inputErrors = 1
                 print errMsg
                 break # exit the for loop
              else:
                 # When not doing strictInput just set the value to the
default.
                 responses[i]= defaultValue
            
    # you should take care of the case where less was entered than was
    # expected, fill in spaces with the default value.
    while (n - len(responses)) > 0:
       responses.append(defaultValue)

    # If there was only one response then don't return a list.
    #wrong -> if len(responses) == 1: responses = responses[0] 
    # you really mean if only one response was _EXPECTED_ then don't return
a list
    if n == 1: 
       return responses[0]
    
    return responses[:n]


##############

example usage:

x = ninput(2)
x
[5, 6.0]

# use list unpacking instead of unpacking the list by hand,
# note you'll get an exception if the number of variables to
# unpack into is different than the number returned.
x, y, z = ninput(3)

# or just assign the resulting list
x = ninput(3)

P.S.

Regarding passing the values you want the results stored in to the function
is not possible using python. All variables are just references, and
parameters are local variables, so they are copies of references. Changing
what a local variable references does not change what the outer variable
references.  



From urnerk@qwest.net  Wed May 22 20:42:10 2002
From: urnerk@qwest.net (Kirby Urner)
Date: Wed, 22 May 2002 12:42:10 -0700
Subject: [Edu-sig] Emulating Pascal input
In-Reply-To: <20020522110320.GA7559@st-annes.oxford.ac.uk>
Message-ID: <4.2.0.58.20020522121931.01bb43c0@pop3.norton.antivirus>

>
>######### Python code ###########
># Either: stdin
>linestring = raw_input()
>
># Or: file
>linestring = f.readline()
>
>linelist = string.split(linestring)
>x = int(linelist[0])
>y = int(linelist[1])
>
># Or perhaps
>linestring = raw_input()
>x,y = string.split(linestring)  # x and y are now strings eg. '1'
>                                 # and '2'
>x = int(x)
>y = int(y)

I know people generally say eval() is "bad" but if you're
a student writing your own programs to read your own data
(not writing some generic thing for over-the-web use) it's
unreasonable to expect iron-clad protection against "abuse"
at every turn.

Just do what works.  It's your sandbox, after all.  If
you're intent upon writing malicious stuff, there's no
protecting you from yourself no matter how good a coder
you are.

If it *is* your sandbox, then splitting space-separated
string elements that you know represent numeric data, and
evaluating them to lists containing actual integers or
floats, is pretty straightforward:

def getdata(strdata):
    return [eval(i) for i in strdata.split()]

  >>> getdata('1.2  7e6 -1  10.39')
  [1.2, 7000000.0, -1, 10.390000000000001]

Given x,y = [1,2] is legal syntax, you can write
stuff like:

x,y,z = getdata(f.readline())

where readline() gets you the next 3 numbers in character
form.  x,y and z end up with integer or float values.

This problem comes up a lot on the tutor list.  To quote
Alan, author of a bestselling Python book:

   > I'd like to convert a string to either a float or an integer
   > ``intelligently", i.e.:

   The easy way would be to use eval()
   All the usual caveats around using eval()
   (and exec()) apply of course....

That's from earlier today.

Another option, if you know the data is either ints or
floats, is to apply int() to the string without pre-checking.
int('2.0') is an error, as is int('2e3').  So if int can't
deal with it, pass it on to float:

def getdata2(strdata):
    rtnval = []
    for i in strdata.split():
      try:
         rtnval.append(int(i))
      except:
         rtnval.append(float(i))
    return rtnval

  >>> getdata2('1.2  7e6 -1  10.39')
  [1.2, 7000000.0, -1, 10.390000000000001]

If you don't trust the data to be all ints or floats,
another level could be added, and/or allow it to
crash gracefully (cuz the data must be corrupt).

Kirby




From sdm7g@Virginia.EDU  Wed May 22 23:43:06 2002
From: sdm7g@Virginia.EDU (Steven Majewski)
Date: Wed, 22 May 2002 18:43:06 -0400 (EDT)
Subject: [Edu-sig] Emulating Pascal input
In-Reply-To: <20020522122502.GA6726@st-annes.oxford.ac.uk>
Message-ID: <Pine.OSX.4.43.0205221752180.17974-100000@d-128-61-180.bootp.virginia.edu>


On Wed, 22 May 2002, Michael Williams wrote:

> On Wed, May 22, 2002 at 07:42:59AM -0400, Guido van Rossum wrote:
> > [Michael Williams is looking for a readln() replacement]
> >
> > If you're willing to change the input format to require commas between
> > numbers, you could use the standard built-in function input(), which
> > was put in Python specifically to support this kind of usage.
>
> I did consider this but:
>
> - the quasi-standard way of delimiting data is whitespace -- not
>   commas.
>
> - allowing users of programs to interact using input() is A Bad Thing.

Why is it a "Bad Thing" ?
If these are the students own programs then security isn't a problem.

It's really handy to be able to type expressions for input args instead
of having to get out a calculator to figure out the input args for your
program.

If you do want to restrict the input use something like:

>>> import math
>>> def expr( e ): return eval( e, math.__dict__, {} )

Now you can use string.split to get your whitespace delimited args:

>>> map( expr, sys.stdin.readline().strip().split() )
1 sqrt(2) pi/2 2 3.0 pi
[1, 1.4142135623730951, 1.5707963267948966, 2, 3.0, 3.1415926535897931]


If you want some latitude in the choice of separator, you should use
re.split -- commas change the evaluation of the string:

>>> map( expr, sys.stdin.readline().strip().split() )
1,2,3
[(1, 2, 3)]
>>> map( expr, sys.stdin.readline().strip().split() )
1, 2, 3
[(1,), (2,), 3]



>>> map( expr, re.split( '[, \t]', sys.stdin.readline() ) )


If you want some input error checking on the number types of input values,
you can use an explicit list of coercions:

map( lambda f,x: f(x), [ int, float, expr ], ...


You could wrap up your preferred style in a function or use something
like this (with all the options):

>>> def readln( source=sys.stdin, prompt='>', sep='[ ,\t]', coerce=None ):
...     if source is sys.stdin:  inp = lambda : raw_input( prompt )
...     else:  inp = source.readline
...     args = re.split( sep, inp().strip() )
...     if coerce is None:
...             return map( expr, args )
...     else:
...             return map( lambda f,x: f(x), coerce, args )
...


Using the coercion functions lets you input strings without requiring
quotes:

>>> readln( coerce=(str,int) )
> abc 1
['abc', 1]


-- Steve Majewski





From lolita86@libero.it  Thu May 23 18:25:03 2002
From: lolita86@libero.it (lolita)
Date: Fri, 24 May 2002 00.25.00 +0200
Subject: [Edu-sig] Eros e soldi:guadagna con internet 0,08 euro a clic
Message-ID: <E17B10s-0007kP-00@mail.python.org>

sono lolita=2C voglio presentarti il mio nuovo sito
affiliazione gratuita con guadagni immediati=3A         erotismo=2C chat=2Cloghi e sonerie etc=2C etc=2C 


l'unico sito che paga cos=EC tanto 0=2C08 euro a clic =2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2Eguarda bene la pg di affiliazione=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2Ee buon divertimento=2E
 

visita il sito=3A         http=3A=2F=2Fmembers=2Exoom=2Eit=2Fmarym1976       http=3A=2F=2Fmembers=2Exoom=2Eit=2Fmarym1976       http=3A=2F=2Fmembers=2Exoom=2Eit=2Fmarym1976         
 
         
 
    
 










From urnerk@qwest.net  Sat May 25 19:09:54 2002
From: urnerk@qwest.net (Kirby Urner)
Date: Sat, 25 May 2002 11:09:54 -0700
Subject: [Edu-sig] Re: New Kind of Science (Wolfram)
In-Reply-To: <4.2.0.58.20020522121931.01bb43c0@pop3.norton.antivirus>
References: <20020522110320.GA7559@st-annes.oxford.ac.uk>
Message-ID: <4.2.0.58.20020525102920.01c58470@pop3.norton.antivirus>

I recently got my copy of Stephan Wolfram's new book,
'A New Kind of Science' (2002) which focuses on complexity
using computer expriments with cellular automata, ala
the Game of Life (but the rules are often even simpler).

The early part of the book focuses on grids populated
according to simple rules, starting from a top row with
just one black cell (the rest white) and working downward.
Cells are considered in groups of 3, with the cell directly
below the middle one turning white or black based on the
mapping rule, i.e. based on how a given combination of 3
(white or black = 8 possibilities) gives a next generation
cell in the next row.

For example, rule 30 looks like this:

  >>> import nks
  >>> p = nks.Pattern(30)
  >>> p.sayrule()
  111 --> 0
  110 --> 0
  101 --> 0
  100 --> 1
  011 --> 1
  010 --> 1
  001 --> 1
  000 --> 0

The combinations on the left are fixed (always the same 8
in that order) whereas the string of 0s and 1s defines a
unique binary number from 0 to 255.  If I fill with 0s to
8 positions, and ask for 30 in binary, I get:

  >>> nks.base2(30,8)
  '00011110'

...which is the same rule as above.

So if in the top row you had 20 whites plus a middle black:

 >>> p = nks.Pattern(30,width=20)
 >>> p.gen
'000000000010000000000'

Then successive rows would be:

  >>> p.next()
  '000000000111000000000'

and:

  >>> p.next()
  '000000001100100000000'

Complexity comes in with some rules (including 30) in a
dramatic fashion, whereas other rules give terminal,
static results, or an expanding fractal of nested,
self-similar patterns (which we might consider complex,
yet here the term is reserved for more unpredictable,
more apparently random patterns).

The beginning of the generation process of rule 30 is
depicted here:

http://www.inetarena.com/~pdx4d/ocn/graphics/nks30a.png

and after a few more rows:

http://www.inetarena.com/~pdx4d/ocn/graphics/nks30b.png

and finally (to a lot more rows):

http://www.inetarena.com/~pdx4d/ocn/graphics/nks30c.png

This last picture is the default output of:

   >>> import nks
   >>> p = nks.Pattern(30)
   >>> p.run()

(I have the user then manually opening Povray to render nks30.pov
-- an automated render invoked from within Python would be
another option (but I like to tweak settings and re-render, so
manual is better)).

It turns out the Wolfram has been exploiting the randomness
in this pattern to serve as a random number generator for
Mathematica all this time (pg. 317).

So, the pictures above come from using my usual Python + Povray
combo.  Another approach would be to populate pixels directly
using PIL or some similar set of tools.  But I wanted quick
results through recycling existing code I've already written.
Another side effect is we get little spheres in place of the
flat squares used in Wolfram's book.  That's OK.  The patterns
are what's important.

I basically just use literal strings of 0s and 1s to generate
the pictures.  I don't keep a whole grid in memory -- each
successive row overwrites the one before, so there's only the
previous row and the next one to mess with at any given time.
The Pattern object accepts any rule from 0 to 255 as input and
the run() method creates the Povray file to 388 generations
(the default).

The first draft of my source code is at:
http://www.inetarena.com/~pdx4d/ocn/python/nks.py

Note dependencies on povray.py and coords.py -- both posted in
the same subdirectory.  And of course you need Povray, available
from http://www.povray.org/

Kirby





From pobrien@orbtech.com  Sat May 25 19:19:00 2002
From: pobrien@orbtech.com (Patrick K. O'Brien)
Date: Sat, 25 May 2002 13:19:00 -0500
Subject: [Edu-sig] Re: New Kind of Science (Wolfram)
In-Reply-To: <4.2.0.58.20020525102920.01c58470@pop3.norton.antivirus>
Message-ID: <NBBBIOJPGKJEKIECEMCBCENFNBAA.pobrien@orbtech.com>

[Kirby Urner]
>
> I recently got my copy of Stephan Wolfram's new book,
> 'A New Kind of Science' (2002) which focuses on complexity
> using computer expriments with cellular automata, ala
> the Game of Life (but the rules are often even simpler).
>
> [Examples snipped]

Cool stuff. This book is on my wish list. How do you like the book overall?
And is it relatively easy to translate into Python code, such as the
examples you gave?

---
Patrick K. O'Brien
Orbtech




From urnerk@qwest.net  Sat May 25 20:06:11 2002
From: urnerk@qwest.net (Kirby Urner)
Date: Sat, 25 May 2002 12:06:11 -0700
Subject: [Tutor] RE: [Edu-sig] Re: New Kind of Science (Wolfram)
In-Reply-To: <NBBBIOJPGKJEKIECEMCBCENFNBAA.pobrien@orbtech.com>
References: <4.2.0.58.20020525102920.01c58470@pop3.norton.antivirus>
Message-ID: <4.2.0.58.20020525115527.01c69760@pop3.norton.antivirus>

>
>Cool stuff. This book is on my wish list. How do you like the
>book overall?

I like that it's written for a broad audience and doesn't assume
much specialized knowledge, except maybe in the notes section.
It's quite a thick tome -- about 1200 pages not including the
index.  Lots of illustrations and diagrams (b&w or grayscale).
The organization is meticulous, with lots of specific citations
to page numbers

>And is it relatively easy to translate into Python code, such as the
>examples you gave?

The examples I gave are the simplest, but are also core/critical.
You can get fancier of course, and Python'd be up to the task,
although Wolfram is understandably focussed on Mathematica as
his implementation system of choice.

Kirby




From i.linkweiler@gmx.de  Wed May 29 23:47:25 2002
From: i.linkweiler@gmx.de (Ingo Linkweiler)
Date: Thu, 30 May 2002 00:47:25 +0200
Subject: [Edu-sig] Python @ Education: What are your problems?
Message-ID: <3CF55A7D.C81ED516@gmx.de>

Hello,

are you using python for teaching programing?

I am just writing a diploma paper about python and want to know your
experiences with python.

What do you like when teaching python?
For example:
- Easy readable syntax
- High Level language
- Lists, Tupels, Dictionaries included
- interpreter: Everything can be tested
- Many tools available
.....

AND MORE IMPORTANT:
What are your problems with python? Are pupils/students having any
problems or often asked questions?
What do you dislike at python?

For example:
- When teaching C or Pascal, newbies do not know, where to set a ";" and

where not. Any similar problems with Python?
- Why must I set a ":" after "if" or "for" ?  " if x == y : "
.....

I hope you have many suggestions.

regards,

Ingo




From michael.williams@st-annes.oxford.ac.uk  Thu May 30 12:16:23 2002
From: michael.williams@st-annes.oxford.ac.uk (Michael Williams)
Date: Thu, 30 May 2002 12:16:23 +0100
Subject: [Edu-sig] Python @ Education: What are your problems?
In-Reply-To: <3CF55A7D.C81ED516@gmx.de>
References: <3CF55A7D.C81ED516@gmx.de>
Message-ID: <20020530111623.GD21073@st-annes.oxford.ac.uk>

On Thu, May 30, 2002 at 12:47:25AM +0200, Ingo Linkweiler wrote:
> are you using python for teaching programing?

We're about to start. We've been running quasi-competetive trials of
Python and C, with a view to replacing the current Pascal implementation
of the undergraduate programming syllabus here as the University of
Oxford's Physics department.

> I am just writing a diploma paper about python and want to know your
> experiences with python.
> 
> What do you like when teaching python?
> For example:
> - Easy readable syntax

Check.

> - High Level language

Check. We would never consider teaching anything ``low-level'' in
scientific programming (C doesn't count).

> - Lists, Tupels, Dictionaries included

Not bothered for our purposes. Lists are mentioned only very briefly in
the context of the range() function, but we got away without discussing
tuples or dictionaries at all. I say ``got away'' because we only have 1
day to teach programming(!) so almost anything we can avoid we will.

> - interpreter: Everything can be tested

I thought this was going to be a big deal. We designed the trial to give
students almost a free reign over whether to use modules or the
interpreter and *none* of them (out of about 40) used the interpreter. I
think this might be due to the length of the programs they were writing
(none more than about 100 lines), so they can derive practically the
same amount of interactivity from repeatedly re-running the the program.
Perhaps when asked to write longer programs, when it becomes unwieldy
to make changes for debugging purposes they might use it.

> - Many tools available

The standard library is nice, but we make particularly heavy use of
Numeric Python and Gnuplot.py

> AND MORE IMPORTANT:
> What are your problems with python? Are pupils/students having any
> problems or often asked questions?

At the moment it's hard to determine if the consistent problems are due
to the way the course is written OR peculiar to Python OR generic
problems that students would encounter in learning programming in every 
language.

We do seem to be having some trouble with the inconsistency of writing
to stdout and file. To make things easier early on we have them write to
screen using the print command. They can then separate abritrary
variables using commas. However then they do fout.write(myfloat, myint,
"Some numbers") and it doesn't work they get confused. It may be better
to teach them to write to screen using sys.stdout.write from the start
as that then provides a consistent writing tool.

> What do you dislike at python?

Input of whitespace separated numbers from file or stdin is relatively
complex in Python:

>>> line = raw_input()
>>> snumbers = string.split(line)
>>> x, y = float(snumbers[0], snumbers[1])

unless I'm missing something obvious. The comparable expression in
Pascal is 

readln(x, y)

> Any similar problems with Python?
> - Why must I set a ":" after "if" or "for" ?  " if x == y : "

I explain this by appealing to their understanding of grammar: A colon
introduces a new idea. (Apologies to whoever it was came up with that
explanation on either this list or tutor). They seem to forget it quite
regularly, but the error message leaves nothing to the imagination.

If you (or anyone) are interested in seeing the handbook for the course,
from which our students work, then I could post the URL to a *work in
progress* version of it here. It's available in HTML, PDF and PS.

-- 
Michael



From guido@python.org  Thu May 30 13:44:26 2002
From: guido@python.org (Guido van Rossum)
Date: Thu, 30 May 2002 08:44:26 -0400
Subject: [Edu-sig] Python @ Education: What are your problems?
In-Reply-To: Your message of "Thu, 30 May 2002 12:16:23 BST."
 <20020530111623.GD21073@st-annes.oxford.ac.uk>
References: <3CF55A7D.C81ED516@gmx.de>
 <20020530111623.GD21073@st-annes.oxford.ac.uk>
Message-ID: <200205301244.g4UCiQp07685@pcp742651pcs.reston01.va.comcast.net>

> > - Lists, Tupels, Dictionaries included
> 
> Not bothered for our purposes. Lists are mentioned only very briefly
> in the context of the range() function, but we got away without
> discussing tuples or dictionaries at all. I say ``got away'' because
> we only have 1 day to teach programming(!) so almost anything we can
> avoid we will.

It seems your course is somewhat unusual in that apparently has a
heavy focus on scientific computing.  Not surprising given that you're
in the Physics program!  Usually data structures are a very important
part of a programming curriculum, and then lists and dicts are
crucial.  Does this mean you represent all arrays of numbers with
Numeric arrays?

> > - interpreter: Everything can be tested
> 
> I thought this was going to be a big deal. We designed the trial to
> give students almost a free reign over whether to use modules or the
> interpreter and *none* of them (out of about 40) used the
> interpreter. I think this might be due to the length of the programs
> they were writing (none more than about 100 lines), so they can
> derive practically the same amount of interactivity from repeatedly
> re-running the the program.  Perhaps when asked to write longer
> programs, when it becomes unwieldy to make changes for debugging
> purposes they might use it.

Interesting.  Could it also be that your students have reasonable
computer experience on Windows, where an interactive command line
interface is not used?

> We do seem to be having some trouble with the inconsistency of
> writing to stdout and file. To make things easier early on we have
> them write to screen using the print command. They can then separate
> abritrary variables using commas. However then they do
> fout.write(myfloat, myint, "Some numbers") and it doesn't work they
> get confused. It may be better to teach them to write to screen
> using sys.stdout.write from the start as that then provides a
> consistent writing tool.

Point taken.  It's just that sys.stdout.write is so cumbersome to
produce neat-looking output. :-(

I wonder what could be done to fix this?  Making write() act more like
print is impossible for backwards compatibility reasons (separate
print calls always insert a space or a newline between data, and
separate write() calls do neither).  Maybe we should add a file method

    f.printf("format string", args)

and a built-in function

    printf("format string", args)

and deprecate the print statement???

--Guido van Rossum (home page: http://www.python.org/~guido/)



From jeff@elkner.net  Thu May 30 14:12:48 2002
From: jeff@elkner.net (Jeffrey Elkner)
Date: 30 May 2002 09:12:48 -0400
Subject: [Edu-sig] Python @ Education: What are your problems?
In-Reply-To: <3CF55A7D.C81ED516@gmx.de>
References: <3CF55A7D.C81ED516@gmx.de>
Message-ID: <1022764414.3107.114.camel@mdeicaza>

On Wed, 2002-05-29 at 18:47, Ingo Linkweiler wrote:
> are you using python for teaching programing?

Please see the "Who teaches Python" page at:

http://www.ibiblio.org/obp/pyBiblio/schools.php

As you find schools not listed on the page, I would be grateful if you
could send them my way.  I would like to keep this list as complete and
up to date as possible to facilitate general communication (and aid in
inquiries like yours ;-)

> I am just writing a diploma paper about python and want to know your
> experiences with python.
> 
> What do you like when teaching python?
> For example:
> - Easy readable syntax
> - High Level language
> - Lists, Tupels, Dictionaries included
> - interpreter: Everything can be tested
> - Many tools available
> .....
> 
> AND MORE IMPORTANT:
> What are your problems with python? Are pupils/students having any
> problems or often asked questions?
> What do you dislike at python?
> 
> For example:
> - When teaching C or Pascal, newbies do not know, where to set a ";" and
> 
> where not. Any similar problems with Python?
> - Why must I set a ":" after "if" or "for" ?  " if x == y : "
> .....

I've written two papers about the Yorktown High School experience with
Python.  They can each be found on my homepage:

http://www.elkner.net


I would like to hear back from you regarding the results of your
inquiry.  It would be great if we could include them on the pyBiblio
site.

jeff elkner
yorktown high school
arlington, va





From michael.williams@st-annes.oxford.ac.uk  Thu May 30 14:30:30 2002
From: michael.williams@st-annes.oxford.ac.uk (Michael Williams)
Date: Thu, 30 May 2002 14:30:30 +0100
Subject: [Edu-sig] Python @ Education: What are your problems?
In-Reply-To: <200205301244.g4UCiQp07685@pcp742651pcs.reston01.va.comcast.net>
References: <3CF55A7D.C81ED516@gmx.de> <20020530111623.GD21073@st-annes.oxford.ac.uk> <200205301244.g4UCiQp07685@pcp742651pcs.reston01.va.comcast.net>
Message-ID: <20020530133030.GE21073@st-annes.oxford.ac.uk>

On Thu, May 30, 2002 at 08:44:26AM -0400, Guido van Rossum wrote:
> > > - Lists, Tupels, Dictionaries included
> > 
> > Not bothered for our purposes. Lists are mentioned only very briefly
> > in the context of the range() function, but we got away without
> > discussing tuples or dictionaries at all. I say ``got away'' because
> > we only have 1 day to teach programming(!) so almost anything we can
> > avoid we will.
> 
> It seems your course is somewhat unusual in that apparently has a
> heavy focus on scientific computing.  Not surprising given that you're
> in the Physics program!  

Indeed.

> Usually data structures are a very important
> part of a programming curriculum, and then lists and dicts are
> crucial.  Does this mean you represent all arrays of numbers with
> Numeric arrays?

Yes.

> > > - interpreter: Everything can be tested
> > 
> > I thought this was going to be a big deal. We designed the trial to
> > give students almost a free reign over whether to use modules or the
> > interpreter and *none* of them (out of about 40) used the
> > interpreter. I think this might be due to the length of the programs
> > they were writing (none more than about 100 lines), so they can
> > derive practically the same amount of interactivity from repeatedly
> > re-running the the program.  Perhaps when asked to write longer
> > programs, when it becomes unwieldy to make changes for debugging
> > purposes they might use it.
> 
> Interesting.  Could it also be that your students have reasonable
> computer experience on Windows, where an interactive command line
> interface is not used?

Yes. Five years ago we made the assumption that students had *no*
experience. Now we make the assumption that they have Windows experience
(I'll leave the question of which one is preferable as an exercise for
the reader ;->). They seem to find the UNIX environment quite difficult
for the first couple of hours, and I don't doubt that an unwillingness
to work intereactively in Python is related.

In the handbook we insist they use the Shell only once (for the ``hello
world'' program). Perhaps we should have them use it for a little
longer.

Interestingly, the experienced UNIX users and more advanced programmers
(not generally the same people as very few students come knowing, for
example, C, but Visual Basic is common), do tend to use the Shell more
when debugging the more substantial problems.

> > We do seem to be having some trouble with the inconsistency of
> > writing to stdout and file. To make things easier early on we have
> > them write to screen using the print command. They can then separate
> > abritrary variables using commas. However then they do
> > fout.write(myfloat, myint, "Some numbers") and it doesn't work they
> > get confused. It may be better to teach them to write to screen
> > using sys.stdout.write from the start as that then provides a
> > consistent writing tool.
> 
> Point taken.  It's just that sys.stdout.write is so cumbersome to
> produce neat-looking output. :-(

Indeed. I can just imagine how terrifying ``Hello World'' would look to
our students (many of whom currently hate and avoid programming at all
costs) with a printf statement. Most of them are happy with formatted
output by the end of the day though.

> I wonder what could be done to fix this?  Making write() act more like
> print is impossible for backwards compatibility reasons (separate
> print calls always insert a space or a newline between data, and
> separate write() calls do neither).  

That was going to be my suggestion, but fair enough.

> Maybe we should add a file method
> 
>     f.printf("format string", args)

How about a file method f.print(arbitrary comma separated variables)
that works in the same way as print? 

> and a built-in function
> 
>     printf("format string", args)
>
> and deprecate the print statement???

Deprecating the print statement is, I think, an unecessarily big change
to the language. This trivial method of writing, that does all sorts of
voodoo to format intelligently is one of Python's strongest features.
Perhaps a printf should be included though -- students learning Python
would then have another skill applicable to C. Part of the political
resistance I'm experiencing seems to be related to the fact that Python
does so much for you--print being a particular example of this.

-- 
Michael



From djrassoc01@mindspring.com  Thu May 30 14:58:20 2002
From: djrassoc01@mindspring.com (Dr. David J. Ritchie)
Date: Thu, 30 May 2002 08:58:20 -0500
Subject: [Edu-sig] Python @ Education: What are your problems?
References: <3CF55A7D.C81ED516@gmx.de>
Message-ID: <3CF62FDB.C984FC75@mindspring.com>


Ingo Linkweiler wrote:

> Hello,
>
> are you using python for teaching programing?

Yes, I have used it over the last year for two middle school
computer clubs (6th graders - 8th graders) that meet once
per week for an hour after school. I have written a handout
(~60 pages) which the club sessions have let me classroom test
and I am in the process now of revising it based on the year's
experience for use with next year's computer clubs.

>
> I am just writing a diploma paper about python and want to know your
> experiences with python.
>
> What do you like when teaching python?

My main attraction for trying Python this year instead of Perl
(which I had done for several years previously) was the clarity of the
object-oriented approach that presents itself in Python as compared to
that in Perl where it is more buried and requires more of a stretch to
understand clearly what is going on.  I thought it was important to
give the kids more experience with object-oriented programming since
they are likely to see so much of that later if they go on in computing.

>
> AND MORE IMPORTANT:
> What are your problems with python?

No particular problems.  The integration with Tk (as exemplified
by the bundle that includes both on the CD that comes with the
O'Reilly Learning Perl book is particularly helpful.  It isn't that I
am a fan of Tk -- any gui is fine -- it's that it is a smooth install to
get both so that there is less complication in getting staff to install it
on the school's computers.

> Are pupils/students having any
> problems or often asked questions?

No, they seem to have done fine.  One girl extended the adventure
game template I wrote for them to try to adapt so that it let the
characters move Northwest, Southwest, Northeast, and Southeast
in addition to NESW.  Mainly, she did a cut and paste job but she was
successful
at it--including introducing bugs and figuring out what the problem was
and fixing them.  Of course, she was pretty experienced having taken
Perl from me two years earlier when she was in sixth grade.

>
> What do you dislike at python?

Nothing particularly.  It's fine. Perl's fine. They all have their uses.
The great thing about teaching either to 6th, 7th, and 8th graders is
that they have no context in which to interpret things so they don't
buy into religious wars about Perl vs. Python vs. Visual Basic vs.
C++ vs. Unix vs. Windows. So, I try to avoid communicating my
hang-ups to them in an effort to stave off yet another generation of
religious wars about those subjects.  For them, it's all about making the
computer do something and it doesn't matter to them much which it is.

>
> I hope you have many suggestions.

Good luck with your studies and survey.

--David

--
Dr. David J. Ritchie, Sr.
djrassoc01@mindspring.com
http://home.mindspring.com/~djrassoc01/





From guido@python.org  Thu May 30 16:48:18 2002
From: guido@python.org (Guido van Rossum)
Date: Thu, 30 May 2002 11:48:18 -0400
Subject: [Edu-sig] Python @ Education: What are your problems?
In-Reply-To: Your message of "Thu, 30 May 2002 14:30:30 BST."
 <20020530133030.GE21073@st-annes.oxford.ac.uk>
References: <3CF55A7D.C81ED516@gmx.de> <20020530111623.GD21073@st-annes.oxford.ac.uk> <200205301244.g4UCiQp07685@pcp742651pcs.reston01.va.comcast.net>
 <20020530133030.GE21073@st-annes.oxford.ac.uk>
Message-ID: <200205301548.g4UFmIM24158@odiug.zope.com>

> In the handbook we insist they use the Shell only once (for the
> ``hello world'' program). Perhaps we should have them use it for a
> little longer.

The standard tutorial uses the Python shell extensively, to show how
various language constructs work.  Maybe you can borrow from there.

> Interestingly, the experienced UNIX users and more advanced
> programmers (not generally the same people as very few students come
> knowing, for example, C, but Visual Basic is common), do tend to use
> the Shell more when debugging the more substantial problems.

Makes sense -- interactive debugging is a very powerful tool.

> > Maybe we should add a file method
> > 
> >     f.printf("format string", args)
> 
> How about a file method f.print(arbitrary comma separated variables)
> that works in the same way as print? 

Alas, print is a keyword and can't be reused as a method name.

> > and a built-in function
> > 
> >     printf("format string", args)
> >
> > and deprecate the print statement???
> 
> Deprecating the print statement is, I think, an unecessarily big change
> to the language. This trivial method of writing, that does all sorts of
> voodoo to format intelligently is one of Python's strongest features.

Ah, I must've suffered from temporary memory loss!  In Python 2.0 and
later you can use the print statement to write to a file, using

    print >>f, var, var, ...

So forget about my suggestion of adding printf().

--Guido van Rossum (home page: http://www.python.org/~guido/)



From urnerk@qwest.net  Thu May 30 14:13:39 2002
From: urnerk@qwest.net (Kirby Urner)
Date: Thu, 30 May 2002 09:13:39 -0400
Subject: [Edu-sig] Python @ Education: What are your problems?
In-Reply-To: <20020530111623.GD21073@st-annes.oxford.ac.uk>
References: <3CF55A7D.C81ED516@gmx.de> <20020530111623.GD21073@st-annes.oxford.ac.uk>
Message-ID: <200205300913.39956.urnerk@qwest.net>

> Input of whitespace separated numbers from file or stdin is relatively
>
> complex in Python:
> >>> line =3D raw_input()
> >>> snumbers =3D string.split(line)
> >>> x, y =3D float(snumbers[0], snumbers[1])
>
> unless I'm missing something obvious. The comparable expression in
> Pascal is
>
> readln(x, y)

True, more complicated, as per previous thread.

def readln():  # defined once
    return [eval(i) for i in raw_input().split()]

x,y =3D readln()  # used elsewhere

is a quickie workaround. =20

Seems if your goal is to get right to Physics and not master Python as a=20
language per se (i.e. Python is very much a means to an end), then=20
you could teach students to go:

   from courseware import *=20

at the top of their programs.   Inside of this module could be included
various shortcuts of this nature (e.g. readln).  This might save time
better spent on physics.  In other words, code up to a higher, yet more
specialized level, and use this customized API in class (the module=20
might well include some routines for Numeric and GnuPlot stuff).

Kirby




From michael.williams@st-annes.oxford.ac.uk  Fri May 31 11:36:20 2002
From: michael.williams@st-annes.oxford.ac.uk (Michael Williams)
Date: Fri, 31 May 2002 11:36:20 +0100
Subject: [Edu-sig] Python @ Education: What are your problems?
In-Reply-To: <200205300913.39956.urnerk@qwest.net>
References: <3CF55A7D.C81ED516@gmx.de> <20020530111623.GD21073@st-annes.oxford.ac.uk> <200205300913.39956.urnerk@qwest.net>
Message-ID: <20020531103620.GH22323@st-annes.oxford.ac.uk>

On Thu, May 30, 2002 at 09:13:39AM -0400, Kirby Urner wrote:
> Seems if your goal is to get right to Physics and not master Python as a 
> language per se (i.e. Python is very much a means to an end), then 
> you could teach students to go:
> 
>    from courseware import * 
> 
> at the top of their programs.   Inside of this module could be included
> various shortcuts of this nature (e.g. readln).  This might save time
> better spent on physics.  In other words, code up to a higher, yet more
> specialized level, and use this customized API in class (the module 
> might well include some routines for Numeric and GnuPlot stuff).

We already have such a library that imports some functions for printing
programs and output, and the appropriate Numeric and Gnuplot objects. If
we found a satisfactory way of simplifying the kind of input we want to
do this is precisely where it would go.

As you say, we're in the business of teaching Physics (and programming
for Physics) and not Python. Our main concern is getting a consistent
input and output model from both stdin/out and file. The string.split()
method isn't appallingly complex and is by no means a show-stopper, so
if it turns out that using it increases student's understanding of what
is going on by making everything more consistent we may stick with that.

-- 
Michael



From urnerk@qwest.net  Fri May 31 15:33:52 2002
From: urnerk@qwest.net (Kirby Urner)
Date: Fri, 31 May 2002 10:33:52 -0400
Subject: [Edu-sig] Python @ Education: What are your problems?
In-Reply-To: <20020531103620.GH22323@st-annes.oxford.ac.uk>
References: <3CF55A7D.C81ED516@gmx.de> <200205300913.39956.urnerk@qwest.net> <20020531103620.GH22323@st-annes.oxford.ac.uk>
Message-ID: <200205311033.52586.urnerk@qwest.net>

> We already have such a library that imports some functions for printing
> programs and output, and the appropriate Numeric and Gnuplot objects. I=
f
> we found a satisfactory way of simplifying the kind of input we want to
> do this is precisely where it would go.

Great minds think alike I guess :-D.

Speaking of physics, you've no doubt checked into VPython, orginally
developed to support study of physics using real time graphics routines a=
t
Carnegie-Mellon Univ, as I understand the history:  http://www.vpython.or=
g/

Seems to me the interface between physics and programming is becoming
richer (and yet more affordable) by the day.  Makes me nostalgic for life=
=20
as an undergraduate (except in my day we had few PCs, no Linux, and
no Python -- but I've got all that now, and a day job to boot).

Kirby




From Burley, Brent" <Brent.Burley@disney.com  Fri May 31 23:56:46 2002
From: Burley, Brent" <Brent.Burley@disney.com (Burley, Brent)
Date: Fri, 31 May 2002 15:56:46 -0700
Subject: [Edu-sig] Re: Python @ Education: What are your problems?
References: <20020531160003.14074.47009.Mailman@mail.python.org>
Message-ID: <3CF7FFAE.92DF840B@fa.disney.com>

> From: Kirby Urner <urnerk@qwest.net>
...
> def readln():  # defined once
>     return [eval(i) for i in raw_input().split()]
> 
> x,y = readln()  # used elsewhere
> 
> is a quickie workaround.

Clever, and concise!

Here's a more robust (albeit verbose) version that checks the number
and types of the arguments:

def readln(spec, prompt=""):
    types = { 'i' : int, 'f' : float, 's' : str }
    while 1:
        words = raw_input(prompt).split()
        if len(words) != len(spec):
            print 'You must input', len(spec), 'items, please try
again'
            continue
        try:
            return [types[s](w) for s,w in zip(spec, words)]
        except KeyError:
            print 'Invalid type specifier passed to readln:', s
            print "  You must pass in a string of i's, f's, or s's"
            return
        except ValueError, e:
            print 'Invalid input, please try again'
            print '  ', e

>>> print readln('ifs', 'input (int float string): ')
input (int float string): 
You must input 3 items, please try again
input (int float string): a b c
Invalid input, please try again
   invalid literal for int(): a
input (int float string): 1 2 3
[1, 2.0, '3']
>>>

Or, if you only care about inputting numbers, you can use this simpler
version:

def readnumbers(num, prompt=""):
    while 1:
        words = raw_input(prompt).split()
        if len(words) != num:
            print 'You must input', num, 'numbers, please try again'
            continue
        try:
            return [float(w) for w in words]
        except ValueError, e:
            print 'Invalid input, please try again'
            print '  ', e

>>> readnumbers(3, 'x y z? ')    
x y z? 1 2
You must input 3 numbers, please try again
x y z? 1 2 z
Invalid input, please try again
   invalid literal for float(): z
x y z? 1 2 3
[1.0, 2.0, 3.0]


	Brent



From Louis.Bertrand@durhamc.on.ca  Fri May 31 23:53:48 2002
From: Louis.Bertrand@durhamc.on.ca (Louis Bertrand)
Date: Fri, 31 May 2002 18:53:48 -0400
Subject: [Edu-sig] Python @ Education: What are your problems?
Message-ID: <F3313FA912E83F4DBD1748E06453C00E09B26D@dcmailex.durhamc.on.ca>

[warning to edu-sig readers -- somewhat long]

Hello,

I use Python to teach the first year programming course in the "computer
systems" and "computer programmer" streams in the School of Technology here
at Durham College. The intent of this course is to take students with no
prior programming experience and teach them the fundamentals: variables,
branches, loops, functions, objects and a bit (excuse the term) of binary &
hex. Students are from mixed backgrounds (fresh out of high school,
returning to school as mature student, foreign students), aiming for
practical, hands-on training as opposed to university-style courses.

The experience has been mixed but mostly good.

Java was the first choice for this course but I got nightmares at the
thought of teaching monstrosities like:
  class HelloWorld {
      public static void main(String[] args) {
          System.out.println("Hello World");
      }
  }
instead of:
print "Hello World"

Interpreted rather than compiled: driving the interpreter directly, line by
line is great for in-class demonstrations because I can "walk" through an
example, then run it full speed from the .py file. This is especially good
for Tkinter examples.

Objects: Python's object model is simple and uncluttered so that's good.
However the "self" reference in method parameter lists and for instance
variables is a source of aggravation. There is trouble reconciling the fact
that a method is nested in the class definition, but it still needs to be
told about itself, and all instance variables need to also be referenced.
Java's "this" is more subtle -- you don't see it, but it's there when you
need it. You don't need to introduce it immediately.

Dynamic typing: mixed blessing. Students don't trip on types, but they
aren't prepared for the strict typing  in Java and the little disasters due
to type errors in C.

Simpler syntax. No squiggles and semicolons to worry about. However, this
leaves the students unprepared for the squiggles and semicolons in C, C++
and Java.

Indenting block structure. Nice because it matches the pseudocode I do in
class. However, some students often don't get it and occasionally give me:
if x == y :
  # do some stuff
  else :
    # do something else
    # Sorry, I couldn't get it to work. It kept giving me errors :(
Basically, since IDLE keeps suggesting an indent, they never de-indent when
they are done the particular block.


The fact that nobody around here had heard of Python before I started has
been a constant aggravation. "If it's not popular, it can't be any good"
(read between the lines: "if it didn't come from Microsoft, it's no good"),
or the even deadlier slag "it won't help our grads get a job"). This leads
to pushback from other teachers and some students who feel I'm teaching
something totally irrelevant and "out in left field". Visual Basic, C, C++,
Java and Turing are the alternatives proposed. (References and "ammunition"
welcome).

IDLE, while it meets its design goals for portability and simplicity, may be
_too_ simple. For example, IDLE doesn't even let students print out their
work -- I have to get them to copy and paste their console output to
Notepad. I'm afraid that we have to "market" to students these days, and the
glitz and flash of Microsoft Visual Studio totally obliterates IDLE. I need
to find a more Microsoft-oriented IDE (but not python for dot N0T) .

Anyway, that's it for now (I vented my frustrations). On the whole, I'll
keep doing the course my way. I want to change a few things, but Python
stays. If there are points you'd like me to follow up, feel free to ask
privately or on the edu-sig list.

Ciao
 --Louis

Louis Bertrand
Durham College, Oshawa, Canada
louis.bertrand@durhamc.on.ca