Nick Coghlan, 06.08.2013 07:35:
> If you wanted to reboot this thread on import-sig, that would probably
> be a good thing :)
Sigh. Yet another list to know about and temporarily follow...
The import-sig list doesn't seem to be mirrored on Gmane yet. Also, it
claims to be dead w.r.t. Py3.4:
"""
On 6 August 2013 15:02, Stefan Behnel wrote:
> Alternatives I see:
>
> 1) Expose a struct that points to the extension module's PyModuleDef struct
> and the init function and expose that struct instead.
>
> 2) Expose both the PyModuleDef and the init function as public symbols.
>
> 3) Provide a pu
Hi,
let me revive and summarize this old thread.
Stefan Behnel, 08.11.2012 13:47:
> I suspect that this will be put into a proper PEP at some point, but I'd
> like to bring this up for discussion first. This came out of issues 13429
> and 16392.
>
> http://bugs.python.org/issue13429
>
> http://
On 6 August 2013 09:53, Larry Hastings wrote:
> On 08/05/2013 02:55 AM, Nick Coghlan wrote:
> On 5 August 2013 18:48, Larry Hastings wrote:
>
> Question 0: How should we integrate Clinic into the build process?
>
> Isn't solving the bootstrapping problem the reason for checking in the
> clinic-ge
> On Windows, the ``subprocess`` closes all handles and file descriptors
> in the child process by default. If at least one standard stream (stdin,
> stdout or stderr) is replaced (ex: redirected into a pipe), all
> inheritable handles are inherited in the child process.
>
> Summary:
>
> ==
On 06/08/2013 1:23am, Victor Stinner wrote:
Each operating system handles the inheritance of file descriptors
differently. Windows creates non-inheritable file descriptors by
default, whereas UNIX creates inheritable file descriptors by default.
The Windows API creates non-inheritable *handles*
On 06/08/2013 1:23am, Victor Stinner wrote:
Each operating system handles the inheritance of file descriptors
differently. Windows creates non-inheritable file descriptors by
default, whereas UNIX creates inheritable file descriptors by default.
The Windows API creates non-inheritable *handles*
Hi,
My second try (old PEP 446) to change how the inheritance of file
descriptors was somehow rejected. Here is a third try (new PEP 446)
which should include all information of the recent discussions on
python-dev, especially how file descriptors and handles are inherited
on Windows.
I added tab
On 08/05/2013 02:55 AM, Nick Coghlan wrote:
On 5 August 2013 18:48, Larry Hastings wrote:
Question 0: How should we integrate Clinic into the build process?
Isn't solving the bootstrapping problem the reason for checking in the
clinic-generated output? If there's no Python available, we buil
On Sat, Aug 3, 2013 at 3:27 PM, Michael Foord wrote:
> It smells to me like a new feature rather than a bugfix, and it's a
> moderately big change. I don't think it can be backported to 2.7 other than
> through unittest2.
>
Is http://hg.python.org/unittest2 the place to backport to unittest2?
--
Antoine Pitrou, 05.08.2013 21:26:
> On Mon, 05 Aug 2013 21:03:33 +0200
> Stefan Behnel wrote:
>> I think the main problem I have with the PEP is this part:
>>
>> """
>> The PEP doesn't change the semantics of:
>> * C extension types with a custom tp_dealloc function.
>> """
>>
>> Meaning, it was d
On Mon, 05 Aug 2013 21:32:54 +0200
Stefan Behnel wrote:
>
> >> Hmm, it seems to me by now that the only safe way of handling this is to
> >> let each tp_dealloc() level in the hierarchy call tp_finalize() through
> >> PyObject_CallFinalizerFromDealloc(), instead of calling up the stack in
> >> tp
Antoine Pitrou, 05.08.2013 20:56:
> On Sun, 04 Aug 2013 17:59:57 +0200
> Stefan Behnel wrote:
>>> I continued my implementation and found that calling up the base type
>>> hierarchy is essentially the same code as calling up the hierarchy for
>>> tp_dealloc(), so that was easy to adapt to in Cython
On Mon, 05 Aug 2013 21:03:33 +0200
Stefan Behnel wrote:
> I think the main problem I have with the PEP is this part:
>
> """
> The PEP doesn't change the semantics of:
> * C extension types with a custom tp_dealloc function.
> """
>
> Meaning, it was designed to explicitly ignore this use case.
Hi,
I was just continuing in my monologue when you replied, so I'll just drop
my response below.
Antoine Pitrou, 05.08.2013 20:51:
> On Sun, 04 Aug 2013 09:23:41 +0200
> Stefan Behnel wrote:
>> I'm currently catching up on PEP 442, which managed to fly completely below
>> my radar so far. It's a
On Sun, 04 Aug 2013 17:59:57 +0200
Stefan Behnel wrote:
> > I continued my implementation and found that calling up the base type
> > hierarchy is essentially the same code as calling up the hierarchy for
> > tp_dealloc(), so that was easy to adapt to in Cython and is also more
> > efficient than
Hi,
On Sun, 04 Aug 2013 09:23:41 +0200
Stefan Behnel wrote:
>
> I'm currently catching up on PEP 442, which managed to fly completely below
> my radar so far. It's a really helpful change that could end up fixing a
> major usability problem that Cython was suffering from: user provided
> deallo
On Mon, 5 Aug 2013 14:56:06 +0200
Victor Stinner wrote:
> 2013/7/27 Nick Coghlan :
> >> Do we even need a new PEP, or should we just do it? Or can we adapt
> >> Victor's PEP 446?
> >
> > Adapting the PEP sounds good - while I agree with switching to a sane
> > default, I think the daemonisation th
On 8/5/2013 1:48 AM, Larry Hastings wrote:
The impl should know whether or not it failed. So it's the
interface we're defining that forces it to throw away that
information. If we provided a way for it to return that
information, we could shave off some cycles. The problem
is, how do we do th
On 5 August 2013 22:52, Victor Stinner wrote:
> I checked the python-daemon module: it closes all open file
> descriptors except 0, 1, 2. It has a files_preserve attribute to keep
> some FD opens. It redirects stdin, stdout and stderr to /dev/null and
> keep these file descriptors open. If python-
I checked the python-daemon module: it closes all open file
descriptors except 0, 1, 2. It has a files_preserve attribute to keep
some FD opens. It redirects stdin, stdout and stderr to /dev/null and
keep these file descriptors open. If python-daemon is used to execute
a new program, the files_pres
2013/7/27 Nick Coghlan :
>> Do we even need a new PEP, or should we just do it? Or can we adapt
>> Victor's PEP 446?
>
> Adapting the PEP sounds good - while I agree with switching to a sane
> default, I think the daemonisation thread suggests there may need to
> be a supporting API to help force F
On 5 August 2013 18:48, Larry Hastings wrote:
> Question 0: How should we integrate Clinic into the build process?
>
> Clinic presents a catch-22: you want it as part of the build process,
> but it needs Python to be built before it'll run. Currently it
> requires Python 3.3 or newer; it might wo
Hi Larry,
On Mon, Aug 5, 2013 at 10:48 AM, Larry Hastings wrote:
> Question 4: Return converters returning success/failure?
The option generally used elsewhere is: if we throw an exception, we
return some special value; but the special value doesn't necessarily
mean by itself that an exception w
It's time to discuss Argument Clinic again. I think the
implementation is ready for public scrutiny.
(It was actually ready a week ago, but I lost a couple of
days to "make distclean" corrupting my hg data store--yes,
I hadn't upped my local clinic branch in a while. Eventually
I gave up on r
25 matches
Mail list logo
