Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #60869

Re: reporting proxy porting problem

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)

Show all headers | View raw


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


Thread

Re: reporting proxy porting problem Robin Becker <robin@reportlab.com> - 2013-12-02 14:42 +0000

csiph-web