Aaron DeVore wrote:
> Wouldn't Cython be a bit big for the stdlib? It would be the largest
> single piece of the standard library, with the possible exception of
> Tkinter.
Counting the .py files from the Cython package gives me 1.1MB for 69
source files, the tests are about 600K, so that's less t
Dag Sverre Seljebotn wrote:
> Stefan Behnel wrote:
>> I'm still for moving Cython to the stdlib one day, but I would prefer a
>> somewhat closer "one day". What do the others think?
>>
> The only concern I have is that of release cycles. I.e. would it
Ondrej Certik wrote:
> one drawback is that I still need to use .pxd files to
> declare cdef functions. Example:
>
> @cython.locals(n=cython.int)
> def fact(n):
> ...
>
> in order for this to become a "cdef int foo()" function, I need to
> have this line in foo.pxd:
>
> cdef int fact(int n)
>
>
Lisandro Dalcin wrote:
> Stefan, could you please explain me what all we (we==Cython developers
> and users) will gain with this inclusion of Cython in Python's core?
I see a couple of advantages in general, and for us in particular.
1) Cython would become an official part of CPython, and shipped
Hi,
Robert Bradshaw wrote:
> I think the most immediate official milestone is being able to
> compile 100% of Cython code. This is the target for 1.0.
Did you really mean Cython here or Python? I think 100% Python is somewhat
hard to prove. I would expect that we are pretty close to compiling P
Hi,
Robert Bradshaw wrote:
> On Nov 5, 2008, at 11:18 AM, Stefan Behnel wrote:
>> Robert Bradshaw wrote:
>>> I think the most immediate official milestone is being able to
>>> compile 100% of Cython code. This is the target for 1.0.
>> Did you really mean C
Willem Broekema wrote:
> In Pure Python mode, code compiled (using annotations) to C should run
> equivalent to running (ignoring annotations) in the Python
> interpreter. That implies that a variable declared as cython.int may
> not rely on overflow behavior, as Python would automatically make a
>
Hi,
Jason Evans wrote:
> The switch conversion, as described at:
>
> http://wiki.cython.org/enhancements/switch
>
> causes a compilation error for the following code:
>
> ===
> cdef int x = 42
>
> if x == 1:
> print x
> elif x == 2:
> print x
> else:
> pass
> =
Hi,
Aaron DeVore wrote:
> cdef void append(UnicodeBuffer *ubuffer, unicode un):
> Py_UNICODE *string = PyUnicode_AsUnicode(un)
> ... append string to buffer ...
>
> I'm trying to find something where I could also append with a function
> like this one:
>
> cdef void appendArray(UnicodeBuf
Hi,
Willem Broekema wrote:
> On Thu, Nov 6, 2008 at 5:17 PM, Robert Bradshaw
> <[EMAIL PROTECTED]> wrote:
>> Um, No. If you declare a variable to be int then it *will* overflow
>> when compiled but not (currently) when interpreted.
>
> The question was not intended as "will overflow happen?" but
Hi again,
Stefan Behnel wrote:
> PyUnicode_AS_DATA(un) to get the length
I (obviously) meant PyUnicode_GET_SIZE(un) ...
Stefan
___
Cython-dev mailing list
Cython-dev@codespeak.net
http://codespeak.net/mailman/listinfo/cython-dev
Hi,
zhen_qing_he_456 wrote:
> if in my fuction i declare a c array like:
>cdef int a[5]
> now if want to initialize my array a, i can do follow:
> a[0] = 1
> a[1] = 10
>:
> :
> a[4] = 3
> the value to my array is not
Hi,
Robert Bradshaw wrote:
> Given the number of new features, I'm thinking it's time to bump a
> more major version number. (Probably should have done so last
> version, but got to start sometime.)
>
> Try the package up at http://cython.org/Cython-0.10.rc.tar.gz .
Good call. I think it m
Hi,
tav wrote:
> Whilst I'm at it, is there any advantage into turning the various
> lists into C arrays? I won't be accessing them from Python and thus
> was wondering if it would also be possible to speed up the
> __getattribute__ implementation in Namespace? Thanks!
This is what you have:
Hi,
tav wrote:
> Stefan Behnel wrote:
>> Who needs setters when you can modify "this" directly?
>>
>>>>> def test():
>>... a = []
>>... def get(i):
>>... return
Hi,
tav wrote:
> robertwb> Short of writing your own sort algorithm there's no
> robertwb> much of a way to speed up sort(). If you're just
> robertwb> sorting strings here, that could probably be done a
> robertwb> lot faster.
>
> Hmz, I am sorting strings. Is there a special subset/subr
Greg Ewing wrote:
> jay wrote:
>> I want declare an array with a shape at the beginning of program,then
>> in my function i will assign value to it by calculation.
>> Is there a good way to do it?
>
> Ideally, what you *should* be able to do is
>
>a[:] = 1, 3, 28, 5, 3
>
> but unless Cython ha
Hi,
Robert Bradshaw wrote:
> On Nov 5, 2008, at 6:52 AM, Ondrej Certik wrote:
>> On Wed, Nov 5, 2008 at 2:52 PM, Stefan Behnel wrote:
>>>@cython.cdef
>>>@cython.locals(n=cython.int, _return=cython.int)
>>>def fact(n):
>>>...
>&g
Robert Bradshaw wrote:
> On Nov 10, 2008, at 9:54 PM, Stefan Behnel wrote:
>> @cython.cexttype(attr1=type, ...)
>> class A:
>> ...
>
> I would prefer cython.cclass(...) or cython.extension_type(...)
> [...]
>> people who know C mig
Hi,
Robert Kern wrote:
> Hoyt Koepke wrote:
>>> Are you sure? I changed the line to this:
>>>
>>> from numpy import random as rn
Hmm, I added this as tests/run/importas.pyx, and it works perfectly:
===
__doc__ = u"""
>>> import sys as sous
>>> import distutils.core as c
Robert Bradshaw wrote:
> On Nov 11, 2008, at 1:22 AM, Stefan Behnel wrote:
>> @cython.cclass(attr1=cython.int, ...)# Py3 only
This actually works in Py2.6 also, where a
@cython.cclass
class A: pass
would still be an old-style class. So, using a class decorator here
Hi,
please don't hijack other people's threads, start a new one for a new topic.
Uwe Schmitt wrote:
> I got a problem in the following situatino when wrapping
> some c code:
>
> file svdlib.h contains:
>
> extern char *SVDVersion;
> extern long SVDVerbosity;
>
> file svlib.pyx begins w
Hi,
Robert Kern wrote:
> I think the problem is that _kp_29 becomes a unicode string u'*'. The
> function that raises the exception explicitly checks for exactly str.
>
> if (!PyString_Check(item)) {
>
> PyErr_SetString(PyExc_TypeError,
>
Hi,
Greg Ewing wrote:
> You can do
>
>a[0], a[1], a[2], a[3], a[4] = 1, 3, 28, 5, 3
>
> which will get turned into a series of assignments.
>
> Ideally, what you *should* be able to do is
>
>a[:] = 1, 3, 28, 5, 3
In Cython, you can now do
cdef int a[5]
a[:] = [1, 3, 2
Greg Ewing wrote:
> Stefan Behnel wrote:
>
>> Not only in this case would it be nice to allow extension classes to
>> inherit from object in Cython without any additional setup.
>
> What do you mean by that? Extension classes already
> inherit from object implicitly.
Y
Hoyt Koepke wrote:
>> Setting the "is_identifier" bit for the specific string should do the
>> trick.
>
> Nice. Would you still like me to file the bug report?
Sure, I can't fix it right away (so that will keep it from getting lost),
and a bug report is very helpful for documentation purposes to
Uwe Schmitt wrote:
> Uwe Schmitt schrieb:
>> Stefan Behnel schrieb:
>>> Uwe Schmitt wrote:
>>>> > I got a problem in the following situatino when wrapping
>>>> > some c code:
>>>> >
>>>> > file svdlib.h contains:
Uwe Schmitt wrote:
> Stefan Behnel schrieb:
>> Hmm, your code example is not very complete. An educated guess is that
>> the
>> above code occurs inside a function, and the assignment to SVDVerbosity
>> makes it a local variable (normal Python behaviour). Since it hasn
Hi,
Robert Bradshaw wrote:
> On Nov 13, 2008, at 2:30 PM, Stefan Behnel wrote:
>> Greg Ewing wrote:
>>> You can do
>>>
>>>a[0], a[1], a[2], a[3], a[4] = 1, 3, 28, 5, 3
>>>
>>> which will get turned into a series of assignments.
>>&g
Hi,
Hoyt Koepke wrote:
> Okay, I'll do that right away. Could someone give me an account on
> the bug tracker?
Please send a htpasswd file/line to Robert Bradshaw. I agree that this
situation is not optimal, though...
Anyway, I applied a fix for this bug. Please give the latest cython-devel
ver
Stefan Behnel wrote:
> Hoyt Koepke wrote:
>> Okay, I'll do that right away. Could someone give me an account on
>> the bug tracker?
>
> Please send a htpasswd file/line to Robert Bradshaw. I agree that this
> situation is not optimal, though...
I a
Hi,
Lisandro Dalcin wrote:
> changeset: 1333:34aca76e1b9d
> summary: array size must be set as int, not numeric string
>
> broke mpi4py and petsc4py, where I use stack-allocated arrays where
> the size comes from an (external) enumeration, for example:
>
> cdef char name[MPI_MAX_OBJECT_NAM
Stefan Behnel wrote:
> Robert Bradshaw wrote:
>> On Nov 13, 2008, at 2:30 PM, Stefan Behnel wrote:
>>> However, the way it's currently implemented does no bounds
>>> checking, so it's
>>> pretty easy to shoot yourself in the foot when you assign no
Hi,
Robert Bradshaw wrote:
> On Nov 15, 2008, at 1:17 PM, Aaron DeVore wrote:
>
>> I'm trying to use PyDict_Next to iterate over a dict in a way that is
>> identical to this statement:
>> for k, v in d.items():
>> # do stuff with key and value
>
> Yes, declare them to be PyObject* rather tha
Hi,
Robert Bradshaw wrote:
> On Nov 16, 2008, at 1:38 AM, Stefan Behnel wrote:
>> I ran timeit on this:
>>
>> ---
>> def items(d):
>> for k,v in d.items():
>> pass
>>
>> def iteritems(d):
>>
Dag Sverre Seljebotn wrote:
> Stefan Behnel wrote:
>> That makes me wonder if it's not worth using such an implementation for
>>
>> cdef dict d
>> ...
>> for (key|value|key,value) in d.iter(keys|values|items)():
>> ...
>>
>
Hi,
Greg Ewing wrote:
> Dag Sverre Seljebotn wrote:
>> I'd definitely not have a DictLoopNode; instead
>> one should use a regular WhileStatNode containing a SimpleCallNode
>> calling PyDict_Next.
>
> Except that you can't express a call to PyDict_Next using
> a standard SimpleCallNode because
Hi Dag,
Dag Sverre Seljebotn wrote:
> Be aware of the TempsBlockNode I wrote if you look at this, for any
> temporary variables needed. (It is currently unused so may have bugs
> too...ask if you have problems with it)
Yep, I found it already. :)
The current implementation works for me in all
Dag Sverre Seljebotn wrote:
> There's one thing that worries me: Calling TupleNode's allocate_temps.
> [...]
> Ideally, one should find a way of not having to call analyse_types and
> allocate_temps on TupleNode, instead one should pass the different
> variables that is set during analysis directly
Lisandro Dalcin wrote:
> I tried to build && install cython-devel on Windows XP, I do not have
> MSVC installed. All went fine, but compiling extension modules
> (Scanners, Scanning, Parsing, Visitor) failed bad because the MSVC
> compiler was not available.
>
> Do it make sense to fix this by prin
Hi,
an lxml user discovered that Cython code currently leaks exception
references when entering a try-except blocks while an exception is set in
sys.exc_*().
This was introduced in my change to the try-except handling a while ago.
It's already fixed in current cython-devel. It would therefore be
Hi,
Dag Sverre Seljebotn wrote:
> If you commit the same change to the cython-branch,
Done.
> one can release a
> bugfix release immediatily with much less extensive release checking
Fine with me.
> I'd like a system where releases of cython-devel always enter a period
> of freezing and bet
Hi,
Lisandro Dalcin wrote:
> While, hacking on setup.py, I noticed the author list has four member.
> I understand this is already a bit long, but ...
>
> I really believe Dag had made so wonderful and non-trivial
> contributions to the project as to deserve a place there.
>
> What do you all th
Lisandro Dalcin wrote:
> On Tue, Nov 18, 2008 at 10:39 AM, Dag Sverre Seljebotn
> <[EMAIL PROTECTED]> wrote:
>> Idea: I was thinking of perhaps a transform that ran through the tree
>> and replaced anything that is a compile-time expression with its literal
>> result, i.e.
>
> But this will not wor
Hi,
Andrew Straw wrote:
> According to the documentation for PyErr_CheckSignals() (at
> http://docs.python.org/c-api/exceptions.html#PyErr_CheckSignals ), the
> KeyboardInterrupt is already raised.
In that case, if you need this inside a cdef function, you can declaring it
as "except *" and simpl
Hi,
William Stein wrote:
> I think it would
> possibly be very good to port this signal stuff into Cython itself (why not?).
Yes, but... :)
It would have to be explicit to avoid unnecessary overhead in time-critical
code (e.g. loops may or may not be a good candidate for signal checking,
dependi
Hi,
when re-reading an older thread about the struct syntax, I had a funny idea
I wanted to share.
Robert Bradshaw wrote:
> I'm with Stefan that it is very
> dangerous to hide the malloc and expect the user to explicitly
> provide the free. If the user wants to manage their own memory, they
> can
replying to myself here...
Stefan Behnel wrote:
> Supporting realloc is also trivial as in
>
> mem.realloc(2 * len(mem))
It's actually not that trivial for a PyVarObject. This would work better:
mem = mem.realloc(2*len(mem))
but if you write
mem2 = mem1.realloc(2*le
Hi,
Hoyt Koepke wrote:
> In iteration over a dictionary, I'm declaring both the variables of
> iteration to have explicit types; i.e. my code is:
>
> cdef int k
> cdef double v
>
> for k, v in d.iteritems():
># do things
>
>
> However, in the c code, I find the following:
>
> int __pyx_v
Hi,
Hoyt Koepke wrote:
> NameError: global name 'dst_type' is not defined
>
> It looks easy to fix, but I'm not sure how, and you could probably fix
> it in 5 seconds.
Yep, I noticed that, too. Fixed already.
Stefan
___
Cython-dev mailing list
Cython-
Hoyt Koepke wrote:
> Thanks! That bug is fixed. Another one has showed up, though:
> [...]
> line 3601, in generate_execution_code
> self.body.generate_execution_code(code)
> File
> "/home/hoytak/sysroot/lib/python2.5/site-packages/Cython/Compiler/Nodes.py",
> line 329, in generate_execut
Hi,
Stefan Behnel wrote:
> Hoyt Koepke wrote:
>> Thanks! That bug is fixed. Another one has showed up, though:
>> [...]
>> line 3601, in generate_execution_code
>> self.body.generate_execution_code(code)
>> File
>> "/home/hoytak/sysroot
Hi,
I noticed that the new-style temps do not currently generate XDECREF code
at the standard function error label. Neither are they considered for
DECREF cleanup by the return statement.
For testing, I let ExprNodes.SequenceNode (i.e. TupleNode and ListNode)
inherit from NewTempExprNode, which w
[replying to myself...]
Stefan Behnel wrote:
> When I add DECREF cleanup code to the return statement, the test suite
> passes just like before
and in fact, the code that the iter-dict transform generates for ticket
#124 shows that this is required. For this code
def spam(
Hi,
Dag Sverre Seljebotn wrote:
> When implementing inlineable functions, I saw that there's code in
> PxdPostParse to enable this kind of code:
>
> cdef int foo(int a, int b):
> cdef int c
> cdef int d
>
> in a pxd file, in order to set "pxd_locals". As soon as some real code
> is a
Hi,
Robert Bradshaw wrote:
>> inline functions in pxd files is something I think comes in *really*
>> handy, it is part of what the "include" statement is currently used
>> for and inline functions are much nicer than include statements.
>
> +1 to inline functions. I've wanted these too.
Absol
Hi,
the ExprNodes.subexpr_nodes() method caches the values of children
referenced in the "subexpr" attribute. However, it can easily get in the
way of tree transforms that replace these subexpressions after they have
been requested for the first time (e.g. during temp allocation). Two ways
to deal
Hi,
Dag Sverre Seljebotn wrote:
> I've might have touched upon this one before, actually I cannot
> remember. At any rate I know I've got no answer.
>
> Can anyone think of a reason why C string literals are allocated as
> variables in C source? I.e. what happens now is
>
> static char __pyx_k
Hi,
Dag Sverre Seljebotn wrote:
> You once mentioned splitting up long
> char literals for MSVC, was this ever done?
No. The problem was only with docstrings at the time, and they are commonly
put into a struct field instead of a string constant. So splitting them up
would have required a separa
Hi,
to fix ticket 124, I tried migrating the for-in loop to new-style temps.
The problem I ran into is that the current support for temp (de-)allocation
in NewTempExprNode during code generation is not enough to get this to
work. Some temps are used longer, some are used shorter than the current
a
Hi,
Dag Sverre Seljebotn wrote:
> C/Python extension modules which depends on a running Python instance
> (the Python version from python.org, not Jython or IronPython or similar).
IronPython has Ironclad, which allows it to run a couple of CPython
extensions already, namely bz2 and (most of) Nu
Hi,
Dag Sverre Seljebotn wrote:
> I must admit I need a little help here. At what point is it the new
> temps differ from the old temps?
They differ in that there is not currently a dedicated flow for temp
allocation/deallocation between nodes at code generation time like there
was one at pre-al
Hi,
Dag Sverre Seljebotn wrote:
> *And*, if that is done, there might be a lot of monotone but crucial
> work (tear it down and build it up), so we better have a coordinated
> coding session with IRC chat. I can put in two or three hours tomorrow.
It will certainly take longer. I actually don't
Hi,
Greg Ewing wrote:
> Dag Sverre Seljebotn wrote:
>
>> Can anyone think of a reason why C string literals are allocated as
>> variables in C source?
>
> I can't remember all the reasons I did it that way in Pyrex,
> but one of them may have been so that I could leave calculating
> the length
Dag Sverre Seljebotn wrote:
> A way to get around this would be to split generate_result_code. So
> mainly my proposal, but with this modification:
>
> self.subexpr.preparation_code(code)
> tmp = code.funcstate.allocate_temp(...)
> self.subexpr.store_result_code(tmp, code)
That's something I th
Stefan Behnel wrote:
> Dag Sverre Seljebotn wrote:
>> A way to get around this would be to split generate_result_code. So
>> mainly my proposal, but with this modification:
>>
>> self.subexpr.preparation_code(code)
>> tmp = code.funcstate.allocate_temp(...)
>
Hi Dag,
Dag Sverre Seljebotn wrote:
> I've made progress.
>
> First off, I'm now somewhat confident that incremental steps can be
> taken anyway. If I'm right, I think that pretty much puts dead the
> discussion about what the optimal solution is for now.
>
> I've boosted NewTempsExprNode and
Hi,
Dag Sverre Seljebotn wrote:
> Note that the current -devel could be released for what I know, except
> for the things that are already noted, there's no rush as the systems
> work together.
There's one remaining problem with the for loop. It seems that in certain
cases (at least in lxml, ha
Dag Sverre Seljebotn wrote:
> Dag Sverre Seljebotn wrote:
>>> Revision: 1393
>>> Branch: default
>>> Author: Stefan Behnel <[EMAIL PROTECTED]> 2008-11-26 18:00:35
>>> Committer: Stefan Behnel <[EMAIL PROTECTED]> 2008-11-26 18:00:35
>>
Greg Ewing wrote:
> Dag Sverre Seljebotn wrote:
>
>> I don't know Pyrex that well, and weren't around at the time of the
>> fork.
>> I assume it is Cython-only then.
>
> Maybe you could provide a bit more context still? I'm just
> wondering why you can't generate the disposal code after
> the whole
Hi,
Kay Schluehr wrote:
>
> cdef class ExtPoint:
> cdef int x
> cdef int y
>
> cdef convert(self, CPoint pt):
> self.x = pt.x
> self.y = pt.y
>
> cpdef test():
> cdef CPoint pt
> pt.x = random.randrange(100)
> pt.y = random.randrange(100)
> ep = ExtP
Robert Bradshaw wrote:
> Unfortunately the devel branch is even less stable than usual, as
> temporary variable handling is undergoing a major shift
"less stable" is a clear understatement. I actually consider it broken in
a couple of places. A lot of code will still work, but crashes (both
compil
Robert Bradshaw wrote:
> Actually, the parsing takes up a significant amount of the compile time.
Which reminds me: I hope the OP uses an installed (i.e. compiled) version
of Cython. That should be a lot faster than running it from a working
directory.
Another thing that comes to mind: in case th
David Cournapeau wrote:
> On Wed, Dec 3, 2008 at 5:58 PM, Robert Bradshaw wrote:
>> Actually, the parsing takes up a significant amount of the compile time.
>
> Is it because the parser cannot assume there is only declarations, or
> is parsing declarations is inherently slow ?
Parsing is slow. Tha
David Cournapeau wrote:
> Something like the following:
>
> ctypedef enum:
> enum1 = 0
> ...
> enum1000 = 0
>
> Takes a significant amount of time, which surprised me a bit. Now, "it
> is slow because nobody bothered speeding it up" is a totally vaild
> answer :)
Sounds like a bug to m
Hi,
Dag Sverre Seljebotn wrote:
> if you feel that this is the wrong time
> for fixing up those things and that it halts other kinds of development,
> you "should" be able to simply change the nodes back to ExprNode and
> have everything go back to a relatively normal, stable state.
I hacked a
Hi,
Dag Sverre Seljebotn wrote:
> Well, the entire tuple (or the object that holds it) could have been
> decrefed too many times and the memory reused for something else that is
> similar enough to bring you to the point of the crash
>
> Not very helpful :-)
;)
What bothers me is that it re
Hi,
the problem really was a ref-counting bug and it was in BoolBinopNode. This
Cython code
a or b
generated the following C code:
/*
* a or b # <<
*/
/* __pyx_t_1 allocated */
__pyx_t_1 = __Pyx_PyObject_IsTrue(__pyx_v_a); if (unlikely(__pyx_t_1 <
0)) {__pyx_
Hi,
Robert Bradshaw wrote:
> What about the other direction, do you see any leaks?
I fixed a couple of leaks already, so it's well possible that there are
more. cython-devel definitely needs some more testing.
Dag's refcount nanny would be helpful here, although it might be enough to
just run th
Hi,
Robert Kern wrote:
> % stats 20
> Thu Dec 4 18:51:19 2008cython.prof
>
> 1092804 function calls (830642 primitive calls) in 2.267 CPU seconds
>
> Ordered by: internal time
> List reduced from 963 to 20 due to restriction <20>
>
> ncalls tottime percall cumtime
Robert Kern wrote:
> It looks like a fair chunk of time is getting spent by the getattr() on line
> 26
> of Visitor.py:BasicVisitor.visit() because of missing entries in the
> dispatch_table.
BTW, I just noticed that I forgot to push my fix for that code section to
the release branch. There's
David Cournapeau wrote:
> On Fri, Dec 5, 2008 at 5:20 PM, Stefan Behnel wrote:
>> Robert Kern wrote:
>>> It looks like a fair chunk of time is getting spent by the getattr() on
>>> line 26
>>> of Visitor.py:BasicVisitor.visit() because of missing entries in th
Hi,
David Cournapeau wrote:
> I managed to get a quite short code snippet: it crashes on an empty
> file
Not on my side. Do you mean that the compiler crashes or that the generated
extension crashes?
> It also crashes on a trivial file (to make sure the empty file
> itself was not the issue)
C
Hi,
David Cournapeau wrote:
> On Fri, Dec 5, 2008 at 6:31 PM, Stefan Behnel wrote:
>>> It also crashes on a trivial file (to make sure the empty file
>>> itself was not the issue)
>> Could you send in the error output you get?
>
> cython crashes, with a segfaul
Hi,
David Cournapeau wrote:
> On Fri, Dec 5, 2008 at 6:10 PM, Stefan Behnel wrote:
>
>> The newest one. I also pushed the Visitor fix to the cython release branch
>> now so that you can try it from there. But there were other improvements in
>> cython-devel that will
Hi,
David Cournapeau wrote:
> I managed to get a quite short code snippet: it crashes on an empty
> file :) It also crashes on a trivial file (to make sure the empty file
> itself was not the issue)
It still doesn't crash for an empty file, but I get it to crash on this:
print "test"
I'
Hi,
Stefan Behnel wrote:
> David Cournapeau wrote:
>> I managed to get a quite short code snippet: it crashes on an empty
>> file :) It also crashes on a trivial file (to make sure the empty file
>> itself was not the issue)
>
> It still doesn't crash for an empt
Hi,
Dag Sverre Seljebotn wrote:
> Dag Sverre Seljebotn wrote:
>> When it comes to FlattenInListTransform, I was thinking about something
>> along the lines of an "StatAsExprNode", which would be sort of the
>> inverse of ExprStatNode: It would contain a block which could contain
>> "ReturnFromS
Hi,
Dag Sverre Seljebotn wrote:
> When it comes to FlattenInListTransform, I was thinking about something
> along the lines of an "StatAsExprNode", which would be sort of the
> inverse of ExprStatNode: It would contain a block which could contain
> "ReturnFromStatAsExprNodeNode" (though a bette
Hi,
Dag Sverre Seljebotn wrote:
> Dag Sverre Seljebotn wrote:
>> Pure optimization transforms should always be done after analysis IMO,
>> so I guess I consider FlattenInListTransform misplaced in the pipeline
>> (though I don't know it well so I'm open for there being reasons I'm
>> overlookin
Hi,
David Cournapeau wrote:
> I would like to know whether adding an IFDEF-like feature in cython
> would be feasible ? I would like to define some cython code depending
> on some defines in the header of the library I am wrapping.
You can use a separate .h file and do something like this
#i
Hi,
Jelle Feringa wrote:
> cdef class FastLoopObj1d:
>
> cdef int N, i
> cdef object obj
>
> def __init__(self, n, obj ):
> self.N = n-1
> self.i = 0
> self.obj = obj
>
> def __iter__(self):
> return self
>
> # no cpdef allowed?
> def __next_
Stefan Behnel wrote:
> Dag Sverre Seljebotn wrote:
>> When it comes to FlattenInListTransform, I was thinking about something
>> along the lines of an "StatAsExprNode", which would be sort of the
>> inverse of ExprStatNode: It would cont
Hi,
Jelle Feringa wrote:
> Thanks for your response; any suggestion what might be more efficient
> than a __getitem__ call?
> Or is this class doomed by design?
I would call it doomed by design. If you use it from Python, I don't think
you can beat direct iteration through __getitem__ *of the o
Hi,
Dag Sverre Seljebotn wrote:
> - It took me some minutes to understand the concept. I definitely think
> another name (as you suggest) would help a lot and perhaps make the
> concept immediately graspable. How about "LetNode" for
> EvalWithTempExprNode? (I don't have a good suggestion for th
Hi,
Dag Sverre Seljebotn wrote:
> Stefan Behnel wrote:
>> I wonder if this can also be useful for common subexpression elimination -
>> and if it makes sense to try such an optimisation in Cython...
>
> I think almost all Python expressions can have potential side-effect
David Cournapeau wrote:
> Is it possible to include docstring in a cdef class exactly as it
> would work for python classes, or do I have to use python wrappers
> around the cython class ? As an example:
>
> cdef Yo:
> def __init__(selg, arg1='arg1'):
> "Some doc"
>
> The Yo.__init__.__
David Cournapeau wrote:
> On Wed, Dec 10, 2008 at 5:35 PM, Stefan Behnel wrote:
>>cdef class Yo:
>>"Some doc"
>
> Hm, why should the __init__ method belong to the class string ? Those
> are different, in my mind: the Yo.__doc__ tells about the Yo cl
Hi,
David Cournapeau wrote:
> I would prefer to have at
> least the signature of __init__ (for default arguments)
Cython can embed the signature of a function or method in its docstring.
However, my guess is that this doesn't work for __init__ yet, where it
would have to put it into the respectiv
Robert Bradshaw wrote:
> %cython
>
> cdef foo_c():
> pass
>
> def do_loop_c_call(int n, int m):
> cdef int i, j
> for i in range(n):
> for j in range(m):
> foo_c()
> [...]
> sage: time do_loop_c_call(5000, 500)
> CPU time: 0.00 s, Wall time: 0.00 s
>
> The mora
501 - 600 of 1001 matches
Mail list logo
