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

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

Basic Python Questions - Oct. 31, 2013

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

Contents

  Basic Python Questions - Oct. 31, 2013 "E.D.G." <edgrsprj@ix.netcom.com> - 2013-10-31 04:31 -0500
    Re: Basic Python Questions - Oct. 31, 2013 Chris “Kwpolska” Warrick <kwpolska@gmail.com> - 2013-10-31 11:03 +0100
      Re: Basic Python Questions - Oct. 31, 2013 "E.D.G." <edgrsprj@ix.netcom.com> - 2013-10-31 05:38 -0500
        Re: Basic Python Questions - Oct. 31, 2013 Chris “Kwpolska” Warrick <kwpolska@gmail.com> - 2013-10-31 12:30 +0100
        Re: Basic Python Questions - Oct. 31, 2013 Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2013-10-31 14:17 +0100
          Re: Basic Python Questions - Oct. 31, 2013 Chris Angelico <rosuav@gmail.com> - 2013-11-01 01:05 +1100
            Re: Basic Python Questions - Oct. 31, 2013 Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2013-10-31 15:18 +0100
              Re: Basic Python Questions - Oct. 31, 2013 Chris Angelico <rosuav@gmail.com> - 2013-11-01 01:45 +1100
          Re: Basic Python Questions - Oct. 31, 2013 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-31 14:15 +0000
            Re: Basic Python Questions - Oct. 31, 2013 Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2013-10-31 15:31 +0100
          Re: Basic Python Questions - Oct. 31, 2013 Robert Kern <robert.kern@gmail.com> - 2013-10-31 14:41 +0000
          Re: Basic Python Questions - Oct. 31, 2013 Chris Angelico <rosuav@gmail.com> - 2013-11-01 01:49 +1100
          Re: Basic Python Questions - Oct. 31, 2013 Robert Kern <robert.kern@gmail.com> - 2013-10-31 15:11 +0000
        Re: Basic Python Questions - Oct. 31, 2013 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-31 13:48 +0000
          Re: Basic Python Questions - Oct. 31, 2013 "E.D.G." <edgrsprj@ix.netcom.com> - 2013-11-03 01:17 -0500
            Re: Basic Python Questions - Oct. 31, 2013 "E.D.G." <edgrsprj@ix.netcom.com> - 2013-11-12 04:21 -0600
              Re: Basic Python Questions - Oct. 31, 2013 Chris Angelico <rosuav@gmail.com> - 2013-11-13 10:05 +1100
        Re: Basic Python Questions - Oct. 31, 2013 rusi <rustompmody@gmail.com> - 2013-10-31 08:48 -0700
          Re: Basic Python Questions - Oct. 31, 2013 "E.D.G." <edgrsprj@ix.netcom.com> - 2013-11-03 00:45 -0500
            Re: Basic Python Questions - Oct. 31, 2013 rusi <rustompmody@gmail.com> - 2013-11-02 23:54 -0700
    Re: Basic Python Questions - Oct. 31, 2013 Roy Smith <roy@panix.com> - 2013-10-31 09:20 -0400
    Re: Basic Python Questions - Oct. 31, 2013 Skip Montanaro <skip@pobox.com> - 2013-10-31 11:14 -0500
    Re: Basic Python Questions - Oct. 31, 2013 William Ray Wing <wrw@mac.com> - 2013-11-01 11:42 -0400
      Re: Basic Python Questions - Oct. 31, 2013 "E.D.G." <edgrsprj@ix.netcom.com> - 2013-11-03 01:28 -0500
    Re: Basic Python Questions - Oct. 31, 2013 Ethan Furman <ethan@stoneleaf.us> - 2013-11-01 11:08 -0700
    Re: Basic Python Questions - Oct. 31, 2013 William Ray Wing <wrw@mac.com> - 2013-11-01 15:17 -0400
    Re: Basic Python Questions - Oct. 31, 2013 "E.D.G." <edgrsprj@ix.netcom.com> - 2013-11-03 01:02 -0500
      Re: Basic Python Questions - Oct. 31, 2013 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-11-03 07:43 +0000
        Re: Basic Python Questions - Oct. 31, 2013 "E.D.G." <edgrsprj@ix.netcom.com> - 2013-11-03 03:47 -0600
          Re: Basic Python Questions - Oct. 31, 2013 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-11-03 10:05 +0000
        Re: Basic Python Questions - Oct. 31, 2013 rusi <rustompmody@gmail.com> - 2013-11-03 10:28 -0800
          Re: Basic Python Questions - Oct. 31, 2013 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-11-03 18:58 +0000
            Re: Basic Python Questions - Oct. 31, 2013 rusi <rustompmody@gmail.com> - 2013-11-03 20:07 -0800
      Re: Basic Python Questions - Oct. 31, 2013 Jim Gibson <JimSGibson@gmail.com> - 2013-11-03 10:18 -0800
        Re: Basic Python Questions - Oct. 31, 2013 Grant Edwards <invalid@invalid.invalid> - 2013-11-03 23:16 +0000
        Re: Basic Python Questions - Oct. 31, 2013 "E.D.G." <edgrsprj@ix.netcom.com> - 2013-11-04 23:22 -0600
          Re: Basic Python Questions - Oct. 31, 2013 88888 Dihedral <dihedral88888@gmail.com> - 2013-11-07 06:05 -0800
    Re: Basic Python Questions - Oct. 31, 2013 sigtool@kcl.ac.uk - 2013-11-10 06:40 -0800

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

