forcallpy: embed Python, call Python scripts within Fortran programs

[Laurent Pointal]

Hello,

Here is an announce for people with main Fortran programs who need to 
call Python scripts and do not want to start another process each time. 
Forcallpy embeds the Python interpreter in your Fortran program and makes 
scalars or one dimensional arrays of numbers easy to transmit between the 
two languages. It automatically install numpy in the Python side (used by 
this library), and support Python multithreading.

Project git repository and bug tracking:

https://sourcesup.renater.fr/projects/forcallpy/

Documentation:

https://forcallpy.readthedocs.io/en/latest/

For an example, here is the Fortran demo program, without comments (more 
details in documentation about values transmission between Python and 
Fortran):

PROGRAM forcallpy_demo
  USE forcallpy
  USE, INTRINSIC :: iso_c_binding, ONLY: c_ptr, c_null_ptr, c_loc
 
  IMPLICIT NONE
  INTEGER :: coderr
  INTEGER :: intres
  INTEGER,DIMENSION(10),TARGET :: tabint;
  DOUBLE PRECISION,DIMENSION(5),TARGET :: tabdbl;
  TYPE(c_ptr),DIMENSION(3) :: tabptr;
  DOUBLE PRECISION,DIMENSION(4),TARGET :: tabres;
 
  tabint(1:10) = (/ 3, 4, 5, 6, 7, 8, 9, 10, 11, 12  /)
  tabdbl(1:5) = (/ 10.1, 10.3, 10.5, 10.7, 10.9 /)
  tabptr(1:3) = (/ c_null_ptr, c_null_ptr , c_null_ptr  /)
  tabres(1:4) = (/ 0.0, 0.0, 0.0, 0.0 /)
  tabptr(2) = c_loc(tabdbl)
 
  CALL pyinit(register_sighandlers=1, print_errors=1, verbosity=0, &
 coderr=coderr)

  CALL pyrun_i4r8('print("result =",3 + 4 *  x)', x=3.6D0)
  CALL pyrun_i4r8('for i in range(3): print("This is a Python loop", i, 
"directly in fortran source.")')
  CALL pyrun_i4r8('import math')
  CALL pyrun_i4r8('print("Pi value is", math.pi)')
  CALL pyrun_i4r8('import sys'//NEW_LINE('a')//'sys.path.insert(0, ".")')
  CALL pyrun_i4r8('import forcallpy_demomodule')
  CALL pyrun_i4r8('print("Doc forcallpy:", forcallpy.__doc__)')
  CALL pyrun_i4r8('print("Namespace forcallpy:", dir(forcallpy)')
  intres = pyfct_i4r8_i4(&
"int(forcallpy_demomodule.a_function(a,b,c,x,av,zv,yw))", &
a=2,b=-4,c=7,x=3.5D+0,av=tabint,zv=tabdbl,yw=tabres)
  WRITE(*,*) "Result =", intres
  WRITE(*,*) "Inout array after:", tabres
  CALL pysub_i4r8("forcallpy_demomodule.a_subroutine(av,zv,p)", &
av=tabint,zv=tabdbl,p=tabptr) 
  WRITE(*,*) "Computing a zero division in Python"
  CALL pysub_i4r8("print(1/0)")
  CALL pyrun_i4r8('forcallpy_demomodule.test_threading()')
  call sleep(10)
  CALL pyterm() 
END PROGRAM forcallpy_demo

--

L.Pointal 
CNRS / LIMSI
-- 
https://mail.python.org/mailman/listinfo/python-announce-list

Support the Python Software Foundation:
http://www.python.org/psf/donations/

pyinstaller not finding external fortran executable

[Heli]

Dear all, 

My code consists of a graphical user interface written in PySide. This GUI will 
then call a FORTRAN executable. 

I run the FORTRAN executable using the following lines in my script:

curPath = os.path.dirname(os.path.realpath(__file__))
execPath = os.path.join(curPath, "myFORTRAN.out")
returnValue = subprocess.call([execPath, self.runConfig]


The script works fine and finds executable. The problem is when I use 
pyinstaller. I use the following command to create standalone executable that 
bundles my script, the external FORTRAN executable and all necessary python 
modules/libraries in to one standalone executable.  

pyinstaller --hidden-import=h5py.defs --hidden-import=h5py.utils 
--hidden-import=h5py.h5ac --hidden-import=h5pyl_proxy main_script.py --onefile

I get the following error running this standalone executable:


  File "subprocess.py", line 534, in call
  File "subprocess.py", line 856, in __init__
  File "subprocess.py", line 1464, in _execute_child
FileNotFoundError: [Errno 2] No such file or directory: 
/myFORTRAN.out'

If I manually copy myFORTRAN.out in to the same directory as the standalone 
executable created by pyinstaller, then it works. 

Does anybody know how to fix this?

Thanks in Advance for your help, 





-- 
https://mail.python.org/mailman/listinfo/python-list

Re: python to call or start a fortran a.out

[Rick Johnson]

On Monday, August 21, 2017 at 11:31:48 AM UTC-5, Chet Buell wrote:
> Need some help with updating python to call or start a
> fortran a.out executable  The problem I am having is I have
> an old Fortran based model that I need to run, in the past
> the fortran was triggered through the following python
> code:
> 
> #run fortran
> x = commands.getoutput(path+'/a.out')
> 
> Since the commands.getoutput has been depreciated it will
> not run on the newly built server that will now host this
> model. I have manually confirmed that the compiled a.out
> does run and produces the files, but the problem I am
> having is in triggering it to run with python.  The answer
> is probably so easy it is obviously being overlooked, but I
> can not seem to find it.  Any suggestions or help would be
> greatly appreciated.

> TITLE: python to call or start a fortran a.out

Please do consider the title of your posts more carefully.

The title you chose here was unfortunate, as it will not
provide an intuitive link between the problem and the
solution, therefore, it is unlikely that someone with the
same _general_ problem, will benefit from this exchange in
the future.

The _general_ problem here had nothing to with Fortran, much
less a specific file or executable named "a.out". So a
better title would have been: "How to run an executable from
Python", or: "How to spawn a subprocess from Python and
capture the result". Or even: "How to poke my OS with a
sharp stick, using Python". Perhaps the last example was a
bit too generalized, i admit, but you get the point. :-)

A good template for composing questions on internet forums
is as follows:

  MESSAGE_TITLE: "A concise, generalization of the problem here..."

  MESSAGE_BODY: " An elaborate and specific explanation of the problem here..."

Mentioning "Fortran" and "a.out" in the body of the message,
would be fine.

One of the happy-accidents[1] of composing thoughtful
queries, is that, many times you will happen upon the answer
to your own question during the composition process, and
even if you don't, at least you will have a much better
chance of receiving prompt and quality responses by
following this template. So either way, it's a win-win.

[1] Think "Bob Ross" here. As his most important
contribution to society was that he taught us all a very
important lesson. Namely, that all accidents can be "happy
accidents". An eternal optimist, he was...
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: python to call or start a fortran a.out

[Peter Otten]

Chet Buell wrote:

> Need some help with updating python to call or start a fortran a.out
> executable
> 
> The problem I am having is I have an old Fortran based model that I need
> to run, in the past the fortran was triggered through the following
> python code:
> 
> #run fortran
> x = commands.getoutput(path+'/a.out')
> 
> Since the commands.getoutput has been depreciated it will not run on the
> newly built server that will now host this model. I have manually
> confirmed that the compiled a.out does run and produces the files, but
> the problem I am having is in triggering it to run with python.
> 
> The answer is probably so easy it is obviously being overlooked, but I
> can not seem to find it.  Any suggestions or help would be greatly
> appreciated.

I don't see how the documentation could be made more explicit than

https://docs.python.org/2/library/commands.html

"""
Note In Python 3.x [...] getstatusoutput() and getoutput() have been moved 
to the subprocess module.
"""

There is also the 2to3 tool that may help you with the mechanical part of 
the migration from Python 2.7 to 3.x. Example:

$ cat runfortran.py
#!/usr/bin/env python
import commands

x = commands.getoutput(path+'/a.out')
print x
$ 2to3-3.6 -w runfortran.py
RefactoringTool: Skipping optional fixer: buffer
[...]
RefactoringTool: Files that were modified:
RefactoringTool: runfortran.py
$ cat runfortran.py
#!/usr/bin/env python
import subprocess

x = subprocess.getoutput(path+'/a.out')
print(x)
$ 

Personally I would avoid the shell and capture stdout/err in separate 
strings with

p = subprocess.run(
[os.path.join(path, "a.out")], 
stdout=subprocess.PIPE, stderr=subprocess.PIPE,
universal_newlines=True
)
print(p.stdout)

or similar.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: python to call or start a fortran a.out

[Grant Edwards]

On 2017-08-21, Chet Buell <clbu...@ncsu.edu> wrote:
> Need some help with updating python to call or start a fortran a.out 
> executable
>
> The problem I am having is I have an old Fortran based model that I need 
> to run, in the past the fortran was triggered through the following 
> python code:
>
> #run fortran
> x = commands.getoutput(path+'/a.out')
>
> Since the commands.getoutput has been depreciated it will not run on the 
> newly built server that will now host this model. I have manually 
> confirmed that the compiled a.out does run and produces the files, but 
> the problem I am having is in triggering it to run with python.
>
> The answer is probably so easy it is obviously being overlooked, but I 
> can not seem to find it.  Any suggestions or help would be greatly 
> appreciated.

https://docs.python.org/2/library/commands.html:

   Deprecated since version 2.6: The commands module has been removed
   in Python 3. Use the subprocess module instead.

   The subprocess module provides more powerful facilities for
   spawning new processes and retrieving their results. Using the
   subprocess module is preferable to using the commands module.

https://docs.python.org/2/library/subprocess.html#popen-constructor:


-- 
Grant Edwards   grant.b.edwardsYow! I'm encased in the
  at   lining of a pure pork
  gmail.comsausage!!

-- 
https://mail.python.org/mailman/listinfo/python-list

python to call or start a fortran a.out

[Chet Buell]

Need some help with updating python to call or start a fortran a.out 
executable


The problem I am having is I have an old Fortran based model that I need 
to run, in the past the fortran was triggered through the following 
python code:


#run fortran
x = commands.getoutput(path+'/a.out')

Since the commands.getoutput has been depreciated it will not run on the 
newly built server that will now host this model. I have manually 
confirmed that the compiled a.out does run and produces the files, but 
the problem I am having is in triggering it to run with python.


The answer is probably so easy it is obviously being overlooked, but I 
can not seem to find it.  Any suggestions or help would be greatly 
appreciated.





--
https://mail.python.org/mailman/listinfo/python-list

Re: Reading Fortran Ascii output using python

[Heli]

On Monday, October 31, 2016 at 8:03:53 PM UTC+1, MRAB wrote:
> On 2016-10-31 17:46, Heli wrote:
> > On Monday, October 31, 2016 at 6:30:12 PM UTC+1, Irmen de Jong wrote:
> >> On 31-10-2016 18:20, Heli wrote:
> >> > Hi all,
> >> >
> >> > I am trying to read an ascii file written in Fortran90 using python. I 
> >> > am reading this file by opening the input file and then reading using:
> >> >
> >> > inputfile.readline()
> >> >
> >> > On each line of the ascii file I have a few numbers like this:
> >> >
> >> > line 1: 1
> >> > line 2: 1000.834739 2000.38473 3000.349798
> >> > line 3: 1000 2000 5000.69394 99934.374638 54646.9784
> >> >
> >> > The problem is when I have more than 3 numbers on the same line such as 
> >> > line 3, python seems to read this using two reads. This makes the above 
> >> > example will be read like this:
> >> >
> >> > line 1: 1
> >> > line 2: 1000.834739 2000.38473 3000.349798
> >> > line 3: 1000 2000 5000.69394
> >> > line 4: 99934.374638 54646.9784
> >> >
> >> > How can I fix this for each fortran line to be read correctly using 
> >> > python?
> >> >
> >> > Thanks in Advance for your help,
> >> >
> >> >
> >>
> >> You don't show any code so it's hard to say what is going on.
> >> My guess is that your file contains spurious newlines and/or CRLF 
> >> combinations.
> >>
> >> Try opening the file in universal newline mode and see what happens?
> >>
> >> with open("fortranfile.txt", "rU") as f:
> >> for line in f:
> >> print("LINE:", line)
> >>
> >>
> >> Irmen
> >
> > Thanks Irmen,
> >
> > I tried with "rU" but that did not make a difference. The problem is a line 
> > that with one single write statement in my fortran code :
> >
> > write(UNIT=9,FMT="(99g20.8)")  value
> >
> > seems to be read in two python inputfile.readline().
> >
> > Any ideas how I should be fixing this?
> >
> > Thanks,
> >
> What is actually in the file?
> 
> Try opening it in binary mode and print using the ascii function:
> 
>  with open("fortranfile.txt", "rb") as f:
>  contents = f.read()
> 
>  print("CONTENTS:", ascii(contents))

Thanks guys, 
I solved the problem on the Fortran side. Some lines contained new lines 
characters that I fixed by setting format descriptors in Fortran.

Thanks for your help, 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Reading Fortran Ascii output using python

[MRAB]

On 2016-10-31 17:46, Heli wrote:

On Monday, October 31, 2016 at 6:30:12 PM UTC+1, Irmen de Jong wrote:

On 31-10-2016 18:20, Heli wrote:
> Hi all,
>
> I am trying to read an ascii file written in Fortran90 using python. I am 
reading this file by opening the input file and then reading using:
>
> inputfile.readline()
>
> On each line of the ascii file I have a few numbers like this:
>
> line 1: 1
> line 2: 1000.834739 2000.38473 3000.349798
> line 3: 1000 2000 5000.69394 99934.374638 54646.9784
>
> The problem is when I have more than 3 numbers on the same line such as line 
3, python seems to read this using two reads. This makes the above example will be 
read like this:
>
> line 1: 1
> line 2: 1000.834739 2000.38473 3000.349798
> line 3: 1000 2000 5000.69394
> line 4: 99934.374638 54646.9784
>
> How can I fix this for each fortran line to be read correctly using python?
>
> Thanks in Advance for your help,
>
>

You don't show any code so it's hard to say what is going on.
My guess is that your file contains spurious newlines and/or CRLF combinations.

Try opening the file in universal newline mode and see what happens?

with open("fortranfile.txt", "rU") as f:
for line in f:
print("LINE:", line)


Irmen


Thanks Irmen,

I tried with "rU" but that did not make a difference. The problem is a line 
that with one single write statement in my fortran code :

write(UNIT=9,FMT="(99g20.8)")  value

seems to be read in two python inputfile.readline().

Any ideas how I should be fixing this?

Thanks,


What is actually in the file?

Try opening it in binary mode and print using the ascii function:

with open("fortranfile.txt", "rb") as f:
contents = f.read()

print("CONTENTS:", ascii(contents))

--
https://mail.python.org/mailman/listinfo/python-list

Re: Reading Fortran Ascii output using python

[Irmen de Jong]

On 31-10-2016 19:24, Irmen de Jong wrote:
> So there must be something in that line in your file that it considers an EOF.

I meant to type EOL there. (end-of-line/newline).

Irmen

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Reading Fortran Ascii output using python

[Irmen de Jong]

On 31-10-2016 18:46, Heli wrote:

> Thanks Irmen, 
> 
> I tried with "rU" but that did not make a difference. The problem is a line 
> that with one single write statement in my fortran code :
> 
> write(UNIT=9,FMT="(99g20.8)")  value
> 
> seems to be read in two python inputfile.readline(). 
> 
> Any ideas how I should be fixing this?
> 
> Thanks, 
> 

We don't speak Fortran here (at least I don't).
Please show your Python code. What is 'inputfile'?
Also, in Python, the readline method is defined as:

