gmane.comp.programming.swig.devel

Haoyu Bai | 30 Jul 07:28

GSoC Python 3.0 Support Weekly Status Report #14

Hi,

In last week I finished the Python buffer typemap. After digging into
the Python buffer interface, I found it is hard for SWIG wrapped class
to expose a buffer interface, because SWIG wrapped C++ class as plain
Python object but not a 'type' object implemented in C extension
module - the Python buffer interface hooks can only be implemented in
C extension module! So, SWIG can only provide some buffer typemap,
which can be used as 'consumer' of the protocol.

Then, for function annotation, there's a lot of discussion about
providing an __annotation__ attribute for built-in and C extension
functions: http://bugs.python.org/issue3208
I'd like to work out a patch for it. But now I still thinking about
the feasibility of implementing it.

Finally, I started a Python wiki page by summarizing my experience of
SWIG's Python 3 migration. You can see it here:
http://wiki.python.org/moin/Py3kExtensionModules

Thanks!
--

-- 
Haoyu Bai

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

(Continue reading)

headers

Richard Boulton | 30 Jul 08:47

Re: GSoC Python 3.0 Support Weekly Status Report #14

Haoyu Bai wrote:
> Hi,
> 
> In last week I finished the Python buffer typemap. After digging into
> the Python buffer interface, I found it is hard for SWIG wrapped class
> to expose a buffer interface, because SWIG wrapped C++ class as plain
> Python object but not a 'type' object implemented in C extension
> module - the Python buffer interface hooks can only be implemented in
> C extension module! So, SWIG can only provide some buffer typemap,
> which can be used as 'consumer' of the protocol.

Ah, that makes sense, I think.  It's a low level interface to allow some
kinds of optimisations, as I understand it

> Then, for function annotation, there's a lot of discussion about
> providing an __annotation__ attribute for built-in and C extension
> functions: http://bugs.python.org/issue3208
> I'd like to work out a patch for it. But now I still thinking about
> the feasibility of implementing it.

It sounds to me like it will be hard to implement if the annotations are
allowed to be a PyObject (implementing an interpreter-local registry for
annotations sounds likean overkill), but it would be easy to implement
if they were stored as a plain "const char *" (as a justification for
this, the current ml_doc attribute is a const char *, and I don't think
non-string values are expected in attributes, although they're not
explicitly outlawed.  I could be wrong, though.  It might be worth
posting to python-3000 about this, to ask if it's reasonable to restrict
attribute values to strings).  I tried to comment on the issue in the
python tracker, but it's not accepting my login for some reason at

(Continue reading)

headers

Amaury Forgeot d'Arc | 30 Jul 11:51

Re: GSoC Python 3.0 Support Weekly Status Report #14

Hello,

Richard Boulton wrote:
> It sounds to me like it will be hard to implement if the annotations are
> allowed to be a PyObject (implementing an interpreter-local registry for
> annotations sounds likean overkill),

IMO, it does not have to be interpreter-local. A global static
registry could be enough.

> but it would be easy to implement
> if they were stored as a plain "const char *" (as a justification for
> this, the current ml_doc attribute is a const char *, and I don't think
> non-string values are expected in attributes, although they're not
> explicitly outlawed.  I could be wrong, though.  It might be worth
> posting to python-3000 about this, to ask if it's reasonable to restrict
> attribute values to strings).

On the contrary, it is expected that attributes could be types,
or some kind of validator object.

In the python 3.0 library itself, in io.py:
    def readline(self, limit: int = -1) -> bytes:

Cheers,

--

-- 
Amaury Forgeot d'Arc

-------------------------------------------------------------------------

(Continue reading)

headers

Richard Boulton | 30 Jul 13:07

Re: GSoC Python 3.0 Support Weekly Status Report #14

Amaury Forgeot d'Arc wrote:
> Hello,
> 
> Richard Boulton wrote:
>> It sounds to me like it will be hard to implement if the annotations are
>> allowed to be a PyObject (implementing an interpreter-local registry for
>> annotations sounds likean overkill),
> 
> IMO, it does not have to be interpreter-local. A global static
> registry could be enough.

I don't know enough about the what it is safe to share between multiple 
python interpreters to be sure, but it seemed unlikely that it would be 
safe to share an arbitrary PyObject between interpreters.  I could be 
wrong, though.  I've got my python bug tracker account working now, so 
I'll comment further there.

>> but it would be easy to implement
>> if they were stored as a plain "const char *" (as a justification for
>> this, the current ml_doc attribute is a const char *, and I don't think
>> non-string values are expected in attributes, although they're not
>> explicitly outlawed.  I could be wrong, though.  It might be worth
>> posting to python-3000 about this, to ask if it's reasonable to restrict
>> attribute values to strings).
> 
> On the contrary, it is expected that attributes could be types,
> or some kind of validator object.
> 
> In the python 3.0 library itself, in io.py:
>     def readline(self, limit: int = -1) -> bytes:

(Continue reading)