Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #60869
| From | Robin Becker <robin@reportlab.com> |
|---|---|
| Subject | Re: reporting proxy porting problem |
| Date | 2013-12-02 14:42 +0000 |
| References | <5297250A.80709@chamonix.reportlab.co.uk> <l78efk$lv3$1@ger.gmane.org> |
| Newsgroups | comp.lang.python |
| Message-ID | <mailman.3463.1385995385.18130.python-list@python.org> (permalink) |
On 28/11/2013 22:01, Terry Reedy wrote: .............. > > All the transition guides I have seen recommend first updating 2.x code (and its > tests) to work in 2.x with *all* classes being new-style classes. I presume one > of the code checker programs will check this for you. To some extent, the > upgrade can be done by changing one class at a time. > the intent is to produce a compatible code with aid of six.py like functions. > Yes, this means abandoning support of 2.1 ;-). It also means giving up > magical hacks that only work with old-style classes. > >> I find that I don't understand exactly how the original works so well, > > To me, not being comprehensible is not a good sign. I explain some of > the behavior below. The author has commented that he might have been drunk at time of writing :) > >> but here is a cut down version > .. thanks for the analysis, I think we came to the same broad conclusion. I think this particular module may get lost in the wash. If it ever needs re-implementing we can presumably rely on some more general approach as used in the various remote object proxies like pyro or similar. -- Robin Becker
Back to comp.lang.python | Previous | Next | Find similar | Unroll thread
Re: reporting proxy porting problem Robin Becker <robin@reportlab.com> - 2013-12-02 14:42 +0000
csiph-web