Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #34222 > unrolled thread

[newbie] problem with usbtmc-communication

Started byJean Dubois <jeandubois314@gmail.com>
First post2012-12-04 04:14 -0800
Last post2012-12-07 05:51 -0800
Articles 6 on this page of 26 — 6 participants

Back to article view | Back to comp.lang.python


Contents

  [newbie] problem with usbtmc-communication Jean Dubois <jeandubois314@gmail.com> - 2012-12-04 04:14 -0800
    Re: [newbie] problem with usbtmc-communication wrw@mac.com - 2012-12-04 09:33 -0500
      Re: problem with usbtmc-communication Jean Dubois <jeandubois314@gmail.com> - 2012-12-04 08:12 -0800
        Re: problem with usbtmc-communication wrw@mac.com - 2012-12-05 10:26 -0500
          Re: problem with usbtmc-communication Jean Dubois <jeandubois314@gmail.com> - 2012-12-05 12:38 -0800
            Re: problem with usbtmc-communication wrw@mac.com - 2012-12-05 17:21 -0500
              Re: problem with usbtmc-communication Jean Dubois <jeandubois314@gmail.com> - 2012-12-06 05:50 -0800
                Re: problem with usbtmc-communication wrw@mac.com - 2012-12-06 09:50 -0500
                  Re: problem with usbtmc-communication Jean Dubois <jeandubois314@gmail.com> - 2012-12-06 11:41 -0800
                    Re: problem with usbtmc-communication Dave Angel <d@davea.name> - 2012-12-06 15:10 -0500
                    Re: problem with usbtmc-communication wrw@mac.com - 2012-12-06 15:15 -0500
                      Re: problem with usbtmc-communication Jean Dubois <jeandubois314@gmail.com> - 2012-12-07 05:46 -0800
                        Re: problem with usbtmc-communication Jean Dubois <jeandubois314@gmail.com> - 2012-12-10 05:31 -0800
                          Re: problem with usbtmc-communication wrw@mac.com - 2012-12-10 10:34 -0500
                            Re: problem with usbtmc-communication Jean Dubois <jeandubois314@gmail.com> - 2012-12-10 22:58 -0800
                              Re: problem with usbtmc-communication wrw@mac.com - 2012-12-11 09:34 -0500
                                Re: problem with usbtmc-communication Jean Dubois <jeandubois314@gmail.com> - 2012-12-11 12:48 -0800
                                  Re: problem with usbtmc-communication wrw@mac.com - 2012-12-11 21:21 -0500
                              Re: problem with usbtmc-communication Jerry Hill <malaclypse2@gmail.com> - 2012-12-11 19:49 -0500
                                Re: problem with usbtmc-communication Jean Dubois <jeandubois314@gmail.com> - 2012-12-12 08:16 -0800
            Re: problem with usbtmc-communication Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-12-05 18:08 -0500
    Re: [newbie] problem with usbtmc-communication Terry Reedy <tjreedy@udel.edu> - 2012-12-04 14:55 -0500
      Re: problem with usbtmc-communication Jean Dubois <jeandubois314@gmail.com> - 2012-12-06 06:05 -0800
      Re: problem with usbtmc-communication Jean Dubois <jeandubois314@gmail.com> - 2012-12-06 07:44 -0800
        Re: problem with usbtmc-communication Terry Reedy <tjreedy@udel.edu> - 2012-12-06 15:28 -0500
          Re: problem with usbtmc-communication Jean Dubois <jeandubois314@gmail.com> - 2012-12-07 05:51 -0800

Page 2 of 2 — ← Prev page 1 [2]


#34341 — Re: problem with usbtmc-communication

FromDennis Lee Bieber <wlfraed@ix.netcom.com>
Date2012-12-05 18:08 -0500
SubjectRe: problem with usbtmc-communication
Message-ID<mailman.536.1354748885.29569.python-list@python.org>
In reply to#34321
On Wed, 5 Dec 2012 12:38:04 -0800 (PST), Jean Dubois
<jeandubois314@gmail.com> declaimed the following in
gmane.comp.python.general:

> This is the information concerning usbtmc from the National
> Instruments site:
> USBTMC stands for USB Test & Measurement Class. USBTMC is a protocol
> built on top of USB that allows GPIB-like communication with USB
> devices. From the user's point of view, the USB device behaves just
> like a GPIB device. For example, you can use VISA Write to send the
> *IDN? query and use VISA Read to get the response. The USBTMC protocol
> supports service request, triggers and other GPIB specific operations.
>

	Off-hand, that seems to imply that you might need a GPIB library to
talk to the "virtual" GPIB provided by USBTMC -- or something that talks
to the USBTMC library directly.

	Note that the NEXT paragraph reads:

NI> SBTMC allows instrument manufacturers to upgrade the physical layer
from GPIB to USB while maintaining software compatibility with existing
software, such as instrument drivers and any application that uses VISA.
This is also what the VXI-11 protocol provides for TCP/IP. 

	So now you have to consider what "VISA" is...

http://digital.ni.com/manuals.nsf/websearch/21992F3750B967ED86256F47007B00B3

	Since usable from M$ VB the question becomes: .NET or native API...
If native API, the win32 extension library on Windows should allow for
using the API from Python. If .NET, the ctypes library may allow access.
NOTE: I've not bothered downloading the docs -- it's your hardware <G>




-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]


#34249

FromTerry Reedy <tjreedy@udel.edu>
Date2012-12-04 14:55 -0500
Message-ID<mailman.471.1354650937.29569.python-list@python.org>
In reply to#34222
On 12/4/2012 7:14 AM, Jean Dubois wrote:
> The following test program which tries to communicate with a Keithley
> 2200 programmable power supply using usbtmc in Python does not work as
> expected. I have connected a 10 ohm resistor to its terminals and I
> apply 0.025A, 0.050A, 0.075A en 0.1A,
> I then measure the current and the voltage en write them in a file
> De data produced looks like this:
> 0.00544643 0.254061; first current value is wrong, voltage value is
> correct
> 0.0250807 0.509289; second current value is wrong, but it corresponds
> to the first, second voltage is correct
> 0.0501099 0.763945; 3rd current value is wrong, but it corresponds to
> the second, 3rd voltage is right
> 0.075099 1.01792; 4th current value is wrong,  it corresponds to the
> 3rd, 4th voltage is right
>                              4th correct current value is missing
>
> But is should be (numerical inaccuracy taking into account)  (these data
> were produced by a similar octave-program):
> 0.0248947 0.254047
> 0.0499105 0.509258
> 0.0749044 0.764001
> 0.0998926 1.01828
>
> Here is the python-program:
> #!/usr/bin/python
> import time
> import os
> import sys

> measurementcurr=''
> measurementvolt=''
> timesleepdefault=1
> filename ='mydata.txt'
> usbkeith = open('/dev/usbtmc1','r+')
> usbkeith.flush()
> usbkeith.write("*IDN?\n")
> #strip blank line:
> identification=usbkeith.readline().strip()
> print 'Found device: ',identification
> usbkeith.write("SYST:REM" + "\n")
> usbkeith.write(":SENS:VOLT:PROT 1.5\n")
> keithdata = open(filename,'w')

> #start first measurement
> usbkeith.write(":SOUR:CURR 0.025\n")
> usbkeith.write(":OUTP:STAT ON\n")
> time.sleep(timesleepdefault)
> usbkeith.write(":MEAS:CURR?\n")
> time.sleep(timesleepdefault)
> measurementcurr=usbkeith.readline()
> print 'Measured current 1: ',measurementcurr
> usbkeith.write("MEAS:VOLT?\n")
> time.sleep(timesleepdefault)
> measurementvolt=usbkeith.readline()
> print 'Measured voltage 1: ',measurementvolt
> keithdata.write(measurementcurr.strip()+' '+measurementvolt)
[3 near repetitions snipped]

This sort of repetitious code without even line breaks is painful for me 
to read. Python has looping statements for a reason. Replace all four 
nearly identical blocks with the following. (If you are not familiar 
with built-in enumerate, you should be. Read its entry in the library 
manual.)

for number, current_in in enumerate(
     ('0.025', '0.050'. '0.075', '0.100'), 1)
   usbkeith.write(":SOUR:CURR %s\n" % current_in)
   ...
   print 'Measured current %d: ' % number, measurementcurr
   ...
   print 'Measured voltage %d: ' % number, measurementvolt

