Greg Ewing | 1 May 2008 01:08
Picon
Picon
Favicon

Re: [Cython] pxi or pxd for numpy?

Brian Granger wrote:

> Previously, (on this list and at an in person meeting of Sage devs)
> some people were saying that .pxi files should be used for this
> purpose.  Because of these discussions, numpy.pxd was renamed
> numpy.pxi, but now this looks like a bad decision.

Indeed, I would say the opposite. You should almost
*never* use a .pxi file for anything.

The reason is the same reason that "import *" is almost
always a bad idea. When you cimport a name, it's easy
to find out where it came from, but if you get it by
including a .pxi, it can be a lot harder.

The 'include' statement is only present in Pyrex mostly
for historical reasons. If I had invented 'cimport'
earlier, it might never have existed at all.

--

-- 
Greg
William Stein | 1 May 2008 01:15
Picon
Gravatar

Re: [Cython] pxi or pxd for numpy?

On Wed, Apr 30, 2008 at 3:52 PM, Brian Granger
<ellisonbg.net@...> wrote:
> >  What recommendation are you talking about? Using a pxd file
>  >  to provide a namespace is fine as far as I'm concerned.
>  >  It's one of the things they were invented for.
>
>  Previously, (on this list and at an in person meeting of Sage devs)
>  some people were saying that .pxi files should be used for this
>  purpose.  Because of these discussions, numpy.pxd was renamed
>  numpy.pxi, but now this looks like a bad decision.
>

It's me.     I gave them some advice about using pxi versus
pxd files at Sage Days 8, but I did not actually *look* at numpy.pxd
before giving said advice.    Clearly I was wrong.   Sorry for
any confusion caused by my offhand comment.

 -- William
Robert Bradshaw | 1 May 2008 03:17
Favicon

Re: [Cython] __getattribute__

On Apr 29, 2008, at 5:42 PM, Peter Todd wrote:

> Is there a __getattribute__ work-alike in Cython?
>
> Essentially I need direct control over an objects tp_getattro and
> tp_setattro slots to implement a wrapper class. Specificly
> wrapped.__class__ should go to the wrapped objects class attribute,  
> not
> the wrapping objects __class__ attribute.
>
> __getattr__ outputs C-source that includes a call to
> PyObject_GenericGetAttr first, and won't run my code if that call
> succeeds.
>
> Thanks,
>
> Peter

Not that I'm aware of, though I'd imagine that implementing  
__getattribute__ (if it exists) as being called at the top of this  
function would be fairly easy to do. One would want to match Python  
symantics exactly.

- Robert

On Apr 29, 2008, at 5:42 PM, Peter Todd wrote:

> Is there a __getattribute__ work-alike in Cython?
(Continue reading)

Robert Bradshaw | 1 May 2008 03:49
Favicon

Re: [Cython] Porting the Docs

On Apr 30, 2008, at 8:39 AM, Gabriel Gellner wrote:

> So I have finished the first rough mockup, which mainly consists of  
> getting
> the markup correct. There are still some rough edges, mainly with  
> tables, and
> some of the latex output, but in the spirit of release early  
> release often ;-)
>
> Check out the html at:
> http://www.mudskipper.ca/cython-doc
>
> Get the pdf at:
> http://www.mudskipper.ca/cython.pdf
>
> And finally get the source at:
> http://www.mudskipper.ca/cython_doc.tar.gz
> or
> http://www.mudskipper.ca/cython_doc.zip
>
> Again I would appreciate any comments on if I am screwing up  
> authorship. Down
> the road I think it would be good to attribute everything to the  
> 'Cython Doc
> Team' and have a page that lists contributers. To do this we should  
> make the
> license and authorship on the wiki more explicit. Tell me what you  
> think? I am
> no lawyer, and certainly don't want to piss anyone off who has put  
> the hard
(Continue reading)

Peter Todd | 1 May 2008 03:41
Gravatar

Re: [Cython] __getattribute__


On Wed, Apr 30, 2008 at 06:17:31PM -0700, Robert Bradshaw wrote:
> On Apr 29, 2008, at 5:42 PM, Peter Todd wrote:
> 
> >Is there a __getattribute__ work-alike in Cython?
> >
> >Essentially I need direct control over an objects tp_getattro and
> >tp_setattro slots to implement a wrapper class. Specificly
> >wrapped.__class__ should go to the wrapped objects class attribute,  
> >not
> >the wrapping objects __class__ attribute.
> >
> >__getattr__ outputs C-source that includes a call to
> >PyObject_GenericGetAttr first, and won't run my code if that call
> >succeeds.
> >
> >Thanks,
> >
> >Peter
> 
> Not that I'm aware of, though I'd imagine that implementing  
> __getattribute__ (if it exists) as being called at the top of this  
> function would be fairly easy to do. One would want to match Python  
> symantics exactly.

