A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2010-August/103331.html below:

[Python-Dev] PEP 384 status

[Python-Dev] PEP 384 statusBenjamin Peterson benjamin at python.org
Sat Aug 28 15:40:36 CEST 2010
2010/8/28 "Martin v. Löwis" <martin at v.loewis.de>:
> I have now started an initial patch for PEP 384, in the pep-0384 branch.
> This has the following features:
> - modules can be compiled under Py_LIMITED_API
> - Tools/scripts/abitype.py converts C code containing static
>  PyTypeObject definitions to use the new API for type definitions.
>
> The following aspects are still missing:
> - there is no support for generating python3.dll on Windows yet
> - there has been no validation whether the API is actually feasible
>  to use in extension modules.
>
> I started looking into porting the sqlite extension, and ran into
> these issues:
> - certain fields of PyTypeObject are called directly:
>  pysqlite_NodeType.tp_alloc
>  Py_TYPE(self)->tp_free

This is from tp_new and tp_dealloc, right? I think we should probably
provide assessors PyObject_Alloc and PyObject_FreeObject.

> - PyObject_Print is used, but can't be supported, as it uses a FILE*
>  parameter

I thought tp_print was supposed to have been removed. Anyway, if
sqlite is already using FILE *, then won't it be afflicted by the
Microsoft runtime version changes anyway? Maybe provide an extra flag
to enable FILE* APIs for those extensions that want to risk it?


-- 
Regards,
Benjamin
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4