Re: [Cython] Gmane archive
Stefan Behnel, 18.02.2011 05:50: I still didn't get a response from Gmane, but this article doesn't look promising: http://article.gmane.org/gmane.discuss/13987 So I guess we'll have to request a new group. Very unfortunate. They've updated the group subscription. Turns out that changing Gmane group *names* is a problem, not their subscribed e-mail address. And the best place to ask for updates is not via e-mail (as the FAQ suggests), but via the gmane.discuss group. Stefan ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] [cython-users] Cython .pxd introspection: listing defined constants
W. Trevor King, 20.02.2011 00:31: On Sat, Feb 19, 2011 at 02:04:16PM -0800, Robert Bradshaw wrote: On Sat, Feb 19, 2011 at 1:45 PM, W. Trevor King wrote: It is unclear to me what `cdef public struct` means. I think it should mean "Python bindings can alter this struct's definition", which doesn't make sense. I think it should mean "this struct is accessible from Python (as X)" Wouldn't that be "cdef readonly struct X"? The problem here is that "public" is used differently in different contexts - usually "exported at the C level" in this kind of context, with the quirk of meaning "modifiable at the Python level" for cdef class attributes. The potentially clearer "cpdef" means "overridable at the Python level" as well as "visible at the Python level", so it doesn't quite match the second meaning by itself. Structs won't be overridable at the Python level, I guess, so cpdef isn't quite right. The intention here isn't to export them at the C level either, so "public" isn't right. We could tweak the "cpdef" meaning into "cdef thing mapped to the Python level, and overridable if supported in the given context", which would lead to broader applicability. Then we could allow cpdef readonly struct ... I think that's a lot clearer than adding to the double meaning of "public". I would also prefer if Python accessible cdef class attributes were defined using "cpdef". We could potentially make that the preferred way in the future? Stefan ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] [cython-users] Cython .pxd introspection: listing defined constants
W. Trevor King, 20.02.2011 03:32: On Sat, Feb 19, 2011 at 04:41:27PM -0800, Robert Bradshaw wrote: On Sat, Feb 19, 2011 at 3:31 PM, W. Trevor King wrote: I think it's better to keep cdef meaning "backed by C data", not necessarily "written using C syntax", since you're trying to do more with Cython, so it doesn't make sense to force C syntax. It means both. Were I to start over, I would make "cdef int* a, b, c" declare three pointers +100 but we're stuck with the C syntax we have... Sadly, yes. This will be impossible to change in the future without breaking all sorts of code in a hard-to-fix-automatically way. In a struct "cdef" on members is entirely redundant As it is in a cdef class. Not quite. The class body of (cdef) classes can potentially contain code, so it's important for the parser to know what is a declaration and what is an executable statement. Stefan ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Control flow graph
2011/2/16 Vitja Makarov :
> 2011/2/15 Stefan Behnel :
>> Robert Bradshaw, 15.02.2011 08:21:
>>>
>>> On Mon, Feb 14, 2011 at 9:49 PM, Vitja Makarov wrote:
2011/2/15 Robert Bradshaw:
>
> On Sun, Feb 13, 2011 at 11:40 PM, Vitja Makarov wrote:
>>
>> Hi!
>>
>> In order to implement "reaching definitions" algorithm.
>> I'm now working on control-flow (or data-flow) graph.
>>
>> Here is funny picture made with graphviz ;)
>>
>> http://piccy.info/view3/1099337/ca29d7054d09bd0503cefa25f5f49420/1200/
>
> Cool. Any plans on handling exceptions?
Sure, but I don't have much time for this :(
Linear block inside try...except body should be split by assignments
and each subblock should point to exception handling entry point.
>>>
>>> Would every possible failing sub-expression have to point to the
>>> exception handling point(s)?
>>
>> Well, in most cases (especially the interesting ones), this will be the
>> function exit point, so it'll be easy. And in some cases, we may be able to
>> infer that a specific exception that an expression (e.g. arithmetics or a
>> 'raise' statement) can raise will not get caught by a given except clause
>> (although that's certainly a tricky optimisation).
>>
>> But in general, I think any subexpression that potentially raises an
>> exception must point to the next exception handling point.
>>
>>
>>> I suppose it depends on whether you'll be handling more than assignment
>>> tracking.
>>
>> We *may* get away with a statement-level graph in that case, but I somehow
>> doubt it already. For example, list comprehensions leak their variable in
>> Py2 code, so it's important to know if they are executed or not, and they
>> may appear in any kind of expression.
>>
>
> Hmm... both python and codespeaks in the thread
>
> Here is my commit it's mostly broken now but anyway
> https://github.com/vitek/cython/commit/5579b23c3c1c06981331b6427a73e5cb19980b8a
>
>
I've update stuff:
- algo for finding definitions
- warnings for uninitialized and may be uninitialised use
- few test cases
Trying to compile ParseTreeTransforms.py I've found this for example:
warning: Cython/Compiler/ParseTreeTransforms.py:1182:27: Variable
'template' may be used uninitialized
def create_Property(self, entry):
if entry.visibility == 'public':
if entry.type.is_pyobject:
template = self.basic_pyobject_property
else:
template = self.basic_property
elif entry.visibility == 'readonly':
template = self.basic_property_ro
property = template.substitute({
u"ATTR": ExprNodes.AttributeNode(pos=entry.pos,
obj=ExprNodes.NameNode(pos=entry.pos, name="self"),
attribute=entry.name),
}, pos=entry.pos).stats[0]
--
vitja.
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] [cython-users] Cython .pxd introspection: listing defined constants
Robert Bradshaw wrote: BTW, the "public" keyword is the wrong thing to use here, as that actually controls name mangling and (c-level) symbol exporting. The fact that means a different thing for members than for top-level symbols isn't ideal, but at least it's unambiguous as members need not be mangled. The overloading of 'public' is really a bit of a mess. I've been thinking for a while that there really ought to be a different keyword such as "exposed" for declaring that things are to be exposed to Python. It would be useful in lots of ways: cdef class Foo: cdef exposed int i # formerly 'public' cdef exposed enum E: a, b, c # creates Python bindings for these names cdef exposed struct S: # Exposed but mangled as usual ... cdef public exposed struct S: # Exposed and unmangled ... -- Greg ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] [cython-users] Cython .pxd introspection: listing defined constants
Greg Ewing, 20.02.2011 21:13: Robert Bradshaw wrote: BTW, the "public" keyword is the wrong thing to use here, as that actually controls name mangling and (c-level) symbol exporting. The fact that means a different thing for members than for top-level symbols isn't ideal, but at least it's unambiguous as members need not be mangled. The overloading of 'public' is really a bit of a mess. I've been thinking for a while that there really ought to be a different keyword such as "exposed" for declaring that things are to be exposed to Python. It would be useful in lots of ways: cdef class Foo: cdef exposed int i # formerly 'public' cdef exposed enum E: a, b, c # creates Python bindings for these names cdef exposed struct S: # Exposed but mangled as usual ... cdef public exposed struct S: # Exposed and unmangled ... Given that Cython has "cpdef" already, why not just use that? Stefan ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] [cython-users] Cython .pxd introspection: listing defined constants
W. Trevor King wrote: On Sat, Feb 19, 2011 at 04:41:27PM -0800, Robert Bradshaw wrote: On Sat, Feb 19, 2011 at 3:31 PM, W. Trevor King wrote: cython $ grep class Cython/Includes/numpy.pxd ctypedef class numpy.dtype [object PyArray_Descr]: ctypedef extern class numpy.flatiter [object PyArrayIterObject]: ctypedef extern class numpy.broadcast [object PyArrayMultiIterObject]: ctypedef class numpy.ndarray [object PyArrayObject]: ctypedef extern class numpy.ufunc [object PyUFuncObject]: "numpy.dtype" is the fully qualified name of the class it's declaring--the module is "numpy." Aren't the module names in the class declarations redundant here? Since they're in a file called numpy.pxd, declarations will go into the numpy module namespace by default. You should be able to write these as just ctypedef class dtype [object PyArray_Descr]: ctypedef class flatiter [object PyArrayIterObject]: ctypedef class broadcast [object PyArrayMultiIterObject]: ctypedef class ndarray [object PyArrayObject]: ctypedef class ufunc [object PyUFuncObject]: The 'extern' syntax for extension classes, including a module name, is really an obsolete feature. Before Pyrex had .pxd files, it was the only way to declare an externally implemented extension type to Pyrex. But now that .pxd files exist, there should be no need for it. Hmm, that means that cimport numpy a = numpy.numpy.ndarray also compiles. Compiles and runs, or just compiles? If this works as a way of getting hold of the ndarray type, then it's a bug -- it's not supposed to work that way. -- Greg ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] [cython-users] Cython .pxd introspection: listing defined constants
On Mon, Feb 21, 2011 at 10:09:42AM +1300, Greg Ewing wrote: > W. Trevor King wrote: > > Hmm, that means that > > > > cimport numpy > > a = numpy.numpy.ndarray > > > > also compiles. > > Compiles and runs, or just compiles? You're right. Cython compilation worked, but it didn't run: $ export CFLAGS="-I/usr/lib/python2.6/site-packages/numpy/core/include/" $ python -c 'import pyximport; pyximport.install(); import np;' Traceback (most recent call last): ... File "np.pyx", line 3, in init np (/.../np.c:2846) a = numpy.numpy.ndarray ImportError: Building module failed: ['NameError: numpy\n'] Sorry for muddying the waters with that claim. -- This email may be signed or encrypted with GPG (http://www.gnupg.org). The GPG signature (if present) will be attached as 'signature.asc'. For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt pgpl7psMqItPR.pgp Description: PGP signature ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
