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

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

[OT] fortran lib which provide python like data type

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

Contents

  [OT] fortran lib which provide python like data type 1989lzhh <1989lzhh@gmail.com> - 2015-01-29 21:39 +0800
    Re: [OT] fortran lib which provide python like data type beliavsky@aol.com - 2015-01-29 14:39 -0800
      Re: [OT] fortran lib which provide python like data type Rustom Mody <rustompmody@gmail.com> - 2015-01-29 17:40 -0800
        Re: [OT] fortran lib which provide python like data type Christian Gollwitzer <auriocus@gmx.de> - 2015-01-30 08:32 +0100
          Re: [OT] fortran lib which provide python like data type Rustom Mody <rustompmody@gmail.com> - 2015-01-30 08:27 -0800
            Re: [OT] fortran lib which provide python like data type Michael Torrie <torriem@gmail.com> - 2015-01-30 10:08 -0700
              Re: [OT] fortran lib which provide python like data type Rustom Mody <rustompmody@gmail.com> - 2015-01-30 09:31 -0800
                RAII vs gc (was fortran lib which provide python like data type) Rustom Mody <rustompmody@gmail.com> - 2015-01-30 10:02 -0800
                  Re: RAII vs gc (was fortran lib which provide python like data type) Sturla Molden <sturla.molden@gmail.com> - 2015-01-30 21:28 +0000
                    Re: RAII vs gc (was fortran lib which provide python like data type) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-01 14:00 +1100
                      Re: RAII vs gc (was fortran lib which provide python like data type) Chris Angelico <rosuav@gmail.com> - 2015-02-01 14:21 +1100
                  Re: RAII vs gc (was fortran lib which provide python like data type) Devin Jeanpierre <jeanpierreda@gmail.com> - 2015-01-31 19:27 -0800
                Re: [OT] fortran lib which provide python like data type Michael Torrie <torriem@gmail.com> - 2015-01-30 11:15 -0700
                  Re: [OT] fortran lib which provide python like data type Paul Rubin <no.email@nospam.invalid> - 2015-01-30 10:23 -0800
                    Re: [OT] fortran lib which provide python like data type Christian Gollwitzer <auriocus@gmx.de> - 2015-01-31 09:27 +0100
                  Re: [OT] fortran lib which provide python like data type Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-01-31 11:51 +1300
                    Re: [OT] fortran lib which provide python like data type Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-31 10:49 +1100
                    Re: [OT] fortran lib which provide python like data type Marko Rauhamaa <marko@pacujo.net> - 2015-01-31 14:22 +0200
                      Re: [OT] fortran lib which provide python like data type Rustom Mody <rustompmody@gmail.com> - 2015-01-31 07:50 -0800
                        Re: [OT] fortran lib which provide python like data type Marko Rauhamaa <marko@pacujo.net> - 2015-01-31 19:43 +0200
                          Re: [OT] fortran lib which provide python like data type Rustom Mody <rustompmody@gmail.com> - 2015-01-31 18:30 -0800
                            Re: [OT] fortran lib which provide python like data type Marko Rauhamaa <marko@pacujo.net> - 2015-02-01 09:38 +0200
                              Re: [OT] fortran lib which provide python like data type Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-02 03:49 +1100
                                Re: [OT] fortran lib which provide python like data type Marko Rauhamaa <marko@pacujo.net> - 2015-02-01 20:57 +0200
                                  Re: [OT] fortran lib which provide python like data type Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-02 12:59 +1100
                                    Re: [OT] fortran lib which provide python like data type Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-02 13:05 +1100
                                      Re: [OT] fortran lib which provide python like data type Marko Rauhamaa <marko@pacujo.net> - 2015-02-02 10:51 +0200
                                    Re: [OT] fortran lib which provide python like data type Chris Angelico <rosuav@gmail.com> - 2015-02-02 13:04 +1100
                                      Re: [OT] fortran lib which provide python like data type Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-02 18:01 +1100
                                      Re: [OT] fortran lib which provide python like data type Marko Rauhamaa <marko@pacujo.net> - 2015-02-02 10:52 +0200
                                        Re: [OT] fortran lib which provide python like data type Paul Rudin <paul.nospam@rudin.co.uk> - 2015-02-02 12:56 +0000
                                          Re: [OT] fortran lib which provide python like data type Marko Rauhamaa <marko@pacujo.net> - 2015-02-02 15:27 +0200
                                        Re: [OT] fortran lib which provide python like data type Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-02-02 16:08 +0000
                                          Re: [OT] fortran lib which provide python like data type Rustom Mody <rustompmody@gmail.com> - 2015-02-02 08:21 -0800
                                            Re: [OT] fortran lib which provide python like data type Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-02-02 16:52 +0000
                                            Re: [OT] fortran lib which provide python like data type Chris Angelico <rosuav@gmail.com> - 2015-02-03 04:25 +1100
                                            Re: [OT] fortran lib which provide python like data type Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-02-02 18:34 +0000
                                            Re: [OT] fortran lib which provide python like data type Chris Angelico <rosuav@gmail.com> - 2015-02-03 10:15 +1100
                                    Re: [OT] fortran lib which provide python like data type Matthew Barnett <auxlang@mrabarnett.plus.com> - 2015-02-02 02:35 +0000
                                    Re: [OT] fortran lib which provide python like data type Chris Angelico <rosuav@gmail.com> - 2015-02-02 13:45 +1100
                                      Re: [OT] fortran lib which provide python like data type Roy Smith <roy@panix.com> - 2015-02-01 23:12 -0500
                                    Re: [OT] fortran lib which provide python like data type Roy Smith <roy@panix.com> - 2015-02-01 23:14 -0500
                                      Re: [OT] fortran lib which provide python like data type Chris Angelico <rosuav@gmail.com> - 2015-02-02 15:47 +1100
                                      Re: [OT] fortran lib which provide python like data type Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-02-02 16:06 +0000
                        Re: [OT] fortran lib which provide python like data type Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-01-31 17:59 +0000
                      Re: [OT] fortran lib which provide python like data type Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-01 13:27 +1100
                      Re: [OT] fortran lib which provide python like data type Paul Rubin <no.email@nospam.invalid> - 2015-01-31 22:26 -0800
                        Re: [OT] fortran lib which provide python like data type Marko Rauhamaa <marko@pacujo.net> - 2015-02-01 09:58 +0200
                          Re: [OT] fortran lib which provide python like data type Christian Gollwitzer <auriocus@gmx.de> - 2015-02-01 09:14 +0100
                            Re: [OT] fortran lib which provide python like data type Marko Rauhamaa <marko@pacujo.net> - 2015-02-01 21:12 +0200
                              Re: [OT] fortran lib which provide python like data type Michael Torrie <torriem@gmail.com> - 2015-02-01 17:50 -0700
                              Re: [OT] fortran lib which provide python like data type Michael Torrie <torriem@gmail.com> - 2015-02-01 18:02 -0700
                                Re: [OT] fortran lib which provide python like data type Marko Rauhamaa <marko@pacujo.net> - 2015-02-02 09:39 +0200
                                  Re: [OT] fortran lib which provide python like data type Michael Torrie <torriem@gmail.com> - 2015-02-02 09:25 -0700
                                    Re: [OT] fortran lib which provide python like data type Marko Rauhamaa <marko@pacujo.net> - 2015-02-02 19:57 +0200
                                      Re: [OT] fortran lib which provide python like data type Michael Torrie <torriem@gmail.com> - 2015-02-02 11:23 -0700
                                        Re: [OT] fortran lib which provide python like data type Marko Rauhamaa <marko@pacujo.net> - 2015-02-02 20:54 +0200
                              Re: [OT] fortran lib which provide python like data type Michael Torrie <torriem@gmail.com> - 2015-02-01 18:02 -0700
                    Re: [OT] fortran lib which provide python like data type beliavsky@aol.com - 2015-02-02 05:30 -0800
                  Re: [OT] fortran lib which provide python like data type Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-31 10:50 +1100
                    Re: [OT] fortran lib which provide python like data type Michael Torrie <torriem@gmail.com> - 2015-01-30 20:49 -0700
                      Re: [OT] fortran lib which provide python like data type Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-31 22:04 +1100
                        Re: [OT] fortran lib which provide python like data type Rustom Mody <rustompmody@gmail.com> - 2015-01-31 08:18 -0800
            Re: [OT] fortran lib which provide python like data type Sturla Molden <sturla.molden@gmail.com> - 2015-01-30 23:12 +0000
            Re: [OT] fortran lib which provide python like data type Michael Torrie <torriem@gmail.com> - 2015-01-30 20:35 -0700