>>> help(io.TextIOBase.readline)
Help on method_descriptor:

readline(...)
Read until newline or EOF.

Returns an empty string if EOF is hit immediately.

So there must be something in that line in your file that it considers an EOF.
Have you tried opening it in a regular text editor and inspecting what the 
characters
are on that particular line?


Irmen

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Reading Fortran Ascii output using python

[Heli]

On Monday, October 31, 2016 at 6:30:12 PM UTC+1, Irmen de Jong wrote:
> On 31-10-2016 18:20, Heli wrote:
> > Hi all, 
> > 
> > I am trying to read an ascii file written in Fortran90 using python. I am 
> > reading this file by opening the input file and then reading using:
> > 
> > inputfile.readline()
> > 
> > On each line of the ascii file I have a few numbers like this:
> > 
> > line 1: 1
> > line 2: 1000.834739 2000.38473 3000.349798 
> > line 3: 1000 2000 5000.69394 99934.374638 54646.9784
> > 
> > The problem is when I have more than 3 numbers on the same line such as 
> > line 3, python seems to read this using two reads. This makes the above 
> > example will be read like this:
> > 
> > line 1: 1
> > line 2: 1000.834739 2000.38473 3000.349798 
> > line 3: 1000 2000 5000.69394 
> > line 4: 99934.374638 54646.9784
> > 
> > How can I fix this for each fortran line to be read correctly using python?
> > 
> > Thanks in Advance for your help, 
> >  
> > 
> 
> You don't show any code so it's hard to say what is going on.
> My guess is that your file contains spurious newlines and/or CRLF 
> combinations.
> 
> Try opening the file in universal newline mode and see what happens?
> 
> with open("fortranfile.txt", "rU") as f:
> for line in f:
> print("LINE:", line)
> 
> 
> Irmen

Thanks Irmen, 

I tried with "rU" but that did not make a difference. The problem is a line 
that with one single write statement in my fortran code :

write(UNIT=9,FMT="(99g20.8)")  value

seems to be read in two python inputfile.readline(). 

Any ideas how I should be fixing this?

Thanks, 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Reading Fortran Ascii output using python

[Irmen de Jong]

On 31-10-2016 18:20, Heli wrote:
> Hi all, 
> 
> I am trying to read an ascii file written in Fortran90 using python. I am 
> reading this file by opening the input file and then reading using:
> 
> inputfile.readline()
> 
> On each line of the ascii file I have a few numbers like this:
> 
> line 1: 1
> line 2: 1000.834739 2000.38473 3000.349798 
> line 3: 1000 2000 5000.69394 99934.374638 54646.9784
> 
> The problem is when I have more than 3 numbers on the same line such as line 
> 3, python seems to read this using two reads. This makes the above example 
> will be read like this:
> 
> line 1: 1
> line 2: 1000.834739 2000.38473 3000.349798 
> line 3: 1000 2000 5000.69394 
> line 4: 99934.374638 54646.9784
> 
> How can I fix this for each fortran line to be read correctly using python?
> 
> Thanks in Advance for your help, 
>  
> 

You don't show any code so it's hard to say what is going on.
My guess is that your file contains spurious newlines and/or CRLF combinations.

Try opening the file in universal newline mode and see what happens?

with open("fortranfile.txt", "rU") as f:
for line in f:
print("LINE:", line)


Irmen

-- 
https://mail.python.org/mailman/listinfo/python-list

Reading Fortran Ascii output using python

[Heli]

Hi all, 

I am trying to read an ascii file written in Fortran90 using python. I am 
reading this file by opening the input file and then reading using:

inputfile.readline()

On each line of the ascii file I have a few numbers like this:

line 1: 1
line 2: 1000.834739 2000.38473 3000.349798 
line 3: 1000 2000 5000.69394 99934.374638 54646.9784

The problem is when I have more than 3 numbers on the same line such as line 3, 
python seems to read this using two reads. This makes the above example will be 
read like this:

line 1: 1
line 2: 1000.834739 2000.38473 3000.349798 
line 3: 1000 2000 5000.69394 
line 4: 99934.374638 54646.9784

How can I fix this for each fortran line to be read correctly using python?

Thanks in Advance for your help, 
 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Self Learning Fortran Programming

[Muhammad Ali]

I don't know how to change the title now, but I am looking for python.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Self Learning Fortran Programming

[Peter Pearson]

On Tue, 31 May 2016 21:50:33 -0700 (PDT), Muhammad Ali wrote:
>
> I am interested in Python programming,
[snip]

Just out of curiosity, why do you seem to be confused about whether
your interest is in FORTRAN or Python?

-- 
To email me, substitute nowhere->runbox, invalid->com.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Self Learning Fortran Programming

[Stephen Tucker]

Hi, there, Muhammad,

I have found Learning Python by Mark Lutz helpful. The fourth edition
covers both Python 2.6 and 3.x. Although it is a text book for a course
that Mark delivers, there are useful summaries of the various functions and
methods for strings, integers, etc at various spots in the book.

Stephen Tucker.


Virus-free.
www.avast.com

<#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Wed, Jun 1, 2016 at 6:47 AM, Joel Goldstick 
wrote:

> start here:
>
>
> https://www.python.org/about/gettingstarted/
>
> On Wed, Jun 1, 2016 at 12:50 AM, Muhammad Ali
>  wrote:
> >
> > Hello,
> >
> > I am interested in Python programming, however, it will be my first
> serious attempt towards coding/simulation/programming. My back ground is
> Physics, no practical experience with programming languages.
> >
> > So, this post is for the valuable suggestions from the experts that how
> can I start self learning Python from scratch to advanced level in minimum
> time. For this, please recommend Python version, literature, text books,
> websites, video lectures, your personnel tips, etc. In addition, you may
> also add some extra suggestions for shell script writing as well. You may
> recommend for both Linux and Windows operating systems.
> >
> > Looking for your posts.
> >
> > Thank you.
> > --
> > https://mail.python.org/mailman/listinfo/python-list
>
>
>
> --
> Joel Goldstick
> http://joelgoldstick.com/blog
> http://cc-baseballstats.info/stats/birthdays
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Self Learning Fortran Programming

[Joel Goldstick]

start here:


https://www.python.org/about/gettingstarted/

On Wed, Jun 1, 2016 at 12:50 AM, Muhammad Ali
 wrote:
>
> Hello,
>
> I am interested in Python programming, however, it will be my first serious 
> attempt towards coding/simulation/programming. My back ground is Physics, no 
> practical experience with programming languages.
>
> So, this post is for the valuable suggestions from the experts that how can I 
> start self learning Python from scratch to advanced level in minimum time. 
> For this, please recommend Python version, literature, text books, websites, 
> video lectures, your personnel tips, etc. In addition, you may also add some 
> extra suggestions for shell script writing as well. You may recommend for 
> both Linux and Windows operating systems.
>
> Looking for your posts.
>
> Thank you.
> --
> https://mail.python.org/mailman/listinfo/python-list



-- 
Joel Goldstick
http://joelgoldstick.com/blog
http://cc-baseballstats.info/stats/birthdays
-- 
https://mail.python.org/mailman/listinfo/python-list

Self Learning Fortran Programming

[Muhammad Ali]

Hello, 

I am interested in Python programming, however, it will be my first serious 
attempt towards coding/simulation/programming. My back ground is Physics, no 
practical experience with programming languages. 

So, this post is for the valuable suggestions from the experts that how can I 
start self learning Python from scratch to advanced level in minimum time. For 
this, please recommend Python version, literature, text books, websites, video 
lectures, your personnel tips, etc. In addition, you may also add some extra 
suggestions for shell script writing as well. You may recommend for both Linux 
and Windows operating systems. 

Looking for your posts. 

Thank you.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python and fortran Interface suggestion

[edmondo . giovannozzi]

Il giorno domenica 19 aprile 2015 22:26:58 UTC+2, Dave Angel ha scritto:
 On 04/19/2015 11:56 AM, pauld11718 wrote:
  I shall provide with further details
 
  Its about Mathematical modelling of a system. Fortran does one part and 
  python does the other part (which I am suppose to provide).
  For a time interval tn -- t_n+1, fortran code generates some values, for 
  which my python code accepts it as an input. It integrates some data for 
  the same time step tn -- tn+1 and fortran computes based on this for the 
  next time step t_n+1 -- t_n+2..and this is how loop continues.
 
  Its the fortran code calling my Python executable at all the time interval.
 
 Then you'd better find out how it's calling your executable.  Calling it 
 is very different than starting it.  The whole import x, y,z is done 
 only upon initial startup of the python code.  You can then call the 
 Python code as many times as you like without incurring that overhead again.
 
 Naturally, if the guy who designed the Fortran code didn't think the 
 same way, and is unavailable for further tweaking, you've got a problem.
 
 
  So,
  1. Is it about rebuilding every thing using cx_freeze kind of stuff in 
  windows?
 
 Don't worry about how you get installed until after you figure out how 
 you're going to get those calls and data back and forth between the 
 Fortran code and your own.
 
 
  2. As interfacing between fortran/python is via .dat file, so on every 
  time-step python executable is called it shall open()/close() .dat file. 
  This along with all those
  from  import *'s
  are unnecessary.
 
 Have you got specs on the whole dat file thing?  How will you know it's 
 time to examine the file again?  As long as you get notified through 
 some other mechanism, there's no problem in both programs having an open 
 handle on the shared file.
 
 For that matter, the notification can be implicit in the file as well.
 
 But is there a designer behind this, or is the program intending to deal 
 with something else and you're just trying to sneak in the back door?
 
 
 
  3. I dont have access to fortran code. I shall provide the python 
  executable only, which will take input from .dat file and write to another 
  .dat file. So, what is your suggestion regarding socket/pipe and python 
  installation on RAM? I have no idea with those.
 
 
 Not much point in opening a pipe if the other end isn't going to be 
 opened by the Fortran code.
 
  Isn't there a better way to handle such issues?
 
 
 Sure, there are lots of ways.  But if the Fortran code is a closed book, 
 you'll have to find out how it was designed, and do all the adapting at 
 your end.
 
 If it becomes open again, then you have the choice between having one of 
 your languages call functions in the other (ie. single process), having 
 some mechanism (like queues, or sockets) between two separately started 
 processes, and having one program launch the other repeatedly.  That 
 last is probably the least performant choice.
 
 If you google python Fortran you'll get lots of hits.  You could start 
 reading to see what your choices are.  But if the Fortran designer has 
 left the room, you'll be stuck with whatever he put together.
 
 And chances are very high that you'll need to develop, and certainly 
 test, some parts of the project on the Windows machine, and particularly 
 with the Windows C/Fortran compilers.
 
 
 -- 
 DaveA

Generally I have used f2py to link Fortran subroutines to Python, then python 
will call this Fortran subroutines. Who is calculating what is not really 
important, except that Python is the driver. You can of course also call a 
python function from Fortran (well look at the documentation of f2py).


When you are saying that you don't have access to the Fortran program what that 
does mean?
Somebody else is developing it or it is an already written full Fortran program?
If the latter I will always use Python as a driver that prepare files for the 
Fortran program then read back the data make some elaboration and prepare the 
data for the following step.

But if somebody else is writing the Fortran part or have access to the source 
tell him to give you some some subroutines that you will call from Python.
  
 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python and fortran Interface suggestion

[Dave Angel]

On 04/19/2015 11:56 AM, pauld11718 wrote:

I shall provide with further details

Its about Mathematical modelling of a system. Fortran does one part and python 
does the other part (which I am suppose to provide).
For a time interval tn -- t_n+1, fortran code generates some values, for which my 
python code accepts it as an input. It integrates some data for the same time step tn 
-- tn+1 and fortran computes based on this for the next time step t_n+1 -- 
t_n+2..and this is how loop continues.

Its the fortran code calling my Python executable at all the time interval.


Then you'd better find out how it's calling your executable.  Calling it 
is very different than starting it.  The whole import x, y,z is done 
only upon initial startup of the python code.  You can then call the 
Python code as many times as you like without incurring that overhead again.


Naturally, if the guy who designed the Fortran code didn't think the 
same way, and is unavailable for further tweaking, you've got a problem.




So,
1. Is it about rebuilding every thing using cx_freeze kind of stuff in windows?


Don't worry about how you get installed until after you figure out how 
you're going to get those calls and data back and forth between the 
Fortran code and your own.




