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, Jun
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 van Rossum [EMAIL
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 thread
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 were up to me, I'd
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
On Tue, Jun 3, 2008 at 3:48 AM, Georg Brandl [EMAIL PROTECTED] wrote:
Antoine Pitrou schrieb:
Guido van Rossum guido at 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
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 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
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:
* Why can't we have
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 right next to
-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 [EMAIL
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
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 would
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_* names still work
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 exact ABI
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 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 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 not
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
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
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 is
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
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
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 perhaps
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 changes
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 time I
26 matches
Mail list logo