Nathan Dunfield, 24.04.2012 14:22:
> On Apr 23, 2012, at 1:28 PM, Stefan Behnel wrote:
>> Hmm, that line basically just says "PyCFunction_Call", which is a
>> function exported by CPython. I wonder why gcc would consider this
>> "not a constant".
>>
>> Could you check if the preprocessor (gcc -E,
On Apr 23, 2012, at 1:28 PM, Stefan Behnel wrote:
> Hmm, that line basically just says "PyCFunction_Call", which is a function
> exported by CPython. I wonder why gcc would consider this "not a constant".
>
> Could you check if the preprocessor (gcc -E, with all the above includes)
> also sees tha
2012/4/24 Stefan Behnel :
> Stefan Behnel, 23.04.2012 20:28:
>> Nathan Dunfield, 23.04.2012 17:58:
>>> I've encountered the following issue with Cython 0.16 on Windows with
>>> using the Mingw32 compiler (I'm using Python 3.2 here, but I don't think
>>> that's the issue):
>>>
>>> $ python3 setup.py
Stefan Behnel, 23.04.2012 20:28:
> Nathan Dunfield, 23.04.2012 17:58:
>> I've encountered the following issue with Cython 0.16 on Windows with
>> using the Mingw32 compiler (I'm using Python 3.2 here, but I don't think
>> that's the issue):
>>
>> $ python3 setup.py build -c mingw32
>> running build
Nathan Dunfield, 23.04.2012 17:58:
> I've encountered the following issue with Cython 0.16 on Windows with
> using the Mingw32 compiler (I'm using Python 3.2 here, but I don't think
> that's the issue):
>
> $ python3 setup.py build -c mingw32
> running build
> running build_py
> running build_ext
I've encountered the following issue with Cython 0.16 on Windows with using the
Mingw32 compiler (I'm using Python 3.2 here, but I don't think that's the
issue):
$ python3 setup.py build -c mingw32
running build
running build_py
running build_ext
skipping 'SnapPy.c' Cython extension (up-to-date)
2012/4/22 Vitja Makarov :
> 2012/4/22 Nathan Dunfield :
>> On Apr 22, 2012, at 1:22 PM, Vitja Makarov wrote:
>>> Oops, it seems to be a problem with locals() dict creation.
>>
>> Yes it does. The following variants of my original example both work:
>>
>> ## prob.pyx version 1
>>
>> def cy_eval(s)
2012/4/22 Nathan Dunfield :
> On Apr 22, 2012, at 1:22 PM, Vitja Makarov wrote:
>> Oops, it seems to be a problem with locals() dict creation.
>
> Yes it does. The following variants of my original example both work:
>
> ## prob.pyx version 1
>
> def cy_eval(s):
> return eval(s)
>
> def f(x):
On Apr 22, 2012, at 1:22 PM, Vitja Makarov wrote:
> Oops, it seems to be a problem with locals() dict creation.
Yes it does. The following variants of my original example both work:
## prob.pyx version 1
def cy_eval(s):
return eval(s)
def f(x):
cdef int* p
return cy_eval(x)
## p
2012/4/22 Nathan Dunfield :
> With Cython 0.15, the following works with Python 2.7:
>
> ### start file: prob.pyx
>
> def f(x):
> cdef int* p
> return eval(x)
>
> ### end file
>
import pyximport; pyximport.install()
import prob
prob.f("5")
> 5
>
> but with Cython 0.16 it doesn'
With Cython 0.15, the following works with Python 2.7:
### start file: prob.pyx
def f(x):
cdef int* p
return eval(x)
### end file
>>> import pyximport; pyximport.install()
>>> import prob
>>> prob.f("5")
5
but with Cython 0.16 it doesn't even compile:
>>> import prob
Error compiling
Dear all,
On OS X Snow Leopard with XCode 3.2.*, I encountered the following issues when
using "easy_install" to install the new Cython 0.16:
(a) With Python 2.7 where Cython 0.15.1 had previously been installed,
"easy_install" failed with the below error message; looks like it's somehow
using
2012/4/21 Stefan Behnel :
> mark florisson, 21.04.2012 15:02:
>> We are pleased to announce a new version of Cython, 0.16
>> Many thanks to the many contributors of this release and to all bug
>> reporters and supporting users!
>> Enjoy!
>
> Thanks, Mark!
>
Cool, thanks!
--
vitja.
__
mark florisson, 21.04.2012 15:02:
> We are pleased to announce a new version of Cython, 0.16
> Many thanks to the many contributors of this release and to all bug
> reporters and supporting users!
> Enjoy!
Thanks, Mark!
Stefan
___
cython-devel mailing l
We are pleased to announce a new version of Cython, 0.16
(http://cython.org/release/Cython-0.16.tar.gz). It comes with new
features, improvements and bug fixes, including
- super() without arguments
- fused types
- memoryviews
- more Python-like functions
Many thanks to the many c
On 20 April 2012 20:04, Stefan Behnel wrote:
> mark florisson, 15.04.2012 20:59:
>> Hopefully a final release candidate for the 0.16 release can be found
>> here: http://wiki.cython.org/ReleaseNotes-0.16 . This corresponds to
>> the 'release' branch of the cython repository on github.
>
> I pushed
On 20 April 2012 20:04, Stefan Behnel wrote:
> mark florisson, 15.04.2012 20:59:
>> Hopefully a final release candidate for the 0.16 release can be found
>> here: http://wiki.cython.org/ReleaseNotes-0.16 . This corresponds to
>> the 'release' branch of the cython repository on github.
>
> I pushed
mark florisson, 15.04.2012 20:59:
> Hopefully a final release candidate for the 0.16 release can be found
> here: http://wiki.cython.org/ReleaseNotes-0.16 . This corresponds to
> the 'release' branch of the cython repository on github.
I pushed another couple of fixes related to the recent importl
Hopefully a final release candidate for the 0.16 release can be found
here: http://wiki.cython.org/ReleaseNotes-0.16 . This corresponds to
the 'release' branch of the cython repository on github.
___
cython-devel mailing list
cython-devel@python.org
http:
On 14 April 2012 22:21, mark florisson wrote:
> On 14 April 2012 22:13, Wes McKinney wrote:
>> On Sat, Apr 14, 2012 at 11:32 AM, mark florisson
>> wrote:
>>> On 14 April 2012 14:57, Dag Sverre Seljebotn
>>> wrote:
On 04/14/2012 12:46 PM, mark florisson wrote:
>
> On 12 April 2012
On 14 April 2012 22:13, Wes McKinney wrote:
> On Sat, Apr 14, 2012 at 11:32 AM, mark florisson
> wrote:
>> On 14 April 2012 14:57, Dag Sverre Seljebotn
>> wrote:
>>> On 04/14/2012 12:46 PM, mark florisson wrote:
On 12 April 2012 22:00, Wes McKinney wrote:
>
> On Thu, Apr 12,
On Sat, Apr 14, 2012 at 11:32 AM, mark florisson
wrote:
> On 14 April 2012 14:57, Dag Sverre Seljebotn
> wrote:
>> On 04/14/2012 12:46 PM, mark florisson wrote:
>>>
>>> On 12 April 2012 22:00, Wes McKinney wrote:
On Thu, Apr 12, 2012 at 10:38 AM, mark florisson
wrote:
>
>>>
On 14 April 2012 14:57, Dag Sverre Seljebotn wrote:
> On 04/14/2012 12:46 PM, mark florisson wrote:
>>
>> On 12 April 2012 22:00, Wes McKinney wrote:
>>>
>>> On Thu, Apr 12, 2012 at 10:38 AM, mark florisson
>>> wrote:
Yet another release candidate, this will hopefully be the last befo
mark florisson, 14.04.2012 13:02:
> I just pushed a fix here:
> https://github.com/markflorisson88/cython/tree/release
Note that I had already pushed a couple of other fixes into the release
branch of the main repo.
Stefan
___
cython-devel mailing list
On 04/14/2012 12:46 PM, mark florisson wrote:
On 12 April 2012 22:00, Wes McKinney wrote:
On Thu, Apr 12, 2012 at 10:38 AM, mark florisson
wrote:
Yet another release candidate, this will hopefully be the last before
the 0.16 release. You can grab it from here:
http://wiki.cython.org/ReleaseN
On 14 April 2012 12:00, Stefan Behnel wrote:
> Arfrever Frehtes Taifersar Arahesis, 14.04.2012 12:16:
>> 4 tests still fail with Python 3.2 (currently 3.2.3).
>> All tests pass with Python 2.6.8, 2.7.3 and 3.1.5.
>
> Thanks for the report.
>
Indeed, I just pushed a fix here:
https://github.com/ma
Arfrever Frehtes Taifersar Arahesis, 14.04.2012 12:16:
> 4 tests still fail with Python 3.2 (currently 3.2.3).
> All tests pass with Python 2.6.8, 2.7.3 and 3.1.5.
Thanks for the report.
> Failures with Python 3.2:
>
> ==
> FAI
On 12 April 2012 22:00, Wes McKinney wrote:
> On Thu, Apr 12, 2012 at 10:38 AM, mark florisson
> wrote:
>> Yet another release candidate, this will hopefully be the last before
>> the 0.16 release. You can grab it from here:
>> http://wiki.cython.org/ReleaseNotes-0.16
>>
>> There were several fix
2012-04-12 16:38:37 mark florisson napisał(a):
> Yet another release candidate, this will hopefully be the last before
> the 0.16 release. You can grab it from here:
> http://wiki.cython.org/ReleaseNotes-0.16
>
> There were several fixes for the numpy attribute rewrite, memoryviews
> and fused typ
Dag Sverre Seljebotn, 12.04.2012 23:32:
> (We should obviously start to tell people which git branch to fetch in
> addition to the tarball.
+1
> And perhaps create a "devel" branch and let master
> be betas and release candidates.)
-1
I think we should just always merge release branches back in
On 04/12/2012 11:00 PM, Wes McKinney wrote:
On Thu, Apr 12, 2012 at 10:38 AM, mark florisson
wrote:
Yet another release candidate, this will hopefully be the last before
the 0.16 release. You can grab it from here:
http://wiki.cython.org/ReleaseNotes-0.16
There were several fixes for the nump
On Thu, Apr 12, 2012 at 10:38 AM, mark florisson
wrote:
> Yet another release candidate, this will hopefully be the last before
> the 0.16 release. You can grab it from here:
> http://wiki.cython.org/ReleaseNotes-0.16
>
> There were several fixes for the numpy attribute rewrite, memoryviews
> and
Yet another release candidate, this will hopefully be the last before
the 0.16 release. You can grab it from here:
http://wiki.cython.org/ReleaseNotes-0.16
There were several fixes for the numpy attribute rewrite, memoryviews
and fused types. Accessing the 'base' attribute of a typed ndarray now
g
All tests pass with Python 2.6 (2.6.7 release).
All tests pass with Python 2.7 (snapshot of 2.7 branch, revision 3623c3e6c049).
All tests pass with Python 3.1 (3.1.4 release).
4 failures with Python 3.2 (snapshot of 3.2 branch, revision 0a4a6f98bd8e).
Failures with Python 3.2:
===
We are happy to announce the first release candidate for Cython 0.16,
you can grab it from here: http://wiki.cython.org/ReleaseNotes-0.16
Since the beta last month several issues have been fixed, including
the NumPy array attribute access deprecation, which are now rewritten
to use the NumPy macro
On 5 March 2012 05:41, Arfrever Frehtes Taifersar Arahesis
wrote:
> All tests pass with Python 2.6 (2.6.7 release).
> All tests pass with Python 2.7 (snapshot of 2.7 branch, revision
> 52ecec12c0ed).
> 10 failures with Python 3.1 (3.1.4 release).
> 14 failures with Python 3.2 (snapshot of 3.2 bra
All tests pass with Python 2.6 (2.6.7 release).
All tests pass with Python 2.7 (snapshot of 2.7 branch, revision 52ecec12c0ed).
10 failures with Python 3.1 (3.1.4 release).
14 failures with Python 3.2 (snapshot of 3.2 branch, revision 4966907d3661).
Failures with Python 3.2:
=
On Fri, Mar 2, 2012 at 8:29 AM, mark florisson
wrote:
> On 1 March 2012 16:18, Dag Sverre Seljebotn
> wrote:
>> On 03/01/2012 04:03 AM, mark florisson wrote:
>>>
>>> On 29 February 2012 17:57, Dag Sverre Seljebotn
>>> wrote:
On 02/29/2012 09:42 AM, Stefan Behnel wrote:
>
>
>>
On 1 March 2012 19:16, Sturla Molden wrote:
> On 01.03.2012 19:33, Dag Sverre Seljebotn wrote:
>>
>>
>> Yeah, I proposed this on another thread as one of the options, but the
>> support wasn't overwhelming at the time...
>
>
> I think it is worse to break parts of it, thus introducing bugs that mi
On 1 March 2012 16:18, Dag Sverre Seljebotn wrote:
> On 03/01/2012 04:03 AM, mark florisson wrote:
>>
>> On 29 February 2012 17:57, Dag Sverre Seljebotn
>> wrote:
>>>
>>> On 02/29/2012 09:42 AM, Stefan Behnel wrote:
Dag Sverre Seljebotn, 29.02.2012 18:06:
>
>
> I'm won
On 01.03.2012 19:33, Dag Sverre Seljebotn wrote:
Yeah, I proposed this on another thread as one of the options, but the
support wasn't overwhelming at the time...
I think it is worse to break parts of it, thus introducing bugs that
might go silent for a long time.
Rather deprecate the whole
On 03/01/2012 09:29 AM, Sturla Molden wrote:
On 01.03.2012 17:18, Dag Sverre Seljebotn wrote:
are saying we (somehow) stick with supporting "arr.shape[0]" in
the future, and perhaps even support "print arr.shape"? (+ arr.dim,
arr.strides).
What if you just deprecate ndarray support completely
On 01.03.2012 17:18, Dag Sverre Seljebotn wrote:
I'm anyway leaning towards deprecating arr.data, as it's too different
from what the Python attribute does.
This should be preferred, I think
&arr[0]
or
&arr[0]
The latter is exacty what arr.data will currently do in Cython (but not
On 01.03.2012 17:18, Dag Sverre Seljebotn wrote:
are saying we (somehow) stick with supporting "arr.shape[0]" in
the future, and perhaps even support "print arr.shape"? (+ arr.dim,
arr.strides).
What if you just deprecate ndarray support completely, and just focus on
memory views?
Yes, you
On 03/01/2012 04:03 AM, mark florisson wrote:
On 29 February 2012 17:57, Dag Sverre Seljebotn
wrote:
On 02/29/2012 09:42 AM, Stefan Behnel wrote:
Dag Sverre Seljebotn, 29.02.2012 18:06:
I'm wondering what the best course of action for deprecating the shape
field in numpy.pxd is.
The thing
On 29 February 2012 17:57, Dag Sverre Seljebotn
wrote:
> On 02/29/2012 09:42 AM, Stefan Behnel wrote:
>>
>> Dag Sverre Seljebotn, 29.02.2012 18:06:
>>>
>>> I'm wondering what the best course of action for deprecating the shape
>>> field in numpy.pxd is.
>>>
>>> The thing is, currently "shape" real
On 02/29/2012 09:42 AM, Stefan Behnel wrote:
Dag Sverre Seljebotn, 29.02.2012 18:06:
I'm wondering what the best course of action for deprecating the shape
field in numpy.pxd is.
The thing is, currently "shape" really gets in the way. In most situations
it is OK with slow access to shape throug
Dag Sverre Seljebotn, 29.02.2012 18:06:
> I'm wondering what the best course of action for deprecating the shape
> field in numpy.pxd is.
>
> The thing is, currently "shape" really gets in the way. In most situations
> it is OK with slow access to shape through the Python layer, and
> "arr.shape[0
I'm wondering what the best course of action for deprecating the shape
field in numpy.pxd is.
The thing is, currently "shape" really gets in the way. In most
situations it is OK with slow access to shape through the Python layer,
and "arr.shape[0]" is often just fine, but currently one is in a
The Cython team is pleased to announce the first beta release for the
upcoming release of Cython 0.16. A tarball can be grabbed from here:
http://cython.org/release/Cython-0.16.beta0.tar.gz. This release comes
with several great new features such as better function introspection,
super without argu
On 4 November 2011 08:58, Vitja Makarov wrote:
> 2011/11/4 mark florisson :
>>>
>>> That's nice. I've also implemented support for dynamic default args
>>>
>>> http://trac.cython.org/cython_trac/ticket/674
>>>
>>> I think it could be merged either.
>>
>> That's great, because it's a nasty bug. I s
2011/11/4 mark florisson :
>>
>> That's nice. I've also implemented support for dynamic default args
>>
>> http://trac.cython.org/cython_trac/ticket/674
>>
>> I think it could be merged either.
>
> That's great, because it's a nasty bug. I see no pull request for that
> though, although I see it in
On 3 November 2011 21:26, Stefan Behnel wrote:
> Vitja Makarov, 03.11.2011 21:42:
>>
>> 2011/11/4 mark florisson:
>>>
>>> With Vitja's super() ready and with fused classmethods and
>>> staticmethods ready, I think we're almost ready for a release. I also
>>> supported cdef class static methods (pr
On 3 November 2011 20:42, Vitja Makarov wrote:
> 2011/11/4 mark florisson :
>> On 29 October 2011 17:40, Vitja Makarov wrote:
>>> 2011/10/29 Stefan Behnel :
mark florisson, 28.10.2011 22:59:
>
> On 28 October 2011 21:55, Robert Bradshaw wrote:
>>
>> With Mark's fused types an
Vitja Makarov, 03.11.2011 21:42:
2011/11/4 mark florisson:
With Vitja's super() ready and with fused classmethods and
staticmethods ready, I think we're almost ready for a release. I also
supported cdef class static methods (previously it gave compiler
crashes).
That's nice. I've also implemen
2011/11/4 mark florisson :
> On 29 October 2011 17:40, Vitja Makarov wrote:
>> 2011/10/29 Stefan Behnel :
>>> mark florisson, 28.10.2011 22:59:
On 28 October 2011 21:55, Robert Bradshaw wrote:
>
> With Mark's fused types and memory views going in, I think it's about
> time fo
On 29 October 2011 17:40, Vitja Makarov wrote:
> 2011/10/29 Stefan Behnel :
>> mark florisson, 28.10.2011 22:59:
>>>
>>> On 28 October 2011 21:55, Robert Bradshaw wrote:
With Mark's fused types and memory views going in, I think it's about
time for a new release.
>>
>> Agreed.
>>
>>
2011/10/31 mark florisson :
> We can now pass a chunksize argument into prange:
> https://github.com/cython/cython/commit/5c3e77d3c70686fedd5619d7267728fc819b4c60
Cool. And very well documented too. Thank you!
--
Francesc Alted
___
cython-devel mailin
We can now pass a chunksize argument into prange:
https://github.com/cython/cython/commit/5c3e77d3c70686fedd5619d7267728fc819b4c60
On 29 October 2011 14:14, mark florisson wrote:
> Before we do a release, would anyone be opposed to a 'chunksize'
> keyword argument to prange()? That may have signi
On 28 October 2011 21:59, mark florisson wrote:
> On 28 October 2011 21:55, Robert Bradshaw
> wrote:
>> With Mark's fused types and memory views going in, I think it's about
>> time for a new release. Thoughts? Anyone want to volunteer to take up
>> the process?
>>
>> - Robert
>> ___
Robert Bradshaw, 29.10.2011 18:58:
On Sat, Oct 29, 2011 at 7:50 AM, Stefan Behnel wrote:
I still haven't investigated the decorator issue that appeared in the Sage
tests. I think it's related to decorators on module level def functions,
which would suggest that it's best to eventually fix it as
On 29 October 2011 18:59, Robert Bradshaw wrote:
> On Sat, Oct 29, 2011 at 10:44 AM, mark florisson
> wrote:
>> On 29 October 2011 18:05, Robert Bradshaw
>> wrote:
>>> On Sat, Oct 29, 2011 at 4:41 AM, mark florisson
>>> wrote:
Hm ok I'll disable them then. Pointers and some other dtypes a
On Sat, Oct 29, 2011 at 10:44 AM, mark florisson
wrote:
> On 29 October 2011 18:05, Robert Bradshaw
> wrote:
>> On Sat, Oct 29, 2011 at 4:41 AM, mark florisson
>> wrote:
>>> Hm ok I'll disable them then. Pointers and some other dtypes are also
>>> not supported yet. As for the documentation, ha
On 29 October 2011 18:47, mark florisson wrote:
> On 29 October 2011 18:44, mark florisson wrote:
>> On 29 October 2011 18:05, Robert Bradshaw
>> wrote:
>>> On Sat, Oct 29, 2011 at 4:41 AM, mark florisson
>>> wrote:
Hm ok I'll disable them then. Pointers and some other dtypes are also
>>>
On 29 October 2011 18:44, mark florisson wrote:
> On 29 October 2011 18:05, Robert Bradshaw
> wrote:
>> On Sat, Oct 29, 2011 at 4:41 AM, mark florisson
>> wrote:
>>> Hm ok I'll disable them then. Pointers and some other dtypes are also
>>> not supported yet. As for the documentation, have you g
On 29 October 2011 18:05, Robert Bradshaw wrote:
> On Sat, Oct 29, 2011 at 4:41 AM, mark florisson
> wrote:
>> Hm ok I'll disable them then. Pointers and some other dtypes are also
>> not supported yet. As for the documentation, have you guys reviewed
>> the documentation for fused types and memo
On Sat, Oct 29, 2011 at 4:41 AM, mark florisson
wrote:
> Hm ok I'll disable them then. Pointers and some other dtypes are also
> not supported yet. As for the documentation, have you guys reviewed
> the documentation for fused types and memoryviews?
I looked at the fused types docs.
> For instan
On Sat, Oct 29, 2011 at 7:50 AM, Stefan Behnel wrote:
> mark florisson, 28.10.2011 22:59:
>>
>> On 28 October 2011 21:55, Robert Bradshaw wrote:
>>>
>>> With Mark's fused types and memory views going in, I think it's about
>>> time for a new release.
>
> Agreed.
>
>
>>> Thoughts?
>
> I still haven
2011/10/29 Stefan Behnel :
> mark florisson, 28.10.2011 22:59:
>>
>> On 28 October 2011 21:55, Robert Bradshaw wrote:
>>>
>>> With Mark's fused types and memory views going in, I think it's about
>>> time for a new release.
>
> Agreed.
>
>
>>> Thoughts?
>
> I still haven't investigated the decorato
mark florisson, 29.10.2011 17:03:
On 29 October 2011 15:50, Stefan Behnel wrote:
mark florisson, 28.10.2011 22:59:
On 28 October 2011 21:55, Robert Bradshaw wrote:
With Mark's fused types and memory views going in, I think it's about
time for a new release.
I still haven't investigated the
It seems that, most ironically, OpenMP "isn't defined" to be called
from multithreaded contexts. It seems that even if I use prange only
in another thread that isn't the main thread the program segfaults if
compiled with gcc. That's kind of worrying, I suppose we should
mention that in the document
On 29 October 2011 15:50, Stefan Behnel wrote:
> mark florisson, 28.10.2011 22:59:
>>
>> On 28 October 2011 21:55, Robert Bradshaw wrote:
>>>
>>> With Mark's fused types and memory views going in, I think it's about
>>> time for a new release.
>
> Agreed.
>
>
>>> Thoughts?
>
> I still haven't inve
On 29 October 2011 15:50, Nathaniel Smith wrote:
> On Oct 29, 2011 4:41 AM, "mark florisson" wrote:
>> "
>> Typed memoryviews can be used for efficient access to buffers. It is
>> similar to the current buffer support, but has more features and
>> cleaner syntax. A memoryview can be used in any c
mark florisson, 28.10.2011 22:59:
On 28 October 2011 21:55, Robert Bradshaw wrote:
With Mark's fused types and memory views going in, I think it's about
time for a new release.
Agreed.
Thoughts?
I still haven't investigated the decorator issue that appeared in the Sage
tests. I think it'
On Oct 29, 2011 4:41 AM, "mark florisson" wrote:
> "
> Typed memoryviews can be used for efficient access to buffers. It is
> similar to the current buffer support, but has more features and
> cleaner syntax. A memoryview can be used in any context (function
> parameters, module-level, cdef class
Heh, that's a +1 :)
This makes me wonder, should we organize soms polls to have users vote
on what functionality they would like to see in Cython? Some users may
read the cython-dev mailing list, but many might also not. E.g.
provide a poll where we list some things that we would like to see,
and
On the contrary, this is an excellent idea!
El 29/10/2011 15:14, "mark florisson" va
escriure:
> Before we do a release, would anyone be opposed to a 'chunksize'
> keyword argument to prange()? That may have significant performance
> impacts.
>
> On 29 October 2011 12:41, mark florisson
> wrote:
Before we do a release, would anyone be opposed to a 'chunksize'
keyword argument to prange()? That may have significant performance
impacts.
On 29 October 2011 12:41, mark florisson wrote:
> Hm ok I'll disable them then. Pointers and some other dtypes are also
> not supported yet. As for the doc
Hm ok I'll disable them then. Pointers and some other dtypes are also
not supported yet. As for the documentation, have you guys reviewed
the documentation for fused types and memoryviews? For instance this
is the introduction for memoryviews:
"
Typed memoryviews can be used for efficient access t
Re b), it would be better to disable object dtypes (or emit a warning about the
possible bug when using them) than to delay the release. Object memoryviews are
rare in the first place, and those who contain themselves should be very rare.
--
Sent from my Android phone with K-9 Mail. Please excus
On Fri, Oct 28, 2011 at 1:59 PM, mark florisson
wrote:
> On 28 October 2011 21:55, Robert Bradshaw
> wrote:
>> With Mark's fused types and memory views going in, I think it's about
>> time for a new release. Thoughts? Anyone want to volunteer to take up
>> the process?
>>
>> - Robert
>>
On 28 October 2011 21:55, Robert Bradshaw wrote:
> With Mark's fused types and memory views going in, I think it's about
> time for a new release. Thoughts? Anyone want to volunteer to take up
> the process?
>
> - Robert
> ___
> cython-devel mailing list
With Mark's fused types and memory views going in, I think it's about
time for a new release. Thoughts? Anyone want to volunteer to take up
the process?
- Robert
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinf
83 matches
Mail list logo
