[spyne] How keep Python 3 moving forward - suds & Python 3

Jurko Gospodnetić jurko.gospodnetic at pke.hr
Fri May 30 08:02:25 UTC 2014


   Hi Burak.

On 30.5.2014. 8:40, Burak Arslan wrote:
> On 29/05/14 23:45, Jurko Gospodnetić wrote:
> My name's Burak. Arslan is my surname. So call me burak :)

   Oh, woops... :-)

   Btw. tried to look you up on Skype before, but there a ton of 'Burak 
Arslans' there. :-D


>>   They also result in the following two exceptions:
>
> Yeah, Travis thought the tests passed because of the issue you filed
> yesterday. I fixed that and I'll fix the tests asap.

   Hehe, glad to hear that helped. :-D


> As for the following issues you reported, it is mostly because you're
> running things on windows. Actually, you might be the first person ever
> running Spyne test suite on windows.

   Woops again... :-D

   Unfortunately my day-job is mostly Windows related so I do not have a 
Linux based machine easily available. :-( But with or without that, I'd 
really like for suds and its testing/development tools to be OS 
agnostic. :-)


>>   After that I don't think your 'call_pytest_subprocess' tests work
>> quite the way you'd want them, at least not on Windows - whichever one
>> I try to run I get the following error:
>>
>>> Traceback (most recent call last):
>>>[...snipped...]
>>> pickle.PicklingError: Can't pickle <function _ at
>>> 0x0000000003FDCAC8>: it's not found as __main__._
>>
>
> You might know that Windows doesn't have the fork() syscall.
> Multiprocessing relies heavily on fork() to work on unix. You know what
> it does on windows? Starts a new Python process, pickles EVERYTHING,
> sends them to the new process and tries to reconstruct the state in the
> "child" process to simulate a fork.
>
> So to use multiprocessing in a cross platform way, you need to make sure
> EVERYTHING is pickleable. In my book, that's just insane, so I didn't
> bother with windows. If anybody's got a better idea for calling py.test
> from the setup script, I'm open to suggestions.
>
> https://docs.python.org/2/library/multiprocessing.html#windows

   Yup, I know about the forking issues on Windows and I'll try to take 
a closer look and get it working as I get enough free time, this weekend 
if I'm lucky :-). Is it just needed to run external pytest processes? If 
that is so, I guess the same could be achieved using the subprocess module.

   Or perhaps I can just track down the non-picklable parts and see if 
they can be tweaked a bit. The 'unpicklable function' mentioned in the 
traceback smells like it's a simple matter of local vs. module-level 
function usage or something like that.


>>   And the main test suite seems to exit and leave behind a background
>> runner process that exits like this:
>>
>>> Traceback (most recent call last):
>>>[...snipped...]
>>
>>   If you have any ideas, I'd love to get this working. :-D
>
> Well, we need a call_pytest_subprocess that works on windows. Probably
> one that doesn't use multiprocessing.
>
> You can just do py.test test_suds.py though, it should work.

   Ok, I'll run the tests using pytest directly and see how that goes.


>>   Oh, one more test left - the final one, called using the
>> 'call_trial' function:
>>
>> 2. When you do install pywin32 it spurts out lots of debug & info log
>> output which I have no idea what to do with.
>>
>> 3. Among that ton of text the following error message gets repeated a
>> few times which I also have no idea what to do with or whether it even
>> represents a test failure or not:
>>
>>> ERROR:spyne.application:Possible
>>>Traceback (most recent call last):
>>>[...snipped...]
>
> This is output from a test to see how twisted handles unexpected
> exceptions. So this is not an error.
>
>> 4. And similar to 3. the following error appears once:
>>
>>> ERROR:spyne.application:Fault(Plausible: 'A plausible fault')
>>> Traceback (most recent call last):
>>>[...snipped...]
>
> And this is testing how twisted handles "expected" exceptions. So this
> also is not an error.

   Testing all this makes sense, but I'd suggest implementing that test 
run to not display its output so verbosely. Specific test output should 
be displayed to the user only if the test fails and possibly not even 
then for such a general all-encompassing test suite such as the one run 
using 'setup.py test'.


   Best regards,
     Jurko Gospodnetić



More information about the people mailing list