#58170

In article <UdGdnaDGa6n9vu_PnZ2dnUVZ_umdnZ2d@earthlink.com>,
 "E.D.G." <edgrsprj@ix.netcom.com> wrote:
 
> 1.  How fast can Python do math calculations compared with other languages 
> such as Fortran and fast versions of Basic.  I would have to believe that it 
> is much faster than Perl for doing math calculations.

Getting a handle on Python's execution speed is not easy.  The problem 
is that the core library is mostly written in C, so operations that 
happen inside the core library are fast.  Operations that happen in 
user-written Python code are slow.  How fast your overall program will 
run is largely determined by how much you're executing user code and how 
much you're executing library calls.

People have done lots of comparisons of language execution speed over 
the years.  If you google for "python speed comparison", you'll find 
plenty of more detailed answers than you'll get here.

> 2.  Can Python be used to create CGI programs?  These are the ones that run 
> on Internet server computers and process data submitted through Web site 
> data entry screens etc.  I know that Perl CGI programs will do that.

Yes, they can.  However, CGI is largely an obsolete interface, partly 
because it's so inefficient.  If you're worried about execution speed, 
CGI is not what you should be looking at.

> 3.  If Python can be used for CGI programming, can it draw charts such as 
> .png files that will then display on Web pages at a Web site?

Yes.  There are a number of modules out there for doing this.  Again, 
google is your friend.  Search for "python charting module", or 
variations on that.

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

#58190

> 1.  How fast can Python do math calculations compared with other languages
> such as Fortran and fast versions of Basic.  I would have to believe that it
> is much faster than Perl for doing math calculations.

As others have indicated, a lot depends on the form of your
calculations. There is a cost to crossing the Python/C boundary, and
you may or may not care about the other stuff Python can do
on-the-fly, like promote ints to Python longs, check for zero
division, etc. If you have floating point code that is array-like,
then organizing it to use numpy can be a big win, as you will cross
that expensive boundary much less often per underlying operation. (I'm
thinking here of more complex operations like trigonometric functions,
not simple adds and subtracts, which are handled by the Python virtual
machine.)

I will relate one anecdote from my job here which highlights the cost
of the boundary. I work at a trading firm. I work solely within a
Python world, but my stuff is built on top of a lot of C++ code
developed by others at the firm. Several years ago, it was decided
that we needed a price library because some exchanges (the London
Stock Exchange, for example) sets the minimum price change based on
the current trading price range. Consider a stock like AAPL, which
closed yesterday at 489.56. It trades in pennies on NASDAQ, no matter
its price. If it was on the LSE, it might trade in half pennies if it
was trading in a $100 range, or in dimes if it was trading near $1000
range. (I'm making this stuff up, just to give you an idea what I'm
referring to.)

So, a price library was written in C++. You could ask for the next
higher or lower valid price. It was all very peppy, because of course,
it relied heavily on C++ inline functions for all these simple
operations. It was wrapped with Boost::Python and tossed over the
fence for us Python peons to use. Guess what? It was unbearably slow,
because not only did we were crossing the Python/C boundary to do
little more (most of the time) than a single add or subtract.

The solution was to write a pure Python version of the parts that mattered most.

Moral of the story: consider how your code is structured and whether
it makes sense to reorganize it when implementing in Python.

Skip

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

#58277

On Oct 31, 2013, at 5:31 AM, "E.D.G." <edgrsprj@ix.netcom.com> wrote:

> Posted by E.D.G. on October 31, 2013
> 
>      The following are several relatively basic questions regarding Python's capabilities.  I am not presently using it myself.  At the moment a number of people including myself are comparing it with other programs such as XBasic for possible use.
> 
> 1.  How fast can Python do math calculations compared with other languages such as Fortran and fast versions of Basic.  I would have to believe that it is much faster than Perl for doing math calculations.
> 

[byte]

> 4.  How well does Python work for interactive programming.  For example, if a Python program is running on a PC and is drawing a chart, can that chart be modified by simply pressing a key while the Python program is running.  I have Perl and Gnuplot program combinations that can do that.  Their interactive speed is not that great.  But it is adequate for my own uses.
> 

I thought about responding to this yesterday, decided others could do so better than I, but then decided to point out a bit of demo code that was one of the first really startling pieces of Python that I stumbled into.

If you look here:   http://wiki.wxpython.org/MatplotlibFourierDemo

You will find a fairly short, well documented demo code that interactively computes a Fast Fourier transform from the frequency domain to the time domain.  As you move the two sliders below the graphs, the input aptitude and location of the frequency peaks are changed and the resulting wavelet is plotted, all in real time.

Computing a Fourier transform is numerically pretty intensive, doing so in real time with no perceptible delay (at least on a reasonably modern system) should convince any skeptic of Python's ability to do BOTH number crunching AND interactive display.

Granted, this performance is based on pulling in libraries.  It imports numpy, mathplotlib, and wx to handle the fast array calculations, the plotting, and the GUI respectively, but those are exactly the sorts of "batteries included" libraries that give Python so much power and flexibility.

-Bill

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

#58373

"William Ray Wing" <wrw@mac.com> wrote in message 
news:mailman.1934.1383320554.18130.python-list@python.org...

>>If you look here:   http://wiki.wxpython.org/MatplotlibFourierDemo

       A suggestion that I would like to add is that when people make "Demo" 
programs like that available they might want to create exe versions that 
people can download and try without installing the original programming 
language.  However, there might have been an exe version at that Web site 
and I just didn't see it.

       I myself use expendable backup computers (Windows XP) for testing new 
exe programs so that problems are not created for my primary computer.  If 
something goes wrong on one of the backup systems it is simply told to go 
back to an earlier restore point.

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

#58284

On 11/01/2013 08:42 AM, William Ray Wing wrote:
>
> Granted, this performance is based on pulling in libraries.  It imports numpy, mathplotlib, and wx to handle the fast array calculations, the plotting, and the GUI respectively, but those are exactly the sorts of "batteries included" libraries that give Python so much power and flexibility.

Not to take away from your points about Python, combined with the appropriate libraries, being fast enough, but the 
"batteries included" refers to what comes in the stdlib -- those three libraries are not in the stdlib, so they're more 
along the lines of "power generators easily acquired".  :)

--
~Ethan~

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

#58289

On Nov 1, 2013, at 2:08 PM, Ethan Furman <ethan@stoneleaf.us> wrote:

> On 11/01/2013 08:42 AM, William Ray Wing wrote:
>> 
>> Granted, this performance is based on pulling in libraries.  It imports numpy, mathplotlib, and wx to handle the fast array calculations, the plotting, and the GUI respectively, but those are exactly the sorts of "batteries included" libraries that give Python so much power and flexibility.
> 
> Not to take away from your points about Python, combined with the appropriate libraries, being fast enough, but the "batteries included" refers to what comes in the stdlib -- those three libraries are not in the stdlib, so they're more along the lines of "power generators easily acquired".  :)
> 
> --
> ~Ethan~
> -- 
> https://mail.python.org/mailman/listinfo/python-list

Strictly speaking, you are absolutely correct.  But, those three libraries are SO widely available (for so many platforms), I took the liberty of being inclusive.

Thanks,
Bill

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

#58368

"E.D.G." <edgrsprj@ix.netcom.com> wrote in message 
news:UdGdnaDGa6n9vu_PnZ2dnUVZ_umdnZ2d@earthlink.com...

       Thanks for all of the comments. I have been away from my Internet 
connection for several days and could not respond to them when they were 
first posted here.

       The comments have all been considered. And I am discussing them with 
other researchers that I work with. Since Perl has a calculation speed limit 
that is probably not easy to get around, before too long another language 
will be selected for initially doing certain things such as performing 
calculations and plotting charts. And the existing Perl code might then be 
gradually translated into that new language.

       Gnuplot is presently being used to draw charts. And it works. But it 
