2011/2/28 Vitja Makarov :
> 2011/2/23 Vitja Makarov :
>> 2011/2/23 Vitja Makarov :
>>> 2011/2/22 Stefan Behnel :
Vitja Makarov, 20.02.2011 18:23:
>
> 2011/2/16 Vitja Makarov:
>>
>> Hmm... both python and codespeaks in the thread
Yes, we should keep it to cython-devel
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
>
On Wed, Mar 2, 2011 at 5:54 PM, W. Trevor King wrote:
> Previous discussions in this thread [1,2] have discussed the issues
> associated with overloading the 'public' keyword. For an example of
> the difficulties this causes, see the ugly workaround [3] in my recent
> commit [4]. Definately wort
Previous discussions in this thread [1,2] have discussed the issues
associated with overloading the 'public' keyword. For an example of
the difficulties this causes, see the ugly workaround [3] in my recent
commit [4]. Definately worth fixing this syntax.
How do syntax changes with deprecations
On 2 March 2011 17:14, Lisandro Dalcin wrote:
> On 2 March 2011 16:18, Vitja Makarov wrote:
>> Hi!
>>
>> I noticed that this error came back again.
>>
>> https://sage.math.washington.edu:8091/hudson/view/cython-devel/job/cython-devel-tests-py26-c/lastCompletedBuild/testReport/(root)/CythonRunTest
On Sat, Feb 26, 2011 at 07:11:48PM -0800, Robert Bradshaw wrote:
> On Sat, Feb 26, 2011 at 6:14 PM, W. Trevor King wrote:
> > On Sat, Feb 26, 2011 at 10:01:43AM -0800, Robert Bradshaw wrote:
> >> On Sat, Feb 26, 2011 at 3:48 AM, W. Trevor King wrote:
> >> > On Fri, Feb 25, 2011 at 11:11:03PM -080
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
2011/3/3 Vitja Makarov :
> This doesn't work:
> def assign():
> a, *b = 1,2,3,4,5
> return a, b
>
import x
x.assign()
> Traceback (most recent call last):
> File "", line 1, in
> File "x.pyx", line 6, in x.assign (x.c:445)
> a, *b = 1,2,3,4,5
> TypeError: Expected list, got in
On 2 March 2011 16:18, Vitja Makarov wrote:
> Hi!
>
> I noticed that this error came back again.
>
> https://sage.math.washington.edu:8091/hudson/view/cython-devel/job/cython-devel-tests-py26-c/lastCompletedBuild/testReport/(root)/CythonRunTestCase/compiling__c__and_running_special_methods_T561/
>
Hi!
I noticed that this error came back again.
https://sage.math.washington.edu:8091/hudson/view/cython-devel/job/cython-devel-tests-py26-c/lastCompletedBuild/testReport/(root)/CythonRunTestCase/compiling__c__and_running_special_methods_T561/
--
vitja.
__
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
20 matches
Mail list logo
