Lisandro Dalcin wrote:
However, in Python
3 that is not te case (and only for the .so, for .py is the same as in
Py2), the import machinery adds the entry later, after the
finalization of the module init function.
Might be an idea to raise this issue on python-dev, to see
if there is a reason f
On Thu, Mar 3, 2011 at 1:59 AM, Stefan Behnel wrote:
> Vitja Makarov, 03.03.2011 10:48:
>>
>> To share common sources is a good idea, we can also share "code" in
>> libcython-.so
>> But then we should handle ABI compatibility problems.
>
> There is little constant code overlap between modules, and
Vitja Makarov, 03.03.2011 10:48:
To share common sources is a good idea, we can also share "code" in
libcython-.so
But then we should handle ABI compatibility problems.
There is little constant code overlap between modules, and putting that
into a separate library would lead to performance reg
mark florisson, 03.03.2011 10:32:
On 3 March 2011 07:43, Stefan Behnel wrote:
Lisandro Dalcin, 03.03.2011 05:38:
On 2 March 2011 21:01, Greg Ewing wrote:
Stefan Behnel wrote:
you'd call "cython" on a package and it would output a directory with a
single __init__.so that contains the module
On 3 March 2011 10:48, Vitja Makarov wrote:
> 2011/3/3 mark florisson :
>> On 3 March 2011 07:43, Stefan Behnel wrote:
>>> Lisandro Dalcin, 03.03.2011 05:38:
On 2 March 2011 21:01, Greg Ewing wrote:
>
> Stefan Behnel wrote:
>>
>> you'd call "cython" on a package and it
2011/3/3 mark florisson :
> On 3 March 2011 07:43, Stefan Behnel wrote:
>> Lisandro Dalcin, 03.03.2011 05:38:
>>>
>>> On 2 March 2011 21:01, Greg Ewing wrote:
Stefan Behnel wrote:
>
> you'd call "cython" on a package and it would output a directory with a
> single __init__.s
On 3 March 2011 07:43, Stefan Behnel wrote:
> Lisandro Dalcin, 03.03.2011 05:38:
>>
>> On 2 March 2011 21:01, Greg Ewing wrote:
>>>
>>> Stefan Behnel wrote:
you'd call "cython" on a package and it would output a directory with a
single __init__.so that contains the modules compiled
Lisandro Dalcin, 03.03.2011 05:38:
On 2 March 2011 21:01, Greg Ewing wrote:
Stefan Behnel wrote:
you'd call "cython" on a package and it would output a directory with a
single __init__.so that contains the modules compiled from all .pyx/.py
files in that package. Importing the package would t
On 2 March 2011 21:01, Greg Ewing wrote:
> Stefan Behnel wrote:
>>
>> you'd call "cython" on a package and it would output a directory with a
>> single __init__.so that contains the modules compiled from all .pyx/.py
>> files in that package. Importing the package would then trigger an import of
>
Stefan Behnel wrote:
you'd call "cython" on a package and it would output a
directory with a single __init__.so that contains the modules compiled
from all .pyx/.py files in that package. Importing the package would
then trigger an import of that __init__.so, which in turn will execute
code in
On 2 March 2011 13:01, Stefan Behnel wrote:
> Dag Sverre Seljebotn, 02.03.2011 16:37:
>>
>> On 03/02/2011 04:11 PM, Lisandro Dalcin wrote:
>>>
>>> On 2 March 2011 08:35, Stefan Behnel wrote:
Dag Sverre Seljebotn, 02.03.2011 11:54:
>
> Problem is that Fortran code often has...inte
On 03/02/2011 05:01 PM, Stefan Behnel wrote:
Dag Sverre Seljebotn, 02.03.2011 16:37:
On 03/02/2011 04:11 PM, Lisandro Dalcin wrote:
On 2 March 2011 08:35, Stefan Behnel wrote:
Dag Sverre Seljebotn, 02.03.2011 11:54:
Problem is that Fortran code often has...interesting...programming
practices.
Dag Sverre Seljebotn, 02.03.2011 16:37:
On 03/02/2011 04:11 PM, Lisandro Dalcin wrote:
On 2 March 2011 08:35, Stefan Behnel wrote:
Dag Sverre Seljebotn, 02.03.2011 11:54:
Problem is that Fortran code often has...interesting...programming
practices. Global variables abound, and are often initia
On 03/02/2011 04:11 PM, Lisandro Dalcin wrote:
On 2 March 2011 08:35, Stefan Behnel wrote:
Dag Sverre Seljebotn, 02.03.2011 11:54:
Problem is that Fortran code often has...interesting...programming
practices. Global variables abound, and are often initialised between
modules. Imagine:
setting
On 2 March 2011 08:35, Stefan Behnel wrote:
> Dag Sverre Seljebotn, 02.03.2011 11:54:
>>
>> Problem is that Fortran code often has...interesting...programming
>> practices. Global variables abound, and are often initialised between
>> modules. Imagine:
>>
>> settings_mod.set_alpha(0.34)
>> print c
Dag Sverre Seljebotn, 02.03.2011 11:54:
On 03/02/2011 11:48 AM, Stefan Behnel wrote:
Dag Sverre Seljebotn, 02.03.2011 11:20:
c) Somehow provide more than one module in the same compilation unit.
Again, this requires the build to work correctly, but seems less dangerous,
and also has the advanta
On 03/02/2011 11:48 AM, Stefan Behnel wrote:
Dag Sverre Seljebotn, 02.03.2011 11:20:
c) Somehow provide more than one module in the same compilation unit.
Again, this requires the build to work correctly, but seems less
dangerous,
and also has the advantage of *allowing* static linking of the
Dag Sverre Seljebotn, 02.03.2011 11:20:
c) Somehow provide more than one module in the same compilation unit.
Again, this requires the build to work correctly, but seems less dangerous,
and also has the advantage of *allowing* static linking of the Fortran
library, if one wants to.
But is someth
This has been raised earlier, but I don't think there was such a
demonstrative use-case as what I have now.
Fwrap is suppose to be able to wrap Fortran "modules", which is
essentially a namespace mechanism. It makes sense to convert the
namespace to Python by creating one Cython pyx file per F
19 matches
Mail list logo