Now you can make changes in only one place and easily add more test values.

> print "Goodbye, data logged in file:"
> print filename
> usbkeith.close()
> keithdata.close()
>
> can anyone here what is going wrong and how to get it right?

No, but if both the python and octave programs used loops, it would be 
easier to see if both are doing the same things before, within, and 
after the loop.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]


#34388 — Re: problem with usbtmc-communication

FromJean Dubois <jeandubois314@gmail.com>
Date2012-12-06 06:05 -0800
SubjectRe: problem with usbtmc-communication
Message-ID<0d03abca-3498-4612-b941-84c3efc87fe6@b11g2000yqh.googlegroups.com>
In reply to#34249
On 4 dec, 20:55, Terry Reedy <tjre...@udel.edu> wrote:
> On 12/4/2012 7:14 AM, Jean Dubois wrote:
>
>
>
>
>
>
>
>
>
> > The following test program which tries to communicate with a Keithley
> > 2200 programmable power supply usingusbtmcin Python does not work as
> > expected. I have connected a 10 ohm resistor to its terminals and I
> > apply 0.025A, 0.050A, 0.075A en 0.1A,
> > I then measure the current and the voltage en write them in a file
> > De data produced looks like this:
> > 0.00544643 0.254061; first current value is wrong, voltage value is
> > correct
> > 0.0250807 0.509289; second current value is wrong, but it corresponds
> > to the first, second voltage is correct
> > 0.0501099 0.763945; 3rd current value is wrong, but it corresponds to
> > the second, 3rd voltage is right
> > 0.075099 1.01792; 4th current value is wrong,  it corresponds to the
> > 3rd, 4th voltage is right
> >                              4th correct current value is missing
>
> > But is should be (numerical inaccuracy taking into account)  (these data
> > were produced by a similar octave-program):
> > 0.0248947 0.254047
> > 0.0499105 0.509258
> > 0.0749044 0.764001
> > 0.0998926 1.01828
>
> > Here is the python-program:
> > #!/usr/bin/python
> > import time
> > import os
> > import sys
> > measurementcurr=''
> > measurementvolt=''
> > timesleepdefault=1
> > filename ='mydata.txt'
> > usbkeith = open('/dev/usbtmc1','r+')
> > usbkeith.flush()
> > usbkeith.write("*IDN?\n")
> > #strip blank line:
> > identification=usbkeith.readline().strip()
> > print 'Found device: ',identification
> > usbkeith.write("SYST:REM" + "\n")
> > usbkeith.write(":SENS:VOLT:PROT 1.5\n")
> > keithdata = open(filename,'w')
> > #start first measurement
> > usbkeith.write(":SOUR:CURR 0.025\n")
> > usbkeith.write(":OUTP:STAT ON\n")
> > time.sleep(timesleepdefault)
> > usbkeith.write(":MEAS:CURR?\n")
> > time.sleep(timesleepdefault)
> > measurementcurr=usbkeith.readline()
> > print 'Measured current 1: ',measurementcurr
> > usbkeith.write("MEAS:VOLT?\n")
> > time.sleep(timesleepdefault)
> > measurementvolt=usbkeith.readline()
> > print 'Measured voltage 1: ',measurementvolt
> > keithdata.write(measurementcurr.strip()+' '+measurementvolt)
>
> [3 near repetitions snipped]
>
> This sort of repetitious code without even line breaks is painful for me
> to read. Python has looping statements for a reason. Replace all four
> nearly identical blocks with the following. (If you are not familiar
> with built-in enumerate, you should be. Read its entry in the library
> manual.)
>
> for number, current_in in enumerate(
>      ('0.025', '0.050'. '0.075', '0.100'), 1)
>    usbkeith.write(":SOUR:CURR %s\n" % current_in)
>    ...
>    print 'Measured current %d: ' % number, measurementcurr
>    ...
>    print 'Measured voltage %d: ' % number, measurementvolt
>
> Now you can make changes in only one place and easily add more test values.
>
> > print "Goodbye, data logged in file:"
> > print filename
> > usbkeith.close()
> > keithdata.close()
>
> > can anyone here what is going wrong and how to get it right?
>
> No, but if both the python and octave programs used loops, it would be
> easier to see if both are doing the same things before, within, and
> after the loop.
>
> --
> Terry Jan Reedy

