[Python-3000] u'text' as an alias for 'text'?

Mike Meyer mwm at mired.org
Mon Mar 24 01:18:32 CET 2008


On Sun, 23 Mar 2008 21:20:11 +0100
"Lennart Regebro" <regebro at gmail.com> wrote:
> On Thu, Mar 20, 2008 at 11:02 PM, Mike Meyer <mwm at mired.org> wrote:
> >  Fair enough. But doesn't 2.5->2.6 present the same problem? After all,
> >  you can't start using 2.6 features until everyone is using it, right?
> No, but you can start using 2.6 before everyone is using it, since 2.6
> is backwards compatible with 2.5. So you write 2.5 code, and run it
> under 2.5 or 2.6. This is not possible with 3.0. You can't write 2.5
> code and run it under 3.0.

I don't think anyone proposed writing 2.5 code to run on 3.0. However,
you can write 2.6 code and run it (after processing by 2to3) on
3.0. Yes, you have to be more careful about things. Yes, you can't use
all of 3.0. But the goal is that is is possible.

It really does appear that, for such a project (and I think two of
mine - python-xlib & plwm - qualify) 2.5->2.6 and 2.6->3.0 aren't that
far apart. You can write code for the old version, and run it (with
suitable preprocessing) on the new version. You can't use features
available in the new version until everyone is off the old version.

The transition will cause projects to do some thinking about what they
support, because doing both 3.0 and versions before 2.6 isn't really
supported (at least, I don't think it is), whereas how far back you
want to go if you're on 2.4 is really a matter of how much you want to
limit yourself.

> >  Given that a simultaneous conversion is unrealistic, you clearly
> >  expect to have some people running on 2.6 while others are running on
> >  2.5.
> Yes I can.

I believe we're in violent agreement here.

> >  Why? Once you've got your web site working on 3.0, what's the point of
> >  keeping the 2.6 web site around? Yes, you need to keep the 2.6 *code*
> >  around, but that's a different issue, dealt with below.
> Yeah, you are right about that point, except for the compilation and
> the fact that you are debugging a different version of the code than
> the one you are writing, which of course is highly confusing,

Um, I hate to tell you this, but the vast majority of programmers
debug a different version of the code than they write, because they
are using a compiled language. They write in a nice character based
language like C, but then debug a binary machine code. Yeah, smart
compilers and debuggers help, by building a mapping from the machine
code back to the character code, and then using it so it looks like
you're debugging the character code.

Which brings up a feature request for 2to3/3.0: the ability to leave
cookies in the 3.0 file that "smart" debuggers can use to help with
debugging code from 2to3? At the very least, each time a line is
changed, the ability to add a comment with the original line and the
file and line number it came from.

> it is
> similar to having 2.5/2.6. The difference is that with 2.5/2.6 you
> develop for one, and then when that works, you make sure it works on
> the other.

Wait a minute here! If you develop for 2.6, how do you make sure it
works for 2.5 unless you've got copies of your web site running on
both 2.5 and 2.6? I thought the prospect of having to maintain two
copies of your web site was a major problem with going to 3.0?

       <mike
-- 
Mike Meyer <mwm at mired.org>		http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.


More information about the Python-3000 mailing list