[ftputil] ftputil 2.4 with python 2.6.1

[Peter Stirling]

Hmm, actually I think I need to make some more tests

On 22 Apr 2009, at 12:01 am, Peter Stirling wrote:

> Hi, again,
>
> I'm pretty certain now that the error is in the code of the  
> python-2.6.1
> windows build on the python site, so they need to get a bug report.
>
> I've done some more testing, your pointing out that the lrucache had  
> its
> own tests was quite helpful for making a smaller reproducer.
>
> I attach a script that runs the same test code by using each of the
> versions of heapq that I had available to me (py-2.5, py-2.5 with the
> c-code module disabled, py-2.6, py-2.6-no-c, and the default heapq).
> When it runs on linux I get the exact same results from using each
> method (and the output is correct), but on windows we see the same  
> stack
> traces for each of the tests, you get different answers from each  
> test,
> and none of the different answers are right.
>
> The archive has linux.txt and win32.txt as output from the program  
> on my
> linux and vista machines.
>
>
> On Thu, 2009-04-09 at 07:12 +0200, Stefan Schwarzer wrote:
>> Hello Peter,
>>
>> On 2009-04-09 01:44, Peter Stirling wrote:
>>> After further inspection it appears that the windows python2.6  
>>> install doesn't
>>> include a dll of the compiled heapq module
>>>
>>> 	/usr/lib/python2.5/lib-dynload/_heapq.so, on ubuntu python2.5
>>>
>>> However when I tried to test the pure python version it decided to  
>>> work, so there
>>> must be a bad dll somewhere.
>>>
>>> To test this I made a copy of the pure python heapq.py as  
>>> heapq26.py, and commented
>>> out the code that replaces pure-python with the c versions (line  
>>> 313). I then altered
>>> ftputil/lrucache.py(line 43) to import from this new module, and  
>>> when I run the test
>>> program I no longer get the exception.
>>
>> thanks a lot for your investigation. :o) Please see also my reply
>> to the mailing list.
>>
>>> I am very confused.
>>
>> Why?
>>
>> Stefan
>
> As I said before, there doesn't appear to be a dll for the compiled
> build to live in, but there definitely is SOMETHING interfering.
> Possibly they compiled the code directly into the python.exe file,  
> but I
> haven't seen any reason for that to be the case (and there are  
> external
> dlls that I would have expected to be part of the executable over the
> heapq module, eg ctypes).
>
>
> <test.tbz>_______________________________________________
> ftputil mailing list
> ftputil at codespeak.net
> http://codespeak.net/mailman/listinfo/ftputil