Thank you for you reply. Of course you are right this kind of code is
not the normal way to program but as I mentioned in my initial post
this is merely a test program, I did avoid using a loop on purpose
because timing can be critical in this kind of application and I
didn't want to add unnecessary uncertainty in the timing which could
be caused by using a loop.
The final version will be more like you suggested here above.
As Bill stated in another e-mail the real trouble here is some kind of
"buffer-problem",  according to him it could be caused by the use of
the readline()-statements. So if anyone could tell me how to
substitute those by some Python commands which read characters instead
does the Octave-code I'd appreciate that very much.

regards,
Jean

[toc] | [prev] | [next] | [standalone]


#34400 — Re: problem with usbtmc-communication

FromJean Dubois <jeandubois314@gmail.com>
Date2012-12-06 07:44 -0800
SubjectRe: problem with usbtmc-communication
Message-ID<5a264830-225a-4321-add4-edda89bfa82c@u19g2000yqj.googlegroups.com>
In reply to#34249
On 4 dec, 20:55, Terry Reedy <tjre...@udel.edu> wrote:
> On 12/4/2012 7:14 AM, Jean Dubois wrote:
>
>
>
>
>
>
>
>
>
> > The following test program which tries to communicate with a Keithley
> > 2200 programmable power supply using usbtmc in Python does not work as
> > expected. I have connected a 10 ohm resistor to its terminals and I
> > apply 0.025A, 0.050A, 0.075A en 0.1A,
> > I then measure the current and the voltage en write them in a file
> > De data produced looks like this:
> > 0.00544643 0.254061; first current value is wrong, voltage value is
> > correct
> > 0.0250807 0.509289; second current value is wrong, but it corresponds
> > to the first, second voltage is correct
> > 0.0501099 0.763945; 3rd current value is wrong, but it corresponds to
> > the second, 3rd voltage is right
> > 0.075099 1.01792; 4th current value is wrong,  it corresponds to the
> > 3rd, 4th voltage is right
> >                              4th correct current value is missing
>
> > But is should be (numerical inaccuracy taking into account)  (these data
> > were produced by a similar octave-program):
> > 0.0248947 0.254047
> > 0.0499105 0.509258
> > 0.0749044 0.764001
> > 0.0998926 1.01828
>
> > Here is the python-program:
> > #!/usr/bin/python
> > import time
> > import os
> > import sys
> > measurementcurr=''
> > measurementvolt=''
> > timesleepdefault=1
> > filename ='mydata.txt'
> > usbkeith = open('/dev/usbtmc1','r+')
> > usbkeith.flush()
> > usbkeith.write("*IDN?\n")
> > #strip blank line:
> > identification=usbkeith.readline().strip()
> > print 'Found device: ',identification
> > usbkeith.write("SYST:REM" + "\n")
> > usbkeith.write(":SENS:VOLT:PROT 1.5\n")
> > keithdata = open(filename,'w')
> > #start first measurement
> > usbkeith.write(":SOUR:CURR 0.025\n")
> > usbkeith.write(":OUTP:STAT ON\n")
> > time.sleep(timesleepdefault)
> > usbkeith.write(":MEAS:CURR?\n")
> > time.sleep(timesleepdefault)
> > measurementcurr=usbkeith.readline()
> > print 'Measured current 1: ',measurementcurr
> > usbkeith.write("MEAS:VOLT?\n")
> > time.sleep(timesleepdefault)
> > measurementvolt=usbkeith.readline()
> > print 'Measured voltage 1: ',measurementvolt
> > keithdata.write(measurementcurr.strip()+' '+measurementvolt)
>
> [3 near repetitions snipped]
>
> This sort of repetitious code without even line breaks is painful for me
> to read. Python has looping statements for a reason. Replace all four
> nearly identical blocks with the following. (If you are not familiar
> with built-in enumerate, you should be. Read its entry in the library
> manual.)
>
> for number, current_in in enumerate(
>      ('0.025', '0.050'. '0.075', '0.100'), 1)
>    usbkeith.write(":SOUR:CURR %s\n" % current_in)
>    ...
>    print 'Measured current %d: ' % number, measurementcurr
>    ...
>    print 'Measured voltage %d: ' % number, measurementvolt
>
> Now you can make changes in only one place and easily add more test values.
>
> > print "Goodbye, data logged in file:"
> > print filename
> > usbkeith.close()
> > keithdata.close()
>
> > can anyone here what is going wrong and how to get it right?
>
> No, but if both the python and octave programs used loops, it would be
> easier to see if both are doing the same things before, within, and
> after the loop.
>
> --
> Terry Jan Reedy
I followed your suggestion an now the code looks like this:
#!/usr/bin/python
import time
import os
import sys
measurementcurr=''
measurementvolt=''
timesleepdefault=2
filename ='mydata.txt'
usbkeith = open('/dev/usbtmc1','r+')
usbkeith.flush()
usbkeith.write("*IDN?\n")
#strip blank line:
identification=usbkeith.readline().strip()
print 'Found device: ',identification
usbkeith.write("SYST:REM" + "\n")
usbkeith.write(":SENS:VOLT:PROT 1.5\n")
keithdata = open(filename,'w')
usbkeith.write(":OUTP:STAT ON\n")
for number, current_in in enumerate(('0.025', '0.050', '0.075',
'0.100'), 1):
   usbkeith.write(":SOUR:CURR %s\n" % current_in)
   time.sleep(timesleepdefault)
   usbkeith.write(":MEAS:CURR?\n")
   measurementcurr=usbkeith.readline()
   print 'Measured current %d: ' % number, measurementcurr
   usbkeith.write(":MEAS:VOLT?\n")
   measurementvolt=usbkeith.readline()
   print 'Measured voltage %d: ' % number, measurementvolt
   keithdata.write(measurementcurr.strip()+' '+measurementvolt)
