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

[Mike Meyer]

On Thu, 20 Mar 2008 20:51:04 +0100
"Lennart Regebro" <regebro at gmail.com> wrote:
> In many other cases, this is not how code is developed. Both within
> larger organisations and within large communities like Zope and Plone
> (and I suspect the same is true for communities such as Turbogears and
> Django), many people are instead working on the same code base at the
> same time.
> 
> So, there are many people working on the same large set of modules.
> All are using direct svn checkouts, because during development of
> their product/site they need a module and they discover bugs or add
> features to this module. They also have wildly varying experience
> levels and python knowledge.
> 
> Either all of these people and modules need to switch to 3.0 at the
> same time, which is unrealistic

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?
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.

> The 2to3 strategy in that case means that everybody that wants to
> go over to 3.0 needs to have two complete development environments for
> every instance of the software that they need. Basically, for every
> website they develop, they would need one instance that runs under 2.6
> and one under 3.0.

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.  In
particular, what about 3.0 would makes you want to keep a 2.6 version
of the web site that doesn't apply to keeping a 2.5 version of the web
site when the world is split between 2.5 and 2.6 and you're on 2.6?

> This even though most of the code developed only would run under 3.0
> or 2.6, as it's custom for that particular website. The developer
> would then have to check out the 2.6 code in the 2.6 site, change it
> there, and test the change, and then run 2to3 copying over the code
> to the 3.0 instance, and test it there.  Basically, any sort of code
> change, no matter how minor, requires a "change -> test -> copy ->
> 2to3 -> test" dance, instead of the normal "change -> test". This
> doubles the effort of making any change.

Why the insistence on checking it on the 2.6 site? That only makes
sense if you're actually going to have it, and you haven't provided a
reason for doing so.

Sure, you don't want to check in code that breaks someones web site
who's still running on 2.6, but you can't test on their web
site. Hopefully, you have some application-specific tests that you
expect people to run to prevent that from happening, but those by
their very nature are going to be independent of any given users web
site.

And, once you split between 2.6 and 3.0, you'll want to add -3 to the
package tests to minimize breaking things for those on 3.0 when people
who aren't on 3.0 yet check them in.

Given that a more realistic original model is:

change -> application tests -> install? -> web site tests -> checkin

(or maybe you do the two tests in the opposite order.)

then someone on 3.0 with a 2.6/3.0 split would do:

change -> application tests -> install w/2to3 -> web site tests -> checkin

(with only one web site, there's no need to copy to test on the second
one).

> And since testing on the
> web often means testing with some sort of browser (zope.testbrowser
> or Selenium or the like) this means restarting a webserver before
> running the tests. Running tests this was often takes a significant
> time.

True, but it's only worse if you actually keep both versions
around. The package testing should be sufficient for the 2.6 code you
checked in? Nuts, this is better than the 2.5/2.6 split, as you know
the code checked in passed the 2.6 package tests, as you pretty much
said that those running 2.6 won't be running the tests with 2.5.

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