Hi,
I would like to remove the "GIL must be held" restriction from
PyMem_Malloc(). In my opinion, the restriction was motived by a bug in
Python, bug fixed by the issue #3329. Let me explain why.
The PyMem_Malloc() function is a thin wrapper to malloc(). It returns
NULL if the size is lager than
On Thu, 13 Jun 2013 23:39:49 +0200
Christian Heimes wrote:
> Am 13.06.2013 20:59, schrieb Antoine Pitrou:
> > How about
> >
> > return Py_BuildValue("", ofile_env, ofile, odir_env, odir);
> >
> > ?
>
> Oh right, I forgot about 'N'. The PyArg_Parse*() methods don't have it.
>
> Do you w
Am 13.06.2013 20:59, schrieb Antoine Pitrou:
> How about
>
> return Py_BuildValue("", ofile_env, ofile, odir_env, odir);
>
> ?
Oh right, I forgot about 'N'. The PyArg_Parse*() methods don't have it.
Do you want me to modify the code to use Py_BuildValue()?
Christian
___
On Mon, 10 Jun 2013 10:47:28 +0200 (CEST)
christian.heimes wrote:
> http://hg.python.org/cpython/rev/6860263c05b3
> changeset: 84077:6860263c05b3
> user:Christian Heimes
> date:Mon Jun 10 10:47:22 2013 +0200
> summary:
> fixd refleak
>
[...]
> -return Py_BuildValue("(
On Fri, 07 Jun 2013 00:37:01 +0200
Christian Heimes wrote:
>
> I'm also thinking about OCSP support and X509v3 extension support for
> _decode_certificate(). Both are a PITB ... Python has an easier and
> better documented C API.
Yes, OpenSSL's documentation is often a joke, unfortunately.
> Qu
2013/6/13 Nick Coghlan :
> Yes, that sounds better. One of the biggest problems with the current
> startup sequence is the way it relies on environment variables for
> configuration, which makes life hard for other applications that want to
> embed the CPython runtime.
I wrote a new patch (attache