usbkeith.write(":OUTP:STAT OFF\n")
print "Goodbye, data logged in file:"
print filename
usbkeith.close()
keithdata.close()

Still there is a "buffer-problem" as you can see in the output below:
0.00639725 0.0104065; these values are completely wrong
0.0248976 0.262959; these should have been be the first values
0.0500431 0.516602: these should been the second values
0.0749168 0.772616; these are the 3rd values
                     4th values are missing

any idea why this does what it does in Python?

jean

[toc] | [prev] | [next] | [standalone]


#34428 — Re: problem with usbtmc-communication

FromTerry Reedy <tjreedy@udel.edu>
Date2012-12-06 15:28 -0500
SubjectRe: problem with usbtmc-communication
Message-ID<mailman.588.1354825729.29569.python-list@python.org>
In reply to#34400
On 12/6/2012 10:44 AM, Jean Dubois wrote:

> I followed your suggestion an now the code looks like this:
> #!/usr/bin/python
> import time
> import os
> import sys
> measurementcurr=''
> measurementvolt=''
> timesleepdefault=2
> filename ='mydata.txt'
> usbkeith = open('/dev/usbtmc1','r+')
> usbkeith.flush()
> usbkeith.write("*IDN?\n")
> #strip blank line:
> identification=usbkeith.readline().strip()
> print 'Found device: ',identification
> usbkeith.write("SYST:REM" + "\n")
> usbkeith.write(":SENS:VOLT:PROT 1.5\n")
> keithdata = open(filename,'w')
> usbkeith.write(":OUTP:STAT ON\n")
> for number, current_in in enumerate(('0.025', '0.050', '0.075',
> '0.100'), 1):
>     usbkeith.write(":SOUR:CURR %s\n" % current_in)
>     time.sleep(timesleepdefault)
>     usbkeith.write(":MEAS:CURR?\n")
>     measurementcurr=usbkeith.readline()
>     print 'Measured current %d: ' % number, measurementcurr
>     usbkeith.write(":MEAS:VOLT?\n")
>     measurementvolt=usbkeith.readline()
>     print 'Measured voltage %d: ' % number, measurementvolt
>     keithdata.write(measurementcurr.strip()+' '+measurementvolt)
> usbkeith.write(":OUTP:STAT OFF\n")
> print "Goodbye, data logged in file:"
> print filename
> usbkeith.close()
> keithdata.close()
>
> Still there is a "buffer-problem" as you can see in the output below:
> 0.00639725 0.0104065; these values are completely wrong
> 0.0248976 0.262959; these should have been be the first values
> 0.0500431 0.516602: these should been the second values
> 0.0749168 0.772616; these are the 3rd values
>                       4th values are missing
>
> any idea why this does what it does in Python?

