On Jan 10, 2:55 pm, Benjamin <musiccomposit...@gmail.com> wrote: > On Jan 8, 11:35 pm, John Machin <sjmac...@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!)? -- http://mail.python.org/mailman/listinfo/python-list