2. As interfacing between fortran/python is via .dat file, so on every 
time-step python executable is called it shall open()/close() .dat file. This 
along with all those
from  import *'s
are unnecessary.


Have you got specs on the whole dat file thing?  How will you know it's 
time to examine the file again?  As long as you get notified through 
some other mechanism, there's no problem in both programs having an open 
handle on the shared file.


For that matter, the notification can be implicit in the file as well.

But is there a designer behind this, or is the program intending to deal 
with something else and you're just trying to sneak in the back door?





3. I dont have access to fortran code. I shall provide the python executable 
only, which will take input from .dat file and write to another .dat file. So, 
what is your suggestion regarding socket/pipe and python installation on RAM? I 
have no idea with those.



Not much point in opening a pipe if the other end isn't going to be 
opened by the Fortran code.



Isn't there a better way to handle such issues?



Sure, there are lots of ways.  But if the Fortran code is a closed book, 
you'll have to find out how it was designed, and do all the adapting at 
your end.


If it becomes open again, then you have the choice between having one of 
your languages call functions in the other (ie. single process), having 
some mechanism (like queues, or sockets) between two separately started 
processes, and having one program launch the other repeatedly.  That 
last is probably the least performant choice.


If you google python Fortran you'll get lots of hits.  You could start 
reading to see what your choices are.  But if the Fortran designer has 
left the room, you'll be stuck with whatever he put together.


And chances are very high that you'll need to develop, and certainly 
test, some parts of the project on the Windows machine, and particularly 
with the Windows C/Fortran compilers.



--
DaveA
--
https://mail.python.org/mailman/listinfo/python-list

Re: Python and fortran Interface suggestion

[Chris Angelico]

On Mon, Apr 20, 2015 at 12:48 AM, pauld11718 pauld11...@gmail.com wrote:
 I am developing a code under Ubuntu(64bit) with python using various 
 libraries. Once done, I need to generate an executable which shall be 
 interfaced with fortran program on account of further collaboration. The 
 python executable shall be used with windows(32bit).

 So, I guess everytime my python executable is called by the fortran code on 
 each time step, all those
 from  import *'s
 will be executed and are time consuming (which is not at all required). 
 Moreover, creating executable for windows, using linux is that possible by 
 any means?

 What is a better methodology for addresing such interfacing?

Hmm. Let's divide that into several parts.

1) You need to have a Python program that interfaces with Fortran.

Does it need to call functions from a Fortran library, or is it simply
invoked by the Fortran program and that's it? If the latter, it's not
hard. But if you're concerned about startup time, you may want to
consider having your Python program keep running indefinitely, and
have some alternative means of communicating between them. For
instance, Python might create a socket or pipe, which the Fortran
program opens and writes to, and then reads a response. (If you can't
edit the Fortran code at all, it's pretty easy to write a slim stub
executable that does the socket/pipe handling.) Or alternatively,
install Python onto a RAM disk, to improve startup time that way.

2) You need to run the whole kit and caboodle on Windows. The best way
to do this is simply to write clean Python code, and then install a
Windows Python, and everything will work just fine. However, Windows
does tend to have far worse disk cache management than Linux has,
which will exacerbate your startup delays.

3) Above all, you need to know exactly how long things are taking.
Before you start trying to speed things up, first figure out where
it's actually slow. You never know, it might already be fast enough!

Check out some details, see how things go. On the face of it, I'd
guess that what you want to do will be quite doable.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Python and fortran Interface suggestion

[pauld11718]

I am developing a code under Ubuntu(64bit) with python using various libraries. 
Once done, I need to generate an executable which shall be interfaced with 
fortran program on account of further collaboration. The python executable 
shall be used with windows(32bit).

So, I guess everytime my python executable is called by the fortran code on 
each time step, all those
from  import *'s
will be executed and are time consuming (which is not at all required). 
Moreover, creating executable for windows, using linux is that possible by any 
means?

What is a better methodology for addresing such interfacing?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python and fortran Interface suggestion

[pauld11718]

I shall provide with further details

Its about Mathematical modelling of a system. Fortran does one part and python 
does the other part (which I am suppose to provide).
For a time interval tn -- t_n+1, fortran code generates some values, for which 
my python code accepts it as an input. It integrates some data for the same 
time step tn -- tn+1 and fortran computes based on this for the next time step 
t_n+1 -- t_n+2..and this is how loop continues.

Its the fortran code calling my Python executable at all the time interval.

So,
1. Is it about rebuilding every thing using cx_freeze kind of stuff in windows? 

2. As interfacing between fortran/python is via .dat file, so on every 
time-step python executable is called it shall open()/close() .dat file. This 
along with all those 
from  import *'s
are unnecessary.

3. I dont have access to fortran code. I shall provide the python executable 
only, which will take input from .dat file and write to another .dat file. So, 
what is your suggestion regarding socket/pipe and python installation on RAM? I 
have no idea with those.

Isn't there a better way to handle such issues?

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] fortran lib which provide python like data type

[Chris Angelico]

On Tue, Feb 3, 2015 at 5:34 AM, Mark Lawrence breamore...@yahoo.co.uk wrote:
 On 02/02/2015 17:25, Chris Angelico wrote:

 On Tue, Feb 3, 2015 at 3:52 AM, Mark Lawrence breamore...@yahoo.co.uk
 wrote:

 I'd like to see anybody define 'a' and 'the' without using 'a' and 'the'.
 Would that be formally rigorous or rigorously formal?


 a: Indefinite article, used to represent individual objects not
 otherwise identifiable.

 Near enough?


 Nope.  'article' begins with 'a' so you can't use it to define itself.

Hrm. This is difficult.

a: Indefinite identifier, used to represent non-specific objects.

Not a perfectly accurate definition now, but hey, I avoided the self-reference!

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] fortran lib which provide python like data type

[beliavsky]

On Friday, January 30, 2015 at 5:51:38 PM UTC-5, Gregory Ewing wrote:
 Michael Torrie wrote:
  On 01/30/2015 10:31 AM, Rustom Mody wrote:
  
 And what about the grey area between lightweight and heavyweight?
  
  That's what the smart pointers are for.
 
 I'd say it's what higher-level languages are for. :-)
 
 I'm completely convinced nowadays that there is
 *no* use case for C++. If you need to program the
 bare metal, use C. For anything more complicated,
 use a language that has proper memory-management
 abstractions built in.

Lots of people are using C++ to build packages for statistical programming 
language R, using the package Rcpp. It has been possible to build such packages 
for R and S using Fortran and C since the beginning, and many have done so, but 
the wide usage of Rcpp suggests that there are advantages to using C++. C++ is 
still the primary language used by financial derivatives quants.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] fortran lib which provide python like data type

[Paul Rudin]

Marko Rauhamaa ma...@pacujo.net writes:

 Chris Angelico ros...@gmail.com:

 On Mon, Feb 2, 2015 at 12:59 PM, Steven D'Aprano
 steve+comp.lang.pyt...@pearwood.info wrote:
 And there are underspecified rules too. What is the plural of octopus? No
 fair looking it up in the dictionary.

 Standard and well-known piece of trivia, and there are several
 options. Octopodes is one of the most rigorously formal, but
 octopuses is perfectly acceptable. Octopi is technically
 incorrect, as the -us ending does not derive from the Latin.

 Your brain's grammar engine will give you the correct answer. It may not
 match your English teacher's answer, but the language we are talking
 about is not standard English but the dialect you have acquired in
 childhood.

Aha - the Humpty Dumpty approach to English usage: When I use a word it
means just what I choose it to mean...

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] fortran lib which provide python like data type

[Marko Rauhamaa]

Paul Rudin paul.nos...@rudin.co.uk:

 Marko Rauhamaa ma...@pacujo.net writes:
 Your brain's grammar engine will give you the correct answer. It may
 not match your English teacher's answer, but the language we are
 talking about is not standard English but the dialect you have
 acquired in childhood.

 Aha - the Humpty Dumpty approach to English usage: When I use a word
 it means just what I choose it to mean...

Yes, and your Humpty Dumpty brain is stringent about the proper usage.
Your brain happens to be highly aligned with those of your childhood
friends. Your communal dialect has thousands of rigorous rules, only you
couldn't make a complete list of them.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] fortran lib which provide python like data type

[Mark Lawrence]

On 02/02/2015 04:47, Chris Angelico wrote:

On Mon, Feb 2, 2015 at 3:14 PM, Roy Smith r...@panix.com wrote:

In article 54ceda0b$0$12977$c3e8da3$54964...@news.astraweb.com,
  Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote:


What is the plural of octopus?


It's a trick question.  Octopus is already plural.  Monopus is singular.


People is already plural, too, but you can talk about all the peoples
of the world. Also, I can use people as the subject and is as the
verb, just to completely destroy any chance of a simple grammar parser
being able to cope with English.

ChrisA



I'm simple and I cope (somehow) with English.

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

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] fortran lib which provide python like data type

[Rustom Mody]

On Monday, February 2, 2015 at 9:40:35 PM UTC+5:30, Mark Lawrence wrote:
 On 02/02/2015 08:52, Marko Rauhamaa wrote:
  Chris Angelico :
 
  On Mon, Feb 2, 2015 at 12:59 PM, Steven D'Aprano wrote:
  And there are underspecified rules too. What is the plural of octopus? No
  fair looking it up in the dictionary.
 
  Standard and well-known piece of trivia, and there are several
  options. Octopodes is one of the most rigorously formal, but
  octopuses is perfectly acceptable. Octopi is technically
  incorrect, as the -us ending does not derive from the Latin.
 
  Your brain's grammar engine will give you the correct answer. It may not
  match your English teacher's answer, but the language we are talking
  about is not standard English but the dialect you have acquired in
  childhood.
 
 
  Marko
 
 
 I'd love to see a formal definition for standard English.
 

I'd also love to see a formal definition of 'formal'
Elsewhere someone (Marko I think) used the term 'rigorous'

Ive heard it said that formal is more rigorous than 'rigorous'.
And of course the other way round as well ;-)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] fortran lib which provide python like data type

[Mark Lawrence]

On 02/02/2015 16:21, Rustom Mody wrote:

On Monday, February 2, 2015 at 9:40:35 PM UTC+5:30, Mark Lawrence wrote:

On 02/02/2015 08:52, Marko Rauhamaa wrote:

Chris Angelico :


On Mon, Feb 2, 2015 at 12:59 PM, Steven D'Aprano wrote:

And there are underspecified rules too. What is the plural of octopus? No
fair looking it up in the dictionary.


Standard and well-known piece of trivia, and there are several
options. Octopodes is one of the most rigorously formal, but
octopuses is perfectly acceptable. Octopi is technically
incorrect, as the -us ending does not derive from the Latin.


Your brain's grammar engine will give you the correct answer. It may not
match your English teacher's answer, but the language we are talking
about is not standard English but the dialect you have acquired in
childhood.


Marko



I'd love to see a formal definition for standard English.



I'd also love to see a formal definition of 'formal'
Elsewhere someone (Marko I think) used the term 'rigorous'

Ive heard it said that formal is more rigorous than 'rigorous'.
And of course the other way round as well ;-)



I'd like to see anybody define 'a' and 'the' without using 'a' and 
'the'.  Would that be formally rigorous or rigorously formal?


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

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] fortran lib which provide python like data type

[Mark Lawrence]

On 02/02/2015 08:52, Marko Rauhamaa wrote:

Chris Angelico ros...@gmail.com:


On Mon, Feb 2, 2015 at 12:59 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:

And there are underspecified rules too. What is the plural of octopus? No
fair looking it up in the dictionary.


Standard and well-known piece of trivia, and there are several
options. Octopodes is one of the most rigorously formal, but
octopuses is perfectly acceptable. Octopi is technically
incorrect, as the -us ending does not derive from the Latin.


Your brain's grammar engine will give you the correct answer. It may not
match your English teacher's answer, but the language we are talking
about is not standard English but the dialect you have acquired in
childhood.


Marko



I'd love to see a formal definition for standard English.

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

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] fortran lib which provide python like data type

[Michael Torrie]

On 02/02/2015 12:39 AM, Marko Rauhamaa wrote:
 Michael Torrie torr...@gmail.com:
 
 http://en.cppreference.com/w/cpp/utility/functional/function

 Thus if we were to shoehorn your example into C++, the result would be
 idiomatically very similar to what you have in your Python code.
 
 I can understand why you wouldn't write out my example in C++:

I wouldn't write it out because it's a contrived example, and why should
I waste my time? You have no intention of being impressed with C++, let
alone simply learn about it.

 
using std::placeholders::_1;
 
std::functionvoid(int) f_add_display2 =
 std::bind( Foo::print_add, foo, _1 );

Looks okay to me.  That's normal C++ that would be clear to any C++
programmer.  And for a statically compiled language, that's incredibly
powerful while providing for a measure of safety.  You may shudder, but
it's a really good statically compiled solution, given the constraints
of C++ and its compiler.

But like I said, idiomatically in C++, this isn't normally what you'd do
anyway.  You'd store a std::ostream object.

 vs
 
f_add_display2 = foo.print_add
 
 The cherry on top: _1! The C++ compiler figures out template types
 heroically but can't wrap its head around the arity of the method.

std::bind is a generic function that works with undecorated function
pointers.  There's no possible way for the compiler to know the arity of
the function without you telling it (how else would you do it? I
honestly want to know.).  That you would find this fact to be
incredulous suggests that you have very little understanding of
compilers in general.  Python being a dynamic, interpreted language can
examine a function at runtime.

Python is a very expressive language compared to C++ that can do things
at runtime that C++ cannot.  It's also an interpreted, dynamically-typed
language, whereas C++ is a statically-typed language that is clearly
faster at many things than Python is.  It's a matter of different tools
for different jobs.  For most of my jobs Python is the right tool.  But
I can see why people would still want to pick a compiled language, and I
can understand why some people still use C++.  It's a very powerful
language.

I'm a little unclear as to why you're even bringing up the comparison
with C++.  What's your point?  To feel superior?


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] fortran lib which provide python like data type

[Michael Torrie]

