Guido van Rossum schrieb:
>> When the new buffer protocol is available in 2.6 we can start back
>> porting bytesarray and the new IO framework.
>
> Are these really so closely tied that they have to wait before they
> can be backported?
I've started with the backport of the bytearray type in a
> I think it can actually be simplified. I think maintaining binary
> compatibility between 2.6 and earlier versions is hopeless anyway
ABI-wise or API-wise?
I would surely hope that the 2.6 API is "mostly" compatible with the
2.5 API.
Regards,
Martin
> I haven't been around during the 1.x -> 2.x days. I was still in the
> dark ages (aka PHP user).
:-)
> How do you want me to tackle down the PyString / PyBytes problem?
I think it can actually be simplified. I think maintaining binary
compatibility between 2.6 and earlier versions is hopele
Guido van Rossum schrieb:
> Right. We've done this 2-stage rename before, during the great
> (sometimes known as grand) renaming, in the 1.x days.
I haven't been around during the 1.x -> 2.x days. I was still in the
dark ages (aka PHP user).
How do you want me to tackle down the PyString / PyByte
On Fri, Mar 21, 2008 at 4:41 PM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Guido van Rossum schrieb:
>
> > Even though the more popular PyInt_ APIs are still available (even if
> > only as macros).
>
> THe PyInt_* macros are only available when Include/intobject.h is
> included explicitly. I
Guido van Rossum schrieb:
> Even though the more popular PyInt_ APIs are still available (even if
> only as macros).
THe PyInt_* macros are only available when Include/intobject.h is
included explicitly. It's not in Python.h any more.
> I disagree. Bad merges are already a frequent cause of insta
On 3/16/08, Travis Oliphant <[EMAIL PROTECTED]> wrote:
>
> Guido van Rossum wrote:
> > Moving this to a new subject to keep the discussion of tasks and the
> > discussion of task tracking tools separate.
> >
> > On Sun, Mar 16, 2008 at 9:42 AM, Christian Heimes <[EMAIL PROTECTED]>
> wrote:
> >> I
On Sun, Mar 16, 2008 at 10:17 AM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Collin Winter wrote:
> > The biggest win in terms of performance would be to reimplement the
> > pattern matching engine used by the fixers.: it by far dominates the
> > running time, taking 99+% of the runtime when
On Sun, Mar 16, 2008 at 1:04 PM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > So this doesn't address merges at all. Suppose we have some C code
> > that's shared between 2.6 and 3.0 and manipulates binary data (e.g.
> > the gzip codec). It currently uses PyString o
On Sun, Mar 16, 2008 at 1:01 PM, Benjamin Peterson <
[EMAIL PROTECTED]> wrote:
>
>
> On Sun, Mar 16, 2008 at 12:32 PM, Guido van Rossum <[EMAIL PROTECTED]>
> wrote:
>
> > On Sun, Mar 16, 2008 at 11:57 AM, Benjamin Peterson
> > <[EMAIL PROTECTED]> wrote:
> > [Guido]
> > > > That's a rather long thr
Guido van Rossum wrote:
> So this doesn't address merges at all. Suppose we have some C code
> that's shared between 2.6 and 3.0 and manipulates binary data (e.g.
> the gzip codec). It currently uses PyString on both branches, so any
> changes to the trunk merge smoothly into the py3k branch. But
Guido van Rossum wrote:
> Moving this to a new subject to keep the discussion of tasks and the
> discussion of task tracking tools separate.
>
> On Sun, Mar 16, 2008 at 9:42 AM, Christian Heimes <[EMAIL PROTECTED]> wrote:
>> I did a quick brainstorming with me, myself and I. I came up with a list
On Sun, Mar 16, 2008 at 12:32 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On Sun, Mar 16, 2008 at 11:57 AM, Benjamin Peterson
> <[EMAIL PROTECTED]> wrote:
> [Guido]
> > > That's a rather long thread. Was any conclusion reached? I'm not sure
> > > how introducing a set of aliases will help me
On Sun, Mar 16, 2008 at 11:57 AM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
[Guido]
> > That's a rather long thread. Was any conclusion reached? I'm not sure
> > how introducing a set of aliases will help merging 2.6 code to 3.0.
> > Can you or Christian describe the proposed approach in more de
Collin Winter wrote:
> The biggest win in terms of performance would be to reimplement the
> pattern matching engine used by the fixers.: it by far dominates the
> running time, taking 99+% of the runtime when I ran 2to3 over Twisted,
> for example. The current design is a heavily-recursive system,
Guido van Rossum wrote:
> -1. This will make merging code from 2.6 harder, and causes more work
> for porting C extensions.
I'm happy to pay the price for the sake of a clean and easy-to-recall C
API.
The for the C extension problem I already proposed a solution in the
thread Benjamin mentioned b
>>> * Replace Windows API calls with wide versions to support unicode
>>> for file names, environment etc.
>> +1. This should be broken into separate tasks for each API.
>
> What are we referring to here? Calling the W versions explicitly and
> using wchar_t for everything, or using the TCHAR/TE
On Sun, Mar 16, 2008 at 11:44 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On Sun, Mar 16, 2008 at 11:26 AM, Benjamin Peterson
> <[EMAIL PROTECTED]> wrote:
> > On Sun, Mar 16, 2008 at 10:23 AM, Guido van Rossum <[EMAIL PROTECTED]>
> wrote:
> > > > PyString -> PyBytes ...
> > >
> > > -1. This
On Sun, Mar 16, 2008 at 8:23 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On Sun, Mar 16, 2008 at 9:42 AM, Christian Heimes <[EMAIL PROTECTED]> wrote:
..
> > and add the fixers to 2to3
>
> +1. I think quite a few changes have not had a fixer added. Again, I
> think we should maintain a
On Sun, Mar 16, 2008 at 11:26 AM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
> On Sun, Mar 16, 2008 at 10:23 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > PyString -> PyBytes ...
> >
> > -1. This will make merging code from 2.6 harder, and causes more work
> > for porting C extensions.
>
On Sun, Mar 16, 2008 at 10:23 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Moving this to a new subject to keep the discussion of tasks and the
> discussion of task tracking tools separate.
>
> On Sun, Mar 16, 2008 at 9:42 AM, Christian Heimes <[EMAIL PROTECTED]>
> wrote:
> > I did a quick b
> > * Replace Windows API calls with wide versions to support unicode
> >for file names, environment etc.
>
> +1. This should be broken into separate tasks for each API.
What are we referring to here? Calling the W versions explicitly and using
wchar_t for everything, or using the TCHAR/TEX
Moving this to a new subject to keep the discussion of tasks and the
discussion of task tracking tools separate.
On Sun, Mar 16, 2008 at 9:42 AM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> I did a quick brainstorming with me, myself and I. I came up with a list
> of (IMHO) important tasks.
>
23 matches
Mail list logo
