On Mar 11, 2015 3:36 PM, "David Cournapeau" wrote:
>
> Hi,
>
> While looking at the import code of python for C extensions, I was
wondering why we pass a relative path instead of an absolute path to
LoadLibraryEx (see bottom for some context).
>
> In python 2.7, the full path existence was even ch
Can we please decouple the ctypes deprecation discussion from efforts to
upgrade cffi? They can coexist just fine, and they don't even really solve
the same problem.
On Wed, Mar 11, 2015 at 3:20 PM, Brett Cannon wrote:
>
>
> On Wed, Mar 11, 2015 at 6:03 PM Paul Moore wrote:
>
>> On 11 March 201
On Wed, 11 Mar 2015 22:55:33 +
Paul Moore wrote:
> On 11 March 2015 at 22:33, Maciej Fijalkowski wrote:
> > You're missing my point. Ripping off the libffi from CPython is a good
> > idea to start with. Maybe deprecating ctypes is *also* a good idea,
> > but it's a separate discussion point.
On Wed, Mar 11, 2015 at 05:34:10PM +, Brett Cannon wrote:
> I have a poll going on G+ to see what people think of the various proposed
> file name formats at
> https://plus.google.com/u/0/+BrettCannon/posts/fZynLNwHWGm . Feel free to
> vote if you have an opinion.
G+ hates my browser and won'
On 11 March 2015 at 22:33, Maciej Fijalkowski wrote:
> You're missing my point. Ripping off the libffi from CPython is a good
> idea to start with. Maybe deprecating ctypes is *also* a good idea,
> but it's a separate discussion point. It certainly does not solve the
> libffi problem.
OK, so let'
On Thu, Mar 12, 2015 at 12:31 AM, Antoine Pitrou wrote:
> On Wed, 11 Mar 2015 23:10:14 +0200
> Maciej Fijalkowski wrote:
>> >
>> > Well, sure. The point is, such bugs are unlikely to appear at a fast
>> > rate... Also, I don't understand why libffi issues would affect cffi
>> > any less than it a
On Thu, Mar 12, 2015 at 12:20 AM, Brett Cannon wrote:
>
>
> On Wed, Mar 11, 2015 at 6:03 PM Paul Moore wrote:
>>
>> On 11 March 2015 at 21:45, Maciej Fijalkowski wrote:
>> >> Is it possible to use cffi without a C compiler/headers as easily than
>> >> ctypes?
>> >
>> > yes, it has two modes, one
On Wed, 11 Mar 2015 23:10:14 +0200
Maciej Fijalkowski wrote:
> >
> > Well, sure. The point is, such bugs are unlikely to appear at a fast
> > rate... Also, I don't understand why libffi issues would affect cffi
> > any less than it affects ctypes, at least in the compiler-less mode of
> > operatio
On Wed, 11 Mar 2015 22:20:58 +
Brett Cannon wrote:
>
> You're ignoring that it's not maintained,
According to which metric/criterion?
changeset: 94932:86c9ef950288
user:Steve Dower
date:Tue Mar 10 09:56:38 2015 -0700
summary: Issue #23606: Disable ctypes.util.find_lib
On Wed, Mar 11, 2015 at 6:03 PM Paul Moore wrote:
> On 11 March 2015 at 21:45, Maciej Fijalkowski wrote:
> >> Is it possible to use cffi without a C compiler/headers as easily than
> >> ctypes?
> >
> > yes, it has two modes, one that does that and the other that does
> > extra safety at the cost
On Wed, Mar 11, 2015 at 5:29 PM Armin Rigo wrote:
> Hi Brett,
>
> On 6 March 2015 at 19:11, Brett Cannon wrote:
> > I disagree with your premise that .pyo files don't have a noticeable
> effect
> > on performance. If you don't use asserts a lot then there is no effect,
> but
> > if you use them
On Wed, Mar 11, 2015 at 4:37 PM David Cournapeau wrote:
> Hi,
>
> While looking at the import code of python for C extensions, I was
> wondering why we pass a relative path instead of an absolute path to
> LoadLibraryEx (see bottom for some context).
>
> In python 2.7, the full path existence was
On 11 March 2015 at 21:45, Maciej Fijalkowski wrote:
>> Is it possible to use cffi without a C compiler/headers as easily than
>> ctypes?
>
> yes, it has two modes, one that does that and the other that does
> extra safety at the cost of a C compiler
So if someone were to propose a practical appr
On Wed, Mar 11, 2015 at 11:34 PM, Victor Stinner
wrote:
>
> Le 11 mars 2015 18:29, "Brett Cannon" a écrit :
>> I'm going to propose a somewhat controversial idea: let's deprecate the
>> ctypes module.
>
> In the past I tried to deprecate many functions or modules because they are
> rarely or neve
Le 11 mars 2015 18:29, "Brett Cannon" a écrit :
> I'm going to propose a somewhat controversial idea: let's deprecate the
ctypes module.
In the past I tried to deprecate many functions or modules because they are
rarely or never used. Many developers prefered to keep them. By the way, I
still wan
On Wed, Mar 11, 2015 at 8:17 PM, Antoine Pitrou wrote:
> On Wed, 11 Mar 2015 19:05:57 +0100
> Antoine Pitrou wrote:
>> > >
>> > > But they are not ctypes. For example, cffi wouldn't be obvious to use
>> > > for interfacing with non-C code, since it requires you to write C-like
>> > > declarations
On Wed, Mar 11, 2015 at 8:31 PM, Wes Turner wrote:
>
> On Mar 11, 2015 12:55 PM, "Maciej Fijalkowski" wrote:
>>
>> On Wed, Mar 11, 2015 at 7:50 PM, Antoine Pitrou
>> wrote:
>> > On Wed, 11 Mar 2015 17:27:58 +
>> > Brett Cannon wrote:
>> >>
>> >> Did anyone ever step forward to do this? I'm
On Wed, Mar 11, 2015 at 8:05 PM, Antoine Pitrou wrote:
> On Wed, 11 Mar 2015 19:54:58 +0200
> Maciej Fijalkowski wrote:
>> >
>> > Depends what you call "dangerous". C code doesn't rot quicker than pure
>> > Python code :-) Also, libffi really offers a wrapper around platform
>> > ABIs, which rare
Hi,
While looking at the import code of python for C extensions, I was
wondering why we pass a relative path instead of an absolute path to
LoadLibraryEx (see bottom for some context).
In python 2.7, the full path existence was even checked before calling into
LoadLibraryEx (
https://github.com/p
[Tim]
>> 1. Merge "2 at a time" instead of just 1. That is, first "sort" the
>> next 2 elements to be merged (1 compare and a possible swap). Then
>> binary search to find where the smaller belongs, and a shorter binary
>> search to find where the larger belongs. Then shift both into place.
[Ar
On Mar 11, 2015 12:55 PM, "Maciej Fijalkowski" wrote:
>
> On Wed, Mar 11, 2015 at 7:50 PM, Antoine Pitrou
wrote:
> > On Wed, 11 Mar 2015 17:27:58 +
> > Brett Cannon wrote:
> >>
> >> Did anyone ever step forward to do this? I'm a bit worried about the
> >> long-term viability of ctypes if we
On Wed, 11 Mar 2015 19:05:57 +0100
Antoine Pitrou wrote:
> > >
> > > But they are not ctypes. For example, cffi wouldn't be obvious to use
> > > for interfacing with non-C code, since it requires you to write C-like
> > > declarations.
> >
> > You mean like Fortran? Or what precisely?
>
> Any to
On Wed, 11 Mar 2015 19:54:58 +0200
Maciej Fijalkowski wrote:
> >
> > Depends what you call "dangerous". C code doesn't rot quicker than pure
> > Python code :-) Also, libffi really offers a wrapper around platform
> > ABIs, which rarely change.
>
> And yet, lesser known ABIs in libffi contain bug
On 11 March 2015 at 17:27, Brett Cannon wrote:
> I'm going to propose a somewhat controversial idea: let's deprecate the
> ctypes module. We now have things like cffi and Cython for people who need
> to interface with C code. Both of those projects are maintained. And they
> are not overly difficu
On Wed, Mar 11, 2015 at 7:50 PM, Antoine Pitrou wrote:
> On Wed, 11 Mar 2015 17:27:58 +
> Brett Cannon wrote:
>>
>> Did anyone ever step forward to do this? I'm a bit worried about the
>> long-term viability of ctypes if we don't have a maintainer or at least
>> someone making sure we are sta
On Wed, 11 Mar 2015 17:27:58 +
Brett Cannon wrote:
>
> Did anyone ever step forward to do this? I'm a bit worried about the
> long-term viability of ctypes if we don't have a maintainer or at least
> someone making sure we are staying up-to-date with upstream libffi. The
> ctypes module is a
On Fri, Mar 6, 2015 at 6:49 PM Benjamin Peterson
wrote:
>
>
> On Fri, Mar 6, 2015, at 15:11, Brett Cannon wrote:
> >
> > OK, but that doesn't influence the PEP's goal of dropping .pyo files.
>
> Correct.
>
> >
> > Are you suggesting that the tag be changed to be less specific to
> > optimizations
On Mon, Dec 22, 2014 at 4:49 PM Jim J. Jewett wrote:
>
>
> On Thu, Dec 18, 2014, at 14:13, Maciej Fijalkowski wrote:
> > ... http://bugs.python.org/issue23085 ...
> > is there any reason any more for libffi being included in CPython?
>
>
> Paul Moore wrote:
> > Probably the easiest way of moving
There are many special names used in Python core and the stdlib, but
absent in the documentation index [1]. If you see names that are defined
or used in the module or area maintained by you, please add references
to these names to the index and document them if it is needed.
Repeat the lists h
Hi Tim,
On 10 March 2015 at 18:22, Tim Peters wrote:
> 1. Merge "2 at a time" instead of just 1. That is, first "sort" the
> next 2 elements to be merged (1 compare and a possible swap). Then
> binary search to find where the smaller belongs, and a shorter binary
> search to find where the larg
30 matches
Mail list logo