On 02/02/2015 10:57 AM, Marko Rauhamaa wrote:
 I really don't understand why you are taking all of this so personally.
 We are just discussing different aspects of different programming
 languages.

Fair enough. You raise good points.  I am not taking it personally; your
emails, lacking emotional context, just seemed a bit unnecessarily
argumentative. For example, The cherry on top: _1! The C++ compiler
figures out template types heroically but can't wrap its head around the
arity of the method.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] fortran lib which provide python like data type

[Mark Lawrence]

On 02/02/2015 17:25, Chris Angelico wrote:

On Tue, Feb 3, 2015 at 3:52 AM, Mark Lawrence breamore...@yahoo.co.uk wrote:

I'd like to see anybody define 'a' and 'the' without using 'a' and 'the'.
Would that be formally rigorous or rigorously formal?


a: Indefinite article, used to represent individual objects not
otherwise identifiable.

the: Definite article, used to represent individual objects
identifiable by context.

Near enough?

ChrisA



Nope.  'article' begins with 'a' so you can't use it to define itself.

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

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] fortran lib which provide python like data type

[Marko Rauhamaa]

Michael Torrie torr...@gmail.com:

 Fair enough. You raise good points.  I am not taking it personally; your
 emails, lacking emotional context, just seemed a bit unnecessarily
 argumentative. For example, The cherry on top: _1! The C++ compiler
 figures out template types heroically but can't wrap its head around the
 arity of the method.

I feel programming languages, being inanimate abstractions, can take my
abuse.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] fortran lib which provide python like data type

[Marko Rauhamaa]

Michael Torrie torr...@gmail.com:

 You have no intention of being impressed with C++, let alone simply
 learn about it.

I am fully open to being impressed. I have more than a decade of C++
programming under my belt, although not much for the past few years.

 There's no possible way for the compiler to know the arity of
 the function without you telling it (how else would you do it?

Somehow, C# manages it just fine.

 I honestly want to know.).

See

  URL: https://msdn.microsoft.com/en-us/library/aa288459%28v=vs.71%29.aspx

 That you would find this fact to be incredulous suggests that you have
 very little understanding of compilers in general. Python being a
 dynamic, interpreted language can examine a function at runtime.

C# does it at compile-time. C++ could have and should have introduced
delegates early on. The method pointer syntax was screaming for delegate
semantics. Too bad that didn't occur to Stroustrup until it was too
late.

 I'm a little unclear as to why you're even bringing up the comparison
 with C++. What's your point? To feel superior?

I really don't understand why you are taking all of this so personally.
We are just discussing different aspects of different programming
languages.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] fortran lib which provide python like data type

[Chris Angelico]

On Tue, Feb 3, 2015 at 3:52 AM, Mark Lawrence breamore...@yahoo.co.uk wrote:
 I'd like to see anybody define 'a' and 'the' without using 'a' and 'the'.
 Would that be formally rigorous or rigorously formal?

a: Indefinite article, used to represent individual objects not
otherwise identifiable.

the: Definite article, used to represent individual objects
identifiable by context.

Near enough?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] fortran lib which provide python like data type

[Marko Rauhamaa]

Steven D'Aprano steve+comp.lang.pyt...@pearwood.info:

 Steven D'Aprano wrote:
 Of course people make grammar mistakes that they don't spot.

 Ironically, this is one of them. It should of course be grammatical
 mistakes.

I don't believe you made a mistake according to your brain's grammar
engine.

Parenthetically, I don't believe you made a mistake even according to
your English teacher.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] fortran lib which provide python like data type

[Marko Rauhamaa]

Chris Angelico ros...@gmail.com:

 On Mon, Feb 2, 2015 at 12:59 PM, Steven D'Aprano
 steve+comp.lang.pyt...@pearwood.info wrote:
 And there are underspecified rules too. What is the plural of octopus? No
 fair looking it up in the dictionary.

 Standard and well-known piece of trivia, and there are several
 options. Octopodes is one of the most rigorously formal, but
 octopuses is perfectly acceptable. Octopi is technically
 incorrect, as the -us ending does not derive from the Latin.

Your brain's grammar engine will give you the correct answer. It may not
match your English teacher's answer, but the language we are talking
about is not standard English but the dialect you have acquired in
childhood.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] fortran lib which provide python like data type

[Christian Gollwitzer]

Am 01.02.15 um 08:58 schrieb Marko Rauhamaa:
 Paul Rubin no.email@nospam.invalid:
 
 Marko Rauhamaa ma...@pacujo.net writes:
 Stroustrup apparently has never had to deal with callbacks; his thick
 books never made a mention of them last time I checked.

 C++ has function pointers just like C,
 
 Et tu, Brute!
 
 C's callbacks always use a void pointer for the self reference. In C,
 I can use void pointers and type casts idiomatically. In C++, type casts
 are apostasy.
 
 Qt gave up on C++ when it comes to callbacks (signals) and went for an
 apocryphal metacompiler.

Yes, but only because C++ compilers were not good enough when QT came
out, and later is was too late to change it to a templated system.
Lookup libsigc++ http://libsigc.sourceforge.net/ which does the same
using standard C++ and http://qt-project.org/doc/qt-4.8/templates.html
for a reasoning of QT.

In C++11 (supported by MSVC, g++, clang) there re also lambda expressions

Christian
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] fortran lib which provide python like data type

[Marko Rauhamaa]

Paul Rubin no.email@nospam.invalid:

 Marko Rauhamaa ma...@pacujo.net writes:
 Stroustrup apparently has never had to deal with callbacks; his thick
 books never made a mention of them last time I checked.

 C++ has function pointers just like C,

Et tu, Brute!

C's callbacks always use a void pointer for the self reference. In C,
I can use void pointers and type casts idiomatically. In C++, type casts
are apostasy.

Qt gave up on C++ when it comes to callbacks (signals) and went for an
apocryphal metacompiler.

 but more idiomatically you'd pass a class instance and the library
 would invoke some method on it.

Yes, that's what I ended up doing, defining a class for each callback
type:

   struct ButtonPushListener {
   virtual void buttonPush(int x, int y) = 0;
   };

(Yes, struct and not class! Why?)

Typing all of that in was quite a chore. All because Stroustrup didn't
think of delegates (Delphi, C#, Python). C++'s method pointers are
ridiculous and useless, they should have been defined as delegates.

 There is also Boost::Coroutine which can get rid of the need for
 callbacks in some situations.

Boost is the world's biggest fig leaf.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] fortran lib which provide python like data type

[Steven D'Aprano]

Marko Rauhamaa wrote:

 The natural language has a rigorous grammar plus a lexicon that includes
 a number of idioms. Nobody has so far been able to codify a natural
 language completely because the rigorous grammar consists of maybe
 10,000 rules.

If nobody has codified the rigorous grammar, how do they know it is
rigorous?

Given how natural languages are constantly in flux (in both space and time),
I don't even know how you could define all the rules of a grammar
rigorously. By the time you finished, it would be different.

Of course, some rules are more rigorous than others. No English speaker
would consider a sentence like

Can me cheeseburger has?

as grammatical. But how about:

I can has cheezburger?

If grammar is defined by usage, not formal rule books (which don't exist!),
then surely LOLspeak is grammatical. (It's probably closer to an argot than
a full language, but even so.)




-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] fortran lib which provide python like data type

[Marko Rauhamaa]

Christian Gollwitzer aurio...@gmx.de:

 Am 01.02.15 um 08:58 schrieb Marko Rauhamaa:
 Qt gave up on C++ when it comes to callbacks (signals) and went for
 an apocryphal metacompiler.

 Yes, but only because C++ compilers were not good enough when QT came
 out, and later is was too late to change it to a templated system.
 Lookup libsigc++ http://libsigc.sourceforge.net/ which does the same
 using standard C++ and http://qt-project.org/doc/qt-4.8/templates.html
 for a reasoning of QT.

 In C++11 (supported by MSVC, g++, clang) there re also lambda expressions

So please implement this small piece of Python code in C++ so we can
compare the idioms:

import sys, time

class MyLogger:
def __init__(self, write):
self.write = sys.stderr.write

def register_writer(self, write):
self.write = write

def log(self, text):
self.write({} {}\n.format(time.time(), text))

class MyApp:
def __init__(self, logger):
self.logf = open(thelog.log, a)
logger.register_writer(self.log_write)

def log_write(self, text):
self.logf.write(text)
self.logf.flush()


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] fortran lib which provide python like data type

[Marko Rauhamaa]

Steven D'Aprano steve+comp.lang.pyt...@pearwood.info:

 Marko Rauhamaa wrote:

 The natural language has a rigorous grammar plus a lexicon that includes
 a number of idioms. Nobody has so far been able to codify a natural
 language completely because the rigorous grammar consists of maybe
 10,000 rules.

 If nobody has codified the rigorous grammar, how do they know it is
 rigorous?

Even a five-year-old will immediately spot grammar mistakes (and let you
know about them!).

 Given how natural languages are constantly in flux (in both space and time),
 I don't even know how you could define all the rules of a grammar
 rigorously. By the time you finished, it would be different.

Every brain has a slightly different variant, and that is evolving, too.
However, you can spot a non-native speaker (or a speaker outside your
community) in a fraction of a second after they open their mouth.

 If grammar is defined by usage, not formal rule books (which don't
 exist!), then surely LOLspeak is grammatical. (It's probably closer to
 an argot than a full language, but even so.)

Whatever it is, your brain will recognize its native language. You never
make a grammar mistake that you don't spot yourself right away.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] fortran lib which provide python like data type

[Michael Torrie]

On 02/01/2015 12:12 PM, Marko Rauhamaa wrote:
 Christian Gollwitzer aurio...@gmx.de:
 
 Am 01.02.15 um 08:58 schrieb Marko Rauhamaa:
 Qt gave up on C++ when it comes to callbacks (signals) and went for
 an apocryphal metacompiler.

 Yes, but only because C++ compilers were not good enough when QT came
 out, and later is was too late to change it to a templated system.
 Lookup libsigc++ http://libsigc.sourceforge.net/ which does the same
 using standard C++ and http://qt-project.org/doc/qt-4.8/templates.html
 for a reasoning of QT.

 In C++11 (supported by MSVC, g++, clang) there re also lambda expressions
 
 So please implement this small piece of Python code in C++ so we can
 compare the idioms:

Honestly with the C++ standard library implementing std::function and
std::bind macros, idiomatically it would look very much similar to the
Python code you showed.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] fortran lib which provide python like data type

[Michael Torrie]

On 02/01/2015 12:12 PM, Marko Rauhamaa wrote:
 So please implement this small piece of Python code in C++ so we can
 compare the idioms:

So I though I might just for kicks code up a C++ version.  In doing so,
I realized that idomatically, this particular example would not really
use callbacks in real life, but rather stream objects.  Would look
nearly the same but be more idiomatic C++.

However, C++ function pointers are actually pretty slick in C++11. See
the example near the bottom of the page:

http://en.cppreference.com/w/cpp/utility/functional/function

Thus if we were to shoehorn your example into C++, the result would be
idiomatically very similar to what you have in your Python code.



-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] fortran lib which provide python like data type

[Michael Torrie]

On 02/01/2015 05:50 PM, Michael Torrie wrote:
 Honestly with the C++ standard library implementing std::function and
 std::bind macros, idiomatically it would look very much similar to the
 Python code you showed.

Make that templates, not macros.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] fortran lib which provide python like data type

[Roy Smith]

In article mailman.18388.1422845124.18130.python-l...@python.org,
 Chris Angelico ros...@gmail.com wrote:

 On Mon, Feb 2, 2015 at 1:35 PM, Matthew Barnett
 auxl...@mrabarnett.plus.com wrote:
  And the plural of virus is viruses, not viri (that's the plural of
  vir) or virii (that would be the plural of virius, if it existed).
 
 Yes indeed.Virii and octopi are as wrong as hice for houses
 (paralleling mice).

And, of course, I die, but we dice.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] fortran lib which provide python like data type

[Roy Smith]

In article 54ceda0b$0$12977$c3e8da3$54964...@news.astraweb.com,
 Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote:

 What is the plural of octopus?

It's a trick question.  Octopus is already plural.  Monopus is singular.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] fortran lib which provide python like data type

[Steven D'Aprano]

Marko Rauhamaa wrote:

 Steven D'Aprano steve+comp.lang.pyt...@pearwood.info:
 
 Marko Rauhamaa wrote:

 The natural language has a rigorous grammar plus a lexicon that includes
 a number of idioms. Nobody has so far been able to codify a natural
 language completely because the rigorous grammar consists of maybe
 10,000 rules.

 If nobody has codified the rigorous grammar, how do they know it is
 rigorous?
 
 Even a five-year-old will immediately spot grammar mistakes (and let you
 know about them!).

That doesn't make it rigorous. That just means that there are rules, and
five-years olds know some of the rules. There may be ambiguities in the
rules. There could be sentences where no rule applies, or multiple
contradictory rules.

Children go through a period of language acquisition where they
over-generalise rules, saying things like I eated the biscuit. Amusingly,
there are at least some reports of children getting angry when their
parents copy those over-generalisations, saying words to the effect of No
Daddy, I say eated, you don't! This suggests that they know that the rule
is wrong even when they say it, yet they continue to say it. This in turn
suggests that there are multiple parts of the brain involved in grammar,
and they aren't always in sync.

Adults also commit hyper-correction. Anyone who has said a sentence
like The dog barked at my daughter and I is being ungrammatical. Cross
out the second party, and you are left with: The dog barked at I which is
clearly wrong.

And there are underspecified rules too. What is the plural of octopus? No
fair looking it up in the dictionary.



[...]
 Whatever it is, your brain will recognize its native language. You never
 make a grammar mistake that you don't spot yourself right away.

Of course people make grammar mistakes that they don't spot.

If you're interested in this topic, I can strongly recommend Steven Pinker's
book Words And Rules.


-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] fortran lib which provide python like data type

[Chris Angelico]

On Mon, Feb 2, 2015 at 12:59 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
 And there are underspecified rules too. What is the plural of octopus? No
 fair looking it up in the dictionary.

