On Apr 18, 4:19 pm, Kay Schluehr <[EMAIL PROTECTED]> wrote: > On 18 Apr., 23:09, Matimus <[EMAIL PROTECTED]> 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. -- http://mail.python.org/mailman/listinfo/python-list
