py3k concerns. An example

[Jason Scheirer]

On Apr 18, 4:19 pm, Kay Schluehr <kay.schlu... at gmx.net> wrote:
> On 18 Apr., 23:09, Matimus <mccre... at gmail.com> wrote:
>
> > The reason it doesn't work is that you are unpacking the dictionary
> > with **, and you have done nothing to define any keys or define a
> > length.
>
> This is a non-issue. The class derives from dict; it has all the
> desired attributes. It is also not a problem in particular because
> these properties are not requested by format ( at least not in the
> code I have examined which was admittedly just a critical section that
> caused the exception ).
>
> > Adding to that... don't worry about py3k. Nobody is forcing you to
> > switch. In fact, you are encouraged not to until you are comfortable.
> > Py3k won't _break_ your code. You wrote the code for Python 2.x use it
> > in 2.x. Python 2.x probably has a good 5-10 years remaining.
>
> These advices start to get annoying.
>
> Software hardly ever exists in isolation for the sake of the beauty of
> the algorithm but is supplementary to a large framework/engine/
> library. So if e.g. Django switches to 3 everyone who works with it
> has to switch sooner or later as well or lose track otherwise, no
> matter how long Python 1.5.2 or Python 2.5.2 or whatever version will
> be maintained. If Pythons code base becomes fragmented it will be
> harmful and affect almost everyones work.

This has happened before, though -- I remember the pain of moving to
2.0 from the 1.5 branch way back when, and it wasn't getting my 1.5
code to work in 2.0, it was being jealous of all the cool features of
2.0 that I had to wait to get. I was working in production with 1.5 in
2000 and all the libraries available for Python gradually stopped
supporting 1.5 to pick up interesting 2.0 features that actually made
them easier to work with, and new libraries all began to assume you
were using a 2.0+ Python version because that's what was current. By
2003-2004 everyone I knew had switched over to 2.0, but by then I had
had nearly 5 years to port my legacy 1.5 code to 2.0, take advantage
of the 2.0 version's features, and do plenty of testing of my 1.5
codebase in 2.0 before I switched my production systems over. Not to
mention the fact that plenty of warning was offered BEFORE 2.0 was
released and 1.5 was not abruptly ended, but gradually phased out
until only the teeniest far ends of the long tail were using it. The
2.6->3.0 process is going to be even less of a pain than the 1.5->2.0
conversion, which was not hard at all going forward into it. You may
not want to switch, but by the time you decide to it will be pretty
easy to move on -- the extreme opposite reality being your application
will be so frozen that both your Python version and your codebase will
be fossils, left to hum on completely unchanged on some forgotten
server like so much other legacy code.