Standard and well-known piece of trivia, and there are several
options. Octopodes is one of the most rigorously formal, but
octopuses is perfectly acceptable. Octopi is technically
incorrect, as the -us ending does not derive from the Latin.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] fortran lib which provide python like data type

[Matthew Barnett]

On 2015-02-02 02:04, Chris Angelico wrote:

On Mon, Feb 2, 2015 at 12:59 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:

And there are underspecified rules too. What is the plural of
octopus? No fair looking it up in the dictionary.


Standard and well-known piece of trivia, and there are several
options. Octopodes is one of the most rigorously formal, but
octopuses is perfectly acceptable. Octopi is technically
incorrect, as the -us ending does not derive from the Latin.


And the plural of virus is viruses, not viri (that's the plural of
vir) or virii (that would be the plural of virius, if it existed).
--
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] fortran lib which provide python like data type

[Steven D'Aprano]

Steven D'Aprano wrote:

 Of course people make grammar mistakes that they don't spot.


Ironically, this is one of them. It should of course be grammatical
mistakes.

Seriously, I didn't do that on purpose. I only noticed the error on reading
it back after sending.


-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] fortran lib which provide python like data type

[Chris Angelico]

On Mon, Feb 2, 2015 at 1:35 PM, Matthew Barnett
auxl...@mrabarnett.plus.com wrote:
 And the plural of virus is viruses, not viri (that's the plural of
 vir) or virii (that would be the plural of virius, if it existed).

Yes indeed.Virii and octopi are as wrong as hice for houses
(paralleling mice).

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] fortran lib which provide python like data type

[Marko Rauhamaa]

Michael Torrie torr...@gmail.com:

 http://en.cppreference.com/w/cpp/utility/functional/function

 Thus if we were to shoehorn your example into C++, the result would be
 idiomatically very similar to what you have in your Python code.

I can understand why you wouldn't write out my example in C++:

   using std::placeholders::_1;

   std::functionvoid(int) f_add_display2 =
std::bind( Foo::print_add, foo, _1 );

vs

   f_add_display2 = foo.print_add

The cherry on top: _1! The C++ compiler figures out template types
heroically but can't wrap its head around the arity of the method.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] fortran lib which provide python like data type

[Steven D'Aprano]

Chris Angelico wrote:

 On Mon, Feb 2, 2015 at 12:59 PM, Steven D'Aprano
 steve+comp.lang.pyt...@pearwood.info wrote:
 And there are underspecified rules too. What is the plural of octopus? No
 fair looking it up in the dictionary.
 
 Standard and well-known piece of trivia, and there are several
 options. Octopodes is one of the most rigorously formal, but
 octopuses is perfectly acceptable. Octopi is technically
 incorrect, as the -us ending does not derive from the Latin.

And that would be relevant if we were speaking Latin, but we aren't :-P

-- 
Steve

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] fortran lib which provide python like data type

[Chris Angelico]

On Mon, Feb 2, 2015 at 3:14 PM, Roy Smith r...@panix.com wrote:
 In article 54ceda0b$0$12977$c3e8da3$54964...@news.astraweb.com,
  Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote:

 What is the plural of octopus?

 It's a trick question.  Octopus is already plural.  Monopus is singular.

People is already plural, too, but you can talk about all the peoples
of the world. Also, I can use people as the subject and is as the
verb, just to completely destroy any chance of a simple grammar parser
being able to cope with English.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] fortran lib which provide python like data type

[Rustom Mody]

On Saturday, January 31, 2015 at 5:52:58 PM UTC+5:30, Marko Rauhamaa wrote:
 Esthetically, I'm most impressed with Scheme. One day it might give
 Python a run for its money.
 
 
 Marko

Aren't you getting this backwards?

http://www.wisdomandwonder.com/link/2110/why-mit-switched-from-scheme-to-python

Dont get me wrong: Ive had more fun with scheme than any other language.
[And APL for very different reasons]
Its just that its 2015 now not 1985...
People did not 'settle' the question: How many angels can dance on the head 
of a pin. It just stopped being relevant.

Likewise, which is the 'best' programming language is a question without the 
edge it had when I was a student
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] fortran lib which provide python like data type

[Rustom Mody]

On Saturday, January 31, 2015 at 4:34:14 PM UTC+5:30, Steven D'Aprano wrote:
 
 Yesterday, as I wrote that message, my web browser crashed *eight times* in
 a matter of half an hour. There are thousands of serious security
 vulnerabilities due to mishandled pointers. Anyone who thinks that Linux
 is secure is deluding themselves. It's only secure in comparison to
 nightmares like Windows. The fact is, the security of computer systems is
 best described as with care and attention to detail, we can make it merely
 awful.

Beware that may be closer to ghost than you may think
http://blog.trendmicro.com/trendlabs-security-intelligence/analyzing-cve-2015-0311-flash-zero-day-vulnerability/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] fortran lib which provide python like data type

[Christian Gollwitzer]

Am 30.01.15 um 19:23 schrieb Paul Rubin:
 Michael Torrie torr...@gmail.com writes:
 Follow basic [C++] rules and 99% of segfaults will never happen and
 the majority of leaks will not happen either.
 
 That is a safe and simple approach, but it works by copying data all
 over the place instead of passing pointers, resulting in performance
 loss.  

This performance loss is partly a myth. Consider the following code,
assuming it is compiled using a recent (C++11) compiler


#include vector

std::vectordouble compute() {
const size_t N=10;
std::vectordouble result(N);
for (size_t i=0; iN; i++) {
result[i]=2*i;
}
return result;
}

int main() {
auto s = compute();
// print it or whatever
return 0;
}

=


At first, it may seem that this code copies the big vector twice: Once
into a temporary return value, once into the automatic variable s. This
is not the case, once for the move constructors in C++11 and second for
return value optimization, some years already in the compilers. Instead,
the vector is constructed directly into the place where the main
functinos expects it to be.

Christian

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] fortran lib which provide python like data type

[Mark Lawrence]

On 31/01/2015 15:50, Rustom Mody wrote:

On Saturday, January 31, 2015 at 5:52:58 PM UTC+5:30, Marko Rauhamaa wrote:

Esthetically, I'm most impressed with Scheme. One day it might give
Python a run for its money.


Marko


Aren't you getting this backwards?

http://www.wisdomandwonder.com/link/2110/why-mit-switched-from-scheme-to-python

Dont get me wrong: Ive had more fun with scheme than any other language.
[And APL for very different reasons]
Its just that its 2015 now not 1985...
People did not 'settle' the question: How many angels can dance on the head
of a pin. It just stopped being relevant.

Likewise, which is the 'best' programming language is a question without the
edge it had when I was a student



The answer is beautifully put here 
https://mail.python.org/pipermail/python-list/2002-November/154258.html 
so I have no hesitation in reposting for the umpteenth time.


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

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] fortran lib which provide python like data type

[Marko Rauhamaa]

Rustom Mody rustompm...@gmail.com:

 On Saturday, January 31, 2015 at 5:52:58 PM UTC+5:30, Marko Rauhamaa wrote:
 Esthetically, I'm most impressed with Scheme. One day it might give
 Python a run for its money.

 Aren't you getting this backwards?

Deep down I'm a minimalist romantic.

 Its just that its 2015 now not 1985...

Python was conceived in the late 1980s [Python, Wikipedia]
Scheme was conceived in the 1920s.   [Combinatory Logic, Wikipedia]

 People did not 'settle' the question: How many angels can dance on
 the head of a pin. It just stopped being relevant.

Speak for yourself. It's just that the answer was found:

ι = λf.((fS)K)   [Iota and Jot, Wikipedia]

Donc Dieu existe, répondez!


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: RAII vs gc (was fortran lib which provide python like data type)

[Steven D'Aprano]

Sturla Molden wrote:

 Rustom Mody rustompm...@gmail.com wrote:
 
 The case of RAII vs gc is hardly conclusive:
 
 http://stackoverflow.com/questions/228620/garbage-collection-in-c-why
 
 The purpose of RAII is not to be an alternative to garbage collection
 (which the those answers imply), but to ensure  deterministc execution of
 setup and tear-down code. The Python equivalent of RAII is not garbage
 collection but context managers.
 
 Those answers is a testimony to how little the majority of C++ users
 actually understand about the language.
 
 
 
 A C++ statement with RAII like
 
 {
Foo bar();
// suite
 }
 
 is not equivalent to
 
 bar = Foo()
 
 in Python. It actually corresponds to
 
 with Foo() as bar:
 suite


Nice answer! I'm not qualified to tell whether you are right or not, but
what you say has the ring of truth about it.



-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] fortran lib which provide python like data type

[Steven D'Aprano]

Marko Rauhamaa wrote:

 I'm most impressed with Scheme. One day it might give
 Python a run for its money.

Scheme is forty years old, having come out in 1975. Python is 24 years old,
having come out in 1991. If Scheme hasn't caught up with Python by now, it
never will.



-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: RAII vs gc (was fortran lib which provide python like data type)

[Devin Jeanpierre]

On Fri, Jan 30, 2015 at 1:28 PM, Sturla Molden sturla.mol...@gmail.com wrote:
 in Python. It actually corresponds to

 with Foo() as bar:
 suite

The problem with with statements is that they only handle the case of
RAII with stack allocated variables, and can't handle transfer of
ownership cleanly.

Consider the case of a function that opens a file and returns it:

def myfunction(name, stuff):
f = open(name)
f.seek(stuff) # or whatever
return f

def blahblah():
with myfunction('hello', 12) as f:
 

This code is wrong, because if an error occurs during seek in
myfunction, the file is leaked.

The correct myfunction is as follows:

def myfunction(name, stuff)
f = open(name)
try:
f.seek(stuff)
except:
f.close()
raise

Or whatever. (I would love a close_on_error context manager, BTW.)

With RAII, the equivalent C++ looks nearly exactly like the original
(bad) Python approach, except it uses unique_ptr to store the file,
and isn't broken. (Modern) C++ makes this easy to get right. But
then, this isn't the common case.

-- Devin
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] fortran lib which provide python like data type

[Marko Rauhamaa]

Rustom Mody rustompm...@gmail.com:

 There is a real conflict between the logician's goal and the
 educator's. The logician wants to minimize the variety of ideas,
 and doesn't mind a long, thin path. The educator (rightly) wants
 to make the paths short and doesn't mind–in fact,
 prefers–connections to many other ideas. And he cares almost not
 at all about the directions of the links.

The natural language has a rigorous grammar plus a lexicon that includes
a number of idioms. Nobody has so far been able to codify a natural
language completely because the rigorous grammar consists of maybe
10,000 rules.

Perl came out of the needs of natural language translation. Perl's novel
idea was to make a programming language like a natural language (yes,
there had been Cobol). So Perl's language description evades a complete,
rigorous description, but it has numerous handy idioms for many common
situations.

Python showed that while interesting and amusing, Perl's way leads to
unnecessary clutter. Why make things complicated when simple will serve
everybody's needs best.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: RAII vs gc (was fortran lib which provide python like data type)

[Chris Angelico]

On Sun, Feb 1, 2015 at 2:00 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
 A C++ statement with RAII like

 {
Foo bar();
// suite
 }

 is not equivalent to

 bar = Foo()

 in Python. It actually corresponds to

 with Foo() as bar:
 suite


 Nice answer! I'm not qualified to tell whether you are right or not, but
 what you say has the ring of truth about it.

I would say that this is indeed correct, with the caveat that RAII is
most often used for memory allocation, in which case the correct
transformation into Python _would_ be a constructor call. But when you
use this kind of thing to set up state and clean up afterwards, then
yes, Python's equivalent would be a context manager.

So a C++ way to release and reacquire the GIL might look like this
(borrowing from https://docs.python.org/3.5/c-api/init.html):

class ReleaseGIL
{
//Internal state
PyThreadState *_save;
public:
//Constructor
ReleaseGIL() {_save = PyEval_SaveThread();}
//Destructor
~ReleaseGIL() {PyEval_RestoreThread(_save);}
};

//Usage example:
int do_work()
{
while (1)
{
//use the Python C API to figure out what we need to do
ReleaseGIL heavy_processing_coming;
//do the heavy computational work
} //GIL is reacquired here
}


The Python equivalent would be something like:

@contextlib.contextmanager
def release_gil():
Why the bleep are we manipulating the
GIL from Python code anyway???
_save = PyEval_SaveThread()
yield
PyEval_RestoreThread(_save)

def do_work()
while True:
# get some work
with release_gil() as heavy_processing_coming:
# do the heavy computational work
# GIL is reacquired here

In each case, you have a guarantee that code following the suite will
not be executed without first performing the appropriate cleanup.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] fortran lib which provide python like data type

[Rustom Mody]

On Saturday, January 31, 2015 at 11:13:29 PM UTC+5:30, Marko Rauhamaa wrote:
 Rustom Mody:
 
  On Saturday, January 31, 2015 at 5:52:58 PM UTC+5:30, Marko Rauhamaa wrote:
  Esthetically, I'm most impressed with Scheme. One day it might give
  Python a run for its money.
 
  Aren't you getting this backwards?
 
 Deep down I'm a minimalist romantic.
 
  Its just that its 2015 now not 1985...
 
 Python was conceived in the late 1980s [Python, Wikipedia]
 Scheme was conceived in the 1920s.   [Combinatory Logic, Wikipedia]
 
  People did not 'settle' the question: How many angels can dance on
  the head of a pin. It just stopped being relevant.
 
 Speak for yourself. It's just that the answer was found:
 
 ι = λf.((fS)K)   [Iota and Jot, Wikipedia]
 
 Donc Dieu existe, répondez!



My répondez:

Marvin Minsky's Turing award lecture
http://web.media.mit.edu/~minsky/papers/TuringLecture/TuringLecture.html

There is a real conflict between the logician's goal and the
educator's. The logician wants to minimize the variety of ideas,
and doesn't mind a long, thin path. The educator (rightly) wants
to make the paths short and doesn't mind–in fact,
prefers–connections to many other ideas. And he cares almost not
at all about the directions of the links.

