Lisandro Dalcin wrote:
On Thu, Jul 23, 2009 at 5:42 PM, Terry Reedy wrote:
Lisandro Dalcin wrote:
On Thu, Jul 23, 2009 at 9:57 AM, Jean-Paul Calderone
wrote:
True, CPython has C infrastructure. What about the other Python
runtimes,
though?
Perhaps these other Python runtimes could implemen
On Thu, Jul 23, 2009 at 5:42 PM, Terry Reedy wrote:
> Lisandro Dalcin wrote:
>>
>> On Thu, Jul 23, 2009 at 9:57 AM, Jean-Paul Calderone
>> wrote:
>>
>>> True, CPython has C infrastructure. What about the other Python
>>> runtimes,
>>> though?
>>>
>>
>> Perhaps these other Python runtimes could imp
Lisandro Dalcin wrote:
On Thu, Jul 23, 2009 at 9:57 AM, Jean-Paul Calderone wrote:
True, CPython has C infrastructure. What about the other Python runtimes,
though?
Perhaps these other Python runtimes could implement the functionality
of PC/_subprocess.c and use ctypes for that ?
Is it se
On Thu, Jul 23, 2009 at 9:57 AM, Jean-Paul Calderone wrote:
>
> True, CPython has C infrastructure. What about the other Python runtimes,
> though?
>
Perhaps these other Python runtimes could implement the functionality
of PC/_subprocess.c and use ctypes for that ?
--
Lisandro Dalcín
---
Jean-Paul Calderone schrieb:
> On Thu, 23 Jul 2009 14:21:38 +0200, Christian Heimes wrote:
>>Michael Foord wrote:
>>> A big advantage of using ctypes is that it works cross-implementation -
>>> on IronPython and PyPy already and on Jython soon. I'd like to see more
>>> standard library modules use
On Thu, Jul 23, 2009 at 8:57 AM, Jean-Paul Calderone wrote:
> On Thu, 23 Jul 2009 14:23:56 +0200, Christian Heimes
> wrote:
>>
>> Nick Coghlan wrote:
>>>
>>> I see ctypes as largely useful when you want to call a native DLL but
>>> don't have any existing infrastructure for accessing native code f
On Thu, 23 Jul 2009 14:23:56 +0200, Christian Heimes wrote:
Nick Coghlan wrote:
I see ctypes as largely useful when you want to call a native DLL but
don't have any existing infrastructure for accessing native code from
your project. A few lines of ctypes code is then a much better solution
tha
On Thu, 23 Jul 2009 14:21:38 +0200, Christian Heimes wrote:
Michael Foord wrote:
A big advantage of using ctypes is that it works cross-implementation -
on IronPython and PyPy already and on Jython soon. I'd like to see more
standard library modules use it. Distributions that choose not to
incl
Nick Coghlan wrote:
> I see ctypes as largely useful when you want to call a native DLL but
> don't have any existing infrastructure for accessing native code from
> your project. A few lines of ctypes code is then a much better solution
> than adding a C or C++ compilation dependency just to acces
Michael Foord wrote:
> A big advantage of using ctypes is that it works cross-implementation -
> on IronPython and PyPy already and on Jython soon. I'd like to see more
> standard library modules use it. Distributions that choose not to
> include it are crippling their Python distribution.
Interes
Christian Heimes wrote:
> By the way I don't think that ctypes is the right way to go here. ctypes
> is very handy if you need a quick solution. However I wouldn't use it as
> a permanent solution for the subprocess module. It's tricky to get
> ctypes based solutions right on multiple platforms (32
Amaury Forgeot d'Arc wrote:
Hi,
2009/7/23 Christian Heimes :
Lisandro Dalcin wrote:
Eric seems to be working on a GSoC for PFS related to improving
subprocess. Even in such case this list is not the right place to make
these posts??
Eric didn't say that he is working on a GSoC
Christian Heimes schrieb:
> Can ctypes release the GIL for a function call?
It will do that automatically, except for functions
using the pythonapi callign convention.
--
Thanks,
Thomas
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.py
Hi,
2009/7/23 Christian Heimes :
> Lisandro Dalcin wrote:
>> Eric seems to be working on a GSoC for PFS related to improving
>> subprocess. Even in such case this list is not the right place to make
>> these posts??
>
> Eric didn't say that he is working on a GSoC project for the PSF. Anyway
> the
Lisandro Dalcin wrote:
> Eric seems to be working on a GSoC for PFS related to improving
> subprocess. Even in such case this list is not the right place to make
> these posts??
Eric didn't say that he is working on a GSoC project for the PSF. Anyway
the Python general mailing list might still be
On Wed, Jul 22, 2009 at 12:33 PM, Amaury Forgeot
d'Arc wrote:
>
> These questions should be redirected to comp.lang.python.
>
Eric seems to be working on a GSoC for PFS related to improving
subprocess. Even in such case this list is not the right place to make
these posts??
--
Lisandro Dalcín
Hi,
2009/7/22 Eric Pruitt :
> Hello,
>
> I have written replacements for a few of Mark Hammond's PyWin32 functions
> using ctypes to call upon the Windows kernel API. Code can be found here;
> http://pastebin.com/m46de01f . When calling ReadFile, it appears that the
> kernel API converts '/n' newl
Hello,
I have written replacements for a few of Mark Hammond's PyWin32 functions
using ctypes to call upon the Windows kernel API. Code can be found here;
http://pastebin.com/m46de01f . When calling ReadFile, it appears that the
kernel API converts '/n' newlines '/r/n' newlines. I have not been ab
18 matches
Mail list logo