I am not familiar with the protocol at all, but my guess (without 
looking at the octave code) is that two of these three commands

 > usbkeith.write("SYST:REM" + "\n")
 > usbkeith.write(":SENS:VOLT:PROT 1.5\n")
 > usbkeith.write(":OUTP:STAT ON\n")

before the loop have responses that you need to read (and toss?)

usbkeith.readline(); usbkeith.readline()

so that the first values you read in the loop are the one that should be 
first. In other words, make sure the read buffer is clear before the loop.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]


#34461 — Re: problem with usbtmc-communication

FromJean Dubois <jeandubois314@gmail.com>
Date2012-12-07 05:51 -0800
SubjectRe: problem with usbtmc-communication
Message-ID<ae7af072-4f64-4fed-9790-c65d5f881f22@f4g2000yqh.googlegroups.com>
In reply to#34428
On 6 dec, 21:28, Terry Reedy <tjre...@udel.edu> wrote:
> On 12/6/2012 10:44 AM, Jean Dubois wrote:
>
>
>
>
>
>
>
>
>
> > I followed your suggestion an now the code looks like this:
> > #!/usr/bin/python
> > import time
> > import os
> > import sys
> > measurementcurr=''
> > measurementvolt=''
> > timesleepdefault=2
> > filename ='mydata.txt'
> > usbkeith = open('/dev/usbtmc1','r+')
> > usbkeith.flush()
> > usbkeith.write("*IDN?\n")
> > #strip blank line:
> > identification=usbkeith.readline().strip()
> > print 'Found device: ',identification
> > usbkeith.write("SYST:REM" + "\n")
> > usbkeith.write(":SENS:VOLT:PROT 1.5\n")
> > keithdata = open(filename,'w')
> > usbkeith.write(":OUTP:STAT ON\n")
> > for number, current_in in enumerate(('0.025', '0.050', '0.075',
> > '0.100'), 1):
> >     usbkeith.write(":SOUR:CURR %s\n" % current_in)
> >     time.sleep(timesleepdefault)
> >     usbkeith.write(":MEAS:CURR?\n")
> >     measurementcurr=usbkeith.readline()
> >     print 'Measured current %d: ' % number, measurementcurr
> >     usbkeith.write(":MEAS:VOLT?\n")
> >     measurementvolt=usbkeith.readline()
> >     print 'Measured voltage %d: ' % number, measurementvolt
> >     keithdata.write(measurementcurr.strip()+' '+measurementvolt)
> > usbkeith.write(":OUTP:STAT OFF\n")
> > print "Goodbye, data logged in file:"
> > print filename
> > usbkeith.close()
> > keithdata.close()
>
> > Still there is a "buffer-problem" as you can see in the output below:
> > 0.00639725 0.0104065; these values are completely wrong
> > 0.0248976 0.262959; these should have been be the first values
> > 0.0500431 0.516602: these should been the second values
> > 0.0749168 0.772616; these are the 3rd values
> >                       4th values are missing
>
> > any idea why this does what it does in Python?
>
> I am not familiar with the protocol at all, but my guess (without
> looking at the octave code) is that two of these three commands
>
>  > usbkeith.write("SYST:REM" + "\n")
>  > usbkeith.write(":SENS:VOLT:PROT 1.5\n")
>  > usbkeith.write(":OUTP:STAT ON\n")
>
> before the loop have responses that you need to read (and toss?)
No they don't need to have there responses be red,
first command sets remote mode
second command sets limit on voltage across output terminals
3rd command connects terminals with DUT


> usbkeith.readline(); usbkeith.readline()
This doesn't work because nothing is sent back
> so that the first values you read in the loop are the one that should be
> first. In other words, make sure the read buffer is clear before the loop.
>
> --
> Terry Jan Reedy

I'll look at it further monday

regards,
jean

[toc] | [prev] | [standalone]


Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.python


csiph-web