Anyway…  Thanks for those links or rather the pointer to
http://en.wikipedia.org/wiki/Iota_and_Jot
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] fortran lib which provide python like data type

[Paul Rubin]

Marko Rauhamaa ma...@pacujo.net writes:

 The guiding principle in C++ language development is to take static
 type safety to the extreme. 

Heh, try Ada.

 Stroustrup apparently has never had to deal with callbacks; his thick
 books never made a mention of them last time I checked.

C++ has function pointers just like C, but more idiomatically you'd pass
a class instance and the library would invoke some method on it.  There
is also Boost::Coroutine which can get rid of the need for callbacks in
some situations.

 Esthetically, I'm most impressed with Scheme. One day it might give
 Python a run for its money.

It's in a small and shrinking niche, unfortunately.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] fortran lib which provide python like data type

[Steven D'Aprano]

Michael Torrie wrote:

 On 01/30/2015 04:50 PM, Steven D'Aprano wrote:
 Oh great. So if the average application creates a hundred thousand
 pointers of the course of a session, you'll only have a thousand or so
 seg faults and leaks.
 
 Well, that certainly explains this:
 
 https://access.redhat.com/articles/1332213
 
 I fail to see the connection. 

The connection is that you made a comment about eliminating 99% of
segfaults, as if that was something to be proud of. It's not. Like 99%
uptime (which means you are down for over three and a half days per year),
it's not very impressive. All it takes is *one* mishandled pointer, and you
can have a seg fault, leak, buffer overflow, security exploit, or other
serious bug. Which leads to vulnerabilities like Ghost.

Yesterday, as I wrote that message, my web browser crashed *eight times* in
a matter of half an hour. There are thousands of serious security
vulnerabilities due to mishandled pointers. Anyone who thinks that Linux
is secure is deluding themselves. It's only secure in comparison to
nightmares like Windows. The fact is, the security of computer systems is
best described as with care and attention to detail, we can make it merely
awful.

And the manual use of pointers in low-level languages like C is a huge
factor in that.


 GLibc is a low-level library written in C, 
 not C++.  By its nature requires a lot of pointer use, and is prone to
 having errors.  But not that many, seeing as *all* Linux software 
 depends on it and uses at least part of it *all* the time.  Pretty
 remarkable if you ask me.  Wonder how they do it.  Perhaps they try to
 follow basic rules.

Exactly. And as Ghost demonstrates, that is *not good enough*.


 Manual low-level pointer manipulation is an anti-pattern. What you glibly
 describe as programmers following basic rules has proven to be beyond
 the ability of the programming community as a whole.
 
 I don't see how you would write system code without this anti-pattern
 as you describe.  Python is a great language for everything else, but I
 certainly wouldn't call it a system language.

I didn't actually mention Python.

 Couldn't write a kernel 
 in it without providing it with some sort of unsafe memory access
 (pointers!).  Or even write a Python interpreter (Yes there's PyPy, but
 with a jit it's still working with pointers).

Systems languages now are, in a sense, in the same position that programming
was back in the days before the invention of Fortran. The programmer,
writing in a low-level assembly, was responsible for pushing items onto the
stack, jumping to a sub-routine, popping the arguments off, then jumping
back to the return address. Before Fortran, there were a number of
proto-languages that aimed to make that safer, but Fortran was the first
language where the compiler itself could completely handle all the
book-keeping needed to use functions easily and safely.

The problem is not *pointers*, but manual low-level pointer manipulation,
as I said. We programmers are expected to work out how much memory we need
before allocating a pointer, remember to check whether it is nil or not
before dereferencing it, don't forget to release the memory when you're
done, oh you just wrote past the end of the buffer and now the Russian mob
owns your computer... 

Where are the systems languages that will do to pointer access what Fortran
did to the stack?

They do exist: Rust claims to be a blazing fast systems language that is
memory-safe and eliminates dangling pointers and buffer overflows at
compile time. Assuming this is true, that means that the Rust compiler
could generate code that is just as fast and efficient as C but without all
the unsafe memory accesses of C.

http://doc.rust-lang.org/nightly/intro.html#ownership

I've never used Rust. I don't know whether it is ready for kernel
development, or whether it lives up to its claims. Rust itself is not the
point: there are other approaches to memory-safety, some of them are
suitable for application development and some are suitable for systems
languages.

C is now four decades old. It took a single decade to go from hand-writing
machine code in binary to Fortran, and here we are sixty years later still
having buffer overflows. The fact that C is still one of the top three
*application development languages* is a shameful indictment on the
conservatism, resistance to change, intellectual laziness and hubris of the
programming community as a whole.

I won't go so far as to say that C must die. But it must become a niche
language, used for the tiny (and growing ever more tiny as time goes on)
segment of code that modern, memory-safe languages *provably* cannot
handle.


 What I call glibly basic rules are in fact shown to more or less work
 out, as Glibc proves.  Pointer use does lead to potential
 vulnerabilities.  And they must be corrected as they are found.  Still
 not sure what your point is.

No. They must be prevented from existing in the first place.

We

Re: [OT] fortran lib which provide python like data type

[Marko Rauhamaa]

Gregory Ewing greg.ew...@canterbury.ac.nz:

 I'm completely convinced nowadays that there is *no* use case for C++.

While I wouldn't go quite that far (my most recent creation was written
in C++; why? because the legacy support libraries were written in C++).

However, C++ is like putting lipstick on a pig. In fact, C++ has so much
makeup on you wouldn't even no there's a pig underneath it. The guiding
principle in C++ language development is to take static type safety to
the extreme. That overriding principle has sacrificed other objectives
and made working with the language painful. And despite all that
machinery, C++ omitted the simplest of things that Delphi/C# got right:
delegates. Stroustrup apparently has never had to deal with callbacks;
his thick books never made a mention of them last time I checked.

Java was a masterful simplification of C++ although it, too, has taken
on unnecessary weight in the form of annotations, generics and closures.
I was exposed to Java very late in the game and was very positively
impressed by the programming model. Too bad Java's ecosystem and
stringent portability requirements make it difficult to integrate Java
with other software. At any rate, Java makes for a great production
server backend language with its high-level programming features coupled
with great performance.

Currently, my main programming languages are bash, Python and C. They
work beautifully together and cover the whole gamut of programming needs
from interrupt routines all the way to test automation. Over time, I've
shifted more and more weight from bash to Python because Python's
predictable, flexible semantics has turned out to be worth its clunky
multiprocessing facilities. Python exposes the OS facilities so doing
the right thing in the linux ecosystem is very possible (unlike in
Java). Python, too, is fast picking up Stroustrup-esque features so I'm
a bit concerned for losing Python as the no-nonsense swiss-army knife.

Esthetically, I'm most impressed with Scheme. One day it might give
Python a run for its money.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] fortran lib which provide python like data type

[Rustom Mody]

On Friday, January 30, 2015 at 1:03:03 PM UTC+5:30, Christian Gollwitzer wrote:
 Am 30.01.15 um 02:40 schrieb Rustom Mody:
  FORTRAN
  
   use dictionary
   type(dictionary), pointer :: d
   d=dict_new()
   call set(d//'toto',1)
   v = d//'toto'
   call dict_free(d)
  
  The corresponding python
  
   d = dict()
   d['toto'] = 1
   v = d['toto']
   del(d)
  
  In particular note the del in the python.
  
  Should highlight the point that languages with gc, support data structures
  in a way that gc-less languages - Fortran, C, C++ - do not and cannot.
 
 For C++ this is not correct. Ususally a garbage collector is not used -
 though possible - but the constructor/destructor/assignment op in C++
 (usually called RAII) provide semantics very similar to the CPython
 refcounting behaviour.

You may be right... Dont claim to be able to wrap my head round C++
However...

 
 For example, I made a set of C++ interface methods to return nested
 dicts/list to Python, which is far from complete, but allows to write
 something like this:
 
 SWList do_something(SWDict attrs) {
   SWList result;
   for (int i=0; i5; i++) {
 SWDict entry; 
 entry.insert(count, i);
 entry.insert(name, something);
 result.push_back(entry);
   }
   return result;
 }
 
 
 There is also Boost::Python which does the same, I think, and much more,
 but only supports Python, whereas I use SWIG to interface these
 dicts/lists to both CPython and Tcl.
 
 You cannot, however, resolve certain cyclic dependencies with pure
 reference counting.

... if I restate that in other words it says that sufficiently
complex data structures will be beyond the reach of the standard
RAII infrastructure.

Of course this only brings up one side of memory-mgmt problems
viz. unreclaimable memory.

What about dangling pointers?
C++ apps are prone to segfault. Seems to suggest
(to me at least) that the memory-management infrastructure
is not right.

Stroustrup talks of the fact that C++ is suitable for lightweight
abstractions. In view of the segfault-proneness I'd say they 
are rather leaky abstractions.

But as I said at the outset I dont understand C++
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] fortran lib which provide python like data type

[Michael Torrie]

On 01/30/2015 09:27 AM, Rustom Mody wrote:
 ... if I restate that in other words it says that sufficiently
 complex data structures will be beyond the reach of the standard
 RAII infrastructure.
 
 Of course this only brings up one side of memory-mgmt problems
 viz. unreclaimable memory.
 
 What about dangling pointers?
 C++ apps are prone to segfault. Seems to suggest
 (to me at least) that the memory-management infrastructure
 is not right.
 
 Stroustrup talks of the fact that C++ is suitable for lightweight
 abstractions. In view of the segfault-proneness I'd say they 
 are rather leaky abstractions.
 
 But as I said at the outset I dont understand C++

Yes I can tell you haven't used C++.  Compared to C, I've always found
memory management in C++ to be quite a lot easier. The main reason is
that C++ guarantees objects will be destroyed when going out of scope.
So when designing a class, you put any allocation routines in the
constructor, and put deallocation routines in the destructor.  And it
just works.  This is something I miss in other languages, even Python.

And for many things, though it's not quite as efficient, when dealing
with objects you can forgo pointers altogether and just use copy
constructors, instead of the

blah *a = new blah_with_label(hello) //allocate on heap
//forget to delete a and it leaks the heap *and* anything
//that class blah allocated on construction.

just simply declare objects directly and use them:

blah a(hello) //assuming there's a constructor that takes a string
//deletes everything when it goes out of scope

So for the lightweight abstractions Stroustrup talks about, this works
very well. And you'll rarely have a memory leak (only in the class
itself) and no dangling pointers.

For other things, though, you have to dynamically create objects.  But
the C++ reference-counting smart pointers offer much of the same
destruction semantics as using static objects.  It's really a slick
system.  Almost makes memory management a non-issue.  Circular
references will still leak (just like they do on Python).  But it
certainly makes life a lot more pleasant than in C from a memory
management perspective.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: RAII vs gc (was fortran lib which provide python like data type)

[Sturla Molden]

Rustom Mody rustompm...@gmail.com wrote:

 The case of RAII vs gc is hardly conclusive:
 
 http://stackoverflow.com/questions/228620/garbage-collection-in-c-why

The purpose of RAII is not to be an alternative to garbage collection
(which the those answers imply), but to ensure  deterministc execution of
setup and tear-down code. The Python equivalent of RAII is not garbage
collection but context managers.

Those answers is a testimony to how little the majority of C++ users
actually understand about the language.



A C++ statement with RAII like

{
   Foo bar(); 
   // suite
}

is not equivalent to

bar = Foo()

in Python. It actually corresponds to

with Foo() as bar:
suite



Sturla

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] fortran lib which provide python like data type

[Sturla Molden]

Michael Torrie torr...@gmail.com wrote:
 
 Yes I can tell you haven't used C++.  Compared to C, I've always found
 memory management in C++ to be quite a lot easier. The main reason is
 that C++ guarantees objects will be destroyed when going out of scope.
 So when designing a class, you put any allocation routines in the
 constructor, and put deallocation routines in the destructor.  And it
 just works.  This is something I miss in other languages, even Python.

Python has context managers for that.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] fortran lib which provide python like data type

[Gregory Ewing]

Michael Torrie wrote:

On 01/30/2015 10:31 AM, Rustom Mody wrote:


And what about the grey area between lightweight and heavyweight?


That's what the smart pointers are for.


I'd say it's what higher-level languages are for. :-)

I'm completely convinced nowadays that there is
*no* use case for C++. If you need to program the
bare metal, use C. For anything more complicated,
use a language that has proper memory-management
abstractions built in.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] fortran lib which provide python like data type

[Rustom Mody]

On Friday, January 30, 2015 at 10:39:12 PM UTC+5:30, Michael Torrie wrote:
 On 01/30/2015 09:27 AM, Rustom Mody wrote:
  ... if I restate that in other words it says that sufficiently
  complex data structures will be beyond the reach of the standard
  RAII infrastructure.
  
  Of course this only brings up one side of memory-mgmt problems
  viz. unreclaimable memory.
  
  What about dangling pointers?
  C++ apps are prone to segfault. Seems to suggest
  (to me at least) that the memory-management infrastructure
  is not right.
  
  Stroustrup talks of the fact that C++ is suitable for lightweight
  abstractions. In view of the segfault-proneness I'd say they 
  are rather leaky abstractions.
  
  But as I said at the outset I dont understand C++
 
 Yes I can tell you haven't used C++.  Compared to C, I've always found
 memory management in C++ to be quite a lot easier. The main reason is
 that C++ guarantees objects will be destroyed when going out of scope.

I hear you and I trust you as a gentleman but I dont trust C++ :-)

The only time in some near 15 years of python use that
I got it to segfault was when Ranting Rick gave some wx code to try
[at that time he was in rant-against-tk mode]
Sure enough it was related to the fact that wx is written in C++
and some expectations were not being followed.

 So when designing a class, you put any allocation routines in the
 constructor, and put deallocation routines in the destructor.  And it
 just works.  This is something I miss in other languages, even Python.
 
 And for many things, though it's not quite as efficient, when dealing
 with objects you can forgo pointers altogether and just use copy
 constructors, instead of the
 
 blah *a = new blah_with_label(hello) //allocate on heap
 //forget to delete a and it leaks the heap *and* anything
 //that class blah allocated on construction.
 
 just simply declare objects directly and use them:
 
 blah a(hello) //assuming there's a constructor that takes a string
 //deletes everything when it goes out of scope
 
 So for the lightweight abstractions Stroustrup talks about, this works
 very well. And you'll rarely have a memory leak (only in the class
 itself) and no dangling pointers.

