On Wed, Mar 11, 2015 at 8:17 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Wed, 11 Mar 2015 19:05:57 +0100
Antoine Pitrou solip...@pitrou.net 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
On Wed, Mar 11, 2015 at 11:34 PM, Victor Stinner
victor.stin...@gmail.com wrote:
Le 11 mars 2015 18:29, Brett Cannon br...@python.org 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
Le 11 mars 2015 18:29, Brett Cannon br...@python.org 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
On Wed, Mar 11, 2015 at 8:31 PM, Wes Turner wes.tur...@gmail.com wrote:
On Mar 11, 2015 12:55 PM, Maciej Fijalkowski fij...@gmail.com wrote:
On Wed, Mar 11, 2015 at 7:50 PM, Antoine Pitrou solip...@pitrou.net
wrote:
On Wed, 11 Mar 2015 17:27:58 +
Brett Cannon br...@python.org 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 checked before calling into
LoadLibraryEx (
On Wed, Mar 11, 2015 at 8:05 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Wed, 11 Mar 2015 19:54:58 +0200
Maciej Fijalkowski fij...@gmail.com wrote:
Depends what you call dangerous. C code doesn't rot quicker than pure
Python code :-) Also, libffi really offers a wrapper around
On Fri, Mar 6, 2015 at 6:49 PM Benjamin Peterson benja...@python.org
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
On Wed, 11 Mar 2015 19:54:58 +0200
Maciej Fijalkowski fij...@gmail.com 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
On 11 March 2015 at 17:27, Brett Cannon br...@python.org 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
On Wed, Mar 11, 2015 at 7:50 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Wed, 11 Mar 2015 17:27:58 +
Brett Cannon br...@python.org 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
On Wed, 11 Mar 2015 19:05:57 +0100
Antoine Pitrou solip...@pitrou.net 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
[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.
[Armin]
Good
On Mar 11, 2015 12:55 PM, Maciej Fijalkowski fij...@gmail.com wrote:
On Wed, Mar 11, 2015 at 7:50 PM, Antoine Pitrou solip...@pitrou.net
wrote:
On Wed, 11 Mar 2015 17:27:58 +
Brett Cannon br...@python.org wrote:
Did anyone ever step forward to do this? I'm a bit worried about the
On Wed, 11 Mar 2015 17:27:58 +
Brett Cannon br...@python.org 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
On Wed, Mar 11, 2015 at 5:29 PM Armin Rigo ar...@tunes.org wrote:
Hi Brett,
On 6 March 2015 at 19:11, Brett Cannon br...@python.org 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,
On Wed, Mar 11, 2015 at 6:03 PM Paul Moore p.f.mo...@gmail.com wrote:
On 11 March 2015 at 21:45, Maciej Fijalkowski fij...@gmail.com 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
On Wed, 11 Mar 2015 22:20:58 +
Brett Cannon br...@python.org wrote:
You're ignoring that it's not maintained,
According to which metric/criterion?
changeset: 94932:86c9ef950288
user:Steve Dower steve.do...@microsoft.com
date:Tue Mar 10 09:56:38 2015 -0700
summary:
On Thu, Mar 12, 2015 at 12:20 AM, Brett Cannon br...@python.org wrote:
On Wed, Mar 11, 2015 at 6:03 PM Paul Moore p.f.mo...@gmail.com wrote:
On 11 March 2015 at 21:45, Maciej Fijalkowski fij...@gmail.com wrote:
Is it possible to use cffi without a C compiler/headers as easily than
ctypes?
On Thu, Mar 12, 2015 at 12:31 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Wed, 11 Mar 2015 23:10:14 +0200
Maciej Fijalkowski fij...@gmail.com 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
On Wed, 11 Mar 2015 22:55:33 +
Paul Moore p.f.mo...@gmail.com wrote:
On 11 March 2015 at 22:33, Maciej Fijalkowski fij...@gmail.com 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
On 11 March 2015 at 22:33, Maciej Fijalkowski fij...@gmail.com 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.
On Wed, 11 Mar 2015 23:10:14 +0200
Maciej Fijalkowski fij...@gmail.com 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
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't
On Wed, Mar 11, 2015 at 4:37 PM David Cournapeau courn...@gmail.com 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
Hi Tim,
On 10 March 2015 at 18:22, Tim Peters tim.pet...@gmail.com 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
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
26 matches
Mail list logo
