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

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

Pipes

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

Contents

  Pipes rogerh906@gmail.com - 2015-08-09 07:10 -0700
    Re: Pipes Ian Kelly <ian.g.kelly@gmail.com> - 2015-08-09 11:13 -0600
    Re: Pipes rogerh906@gmail.com - 2015-08-09 10:39 -0700
      Re: Pipes Ian Kelly <ian.g.kelly@gmail.com> - 2015-08-09 11:52 -0600
      Re: Pipes Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-08-09 19:34 +0100
    Re: Pipes rogerh906@gmail.com - 2015-08-09 10:55 -0700
      Re: Pipes Emile van Sebille <emile@fenx.com> - 2015-08-09 11:51 -0700
      Re: Pipes alister <alister.nospam.ware@ntlworld.com> - 2015-08-09 18:55 +0000
      Re: Pipes Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-08-09 16:43 -0400
      Re: Pipes Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-08-09 22:18 +0100
      Re: Pipes Cameron Simpson <cs@zip.com.au> - 2015-08-10 08:27 +1000
      RE: Pipes "Clayton Kirkwood" <crk@godblessthe.us> - 2015-08-09 17:44 -0700
      Re: Pipes Chris Angelico <rosuav@gmail.com> - 2015-08-10 20:50 +1000
      Re: Pipes Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-08-10 14:44 +0100
        Re: Pipes rogerh906@gmail.com - 2015-08-10 07:05 -0700
          Re: Pipes Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-08-10 15:36 +0100
    Re: Pipes Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-08-09 14:17 -0400
    Re: Pipes "E.D.G." <edgrsprj@ix.netcom.com> - 2015-08-10 15:43 -0500
      Re: Pipes Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-08-10 22:59 +0100
      Re: Pipes Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-08-10 18:41 -0400
      Re: Pipes Larry Hudson <orgnut@yahoo.com> - 2015-08-10 21:48 -0700
      Re: Pipes Laura Creighton <lac@openend.se> - 2015-08-11 11:07 +0200
      Re: Pipes Laura Creighton <lac@openend.se> - 2015-08-11 11:58 +0200
      Re: Pipes Tim Golden <mail@timgolden.me.uk> - 2015-08-11 11:15 +0100

Page 1 of 2  [1] 2  Next page →

#95192 — Pipes

Just learning Python and have a question.

Is it possible for Python to pass information to another program (in Windows), wait for that program to finish and then resume operating?

It's called a pipe in Unix systems.

Thanks,

Roger

[toc] | [next] | [standalone]

#95194

On Sun, Aug 9, 2015 at 8:10 AM,  <rogerh906@gmail.com> wrote:
> Just learning Python and have a question.
>
> Is it possible for Python to pass information to another program (in Windows), wait for that program to finish and then resume operating?
>
> It's called a pipe in Unix systems.

Yes, pipes can also be used in Windows. In Python, use the subprocess
module for this.

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

#95195

On Sunday, August 9, 2015 at 8:11:18 AM UTC-6, roge...@gmail.com wrote:
> Just learning Python and have a question.
> 
> Is it possible for Python to pass information to another program (in Windows), wait for that program to finish and then resume operating?
> 
> It's called a pipe in Unix systems.
> 
> Thanks,
> 
> Roger

Where can I find out about this? It's not mentioned in my "Introduction to Python" book.

Roger

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

#95197

On Sun, Aug 9, 2015 at 11:39 AM,  <rogerh906@gmail.com> wrote:
> Where can I find out about this? It's not mentioned in my "Introduction to Python" book.

The Python documentation at docs.python.org are an important resource,
and in particular the subprocess module is covered at
https://docs.python.org/3/library/subprocess.html.

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

#95200

On 09/08/2015 18:52, Ian Kelly wrote:
> On Sun, Aug 9, 2015 at 11:39 AM,  <rogerh906@gmail.com> wrote:
>> Where can I find out about this? It's not mentioned in my "Introduction to Python" book.
>
> The Python documentation at docs.python.org are an important resource,
> and in particular the subprocess module is covered at
> https://docs.python.org/3/library/subprocess.html.
>

Just a tip aimed at everybody.  If you go to the main page here 
https://docs.python.org/3/ up in the top right corner it says "modules | 
index".  The former is for all modules in the standard library, the 
latter is the general index for everything in all of the docs.  Both of 
them are a real time saver.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

#95198

