[Cython] Cython 0.16

[mark florisson]

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 an option with a form that allows them to fill in something else
entirely.

Maybe we could do that on cython.org to allow anonymous votes, not
everyone may be interested in discussion, just in voting.

On 29 October 2011 15:23, Francesc Alted <faltet at gmail.com> wrote:
> On the contrary, this is an excellent idea!
>
> El 29/10/2011 15:14, "mark florisson" <markflorisson88 at gmail.com> 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 <markflorisson88 at gmail.com>
>> 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? For instance this
>> > is the introduction for memoryviews:
>> >
>> > "
>> > 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 attribute, etc) and can be
>> > obtained from any object that exposes the PEP 3118 buffer interface.
>> > "
>> >
>> > but I'm not sure this new functionality won't confuse users of the old
>> > buffer support.
>> >
>> > For fused types, cython.numeric only includes long, double and double
>> > complex. I think that should be changed to short, int, long, float,
>> > double, float complex and double complex. I was deliberately avoiding
>> > long long and long double as they (if not used as a base type) would
>> > be preferred over the others and may be a lot slower. But then, such
>> > usage wouldn't be very useful. Should I include them then?
>> >
>> > On 29 October 2011 10:30, Dag Sverre Seljebotn
>> > <d.s.seljebotn at astro.uio.no> wrote:
>> >> 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 excuse my brevity.
>> >>
>> >> Robert Bradshaw <robertwb at math.washington.edu> wrote:
>> >>>
>> >>> On Fri, Oct 28, 2011 at 1:59 PM, mark florisson
>> >>> <markflorisson88 at gmail.com> wrote: > On 28 October 2011 21:55, Robert
>> >>> Bradshaw <robertwb at math.washington.edu> 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 >> cython-devel at python.org >>
>> >>> >> http://mail.python.org/mailman/listinfo/cython-devel >> > > That'd
>> >>> >> be cool.
>> >>> >> However there are a few outstanding issues: >    a) the compiler is
>> >>> >> somewhat
>> >>> >> slower (possible solution: lazy utility codes) Yeah, I forgot about
>> >>> >> that.
>> >>> >> This should get resolved. Lazy utility codes (perhaps breaking them
>> >>> >> up)
>> >>> >> would probably got us most of the way there. Long term, I really
>> >>> >> like the
>> >>> >> "declaration caching" idea which could be used for users .pxd files
>> >>> >> as well
>> >>> >> as internally. >    b) there's a potential memory leak problem for
>> >>> >> memoryviews with > object dtype that contain themselves, this still
>> >>> >> needs
>> >>> >> investigation. I think this could be mentioned as a caviat rather
>> >>> >> than being
>> >>> >> a blocker. > As for a), Stefan mentioned code spending a lot of
>> >>> >> time in sub.
>> >>> >> > Stefan, could you post the code for this that made Cython compile
>> >>> >> > very >
>> >>> >> slowly? >
>> >>> ________________________________
>> >>> > cython-devel mailing list > cython-devel at python.org >
>> >>> > http://mail.python.org/mailman/listinfo/cython-devel >
>> >>> ________________________________
>> >>> cython-devel mailing list cython-devel at python.org
>> >>> http://mail.python.org/mailman/listinfo/cython-devel
>> >>
>> >> _______________________________________________
>> >> cython-devel mailing list
>> >> cython-devel at python.org
>> >> http://mail.python.org/mailman/listinfo/cython-devel
>> >>
>> >>
>> >
>> _______________________________________________
>> cython-devel mailing list
>> cython-devel at python.org
>> http://mail.python.org/mailman/listinfo/cython-devel
>
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> http://mail.python.org/mailman/listinfo/cython-devel
>
>