has its own limitations such as with its interaction speed when it is used 
for working with Perl program generated data files.

       My main, complex programs won't be run at Web sites. They will 
instead continue to be available as downloadable exe programs.  The CGI (or 
whatever) programming work would involve relatively simple programs. But 
they would need to be able to generate charts that would be displayed on Web 
pages. That sounds like it is probably fairly easy to do using Python. A 
Perl - Gnuplot combination is also supposed to be able to do that. But so 
far I have not seen any good explanations for how to actually get Gnuplot to 
run as a callable CGI program. So other programs such as Python are being 
considered.

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

#58378

On Sun, 03 Nov 2013 01:02:24 -0500, E.D.G. wrote:

[...]
> Since Perl has a calculation speed
> limit that is probably not easy to get around, before too long another
> language will be selected for initially doing certain things such as
> performing calculations and plotting charts. And the existing Perl code
> might then be gradually translated into that new language.

The nice things about Python are that it makes a great glue language for 
putting together components written in low-level languages like C and 
Fortran, and that there is a rich ecosystem of products for speeding it
up in various ways. So when you hit the speed limits of pure Python, you
have lots of options. In no particular order:


* try using another Python compiler: PyPy is probably the most 
  mature of the stand-alone optimizing compilers, and you can 
  expect to double the speed of "typical" Python code, but 
  there are others;

* use numpy and scipy for vectorized mathematical routines;

* re-write critical code as C or Fortran libraries;

* use Pyrex (possibly unmaintained now) or Cython to write
  C extensions in a Python-like language;

* use Psyco or Numba (JIT specialising compilers for Python);

* use Theano (optimizing computer algebra system compiler);

* use ctypes to call C functions directly;

* use other products like Boost, Weave, and more.


See, for example:

http://jakevdp.github.io/blog/2013/06/15/numba-vs-cython-take-2/

http://technicaldiscovery.blogspot.com.au/2011/06/speeding-up-python-numpy-cython-and.html



-- 
Steven

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

#58381

"Steven D'Aprano" <steve+comp.lang.python@pearwood.info> wrote in message 
news:5275fe91$0$29972$c3e8da3$5496439d@news.astraweb.com...

> http://jakevdp.github.io/blog/2013/06/15/numba-vs-cython-take-2/
>
> http://technicaldiscovery.blogspot.com.au/2011/06/speeding-up-python-numpy-cython-and.html

       It appears that Python can do what is needed.  And if the people that 
I work with want to move in that direction I will probably post a note here 
stating, "This is exactly what we need to do.  What would be the best Python 
download and compiler to do that?"

      It should be a simple matter to determine which compiler and libraries 
etc. should be used.

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

#58383

On 03/11/2013 09:47, E.D.G. wrote:
> "Steven D'Aprano" <steve+comp.lang.python@pearwood.info> wrote in
> message news:5275fe91$0$29972$c3e8da3$5496439d@news.astraweb.com...
>
>> http://jakevdp.github.io/blog/2013/06/15/numba-vs-cython-take-2/
>>
>> http://technicaldiscovery.blogspot.com.au/2011/06/speeding-up-python-numpy-cython-and.html
>>
>
>        It appears that Python can do what is needed.  And if the people
> that I work with want to move in that direction I will probably post a
> note here stating, "This is exactly what we need to do.  What would be
> the best Python download and compiler to do that?"
>
>       It should be a simple matter to determine which compiler and
> libraries etc. should be used.
>

I've literally just stumbled across this, I've no idea whether it's of 
any use to you https://speakerdeck.com/ianozsvald/high-performance-python

-- 
Python is the second best programming language in the world.
But the best has yet to be invented.  Christian Tismer

Mark Lawrence

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

#58405

On Sunday, November 3, 2013 1:13:13 PM UTC+5:30, Steven D'Aprano wrote:
> On Sun, 03 Nov 2013 01:02:24 -0500, E.D.G. wrote:

> [...]
> > Since Perl has a calculation speed
> > limit that is probably not easy to get around, before too long another
> > language will be selected for initially doing certain things such as
> > performing calculations and plotting charts. And the existing Perl code
> > might then be gradually translated into that new language.

> The nice things about Python are that it makes a great glue language for 
> putting together components written in low-level languages like C and 
> Fortran, and that there is a rich ecosystem of products for speeding it
> up in various ways. So when you hit the speed limits of pure Python, you
> have lots of options. In no particular order:

> * try using another Python compiler: PyPy is probably the most 
>   mature of the stand-alone optimizing compilers, and you can 
>   expect to double the speed of "typical" Python code, but 
>   there are others;

> * use numpy and scipy for vectorized mathematical routines;

> * re-write critical code as C or Fortran libraries;

> * use Pyrex (possibly unmaintained now) or Cython to write
>   C extensions in a Python-like language;

> * use Psyco or Numba (JIT specialising compilers for Python);

> * use Theano (optimizing computer algebra system compiler);

> * use ctypes to call C functions directly;

> * use other products like Boost, Weave, and more.

Yes python is really state-of-art in this respect:
Every language will have some area where it sucks.
Allowing for a hatch where one could jump out is helpful.
Python allows more such hatches than probably any other language (that I know)

https://mail.python.org/pipermail/python-list/2012-August/628090.html
is a (non exhaustive) list I had made some time.

On the other hand if you know you are going to be escaping out often,
you may want to consider whether the 'escapee' should be your base
rather than python.

Which means take something like the pairwise function and code it up in python and julia -- its hardly 10 lines of code.  And see what comparative performance you get. 

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

#58406

On 03/11/2013 18:28, rusi wrote:
>
> Which means take something like the pairwise function and code it up in python and julia -- its hardly 10 lines of code.  And see what comparative performance you get.
>

Solely on the grounds that you've mentioned julia how about this 
http://blog.leahhanson.us/julia-calling-python-calling-julia.html

-- 
Python is the second best programming language in the world.
But the best has yet to be invented.  Christian Tismer

Mark Lawrence

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

#58428

On Monday, November 4, 2013 12:28:24 AM UTC+5:30, Mark Lawrence wrote:
> On 03/11/2013 18:28, rusi wrote:
> > Which means take something like the pairwise function and code it
> > up in python and julia -- its hardly 10 lines of code.  And see
> > what comparative performance you get.

> Solely on the grounds that you've mentioned julia how about this 
> http://blog.leahhanson.us/julia-calling-python-calling-julia.html

Good stuff -- thanks

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

#58404

In article <OKCdnXfaQqxze-jPnZ2dnUVZ_jGdnZ2d@earthlink.com>, E.D.G.
<edgrsprj@ix.netcom.com> wrote:

>        My main, complex programs won't be run at Web sites. They will 
> instead continue to be available as downloadable exe programs.  The CGI (or 
> whatever) programming work would involve relatively simple programs. But 
> they would need to be able to generate charts that would be displayed on Web 
> pages. That sounds like it is probably fairly easy to do using Python. A 
> Perl - Gnuplot combination is also supposed to be able to do that. But so 
> far I have not seen any good explanations for how to actually get Gnuplot to 
> run as a callable CGI program. So other programs such as Python are being 
> considered.

One way to generate plot within a CGI program is this:

1. Write a file with gnuplot commands (e.g., 'gnuplot.cmd') that set
the output device to a graphics file of some format (e.g., PNG),
generate a plot, and quit gnuplot.