And what about the grey area between lightweight and heavyweight?

You say just use copy constructors and no pointers.
Can you (ie C++) guarantee that no pointer is ever copied out of 
scope of these copy-constructed objects?

 
 For other things, though, you have to dynamically create objects.  But
 the C++ reference-counting smart pointers offer much of the same
 destruction semantics as using static objects.  It's really a slick
 system.  Almost makes memory management a non-issue.  Circular
 references will still leak (just like they do on Python).  But it
 certainly makes life a lot more pleasant than in C from a memory
 management perspective.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] fortran lib which provide python like data type

[Michael Torrie]

On 01/30/2015 10:31 AM, Rustom Mody wrote:
 And what about the grey area between lightweight and heavyweight?

That's what the smart pointers are for.

 You say just use copy constructors and no pointers.
 Can you (ie C++) guarantee that no pointer is ever copied out of 
 scope of these copy-constructed objects?

If that happened, then it's because you the programmer wanted it to
happen.  It's not just going to happen all by itself.  Yes anytime
pointers are allowed, things are potentially unsafe in the hands of a
programmer.  I'm just saying it's not nearly so bad as you make it out
to be.  Follow basic rules and 99% of segfaults will never happen and
the majority of leaks will not happen either.

Python can still leak badly if a programmer causes it to.  As for
segfaulting, no your python code should not itself segfault.  C++ code
certainly could.  Exposing pointers to the programmer can be very
powerful (and necessary... cannot write a bare-metal OS in common
Python) but the programmer can screw it up too on occasion.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] fortran lib which provide python like data type

[Paul Rubin]

Michael Torrie torr...@gmail.com writes:
 Follow basic [C++] rules and 99% of segfaults will never happen and
 the majority of leaks will not happen either.

That is a safe and simple approach, but it works by copying data all
over the place instead of passing pointers, resulting in performance
loss.  Alex Martelli used to post a good riff here about how the main
reason to use C++ in the first place was for when you needed to
explicitly control resources for performance.  So the data copying
style seems to somewhat miss the point.

Smart pointers have similar issues to Python's reference-counted
allocation, e.g. cache and thread unfriendliness, and no compaction
mechanism AFAIK.  Plus I always found them scary in terms of subtle bug
potential due to abstraction leaks.  But I haven't used them so far.
-- 
https://mail.python.org/mailman/listinfo/python-list

RAII vs gc (was fortran lib which provide python like data type)

[Rustom Mody]

On Friday, January 30, 2015 at 11:01:50 PM UTC+5:30, Rustom Mody wrote:
 On Friday, January 30, 2015 at 10:39:12 PM UTC+5:30, Michael Torrie wrote:
  On 01/30/2015 09:27 AM, Rustom Mody wrote:
   ... if I restate that in other words it says that sufficiently
   complex data structures will be beyond the reach of the standard
   RAII infrastructure.
   
   Of course this only brings up one side of memory-mgmt problems
   viz. unreclaimable memory.
   
   What about dangling pointers?
   C++ apps are prone to segfault. Seems to suggest
   (to me at least) that the memory-management infrastructure
   is not right.
   
   Stroustrup talks of the fact that C++ is suitable for lightweight
   abstractions. In view of the segfault-proneness I'd say they 
   are rather leaky abstractions.
   
   But as I said at the outset I dont understand C++
  
  Yes I can tell you haven't used C++.  Compared to C, I've always found
  memory management in C++ to be quite a lot easier. The main reason is
  that C++ guarantees objects will be destroyed when going out of scope.
 
 I hear you and I trust you as a gentleman but I dont trust C++ :-)
 
 The only time in some near 15 years of python use that
 I got it to segfault was when Ranting Rick gave some wx code to try
 [at that time he was in rant-against-tk mode]
 Sure enough it was related to the fact that wx is written in C++
 and some expectations were not being followed.
 
  So when designing a class, you put any allocation routines in the
  constructor, and put deallocation routines in the destructor.  And it
  just works.  This is something I miss in other languages, even Python.
  
  And for many things, though it's not quite as efficient, when dealing
  with objects you can forgo pointers altogether and just use copy
  constructors, instead of the
  
  blah *a = new blah_with_label(hello) //allocate on heap
  //forget to delete a and it leaks the heap *and* anything
  //that class blah allocated on construction.
  
  just simply declare objects directly and use them:
  
  blah a(hello) //assuming there's a constructor that takes a string
  //deletes everything when it goes out of scope
  
  So for the lightweight abstractions Stroustrup talks about, this works
  very well. And you'll rarely have a memory leak (only in the class
  itself) and no dangling pointers.
 
 And what about the grey area between lightweight and heavyweight?
 
 You say just use copy constructors and no pointers.
 Can you (ie C++) guarantee that no pointer is ever copied out of 
 scope of these copy-constructed objects?
 
  
  For other things, though, you have to dynamically create objects.  But
  the C++ reference-counting smart pointers offer much of the same
  destruction semantics as using static objects.  It's really a slick
  system.  Almost makes memory management a non-issue.  Circular
  references will still leak (just like they do on Python).  But it
  certainly makes life a lot more pleasant than in C from a memory
  management perspective.

The case of RAII vs gc is hardly conclusive:

http://stackoverflow.com/questions/228620/garbage-collection-in-c-why
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] fortran lib which provide python like data type

[Steven D'Aprano]

Michael Torrie wrote:

 If that happened, then it's because you the programmer wanted it to
 happen.  It's not just going to happen all by itself.  Yes anytime
 pointers are allowed, things are potentially unsafe in the hands of a
 programmer.  I'm just saying it's not nearly so bad as you make it out
 to be.  Follow basic rules and 99% of segfaults will never happen and
 the majority of leaks will not happen either.


Oh great. So if the average application creates a hundred thousand pointers
of the course of a session, you'll only have a thousand or so seg faults
and leaks.

Well, that certainly explains this:

https://access.redhat.com/articles/1332213

Manual low-level pointer manipulation is an anti-pattern. What you glibly
describe as programmers following basic rules has proven to be beyond the
ability of the programming community as a whole.



-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] fortran lib which provide python like data type

[Steven D'Aprano]

Gregory Ewing wrote:

 I'm completely convinced nowadays that there is
 no use case for C++.


I can think of one use-case for C++.

You walk up to somebody in the street, say I wrote my own C++ parser!, and
while they are gibbering and shaking in shock, you rifle through their
pockets and steal any valuables you find.



-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] fortran lib which provide python like data type

[Michael Torrie]

On 01/30/2015 04:50 PM, Steven D'Aprano wrote:
 Oh great. So if the average application creates a hundred thousand pointers
 of the course of a session, you'll only have a thousand or so seg faults
 and leaks.
 
 Well, that certainly explains this:
 
 https://access.redhat.com/articles/1332213

I fail to see the connection. GLibc is a low-level library written in C,
not C++.  By its nature requires a lot of pointer use, and is prone to
having errors.  But not that many, seeing as *all* Linux software
depends on it and uses at least part of it *all* the time.  Pretty
remarkable if you ask me.  Wonder how they do it.  Perhaps they try to
follow basic rules.

 Manual low-level pointer manipulation is an anti-pattern. What you glibly
 describe as programmers following basic rules has proven to be beyond the
 ability of the programming community as a whole.

I don't see how you would write system code without this anti-pattern
as you describe.  Python is a great language for everything else, but I
certainly wouldn't call it a system language.  Couldn't write a kernel
in it without providing it with some sort of unsafe memory access
(pointers!).  Or even write a Python interpreter (Yes there's PyPy, but
with a jit it's still working with pointers).

What I call glibly basic rules are in fact shown to more or less work
out, as Glibc proves.  Pointer use does lead to potential
vulnerabilities.  And they must be corrected as they are found.  Still
not sure what your point is.

Is there a reason to use C or C++ for many of us?  Nope.  I'm not
arguing that we should find them of use.  It's easy for us to sit on
Python and look with contempt at C or C++, but they really do have their
place (C more than C++ IMO).  This is so far off the original topic that
it probably is construed that I am arguing for C++ vs Python or
something.  But I am not.  I'm quite content with Python.  There are a
host of languages I find interesting including D, Google Go, Vala,
FreeBASIC, Mozilla Rust, etc.  But Python fits my needs so well, I can't
be bothered to invest much time in these other languages.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] fortran lib which provide python like data type

[Michael Torrie]

On 01/30/2015 04:12 PM, Sturla Molden wrote:
 Michael Torrie torr...@gmail.com wrote:
  
 Yes I can tell you haven't used C++.  Compared to C, I've always found
 memory management in C++ to be quite a lot easier. The main reason is
 that C++ guarantees objects will be destroyed when going out of scope.
 So when designing a class, you put any allocation routines in the
 constructor, and put deallocation routines in the destructor.  And it
 just works.  This is something I miss in other languages, even Python.
 
 Python has context managers for that.

Right I had forgotten about that.  That's a good solution for dynamic,
GC languages.

-- 
https://mail.python.org/mailman/listinfo/python-list

[OT] fortran lib which provide python like data type

[1989lzhh]

Hi,
I am not sure here is the right place to ask this question, but I want to give 
it a shot:)
are there fortran libs providing python like data type, such as set, dict, list?
Thanks,
Yours liuzhenhai
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] fortran lib which provide python like data type

[beliavsky]

On Thursday, January 29, 2015 at 10:01:00 AM UTC-5, Liu Zhenhai wrote:
 Hi,
 I am not sure here is the right place to ask this question, but I want to 
 give it a shot:)
 are there fortran libs providing python like data type, such as set, dict, 
 list?
 Thanks,
 Yours liuzhenhai

The Fortran library http://bigdft.org/Wiki/index.php?title=Fortran_library 
appears to have some of what you want. I have not tried the code.

The flib library provides an object called dictionary which is -- strictly 
speaking -- more than just a dictionary. It is polymorphic and can be a list or 
a dictionary, as in the python language. The other difference is that it keeps 
the order of the elements, which is very useful if we want to dump its contents 
to the yaml output. It represents indeed a tree of data, and for these reasons 
it will most likely change name into f_tree in a future release of the module.

These dictionaries are also used in the other parts of the flib library and are 
thus essential for its proper use. There are many examples in the file 
dicts.f90.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] fortran lib which provide python like data type

[Rustom Mody]

On Friday, January 30, 2015 at 4:09:19 AM UTC+5:30, beli...@aol.com wrote:
 On Thursday, January 29, 2015 at 10:01:00 AM UTC-5, Liu Zhenhai wrote:
  Hi,
  I am not sure here is the right place to ask this question, but I want to 
  give it a shot:)
  are there fortran libs providing python like data type, such as set, dict, 
  list?
  Thanks,
  Yours liuzhenhai
 
 The Fortran library http://bigdft.org/Wiki/index.php?title=Fortran_library 
 appears to have some of what you want. I have not tried the code.
 
 The flib library provides an object called dictionary which is -- strictly 
 speaking -- more than just a dictionary. It is polymorphic and can be a list 
 or a dictionary, as in the python language. The other difference is that it 
 keeps the order of the elements, which is very useful if we want to dump its 
 contents to the yaml output. It represents indeed a tree of data, and for 
 these reasons it will most likely change name into f_tree in a future release 
 of the module.
 
 These dictionaries are also used in the other parts of the flib library and 
 are thus essential for its proper use. There are many examples in the file 
 dicts.f90.

Interesting

Note the very first minimal example

FORTRAN

 use dictionary
 type(dictionary), pointer :: d
 d=dict_new()
 call set(d//'toto',1)
 v = d//'toto'
 call dict_free(d)

The corresponding python

 d = dict()
 d['toto'] = 1
 v = d['toto']
 del(d)

In particular note the del in the python.

Should highlight the point that languages with gc, support data structures
in a way that gc-less languages - Fortran, C, C++ - do not and cannot.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] fortran lib which provide python like data type

[Christian Gollwitzer]

Am 30.01.15 um 02:40 schrieb Rustom Mody:
 FORTRAN
 
  use dictionary
  type(dictionary), pointer :: d
  d=dict_new()
  call set(d//'toto',1)
  v = d//'toto'
  call dict_free(d)
 
 The corresponding python
 
  d = dict()
  d['toto'] = 1
  v = d['toto']
  del(d)
 
 In particular note the del in the python.
 
 Should highlight the point that languages with gc, support data structures
 in a way that gc-less languages - Fortran, C, C++ - do not and cannot.

For C++ this is not correct. Ususally a garbage collector is not used -
though possible - but the constructor/destructor/assignment op in C++
(usually called RAII) provide semantics very similar to the CPython
refcounting behaviour.

For example, I made a set of C++ interface methods to return nested
dicts/list to Python, which is far from complete, but allows to write
something like this:

SWList do_something(SWDict attrs) {
  SWList result;
  for (int i=0; i5; i++) {
SWDict entry;   
entry.insert(count, i);
entry.insert(name, something);
result.push_back(entry);
  }
  return result;
}


There is also Boost::Python which does the same, I think, and much more,
but only supports Python, whereas I use SWIG to interface these
dicts/lists to both CPython and Tcl.

You cannot, however, resolve certain cyclic dependencies with pure
reference counting.

Christian

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Interfacing Fortran applications

[alister]

On Mon, 09 Jun 2014 14:24:07 +0200, Michael Welle wrote:

 Hello,
 
 Sturla Molden sturla.mol...@gmail.com writes:
 
 Michael Welle mwe012...@gmx.net wrote:

 I thought about equipping the Fortran application with sockets, so
 that I can send input data and commands (which is now done via cmd
 line) and reading output data back. Any opinions on this? Best
 pratices?

 If you are to rewrite the Fortran app you can just as well use f2py
 from NumPy.
 a rewrite of the application isn't possible. That would require
 knowledge about what the used algorithms are, why they are implemented
 as they are, that would require extensive testing with test cases that
 don't exist. I can change as much as I want, as long as the core of the
 application isn't touched. I can change everything until after the
 initialisation of the application and the output of the results. That,
 hopefully, will not break something.
 
 Regards hmw

If you have no tests  the Fortran App  is business critical I am 
inclined to leave it totally alone.
i would there for look for ways of calling the Fotran application as it 
is for now (os.subprocess)





-- 
filesystem not big enough for Jumbo Kernel Patch
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Interfacing Fortran applications

[Chris Angelico]

On Mon, Jun 9, 2014 at 5:43 PM, Michael Welle mwe012...@gmx.net wrote:
 I want to build a Python based user interface for an existing Fortran
 application (as everyone wants to do ;)). Lets assume the application is
 parametrised via cmdline parameters and it calculates tons of numbers
 that have to find their way into the Python UI. There are several ways
 to achieve this: using stdin/stdout to exchange data, using files,
 converting the application to a library and load that from Python,
 etc.

 I thought about equipping the Fortran application with sockets, so that
 I can send input data and commands (which is now done via cmd line) and
 reading output data back. Any opinions on this? Best pratices?