Thanks for the reply.

I've been looking at the Cython source myself, and it looks doable, I'll
put some effort into implementing it. From what I can see I'd be
updating generate_getattro_function() to do a scope.lookup_here() on
(Continue reading)

Robert Bradshaw | 1 May 2008 04:12
Favicon

Re: [Cython] __getattribute__

On Apr 30, 2008, at 6:41 PM, Peter Todd wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Wed, Apr 30, 2008 at 06:17:31PM -0700, Robert Bradshaw wrote:
>> On Apr 29, 2008, at 5:42 PM, Peter Todd wrote:
>>
>>> Is there a __getattribute__ work-alike in Cython?
>>>
>>> Essentially I need direct control over an objects tp_getattro and
>>> tp_setattro slots to implement a wrapper class. Specificly
>>> wrapped.__class__ should go to the wrapped objects class attribute,
>>> not
>>> the wrapping objects __class__ attribute.
>>>
>>> __getattr__ outputs C-source that includes a call to
>>> PyObject_GenericGetAttr first, and won't run my code if that call
>>> succeeds.
>>>
>>> Thanks,
>>>
>>> Peter
>>
>> Not that I'm aware of, though I'd imagine that implementing
>> __getattribute__ (if it exists) as being called at the top of this
>> function would be fairly easy to do. One would want to match Python
>> symantics exactly.
>
> Thanks for the reply.
(Continue reading)

Robert Bradshaw | 1 May 2008 04:16
Favicon

Re: [Cython] a problem with declaring and initializing <type> (*pointer)[N] = NULL

That is really strange, no idea why.

On Apr 30, 2008, at 8:22 AM, Lisandro Dalcin wrote:
> Just pulled from cython-devel repo, this does not work (neither  
> before the pull)
>
> cdef int (*iranges)[3] = NULL
>
> but this indeed work
>
> cdef int (*iranges)[3]
> iranges = NULL
>
>
>
> -- 
> Lisandro Dalcín
> ---------------
> Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
> Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
> Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
> PTLC - Güemes 3450, (3000) Santa Fe, Argentina
> Tel/Fax: +54-(0)342-451.1594
> _______________________________________________
> Cython-dev mailing list
> Cython-dev@...
> http://codespeak.net/mailman/listinfo/cython-dev

Peter Todd | 1 May 2008 05:16
Gravatar

Re: [Cython] __getattribute__

On Wed, Apr 30, 2008 at 07:12:42PM -0700, Robert Bradshaw wrote:
> >From what I can see I'd be
> >updating generate_getattro_function() to do a scope.lookup_here() on
> >'__getattribute__' first, if that succeeds, output code to call it,
> >otherwise go on to the existing code.
> 
> Sounds like a good plan. Is __getattribute__ inherited?

Yes, and when inherited, it overrides __getattr__:

>>> class a(object):
...     def __getattribute__(self,n):
...             print 'a getattribute',n
...             raise AttributeError
... 
>>> class b(a):
...     def __getattr__(self,n):
...             print 'b getattr',n
...             return None
... 
>>> o = b()
>>> print o.asdf
a getattribute asdf
b getattr asdf
None
>>> 

But note that b.__getattr__ is called in the end. If b defines __setattr__, it
is called for any setattr as well. 

(Continue reading)

Robert Bradshaw | 1 May 2008 07:32
Favicon

[Cython] Cython 0.9.6.14 release candidate

Up at http://www.cython.org/Cython-0.9.6.14.tar.gz (or pull from the  
devel branch). If no problems are found, this will be the release. (I  
have already tested Sage).

- Robert

Greg Ewing | 1 May 2008 07:44
Picon
Picon
Favicon

Re: [Cython] __getattribute__

Peter Todd wrote:
> Another question is I noticed that the latest cython-devel code emits
> warnings on usage of __new__, saying to use __cinit__ instead. I take it
> there is planned work to make __new__ more like Python's __new__ and
> have it create the object as well? Again, that's another feature I could
> really use.

That's the idea. I'm not sure exactly what I'm going to
do with __new__ yet, but I want to free up the name so
I can do something better with it later.

--

-- 
Greg

Gmane