2. Run gnuplot and point it to the file of commands (e.g., 'gnuplot
gunplot.cmd') . How this is done depends upon the CGI program language
(see below).

3. Generate HTML that uses the generated graphics file as an embedded
image (using the <img> tag).

I have done this in the past, but not recently. This should work for
Python (os.system("gnuplot gnuplot.cmd") or Perl (system("gnuplot
gnuplot.cmd") with suitable commands to execute external programs.

-- 
Jim Gibson

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

#58418

On 2013-11-03, Jim Gibson <JimSGibson@gmail.com> wrote:
> In article <OKCdnXfaQqxze-jPnZ2dnUVZ_jGdnZ2d@earthlink.com>, E.D.G.
><edgrsprj@ix.netcom.com> wrote:
>
>>        My main, complex programs won't be run at Web sites. They will 
>> instead continue to be available as downloadable exe programs.  The CGI (or 
>> whatever) programming work would involve relatively simple programs. But 
>> they would need to be able to generate charts that would be displayed on Web 
>> pages. That sounds like it is probably fairly easy to do using Python. A 
>> Perl - Gnuplot combination is also supposed to be able to do that. But so 
>> far I have not seen any good explanations for how to actually get Gnuplot to 
>> run as a callable CGI program. So other programs such as Python are being 
>> considered.
>
> One way to generate plot within a CGI program is this:
>
> 1. Write a file with gnuplot commands (e.g., 'gnuplot.cmd') that set
> the output device to a graphics file of some format (e.g., PNG),
> generate a plot, and quit gnuplot.

Or you can use the pygnuplot module which handles much of that for y0ou.

http://pygnuplot.sourceforge.net/

-- 
Grant

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

#58479

"Jim Gibson" <JimSGibson@gmail.com> wrote in message 
news:031120131018099327%JimSGibson@gmail.com...

> One way to generate plot within a CGI program is this:

       To start off with, I am not a CGI expert.  Also, I have several 
degrees in the physical sciences and many years of doing computer 
programming.  But the programming work is done just to get various science 
projects to work.

       The question that I could not get an answer for was, “How can you get 
Gnuplot to run on an Internet server computer?”

       And I would eventually have to ask that same question for Python.

       My Internet Server looks like it has Perl, Perl5, and PHP available. 
And I have created a number of CGI Perl programs that run on the Web site. 
But as I said, I would not know how to get Gnuplot or Python to run at the 
site.

       Any recommendations for how to do that?  Or should I just do a search 
for the necessary documentation?

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

#58657

On Tuesday, November 5, 2013 1:22:05 PM UTC+8, E.D.G. wrote:
> "Jim Gibson" <JimSGibson@gmail.com> wrote in message 
> 
> news:031120131018099327%JimSGibson@gmail.com...
> 
> 
> 
> > One way to generate plot within a CGI program is this:
> 
> 
> 
>        To start off with, I am not a CGI expert.  Also, I have several 
> 
> degrees in the physical sciences and many years of doing computer 
> 
> programming.  But the programming work is done just to get various science 
> 
> projects to work.
> 
> 
> 
>        The question that I could not get an answer for was, “How can you get 
> 
> Gnuplot to run on an Internet server computer?”
> 
> 
> 
>        And I would eventually have to ask that same question for Python.
> 
> 
> 
>        My Internet Server looks like it has Perl, Perl5, and PHP available. 
> 
> And I have created a number of CGI Perl programs that run on the Web site. 
> 
> But as I said, I would not know how to get Gnuplot or Python to run at the 
> 
> site.
> 
> 
> 
>        Any recommendations for how to do that?  Or should I just do a search 
> 
> for the necessary documentation?

Please try modpy.

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

#59008

On Q4, you could try Waterloo Graphics <http://waterloo.sourceforge.net>. Its LGPLv3 and, although Java-based, runs in Python via Py4J. It has built-in mouse interactivity/GUI editors etc that will all be active when used from Python.

It is Java Swing-based, so e.g. data points can be drawn as standard clickable Swing components (see http://waterloo.sourceforge.net/R/scatter.html for an example using R [N.B. not interactive on the web site which just shows a bit-map]).

For Python examples see http://waterloo.sourceforge.net/python/grid.html







On Thursday, October 31, 2013 9:31:11 AM UTC, E.D.G. wrote:
> Posted by E.D.G. on October 31, 2013
> 
> 
> 
>        The following are several relatively basic questions regarding Python's 
> 
> capabilities.  I am not presently using it myself.  At the moment a number 
> 
> of people including myself are comparing it with other programs such as 
> 
> XBasic for possible use.
> 
> 
> 
> 1.  How fast can Python do math calculations compared with other languages 
> 
> such as Fortran and fast versions of Basic.  I would have to believe that it 
> 
> is much faster than Perl for doing math calculations.
> 
> 
> 
> 2.  Can Python be used to create CGI programs?  These are the ones that run 
> 
> on Internet server computers and process data submitted through Web site 
> 
> data entry screens etc.  I know that Perl CGI programs will do that.
> 
> 
> 
> 3.  If Python can be used for CGI programming, can it draw charts such as 
> 
> .png files that will then display on Web pages at a Web site?
> 
> 
> 
> 4.  How well does Python work for interactive programming.  For example, if 
> 
> a Python program is running on a PC and is drawing a chart, can that chart 
> 
> be modified by simply pressing a key while the Python program is running.  I 
> 
> have Perl and Gnuplot program combinations that can do that.  Their 
> 
> interactive speed is not that great.  But it is adequate for my own uses.
> 
> 
> 
> 5.  Can a running Python program send information to the Windows operating 
> 
> system as if it were typed in from the keyboard?  Perl can do that and I 
> 
> would imagine that Python probably has that same capability.

[toc] | [prev] | [standalone]

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

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

csiph-web