>>> It also might make it easier for alternate implementations to support
>>> the same API so some modules could work cross implementation - but I
>>> suspect that's a non-goal of this PEP :).
>>>
>>
>> Indeed :-) I'm also skeptical that this would actually allow
>> cross-implementation module
On May 17, 2009, at 4:54 PM, Martin v. Löwis wrote:
Currently, each feature release introduces a new name for the
Python DLL on Windows, and may cause incompatibilities for extension
modules on Unix. This PEP proposes to define a stable set of API
functions which are guaranteed to be available f
Martin v. Löwis wrote:
Dino Viehland wrote:
Dirkjan Ochtman wrote:
It would seem to me that optimizations are likely to require data
structure changes, for exactly the kind of core data structures that
you're talking about locking down. But that's just a high-level view,
I might be wron
Dirkjan Ochtman wrote:
>
> It would seem to me that optimizations are likely to require data
> structure changes, for exactly the kind of core data structures that
> you're talking about locking down. But that's just a high-level view,
> I might be wrong.
>
In particular I would guess that ref co
Dino Viehland wrote:
> Dirkjan Ochtman wrote:
>> It would seem to me that optimizations are likely to require data
>> structure changes, for exactly the kind of core data structures that
>> you're talking about locking down. But that's just a high-level view,
>> I might be wrong.
>>
>
>
> In part
Dirkjan Ochtman wrote:
> On Mon, May 18, 2009 at 12:07 AM, "Martin v. Löwis"
> wrote:
>> I fail to see the relationship, so: no effect that I can see.
>>
>> Why do you think that optimization efforts could be related to
>> the PEP 384 proposal?
>
> It would seem to me that optimizations are like
On Mon, May 18, 2009 at 12:43 AM, Antoine Pitrou wrote:
> Unless I'm misunderstanding something, Martin doesn't advocate locking data
> structures down (except a couple of outliers such as Py_buffer). An
> ABI-compliant application mustn't tinker directly with Python's data
> structures,
> but us
Dirkjan Ochtman ochtman.nl> writes:
>
> It would seem to me that optimizations are likely to require data
> structure changes, for exactly the kind of core data structures that
> you're talking about locking down. But that's just a high-level view,
> I might be wrong.
Unless I'm misunderstanding
>> Header Files and Preprocessor Definitions
>> -
>>
>> Applications shall only include the header file Python.h (before
>> including any system headers), or, optionally, include pyconfig.h, and
>> then Python.h.
>
> What about structmember.h? It's not yet
On Mon, May 18, 2009 at 12:07 AM, "Martin v. Löwis" wrote:
> I fail to see the relationship, so: no effect that I can see.
>
> Why do you think that optimization efforts could be related to
> the PEP 384 proposal?
It would seem to me that optimizations are likely to require data
structure changes
Martin v. Löwis schrieb:
> Header Files and Preprocessor Definitions
> -
>
> Applications shall only include the header file Python.h (before
> including any system headers), or, optionally, include pyconfig.h, and
> then Python.h.
What about structmember.
>> Functions declared in the following header files are not part
>> of the ABI:
>> - cellobject.h
>> - classobject.h
>> - code.h
>> - frameobject.h
>> - funcobject.h
>> - genobject.h
>> - pyarena.h
>> - pydebug.h
>> - symtable.h
>> - token.h
>> - traceback.h
>
> What kind of effect does this have
On Sun, May 17, 2009 at 10:54 PM, "Martin v. Löwis" wrote:
> Excluded Functions
> --
>
> Functions declared in the following header files are not part
> of the ABI:
> - cellobject.h
> - classobject.h
> - code.h
> - frameobject.h
> - funcobject.h
> - genobject.h
> - pyarena.h
> - py
Thomas Wouters reminded me of a long-standing idea; I finally
found the time to write it down.
Please comment!
Regards,
Martin
PEP: 384
Title: Defining a Stable ABI
Version: $Revision: 72754 $
Last-Modified: $Date: 2009-05-17 21:14:52 +0200 (So, 17. Mai 2009) $
Author: Martin v. Löwis
Status: D
> Ned Deily (ND) wrote:
>ND> In article , Piet van Oostrum
>ND> wrote:
>>> > Ronald Oussoren (RO) wrote:
>>> >RO> For what it's worth, the OSX API's seem to behave as follows:
>>> >RO> * If you create a file with an non-UTF8 name on a HFS+ filesystem the
>>> >RO> system automaticly enc
> But, there's an option in Distutils.make_archive to create a tarball
> using the "compress" [1] program rather than gzip or bzip2.
> Using tar -Z, it will pipe it to the compress program if present. This
> program implements the LZW algorithm [2].
As everybody else says: it might be best to just
Antoine Pitrou wrote:
Tarek Ziadé gmail.com> writes:
But I was wondering if we should we add a LZW support in tarinfo,
besides gzip and bzip2 ?
Although this compression standard doesn't seem very used these days,
It would be more useful to add LZMA / xz support.
I don't think compre
Tarek Ziadé gmail.com> writes:
>
> But I was wondering if we should we add a LZW support in tarinfo,
> besides gzip and bzip2 ?
>
> Although this compression standard doesn't seem very used these days,
It would be more useful to add LZMA / xz support.
I don't think compress is used anymore, exc
Alexander Shigin wrote:
В Сбт, 16/05/2009 в 23:15 +0100, MRAB пишет:
FYI, on RISC OS '/' is a valid filename character and '.' is used as
the directory separator.
I'd probably say that TAB is s reasonable character to use, even
though it's OK in POSIX; after all, should anyone really be using a
Hello,
I want to remove the usage of the "tar" command in Distutils in favor
or the "tarfile" module.
But, there's an option in Distutils.make_archive to create a tarball
using the "compress" [1] program rather than gzip or bzip2.
Using tar -Z, it will pipe it to the compress program if present.
20 matches
Mail list logo
