Christian Heimes wrote:
> Stefan Behnel schrieb:
>> Christian Heimes wrote:
>>> * add a new file stringobject.h which contains the aliases PyString_ ->
>>> PyBytes_
>> Just a quick note that that file is still missing from SVN, so it's kind of
>> hard to compile existing code against the current b
Stefan Behnel schrieb:
> Christian Heimes wrote:
>> * add a new file stringobject.h which contains the aliases PyString_ ->
>> PyBytes_
>
> Just a quick note that that file is still missing from SVN, so it's kind of
> hard to compile existing code against the current branch state...
No, the file
M.-A. Lemburg schrieb:
> I have a feeling that we should be looking for better merge
> tools, rather than implement code changes that cause more trouble
> than do good, just because our existing tools aren't smart
> enough.
We don't have better tools at our hands. I don't think we'll get any
tools
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 such as the renaming
of the PyString APIs to go into the trunk without discussi
Stefan Behnel schrieb:
> will that be included by Python.h by default?
Only in Python 2.6
Christian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options
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 mean
it for real! :]
Last time Guido said:
---
I think it can actually be simplif
