On Mon, Aug 30, 2010 at 7:43 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Mon, 30 Aug 2010 07:31:34 +1000
Nick Coghlan ncogh...@gmail.com wrote:
Since part of the point of
PEP 384 is to support multiple versions of the C runtime in a single
process, [...]
I think that's quite a
Le lundi 30 août 2010 à 22:18 +1000, Nick Coghlan a écrit :
FILE* is very different from the other things you mention. Function
call conventions and binary representations are defined in the C
standard. FILE*, on the other hand, is explicitly called out as an
opaque reference completely
On Aug 30, 2010, at 07:31 AM, Nick Coghlan wrote:
Since part of the point of PEP 384 is to support multiple versions of the C
runtime in a single process
Is it? That's certainly not explicit in the Rationale section of PEP 384.
It seems to me that the PEP is all about inoculating extension
On Aug 30, 2010, at 10:18 PM, Nick Coghlan wrote:
Since the Linkage section of PEP 384 specifically states the
availability of a generic python3.dll that dynamically redirects to
the relevant python3y.dll to allow an extension module to run
against any 3.2 or later Python version as a goal of the
On 30/08/2010 17:35, Barry Warsaw wrote:
On Aug 30, 2010, at 10:18 PM, Nick Coghlan wrote:
Since the Linkage section of PEP 384 specifically states the
availability of a generic python3.dll that dynamically redirects to
the relevant python3y.dll to allow an extension module to run
against any
On Aug 28, 2010, at 01:12 AM, Georg Brandl wrote:
I don't think I'll want to bother with porting doc fixes to the 2.6
branch.
Thanks for the feedback everyone. We will not be porting doc fixes to
release26-maint. I would be open to a doc fix that was specifically
addressing a security concern,
On Aug 28, 2010, at 12:29 PM, Martin v. Löwis wrote:
The intention is that there is indeed just one stable ABI, so one
configuration is the supported one, and that should be the default
build.
As for the specific settings, my analysis would be this:
- pydebug: not supported by the stable ABI, as
Since the recent history of my two Windows buildbots has turned ugly,
I figured I'd mention that they both (XP and Windows 7) have started
generating quite a few GUI C++ RTL runtime pop-up assertions, which
has been throwing a wrench into things until they get manually
cleared. I first noticed
With the help of bbreport, I collected these informations:
- 3 tests are freezing randomly : test_bz2, test_codecs and test_tarfile
- it happens on XP-4 and Windows7 builders (branches 2.7 and 3.1
only, trunk is not affected)
- it seems to happen since revisions 84345 and 84346 which fixed
On Tue, Aug 31, 2010 at 12:30 AM, Barry Warsaw ba...@python.org wrote:
On Aug 30, 2010, at 07:31 AM, Nick Coghlan wrote:
Since part of the point of PEP 384 is to support multiple versions of the C
runtime in a single process
Is it? That's certainly not explicit in the Rationale section of PEP
On Tue, Aug 31, 2010 at 12:47 AM, Michael Foord
fuzzy...@voidspace.org.uk wrote:
An extension compiled for one version of Python will be linked against the
version of the C runtime used by that version of Python (if it is compiled
with the same version of Visual Studio of course).
If the
On Tue, Aug 31, 2010 at 6:54 AM, Nick Coghlan ncogh...@gmail.com wrote:
Hmm... that last point is a bit of any issue actually, since it also
flows the other way (changes made via the locale module won't be
visible to any extension modules using a different C runtime). So I
suspect mixing C
On 31/08/2010 7:54 AM, Nick Coghlan wrote:
On Tue, Aug 31, 2010 at 12:47 AM, Michael Foord
fuzzy...@voidspace.org.uk wrote:
An extension compiled for one version of Python will be linked against the
version of the C runtime used by that version of Python (if it is compiled
with the same
13 matches
Mail list logo