Is the application a complete black box? Sounds to me like you have
the power to edit it, so I'm guessing you have the source code and
some knowledge of how it works. If you can, as you suggest, convert it
into a library that can be called from a C program, you can use Cython
to call on it from Python. That'd be my first recommendation.

(One-and-a-halfth recommendation: If the actual application is very
simple, and most of its work is done in library functions, access the
library via Cython, and port the main application logic entirely into
Python. No need to wrap the application into a library, that way.)

Second option would be some kind of coroutine system, interfacing via
a socket. That's quite a good option; all you have to do is settle,
between the two, a set of protocol rules. Some examples:
* Everything is encoded in ASCII. (That gives you the option of
expanding to UTF-8 later, if you need full Unicode, but keeps it
really easy for now.)
* Commands and responses are terminated with end-of-line, 0x0A.
* Commands follow the basic shell style of command, then a space
(0x20), then parameters.
* If you don't need to overlay responses: One command's responses end
with a dot (0x2E) on a blank line. (See SMTP for an example of this.)
* If you do need to have multiple commands in flight simultaneously:
Every command is prefixed with an arbitrary token, followed by a
space, and every line of response is prefixed with the same token.
(See IMAP for an example of this.)

Nut out your protocol first, before you write a single line of code.
Keep your protocol document up-to-date if you change anything. Then,
if you want to write a different program for one end or the other, you
can guarantee that they'll be able to communicate. And if you want to
change from Unix sockets to TCP/IP sockets, or to stdin/stdout, or to
any other system, the translation will be easier for having that
document.

Third option: Keep the application as it is, and use Python's
subprocess module to send it parameters and maybe stdin, and retrieve
its stdout.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Interfacing Fortran applications

[Sturla Molden]

Michael Welle mwe012...@gmx.net wrote:

 I thought about equipping the Fortran application with sockets, so that
 I can send input data and commands (which is now done via cmd line) and
 reading output data back. Any opinions on this? Best pratices?  

If you are to rewrite the Fortran app you can just as well use f2py from
NumPy.

Sturla

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Interfacing Fortran applications

[Chris Angelico]

On Mon, Jun 9, 2014 at 10:24 PM, Michael Welle mwe012...@gmx.net wrote:
 I can change everything until after the
 initialisation of the application and the output of the results. That,
 hopefully, will not break something.

Okay. So you should be able to go for the socket approach, fairly
easily. Or possibly you could turn the whole thing into a C-callable
library, although I've no idea how easy it is to do that. (My
experience with FORTRAN - yes, not Fortran, the code was that old -
goes as far as eyeballing some of IBM's DB2 examples and translating
them into REXX. I've never actually used a Fortran compiler.)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Interfacing Fortran applications

[Sturla Molden]

On 09/06/14 14:24, Michael Welle wrote:
 If you are to rewrite the Fortran app you can just as well use f2py from
 NumPy.
 a rewrite of the application isn't possible. That would require
 knowledge about what the used algorithms are, why they are implemented
 as they are, that would require extensive testing with test cases that
 don't exist.

You are ok with adding sockets and IPC to a Fortran app, but using f2py 
is off limits because it requires a rewrite? Sorry, this doesn't make 
any sense. But it's your problem, I don't care what you decide to do.



Sturla


--
https://mail.python.org/mailman/listinfo/python-list

Re: Fortran (Was: The does Python have variables? debate)

[Albert van der Horst]

In article lkoi5v$vfj$1...@speranza.aioe.org,
Mark H Harris  harrismh...@gmail.com wrote:
On 5/11/14 1:59 PM, Chris Angelico wrote:
 julia prec=524288
 524288

 julia with_bigfloat_precision(prec) do
  println(atan(BigFloat(1)/5)*16 - atan(BigFloat(1)/239)*4)
end

 Would it be quicker (and no less accurate) to represent pi as
 atan(BigFloat(1))*4 instead? That's how I originally met a
 pi-calculation (as opposed to PI = 3.14 extended to however much
 accuracy someone cared to do).

No.  Simple experiment will show you. The atan(x=1) will converge
faster. For 524288 bits atan(1) formula converged in 3 seconds, and
Machin's formula atan(x1) converged in 2 seconds. Where it becomes very
apparent is 10K and 100K or above.  Also, the difference is much more
noticeable in Python than in Julia, but it is there no-the-less.

But here is the cool part: what if your π function could be broken
down into three very fast converging atan(x1) functions like this one:

  pi = 24*atan(1/8) + 8*atan(1/57) + 4*atan(1/239)(Shanks used this)


... and then, you have julia send each piece to a separate
processor|core (it does this at its center) and they converge together,
then julia pieces them together at the end. Then things get incredibly
faster.

I know now how to interpret your posts. Using incredible for a mere
factor of at most 3. Balanced views are more convincing.

Groetjes Albert

-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spearc.xs4all.nl =n http://home.hccnet.nl/a.w.m.van.der.horst

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Fortran

[Albert van der Horst]

In article 8761l9pi3n@elektro.pacujo.net,
Marko Rauhamaa  ma...@pacujo.net wrote:
SNIP

Producing an effective JIT for Python seems like a formidable challenge
but not impossible in principle. After all, the developer *could*
provide that static typing information in, like, 99.9% of the code. That
would be feat worthy of a Millennium Technology Prize. It would be like
having the cake and eating it, too.

I'm totally flabbergasted by comments like this. I always thought that
the real point of JIT was that it can take advantage of type information
that is not available until runtime. If it can infer that something is
an integer, just before entering a loop to be executed millions of times,
that should be a big win, not?



Marko
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spearc.xs4all.nl =n http://home.hccnet.nl/a.w.m.van.der.horst

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Fortran

[Marko Rauhamaa]

alb...@spenarnc.xs4all.nl (Albert van der Horst):

 I always thought that the real point of JIT was that it can take
 advantage of type information that is not available until runtime. If
 it can infer that something is an integer, just before entering a loop
 to be executed millions of times, that should be a big win, not?

JIT most generally refers to on-the-fly optimization of the code. In the
case of Java, the code to be executed is bytecode that is independent of
the CPU instruction set and thus needs to be interpreted. You could
perform the optimization before the execution and save the executable
binary, but the Java gods are reluctant to do that for ideological
reasons (compile once, run everywhere).

Python code, too, is compiled into interpreted bytecode. Again, you
could compile it into machine code ahead of execution or perform the
compilation on the fly with JIT techniques. However, Python is so
ridiculously dynamic that such compilers have an extremely difficult
time making effective optimizations.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Fortran

[Chris Angelico]

On Fri, May 30, 2014 at 12:50 AM, Marko Rauhamaa ma...@pacujo.net wrote:
 Python code, too, is compiled into interpreted bytecode. Again, you
 could compile it into machine code ahead of execution or perform the
 compilation on the fly with JIT techniques. However, Python is so
 ridiculously dynamic that such compilers have an extremely difficult
 time making effective optimizations.

I'd avoid the word ridiculously there. Python's dynamism is a
feature, not a flaw. It's a feature with consequences (but then, what
isn't), and if you don't want it, use a different language, but it's
not ridiculous.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Fortran

[Marko Rauhamaa]

Chris Angelico ros...@gmail.com:

 On Fri, May 30, 2014 at 12:50 AM, Marko Rauhamaa ma...@pacujo.net wrote:
 Python code, too, is compiled into interpreted bytecode. Again, you
 could compile it into machine code ahead of execution or perform the
 compilation on the fly with JIT techniques. However, Python is so
 ridiculously dynamic that such compilers have an extremely difficult
 time making effective optimizations.

 I'd avoid the word ridiculously there. Python's dynamism is a
 feature, not a flaw. It's a feature with consequences (but then, what
 isn't), and if you don't want it, use a different language, but it's
 not ridiculous.

The ridiculous dynamism is the main selling point of high-level
programming languages. I wouldn't have it any other way.

But from the point of view of the JIT developer, it must feel like Alice
in Wonderland.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Fortran (Was: The does Python have variables? debate)

[Peter Pearson]

On 29 May 2014 14:06:47 GMT, Albert van der Horst wrote:
 In article lkoi5v$vfj$1...@speranza.aioe.org,
 Mark H Harris  harrismh...@gmail.com wrote:
On 5/11/14 1:59 PM, Chris Angelico wrote:
 julia prec=524288
 524288

 julia with_bigfloat_precision(prec) do
  println(atan(BigFloat(1)/5)*16 - atan(BigFloat(1)/239)*4)
end

 Would it be quicker (and no less accurate) to represent pi as
 atan(BigFloat(1))*4 instead? That's how I originally met a
 pi-calculation (as opposed to PI = 3.14 extended to however much
 accuracy someone cared to do).

No.  Simple experiment will show you. The atan(x=1) will converge
faster. For 524288 bits atan(1) formula converged in 3 seconds, and
Machin's formula atan(x1) converged in 2 seconds. Where it becomes very
apparent is 10K and 100K or above.  Also, the difference is much more
noticeable in Python than in Julia, but it is there no-the-less.

But here is the cool part: what if your π function could be broken
down into three very fast converging atan(x1) functions like this one:

  pi = 24*atan(1/8) + 8*atan(1/57) + 4*atan(1/239)(Shanks used this)


... and then, you have julia send each piece to a separate
processor|core (it does this at its center) and they converge together,
then julia pieces them together at the end. Then things get incredibly
faster.

 I know now how to interpret your posts. Using incredible for a mere
 factor of at most 3. Balanced views are more convincing.

Won't there be an additional speedup resulting from the computation
of atan(x) converging faster for x=1/8 than for x=1?

-- 
To email me, substitute nowhere-spamcop, invalid-net.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Fortran

[Steven D'Aprano]

On Thu, 29 May 2014 17:50:00 +0300, Marko Rauhamaa wrote:

 alb...@spenarnc.xs4all.nl (Albert van der Horst):
 
 I always thought that the real point of JIT was that it can take
 advantage of type information that is not available until runtime. If
 it can infer that something is an integer, just before entering a loop
 to be executed millions of times, that should be a big win, not?
 
 JIT most generally refers to on-the-fly optimization of the code.

Using information available at run-time, which was Albert's point. Why 
would you delay compilation to run-time if you're only going to use 
information available at edit-time? You pay all the cost of delayed 
compilation and get none of the benefits.


 In the
 case of Java, the code to be executed is bytecode that is independent of
 the CPU instruction set and thus needs to be interpreted.

Not so. There are Java compilers which compile to machine code.

http://www.excelsiorjet.com/
http://gcc.gnu.org/java/

Both are AOT (Ahead Of Time) compilers, but that's not important for this 
discussion. If an AOT compiler can emit machine code, so can a JIT 
compiler, and that's exactly what PyPy does:

http://morepypy.blogspot.com.au/2011/08/visualization-of-jitted-code.html


 You could
 perform the optimization before the execution and save the executable
 binary, but the Java gods are reluctant to do that for ideological
 reasons (compile once, run everywhere).

Who are these Java gods of which you speak?


 Python code, too, is compiled into interpreted bytecode. 

An unjustified assertion. The Python infrastructure is incredibly rich, 
and compilers include many different strategies:

- compile to byte-code for some virtual machine 
  (e.g. JVM, .Net, Parrot)

- static compilation to machine-code;

- JIT compilation to machine-code;

- translation to some other language (e.g. Haskell, Javascript) 
  followed by compilation of that code to machine code.

I've already mentioned that PyPy compiles to machine code. So did its 
predecessor, Psyco. Both are JIT compilers, as are Numba and Parakeet and 
Pyston and Unladen Swallow[1].

Then there's at least one AOT compiler, Nuitka, which produces machine 
code. It's not optimized yet, but there's only one guy working on this 
project, and it's still young.

http://nuitka.net/posts/static-compilation-that-is-the-point.html


 Again, you
 could compile it into machine code ahead of execution or perform the
 compilation on the fly with JIT techniques. 

You're talking as if this were only theoretical. It is not. The state of 
the art in compiler techniques has advanced a lot since the old days of 
the Pascal P-Machine. Parakeet, for example[2], compiles numeric 
functions to optimized machine code on the fly using decorators, using 
Static Single Assignment, which some wag described as being covered in 
Fisher Price's My First Compiler[3].


 However, Python is so
 ridiculously dynamic that such compilers have an extremely difficult
 time making effective optimizations.

Anyone who used Psyco ten years ago would laugh at that statement, and 
Psyco isn't even close to cutting edge.




[1] Unladen Swallow was not a failure. It's just that expectations were 
so high (OMG OMG Google is making a Python compiler this will be more 
powerful than the Death Star and faster than time travel!!!1!) that it 
couldn't help but be a disappointment.

[2] http://www.phi-node.com/2013/01/a-transformative-journey-from-python-to.html

[3] http://blog.cdleary.com/2011/06/mapping-the-monkeysphere/


-- 
Steven D'Aprano
http://import-that.dreamwidth.org/
-- 
https://mail.python.org/mailman/listinfo/python-list