>>>
>>> I think you could even pass in two flags, one for wraparound and one for
>>> boundscheck, and then just evaluate them appropriately in the existing "if"
>>> tests above. That should allow both features to be supported independently
>>> in a fast way.
>>>
>> Intresting, could C compilers in
tuvwxyz"
cdef long f_1(unicode text):
cdef int i, j
cdef int n = len(text)
cdef int val
cdef long S = 0
for j in range(10):
for i in range(n):
val = len(unicode_slice(text, 0, i))
S += val * j
return S
cdef long f_
>> Then it can simplify writing utility code in order to support
>> different optimization flags in other cases too.
>
> Usually, yes. Look at the dict iteration code, for example, which makes
> pretty heavy use of it.
>
> This may not work in all cases, because the C compiler can decide to *not*
>
meit -n 50 -r 5 -s "from
>> mytests.unicode_index import test_1" "test_1()"
>> 50 loops, best of 5: 152 msec per loop
>> (py33) zbook:mytests $ python3.3 -m timeit -n 50 -r 5 -s "from
>> mytests.unicode_index import test_2" "test_2()"
>
2013/3/1 Stefan Behnel :
> Zaur Shibzukhov, 01.03.2013 10:46:
>> Could I help in order to include this in 19.0?
>
> I like pull requests. ;)
>
OK
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
2013/3/2 Stefan Behnel :
>> I think you could even pass in two flags, one for wraparound and one for
>> boundscheck, and then just evaluate them appropriately in the existing "if"
>> tests above. That should allow both features to be supported independently
>> in a fast way.
>
> https://github.com/
2013/3/2 Stefan Behnel :
> Stefan Behnel, 28.02.2013 22:16:
>
> https://github.com/scoder/cython/commit/cc4f7daec3b1f19b5acaed7766e2b6f86902ad94
>
> Stefan
>
I tried to build with that change. Tests `unicode_indexing` and
`index` are passed.
___
cython-de
nstead of direct usage of "non-native" C
macros from datetime.h.
Now you call `import_array ()` first in the same way as is done with `numpy`.
This approach looks natural in the light of experience with numpy.
Zaur Shibzukhov
___
cython-de
2013/3/3 Zaur Shibzukhov :
> 2013/3/2 Stefan Behnel :
>> Hi,
>>
>> the last pull request looks good to me now.
>>
>> https://github.com/cython/cython/pull/189
>>
>> Any more comments on it?
>
> As was suggested earlier, I added `import_datetim
2013/3/3 Zaur Shibzukhov :
> 2013/3/3 Zaur Shibzukhov :
>> 2013/3/2 Stefan Behnel :
>>> Hi,
>>>
>>> the last pull request looks good to me now.
>>>
>>> https://github.com/cython/cython/pull/189
>>>
>>> Any more comments
2013/3/3 Zaur Shibzukhov :
> 2013/3/3 Zaur Shibzukhov :
>> 2013/3/3 Zaur Shibzukhov :
>>> 2013/3/2 Stefan Behnel :
>>>> Hi,
>>>>
>>>> the last pull request looks good to me now.
>>>>
>>>> https://github.com/cython/cytho
/commit/bd041680b78067007ad6b9894a2f2c18514e397c
Zaur Shibzukhov
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
2013/3/5 Zaur Shibzukhov
> In ExprNodes.py there are several places where method `as_none_safe_node`
> was applied in order to wrap a node by NoneCheckNode.
> I think it would be resonable to apply that mostly only in cases when
> noncheck=True.
>
> Here are possible chang
2013/3/5 Zaur Shibzukhov
> 2013/3/5 Zaur Shibzukhov
>
>> In ExprNodes.py there are several places where method `as_none_safe_node`
>> was applied in order to wrap a node by NoneCheckNode.
>> I think it would be resonable to apply that mostly only in cases when
>>
2013/3/5 Stefan Behnel
> Zaur Shibzukhov, 05.03.2013 07:21:
> > In ExprNodes.py there are several places where method `as_none_safe_node`
> > was applied in order to wrap a node by NoneCheckNode.
> > I think it would be resonable to apply that mostly only in cases w
2013/3/5 Zaur Shibzukhov
>
> May be the safer strategy is to set nonecheck=True by default and allow
> locally to apply nonecheck(False) when developer believes that it is
> necessary?
>
Strategy of making nonecheck=True by default and setting explicitly
nonecheck=False when it
ed memory exactly for N elements.
N*[NULL] - changes semantics because there can't be list with N elements
and filled by NULL.
N*[None] - more expansive for further assignments because of Py_DECREFs.
I suppose that N*[] could do the trick. It could be optimized so that N*[]
is equal to an
2013/3/7 Zaur Shibzukhov
> I guess the problem is to construct new (even empty) list with
> pre-allocated memory exactly for N elements.
>
> N*[NULL] - changes semantics because there can't be list with N elements
> and filled by NULL.
> N*[None] - more expansive for furt
/27525a5dc9f6eba31b330a6ec04e7a105191d9f5
Zaur Shibzukhov
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
2013/3/7 Zaur Shibzukhov :
> Current Cython generate for slicing of list/tuple general
> PySequence_GetSlice/SetSlice call.
> We could replace that to native call for Py{List|Tuple}_GetSlice and
> PyList_SetSlice for lists/tuples.
There is updated change that use utility code
__Pyx_P
20 matches
Mail list logo