Page 1 of 4  [1] 2 3 4  Next page →

#84819 — [OT] fortran lib which provide python like data type

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

[toc] | [next] | [standalone]

#84851

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."

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

#84859

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.

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

#84866

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; i<5; 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

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

#84899

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; i<5; 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++

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

#84903

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.

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

#84906

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.

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

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

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

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

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

Rustom Mody <rustompmody@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

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

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

Sturla Molden wrote:

> Rustom Mody <rustompmody@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

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

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

On Sun, Feb 1, 2015 at 2:00 PM, Steven D'Aprano
<steve+comp.lang.python@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

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

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

On Fri, Jan 30, 2015 at 1:28 PM, Sturla Molden <sturla.molden@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

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

#84908

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.

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

#84909

Michael Torrie <torriem@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.

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

#84938

Am 30.01.15 um 19:23 schrieb Paul Rubin:
> Michael Torrie <torriem@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::vector<double> compute() {
	const size_t N=100000;
	std::vector<double> result(N);
	for (size_t i=0; i<N; 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

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

#84922

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

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

#84925

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

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

#84952

Gregory Ewing <greg.ewing@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

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

#84962

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

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

#84964

Rustom Mody <rustompmody@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

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

Page 1 of 4  [1] 2 3 4  Next page →

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

csiph-web