py3k concerns. An example

[Aaron Watters]

On Apr 24, 10:10 am, Paul McGuire <pt... at austin.rr.com> wrote
> end point applications (I consider maintaining 2 branches to be in the
> "not working" category), but it does NOT WORK for people who maintain
> modules for other people to use, because those people may be on a
> range of Python versions that extend beyond 2.6-3.0.  So if I upgrade
> my module to 2.6, those running on earlier versions can no longer use
> it.  At some point in the future, I'll probably be able to say "no
> more support for pre-2.6", but it is a bit early to start saying that
> now.

In my view using a conversion tool on an ongoing basis is
not an option.  It just adds a dependancy.  What happens when
the conversion tool is upgraded in a non-backwards-compatible
way?  Or do we have assurance that it won't be ;)?

Will changes to the converter
mean that the users of my
converted libraries have to start
using my tools in a different way?  Even if it breaks some
users in a very subtle way it's not acceptible.
I have no interest in adding additional dependancies,
with an additional degree of freedom to break.

This is all made worse because it's binary -- with
upgrades to C or C# you usually had the option of cross
linking between old style components and new style
components (and at least with C these could usually
be made to work) and you could port the older stuff
with care.  With py 3.0 and python 2.6 *everything*
either works with the interpreter or none of it does.
(Don't ask my users to install two interpreters:
they'll just give up and use something else.)

So if I want to support both I have to do everything
twice in the expected case and in the best case test
everything twice, at the same time, if I want to
support both versions and keep features in sync.
This is of course assuming that all the supporting
libraries do the same thing.  If they don't and
one of the libraries doesn't support 2.* and another
doesn't support 3.*... I guess I'm just screwed.

I still think it's a shame, and I think it's
different in kind from python 1.x->2.x. 2.x
broke very little as I recall.  Most 1.x code
just worked in 2.x and most of the rest required
very minor change.  I think this is not the case
for 2.x->3.x.

  -- Aaron (Scummy) Watters, hoping to shut up now.

ps: I didn't notice that % was vanishing later (3.3).
  that's a bit better (whew ;) ).

pps: I have to note that it would be nice if the
  ad-hominem (sp?) invective would drop out of
  these threads -- it doesn't add a lot, I think.

===

http://www.xfeedme.com/nucular/pydistro.py/go?FREETEXT=garbage+left+over