"python -3" not working as expected

[John Machin]

On Jan 10, 2:55 pm, Benjamin <musiccomposit... at gmail.com> wrote:
> On Jan 8, 11:35 pm, John Machin <sjmac... at lexicon.net> wrote:

> > > Actually, don't bother now; I've fixed it up in the trunk.
>
> > Would you mind giving a pointer to where or what your fix is? The
> > reason for asking is that Thorsten's suggestion is ambiguous: warn
> > about some? all? 3.x problems that can't be trivially fixed by 2to3?
> > Can't be "all"; there are in fact a number of problems that can't be
> > trivially fixed by 2to3 and can't be detected by running 2.6 with the
> > -3 option.
>
> I added "and cannot by trivially fixed by 2to3".

That's what I was afraid of. Please consider changing it so that it
does not give the impression that together -3 and 2to3 cover all the
bases.

> Yes, bytes/str is an excellent example of where the third part of the
> porting helpers.

I don't understand that. What is/are "the third part of the porting
helpers"? Are there words missing from the end?


> We'll need good documentation. Unfortunately, as you
> note below, this isn't exactly the case yet.

So is there a plot to remedy this? Where do we sign up?

> > Perhaps some of this info could be put intohttp://docs.python.org/dev/py3k/whatsnew/3.0.html#porting-to-python-3-0
> > ... or maybe a separate HOWTO or wiki chapter could be set up for
> > porting to 3.x, including topics like:
> > (1) maintaining one set of source files (when you are maintaining a
> > package that must run on e.g. 2.1 through 3.x)
> > (2) the possibility of a 3to2 kit for those who have the 2.1 to 3.x
> > support-range issue but would like to have the one set of source
> > looking like 3.x code instead of the ugliness of version-conditional
> > stuff like
> > BYTES_NULL = bytes(0) # 3.x
> > or
> > BYTES_NULL = '' # 2.x
> > and (3) [getting in early] what about a %to{} kit (or a {}to% kit!)?