On Sunday, August 9, 2015 at 8:11:18 AM UTC-6, roge...@gmail.com wrote:
> Just learning Python and have a question.
> 
> Is it possible for Python to pass information to another program (in Windows), wait for that program to finish and then resume operating?
> 
> It's called a pipe in Unix systems.
> 
> Thanks,
> 
> Roger

Nevermind, I found it. Thanks for the pointer. But WOW! Python is described as an easy to learn language. I don't think so!

Roger

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

#95201

On 8/9/2015 10:55 AM, rogerh906@gmail.com wrote:
> On Sunday, August 9, 2015 at 8:11:18 AM UTC-6, roge...@gmail.com wrote:
>> Just learning Python and have a question.
>>
>> Is it possible for Python to pass information to another program
 >>(in Windows), wait for that program to finish and then resume operating?
>>
>> It's called a pipe in Unix systems.
>>
>> Thanks,
>>
>> Roger
>
> Nevermind, I found it. Thanks for the pointer. But WOW! Python is described
 > as an easy to learn language. I don't think so!

Well, 2.7 only has 31 keywords most of which are easily understood[1], 
as is the enforced indentation structure.  Also, pipes and interprocess 
communications aren't usually CS101 level classes.  The libraries are 
where things get interesting and where you should focus your attention.

https://docs.python.org/2/library/ is the official docs, but effbot's 
guide, while old, is not entirely obsolete and still provides a nice 
overview of things.  See http://effbot.org/zone/librarybook-index.htm

Emile


[1]
and       del       from      not       while
as        elif      global    or        with
assert    else      if        pass      yield
break     except    import    print
class     exec      in        raise
continue  finally   is        return
def       for       lambda    try

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

#95202

On Sun, 09 Aug 2015 10:55:36 -0700, rogerh906 wrote:

> On Sunday, August 9, 2015 at 8:11:18 AM UTC-6, roge...@gmail.com wrote:
>> Just learning Python and have a question.
>> 
>> Is it possible for Python to pass information to another program (in
>> Windows), wait for that program to finish and then resume operating?
>> 
>> It's called a pipe in Unix systems.
>> 
>> Thanks,
>> 
>> Roger
> 
> Nevermind, I found it. Thanks for the pointer. But WOW! Python is
> described as an easy to learn language. I don't think so!
> 
> Roger

that depends on what you are comparing it to.

I used to be an assembler programmer on on 8 bit micros so I believe i 
have a reasonable programming background & found python much easier to 
learn than for example C.




-- 
And on the seventh day, He exited from append mode.

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

#95204

On Sun, 9 Aug 2015 10:55:36 -0700 (PDT), rogerh906@gmail.com declaimed the
following:

>
>Nevermind, I found it. Thanks for the pointer. But WOW! Python is described as an easy to learn language. I don't think so!
>
	It is... The Language Reference Manual is only some 70 or so pages (I
haven't counted the later versions; probably grew to 100 behind my back).

	But the LIBRARIES that do all the nice things for you so you don't have
program the stuff from scratch may take some time to get familiar.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

#95205

On 09/08/2015 21:43, Dennis Lee Bieber wrote:
> On Sun, 9 Aug 2015 10:55:36 -0700 (PDT), rogerh906@gmail.com declaimed the
> following:
>
>>
>> Nevermind, I found it. Thanks for the pointer. But WOW! Python is described as an easy to learn language. I don't think so!
>>
> 	It is... The Language Reference Manual is only some 70 or so pages (I
> haven't counted the later versions; probably grew to 100 behind my back).
>
> 	But the LIBRARIES that do all the nice things for you so you don't have
> program the stuff from scratch may take some time to get familiar.
>

I assume that by LIBRARIES you mean the stdlib?  Once you've mastered 
all of them, a couple of hundred at most which shouldn't take more than 
a few minutes, it shouldn't take too very much longer to get to grips 
with the 64337 packages listed on pypi alone.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

#95206

On 09Aug2015 10:55, rogerh906@gmail.com <rogerh906@gmail.com> wrote:
>But WOW! Python is described as an easy to learn language. I don't think so!

The language itself is pretty compact and expressive. You also need to gain 
some familarity with the standard library that comes with it. That has lots of 
stuff. "subprocess" is part of the library.

I'm not sure what metric you're using here for "easy to learn".

Cheers,
Cameron Simpson <cs@zip.com.au>

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

#95208

> -----Original Message-----
> From: Python-list [mailto:python-list-
> bounces+crk=godblessthe.us@python.org] On Behalf Of Dennis Lee Bieber
> Sent: Sunday, August 09, 2015 1:43 PM
> To: python-list@python.org
> Subject: Re: Pipes
> 
> On Sun, 9 Aug 2015 10:55:36 -0700 (PDT), rogerh906@gmail.com declaimed
> the
> following:
> 
> >
> >Nevermind, I found it. Thanks for the pointer. But WOW! Python is
> described as an easy to learn language. I don't think so!
> >
> 	It is... The Language Reference Manual is only some 70 or so pages
(I
> haven't counted the later versions; probably grew to 100 behind my back).
> 
> 	But the LIBRARIES that do all the nice things for you so you don't
have
> program the stuff from scratch may take some time to get familiar.

But there is nothing non-cryptic and orderly that I have found that lists
out various modules and packages. If you know the module, it generally gives
most of the information, but if you don't know the module name or function
capability, you're lost. It would be nice to have a 'if you want to do this,
look at these packages'. You have a language ref that defines the basics but
gives very little insight. Take list comprehension. As described in the
language ref and given tutotial, you get maybe a paragraph of what it is,
but there was no definition of what the brackets were for or how the
comprehension worked and maybe you get one or two examples, but you're still
left with what is it.

Is there an up to date book on 3.x even. Every book seems to be from 2006 or
so.

Clayton
> --
> 	Wulfraed                 Dennis Lee Bieber         AF6VN
>     wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/
> 
> --
> https://mail.python.org/mailman/listinfo/python-list

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

#95217

On Mon, Aug 10, 2015 at 12:55 PM, Roger Hunter <rogerh906@gmail.com> wrote:
> I agree that some of Python is simple but the description of subprocess is
> certainly not.

That's because spawning subprocesses is a complicated thing to do - or
rather, it's a simple thing to do, but with a large number of options.
This is particularly true when you want (a) security, (b) performance,
(c) flexibility, and (d) convenience/simplicity in your code, as you
basically can't have all of them at once. Compare other modern
languages and how they go about spawning processes; chances are you'll
see stuff about chroot, standard streams, environment, uid/gid,
priority, file descriptors, resource limits, whether it uses a shell,
and stuff like that. Python handles all of those using keyword
arguments; Pike lets you provide an options mapping; I'm guessing
Node.js has you provide an object with key/value pairs to configure
it; whatever your language, whatever your framework, these features
require a bit of complexity.

Python *is* simple. As languages go, Python has far fewer edge cases
and detaily bits than most. But you can't get away from the inherent
complexity of computers... fortunately, Python puts most of that into
its standard library, so you can follow the standard lookup rules and
function calling conventions to figure out what's going on.

Of course, simplicity isn't all there is to making a good language.
Ook has just three tokens (used in pairs, making eight effective
opcodes), but that doesn't make it easy to use.

ChrisA

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

#95220

On 10/08/2015 03:55, Roger Hunter wrote:
> I agree that some of Python is simple but the description of subprocess
> is certainly not.
>
> I spent much of my working career using Fortran and TrueBasic on mainframes.

That's good.  It means that you were probably taught to read and write 
from left to right *AND* from top to bottom.  Would you like to keep to 
that convention here please as it makes following long threads much 
easier, thank you.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

#95221

On Monday, August 10, 2015 at 7:45:28 AM UTC-6, Mark Lawrence wrote:
> On 10/08/2015 03:55, Roger Hunter wrote:
> > I agree that some of Python is simple but the description of subprocess
> > is certainly not.
> >
> > I spent much of my working career using Fortran and TrueBasic on mainframes.
> 
> That's good.  It means that you were probably taught to read and write 
> from left to right *AND* from top to bottom.  Would you like to keep to 
> that convention here please as it makes following long threads much 
> easier, thank you.
> 
> -- 
> My fellow Pythonistas, ask not what our language can do for you, ask
> what you can do for our language.
> 
> Mark Lawrence

Sorry Mark, I don't know how these posts came out backward. I didn't do it.

Roger

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

#95222

On 10/08/2015 15:05, rogerh906@gmail.com wrote:
> On Monday, August 10, 2015 at 7:45:28 AM UTC-6, Mark Lawrence wrote:
>> On 10/08/2015 03:55, Roger Hunter wrote:
>>> I agree that some of Python is simple but the description of subprocess
>>> is certainly not.
>>>
>>> I spent much of my working career using Fortran and TrueBasic on mainframes.
>>
>> That's good.  It means that you were probably taught to read and write
>> from left to right *AND* from top to bottom.  Would you like to keep to
>> that convention here please as it makes following long threads much
>> easier, thank you.
>>
>> --
>> My fellow Pythonistas, ask not what our language can do for you, ask
>> what you can do for our language.
>>
>> Mark Lawrence
>
> Sorry Mark, I don't know how these posts came out backward. I didn't do it.
>
> Roger
>

Nothing to worry about.  It's mostly a result of people so used to M$ 
Outlook in a business environment that they don't stop to think about 
it.  On short threads it's not a problem, but some Python related 
threads can run into hundreds of entries, all being bounced backwards 
and forwards between umpteen different technologies.  Try reading those 
if they're all top posted, complete nightmare.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

#95199

On Sun, 9 Aug 2015 07:10:50 -0700 (PDT), rogerh906@gmail.com declaimed the
following:

>Just learning Python and have a question.
>
>Is it possible for Python to pass information to another program (in Windows), wait for that program to finish and then resume operating?
>
>It's called a pipe in Unix systems.
>

	They are called pipes in Windows too... IF you mean the chaining of one
process's stdout to another process's stdin -- and this feature is handled
by the OS, not Python.

-=-=-=-=- generator.py
import random
import sys

for i in xrange(100):   #yes, it's Python 2.7!
    sys.stdout.write("%s\n" %
                     (random.randint(1, 6)
                     + random.randint(1, 6)) )

-=-=-=-=- eater.py
import sys

while True:
    ln = sys.stdin.readline()
    if not ln: break
    v = int(ln.strip())
    if v == 2:
        v = "snake-eyes"
    elif v == 12:
        v = "boxcars"
    print "You rolled %s" % v

-=-=-=-=- console
C:\Users\Wulfraed\Documents\Python Progs>generator | eater
You rolled 6
You rolled 11
You rolled 6
You rolled 5
You rolled 11
You rolled 4
You rolled 4
You rolled 7
You rolled 3
You rolled boxcars
You rolled 9
You rolled 8
You rolled 6
You rolled 7
You rolled 9
You rolled 7
You rolled 3
You rolled 8
You rolled 3
You rolled snake-eyes
You rolled 6
You rolled 9
You rolled snake-eyes
You rolled 7
You rolled 7
You rolled 7
You rolled 10
You rolled 7
You rolled 7
You rolled 7
You rolled 6
You rolled 3
You rolled 9
You rolled 4
You rolled 11
You rolled 6
You rolled 8
You rolled 7
You rolled 6
You rolled 10
You rolled 6
You rolled 8
You rolled 6
You rolled 9
You rolled 6
You rolled boxcars
You rolled 8
You rolled 9
You rolled 9
You rolled 4
You rolled 7
You rolled 5
You rolled 8
You rolled 5
You rolled 11
You rolled 7
You rolled snake-eyes
You rolled 8
You rolled snake-eyes
You rolled 6
You rolled 9
You rolled 6
You rolled 6
You rolled 6
You rolled 10
You rolled 7
You rolled 6
You rolled 8
You rolled 7
You rolled 6
You rolled 6
You rolled 9
You rolled 5
You rolled 5
You rolled 4
You rolled 6
You rolled 4
You rolled 8
You rolled 8
You rolled snake-eyes
You rolled 7
You rolled 5
You rolled 4
You rolled 7
You rolled 6
You rolled 7
You rolled 8
You rolled 8
You rolled 10
You rolled 9
You rolled 5
You rolled 10
You rolled 6
You rolled 8
You rolled 3
You rolled 5
You rolled 5
You rolled 4
You rolled 9
You rolled 8

C:\Users\Wulfraed\Documents\Python Progs>

	If you mean something more complex, then I suggest you read the library
manual -- in particular, look for the module "subprocess"
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

#95227

<rogerh906@gmail.com> wrote in message 
news:d6a3dfe4-8389-463b-ac66-a93f14a91a5e@googlegroups.com...
> Just learning Python and have a question.

Posted by E.D.G. on August 10, 2015

       Roger's original post is largely a continuation of my July 25, 2015 
posting regarding "Python Questions."  His post does not actually explain 
what the general goal is here.  So I will explain it once again.

       It has been my experience that researchers, particularly scientists, 
need to have some versatile and powerful programming language available that 
is compatible with the Windows operating system.  The language needs to make 
certain resources available to the researchers.  And in some form it should 
ultimately be compatible with other operating systems.

       Among the needed resources would be the ability to open and close 
files, read from and write to files, open "pipes" to other Windows programs, 
execute system or shell commands, read and respond to keyboard key presses, 
send text etc. to a running Windows program such as Notepad.exe and have it 
printed on the screen, and read and write to the Windows clipboard.

       Other important resources would be the ability to perform rapid 
calculations and the ability to generate plots that could display on the 
screen and also be saved as .png files etc.

       The language also has to have the ability to be "cloned."  That means 
that it could be stored in some directory that could be copied from one 
computer to another.  And programs written with that language would then run 
on the new computer.  One person responding to my own earlier post stated 
that this is possible with Python.

       There are not too many programming languages that can do all of those 
things.  Perl and probably Fortran will.  But we could not get simple 
questions answered regarding how to do specific things such as open a "pipe" 
to a running Windows program.  And there are two versions of Fortran, 
gfortran and F95 that we looked at.  And we could not decided which one 
would work better.

       Python apparently also provides all of the necessary resources.  And 
as all of these posts demonstrate, it has the major advantage in that when a 
question gets asked in the Python newsgroup, there is usually an answer.

       It will likely be up to Roger to decide if we will go with gfortran 
or Python since he does most of the actual computer program code 
development.  Even though he prefers True Basic, I explained that we can't 
continue to use it.  For example, with the versions we have been using, when 
it is waiting for a key to be pressed it is using 100% of the processor 
time.  Perl and Fortran and probably Python just "go to sleep" while they 
are waiting for the Enter key to be pressed.  They largely stop using the 
processor.

       The following is an example of how it can be important for 
researchers to have a powerful and versatile programming language available:

       I needed a program that could generate data regarding the locations 
of the sun and the moon in the sky in response to specific times entered. 
Roger developed the basic equations with some help from another researcher. 
And that took a while.  But it probably took a full six months for us to 
compare notes by E-mail and get the program into a final form that people 
could download for free use.

       That is just too much time.  Researchers need to be able to do things 
such as create simple charts etc. without spending months or years learning 
some programming language or comparing notes with one another.  So, an 
entire Python directory that made that possible and that had clear 
instructions for how to open and close files and create "pipes" etc. would 
get the job done.

       If Roger wants to use Python then we might use the ActiveState 
version and then build those various resources into it.  It reportedly 
installs in a Windows environment without problems.  And I myself have used 
the ActiveState versions of Perl for quite a few years with a considerable 
amount of success.

       This assumes that the ActiveState version of Python can be taught to 
do fast calculations and to generate charts.  If that does not look possible 
or easy then we will probably try one of the available scientific versions 
of Python.

       Would researchers then put professional Python programmers "out of 
business?"

       The answer is probably just the opposite.  Researchers want to do 
research and not write computer programs.  And if they can do at least some 
programming themselves then it makes it easier for them to work with 
professional programmers and explain what needs to be done.  They are then 
more inclined to work with the programmers.  And they won't have to compare 
notes with them for six months just to get a relatively simple task 
completed.

Regards to all,

E.D.G.

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

#95231

On 10/08/2015 21:43, E.D.G. wrote:
> <rogerh906@gmail.com> wrote in message
> news:d6a3dfe4-8389-463b-ac66-a93f14a91a5e@googlegroups.com...
>> Just learning Python and have a question.

>        Other important resources would be the ability to perform rapid
> calculations and the ability to generate plots that could display on the
> screen and also be saved as .png files etc.

numpy and matplotlib are the leaders here.

>
>        The language also has to have the ability to be "cloned."  That
> means that it could be stored in some directory that could be copied
> from one computer to another.  And programs written with that language
> would then run on the new computer.  One person responding to my own
> earlier post stated that this is possible with Python.

Certainly.  In your position I think the easiest option is to have 
Python installed on all your machines and simply copy your programs aka 
scripts from machine to machine.  I suppose it all depends on how easy 
it is to bribe your admin people!!!

>
>        Python apparently also provides all of the necessary resources.
> And as all of these posts demonstrate, it has the major advantage in
> that when a question gets asked in the Python newsgroup, there is
> usually an answer.

No "usually" about it :)

>        I needed a program that could generate data regarding the
> locations of the sun and the moon in the sky in response to specific
> times entered. Roger developed the basic equations with some help from
> another researcher. And that took a while.  But it probably took a full
> six months for us to compare notes by E-mail and get the program into a
> final form that people could download for free use.
> That is just too much time.  Researchers need to be able to do
> things such as create simple charts etc. without spending months or
> years learning some programming language or comparing notes with one
> another.  So, an entire Python directory that made that possible and
> that had clear instructions for how to open and close files and create
> "pipes" etc. would get the job done.

http://ipython.org/notebook.html could be what you're looking for here, 
both for your collaboration rather than comparing notes by email, and 
for actually producing your output.

>
>        If Roger wants to use Python then we might use the ActiveState
> version and then build those various resources into it.  It reportedly
> installs in a Windows environment without problems.  And I myself have
> used the ActiveState versions of Perl for quite a few years with a
> considerable amount of success.
>
>        This assumes that the ActiveState version of Python can be taught
> to do fast calculations and to generate charts.  If that does not look
> possible or easy then we will probably try one of the available
> scientific versions of Python.

Anaconda always comes up in this area, with numpy, ipython and 
matplotlib included in the distibution, see 
http://docs.continuum.io/anaconda/index

>
>        Would researchers then put professional Python programmers "out
> of business?"

No, they'll work perfectly happily side by side.

If you're not already aware then scipy http://www.scipy.org/ should be 
pointed out, as well as pypi https://pypi.python.org/pypi which 
currently holds 64383 packages.  Heck, I almost forgot pythonlibs 
http://www.lfd.uci.edu/~gohlke/pythonlibs/ which is a godsend if you 
haven't got Visual Studio and don't want to install it.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

#95232

On Mon, 10 Aug 2015 15:43:26 -0500, "E.D.G." <edgrsprj@ix.netcom.com>
declaimed the following:

>       Other important resources would be the ability to perform rapid 
>calculations and the ability to generate plots that could display on the 
>screen and also be saved as .png files etc.
>
	None of which are "native" to Python. The common number cruncher
accelerator is to install numpy/scipy, matplotlib (or related) for
plots/charts, and maybe PIL/pillow for generation of image files.

>       The language also has to have the ability to be "cloned."  That means 
>that it could be stored in some directory that could be copied from one 
>computer to another.  And programs written with that language would then run 
>on the new computer.  One person responding to my own earlier post stated 
>that this is possible with Python.
>
	The normal "no-install" packaging scheme, from what I've seen, work by
packaging all the modules/libraries (including the core interpreter) with
the program files -- making an "executable" that operates by unpacking
everything into a temporary directory, running the provided source files,
and then deleting (I think) the temporary directory when done.

	If you expect people to do ad hoc programs, they'll need a more
standard install on the target machine, with the interpreter exposed.

	Besides numpy, et al... If doing statistical stuff, there is rPy -- a
module for driving the R statistics package from Python.

>       There are not too many programming languages that can do all of those 
>things.  Perl and probably Fortran will.  But we could not get simple 
>questions answered regarding how to do specific things such as open a "pipe" 
>to a running Windows program.  And there are two versions of Fortran, 
>gfortran and F95 that we looked at.  And we could not decided which one 
>would work better.

	"F95", to most of the world, specifies the level of the language
standard (a tweaked variant of F90). gfortran is an implementation in the
GCC system supporting F95 along with F2003 and F2008 updates to the
standard.

	For the most part, in such languages (including souped up Pascal, Ada,
C), operations like IPC (interprocess communication -- "pipes" are just one
form of such, biased on the UNIX/Linux concept that everything works as a
stream filter [input on stdin, manipulate it, send output to stdout, and
linking stdout to the stdin of the next program]; on the old VMS OS one
would use "mailboxes" and on the Amiga "message ports")... Operations like
IPC are OS level features and one has to code for the OS (ie,
non-portable). The Python subprocess module is one such OS-specific bit of
code -- someone (the Python developers) defined an API for use on all
supported OS, and then had to write OS specific parts to perform the
function. Even with the one API, there are subtle differences between OS.
Windows doesn't do "fork" so each subprocess goes through the full Windows
process creation overhead. What are stand-alone executable utilities in
UNIX/Linux may be built-in to a Windows command line interpreter -- so on
Windows one has to have a subprocess "with shell" for those.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web