On 2008-06-11 05:42, Gregory P. Smith wrote:
On Mon, Jun 9, 2008 at 1:44 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
On 2008-06-09 07:20, Gregory P. Smith wrote:
On Fri, Jun 6, 2008 at 2:19 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
On 2008-06-03 01:29, Gregory P. Smith wrote:
On Mon,
On Mon, Jun 9, 2008 at 1:44 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> On 2008-06-09 07:20, Gregory P. Smith wrote:
>
>> On Fri, Jun 6, 2008 at 2:19 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
>>
>> On 2008-06-03 01:29, Gregory P. Smith wrote:
>>>
>>> On Mon, Jun 2, 2008 at 4:09 PM, Guido v
On 2008-06-09 07:20, Gregory P. Smith wrote:
On Fri, Jun 6, 2008 at 2:19 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
On 2008-06-03 01:29, Gregory P. Smith wrote:
On Mon, Jun 2, 2008 at 4:09 PM, Guido van Rossum <[EMAIL PROTECTED]>
wrote:
I will freely admit that I haven't followed this thr
On Fri, Jun 6, 2008 at 2:19 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> On 2008-06-03 01:29, Gregory P. Smith wrote:
>
>> On Mon, Jun 2, 2008 at 4:09 PM, Guido van Rossum <[EMAIL PROTECTED]>
>> wrote:
>>
>> I will freely admit that I haven't followed this thread in any detail,
>>> but if it we
On 2008-06-03 01:29, Gregory P. Smith wrote:
On Mon, Jun 2, 2008 at 4:09 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
I will freely admit that I haven't followed this thread in any detail,
but if it were up to me, I'd have the 2.6 internal code use PyString
...
Should we read this as a BD
On 2008-06-03 01:09, Guido van Rossum wrote:
I will freely admit that I haven't followed this thread in any detail,
but if it were up to me, I'd have the 2.6 internal code use PyString
(as both what the linker sees and what the human reads in the source
code) and the 3.0 code use PyBytes for the
On Tue, Jun 3, 2008 at 3:48 AM, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Antoine Pitrou schrieb:
>>
>> Guido van Rossum python.org> writes:
>>>
>>> I'd prefer the 2.6 code base to
>>> stay true to 2.x, and the 3.0 code base start afresh where it makes
>>> sense. We should reindent more of the 3.0
Antoine Pitrou schrieb:
Guido van Rossum python.org> writes:
I'd prefer the 2.6 code base to
stay true to 2.x, and the 3.0 code base start afresh where it makes
sense. We should reindent more of the 3.0 code base to use
4-space-indents in C code too.
Is there any reason reindenting shouldn't
Guido van Rossum python.org> writes:
> I'd prefer the 2.6 code base to
> stay true to 2.x, and the 3.0 code base start afresh where it makes
> sense. We should reindent more of the 3.0 code base to use
> 4-space-indents in C code too.
Is there any reason reindenting shouldn't be done for 2.6 too?
On Mon, Jun 2, 2008 at 4:09 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I will freely admit that I haven't followed this thread in any detail,
> but if it were up to me, I'd have the 2.6 internal code use PyString
...
Should we read this as a BDFL pronouncement and make it so?
All that wo
I will freely admit that I haven't followed this thread in any detail,
but if it were up to me, I'd have the 2.6 internal code use PyString
(as both what the linker sees and what the human reads in the source
code) and the 3.0 code use PyBytes for the same thing. Let the merges
be damed -- most cha
-cc: python-3000
I believe those APIs are already there in the existing interface. Why does
that concern you?
On Mon, Jun 2, 2008 at 9:17 AM, Lisandro Dalcin <[EMAIL PROTECTED]> wrote:
> Are you completelly sure of adding those guys: PyBytes_InternXXX ???
>
>
> On 6/1/08, Gregory P. Smith <[EM
On Mon, Jun 2, 2008 at 5:33 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
>
>> Okay, how about this? http://codereview.appspot.com/1521
>>
>> Using that patch, both PyString_ and PyBytes_ APIs are available using
>> function stubs similar to the above. I opted to define the stub
>> functions righ
Are you completelly sure of adding those guys: PyBytes_InternXXX ???
On 6/1/08, Gregory P. Smith <[EMAIL PROTECTED]> wrote:
> On Fri, May 30, 2008 at 1:37 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> > On 2008-05-30 00:57, Nick Coghlan wrote:
> >>
> >> M.-A. Lemburg wrote:
> >>>
> >>> * W
On 2008-06-02 01:30, Gregory P. Smith wrote:
On Fri, May 30, 2008 at 1:37 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
Sorry, I probably wasn't clear enough:
Why can't we have both PyString *and* PyBytes exposed as C
APIs (ie. visible in code and in the linker) in 2.x, with one redirecting
to t
On Fri, May 30, 2008 at 1:37 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> On 2008-05-30 00:57, Nick Coghlan wrote:
>>
>> M.-A. Lemburg wrote:
>>>
>>> * Why can't we have both PyString *and* PyBytes exposed in 2.x,
>>> with one redirecting to the other ?
>>
>> We do have that - the PyString_* name
On 2008-05-30 00:57, Nick Coghlan wrote:
M.-A. Lemburg wrote:
* Why can't we have both PyString *and* PyBytes exposed in 2.x,
with one redirecting to the other ?
We do have that - the PyString_* names still work perfectly fine in 2.x.
They just won't be used in the Python core codebase anymor
On Thu, May 29, 2008 at 3:57 PM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> M.-A. Lemburg wrote:
>> * Why should the 2.x code base turn to hacks, just because 3.x wants
>> to restructure itself ?
>
> With the better explanation from Greg of what the checked in approach
> achieves (i.e. preserving ex
M.-A. Lemburg wrote:
* Why can't we have both PyString *and* PyBytes exposed in 2.x,
with one redirecting to the other ?
We do have that - the PyString_* names still work perfectly fine in 2.x.
They just won't be used in the Python core codebase anymore - everything
in the Python core will us
Christian,
so far you have not responded to any of the suggestions made on
this thread, only defended your checkin. That's not very helpful
in getting to some conclusion.
* What's so hard about going with a proper, standard solution that
doesn't involve using your preprocessor hack ?
* Why can'
M.-A. Lemburg schrieb:
> Well, first of all, it is a change in the C API:
> APIs have different names now, they live in different files,
> the Python documentation doesn't apply anymore, books have to
> be updated, programmers trained, etc. etc. That's fine for
> 3.x, it's not for 2.x.
No, that's
On 2008-05-28 22:47, Gregory P. Smith wrote:
On Wed, May 28, 2008 at 3:12 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
I'm beginning to wonder whether I'm the only one who cares about
the Python 2.x branch not getting cluttered up with artifacts caused
by a broken forward merge strategy.
How ca
On 2008-05-28 19:08, Bill Janssen wrote:
I'm beginning to wonder whether I'm the only one who cares about
the Python 2.x branch not getting cluttered up with artifacts caused
by a broken forward merge strategy.
I share your concern. Seems to me that perhaps (not sure, but
perhaps) the rush to
On Wed, May 28, 2008 at 3:12 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> I'm beginning to wonder whether I'm the only one who cares about
> the Python 2.x branch not getting cluttered up with artifacts caused
> by a broken forward merge strategy.
>
> How can it be that we allow major C API chang
On Wed, May 28, 2008 at 10:08 AM, Bill Janssen <[EMAIL PROTECTED]> wrote:
>> I'm beginning to wonder whether I'm the only one who cares about
>> the Python 2.x branch not getting cluttered up with artifacts caused
>> by a broken forward merge strategy.
>
> I share your concern. Seems to me that pe
> I'm beginning to wonder whether I'm the only one who cares about
> the Python 2.x branch not getting cluttered up with artifacts caused
> by a broken forward merge strategy.
I share your concern. Seems to me that perhaps (not sure, but
perhaps) the rush to back-port from 3.x, and the concern ab
On 2008-05-28 14:29, Paul Moore wrote:
On 28/05/2008, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
I'm beginning to wonder whether I'm the only one who cares about
the Python 2.x branch not getting cluttered up with artifacts caused
by a broken forward merge strategy.
I care, but I struggle to und
On 28/05/2008, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> I'm beginning to wonder whether I'm the only one who cares about
> the Python 2.x branch not getting cluttered up with artifacts caused
> by a broken forward merge strategy.
I care, but I struggle to understand the implications and/or what
On Sun, May 25, 2008 at 7:59 AM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Hello!
>
> The first set of betas of Python 2.6 and 3.0 is fast apace. I like to
> grab the final chance and clean up the C API of 2.6 and 3.0. I know, I
> know, I brought up the topic two times in the past. But this tim
29 matches
Mail list logo
