suds October 2010

suds@lists.fedoraproject.org

29 participants
34 discussions

Undelivered Mail Returned to Sender
by Mail Delivery System 30 Oct '10

30 Oct '10

This is the mail system at host mx01.topica.com. I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below. For further assistance, please send mail to postmaster. If you do so, please include this problem report. You can delete your own text from the attached returned message. The mail system <ccsam_info_exchange(a)topica.com>: delivery temporarily suspended: connect to topica.com[66.227.60.227]: No route to host

1 0

Timezone aware objects - Revisited
by Daniel Rodriguez 29 Oct '10

29 Oct '10

Dear Jeff et al, I am recovering a topic from the list archive, as I could finally give it a serious test (on Sunday the clocks will change and the server is giving me real answers I can check). The original thread is paste below. After testing with real answers from the server here are my conclusions: - The answers I receive are all in UTC format. Examples from the XML response: - 2010-10-30T14:00:00.000Z (Before clock change on Sunday) - 2010-11-02T19:45:00.000Z (After clock change on Sunday) Given that my timezone is CET (GMT+1 + Daylight Saving Time during the summer), I would expect the following transformations back from suds (the time is the only important part): - 14:00 -> 16:00 (+2 added during parsing, because DST will still apply on Sun, Oct 30th) - 19:45 -> 20:45 (+1 added during parsing, because DST will no longer apply on Tue, Nov 2nd) But unfortunately I receive the following transformation: - 14:00 -> 15:00 (+1 added ...) Wrong answer - 19:45 -> 20:45 (+1 added ...) Right answer The above seems to indicate that suds is finding out the right "offset" for my timezone (+1) but it is not capable of detecting the DST settings (+1 now, +0 next week) After having a look at the suds/sax/date.py module, I think the problem is in the Timezone object. This object is the one responsible parsing the timezone part (offset) and later returning the "adjustment". But it returns a *blind adjustment*, because it returns an offset without taking into account the date, and therefore without taking into account DST. Of course I can compensate for that in my code, but I think the Timezone object could and should handle it. And following my proposal from March, I do also truly believe that objects could be returned being "Timezone aware" by returning them with a "LocalTimezone object". The LocalTimezone class below could be added to the "datetime" generated by suds. The LocalTimezone class was adapted (small changes) from the Python documentation and relies on the information of the underlying operating system. The code is pasted below. Currently I am currently using this code in my own application. A quick cure for suds woul be to include it in suds/sax/date.py and add the following 2 lines at the beginning of DateTime.__adjust: (I even told my system that we were already in November where DST no longer applies): dstDelta = LocalTimezone().dst(self.datetime) self.datetime += dstDelta The rest of the offset calculations can proceed as normal. Code for "LocalTimezone" follows. from datetime import datetime, timedelta, tzinfo class LocalTimezone(tzinfo): ''' System specific local timezone. As seen in the Python docs (with mods) ''' ZERO = timedelta(0) STDOFFSET = timedelta(seconds=-_time.timezone) if _time.daylight: DSTOFFSET = timedelta(seconds=-_time.altzone) else: DSTOFFSET = STDOFFSET DSTDIFF = DSTOFFSET - STDOFFSET def utcoffset(self, dt): ''' Return the offset to UTC (GMT) for the given datetime @param dt: datetime to see offset against @type dt: datetime ''' if self._isdst(dt): return LocalTimezone.DSTOFFSET else: return LocalTimezone.STDOFFSET def dst(self, dt): ''' Return the daylight savings offset for the given datetime @param dt: datetime to see offset against @type dt: datetime ''' if self._isdst(dt): return LocalTimezone.DSTDIFF else: return LocalTimezone.ZERO def tzname(self, dt): ''' Return the name of this timezone for the given datetime @param dt: datetime to see offset against @type dt: datetime ''' return _time.tzname[self._isdst(dt)] def _isdst(self, dt): ''' Private function to find out if the system reports to be in DST mode for the given datetime @param dt: datetime to see offset against @type dt: datetime ''' tt = (dt.year, dt.month, dt.day, dt.hour, dt.minute, dt.second, dt.weekday(), 0, -1) stamp = _time.mktime(tt) tt = _time.localtime(stamp) return tt.tm_isdst > 0 Best regards Daniel ---------------------------------------------------------------------------------------- *Daniel Rodriguez* danjrod at gmail.com <suds%40lists.fedoraproject.org?Subject=Re:%20%5BFedora-suds-list%5D%20Timezone-aware%20Datetime%20objects&In-Reply-To=%3C8ba9089f1003300650yed76596icfb55ae4e283f9c4%40mail.gmail.com%3E> *Tue Mar 30 13:50:08 UTC 2010* - Previous message: [Fedora-suds-list] Timezone-aware Datetime objects<http://lists.fedoraproject.org/pipermail/suds/2010-March/000779.html> - Next message: [Fedora-suds-list] Handling faults from Axis web service<http://lists.fedoraproject.org/pipermail/suds/2010-March/000781.html> - *Messages sorted by:* [ date ]<http://lists.fedoraproject.org/pipermail/suds/2010-March/date.html#780> [ thread ]<http://lists.fedoraproject.org/pipermail/suds/2010-March/thread.html#780> [ subject ]<http://lists.fedoraproject.org/pipermail/suds/2010-March/subject.html#780> [ author ]<http://lists.fedoraproject.org/pipermail/suds/2010-March/author.html#780> - Hi Jeff, Thanks for your answer. I think you followed perfectly by reading your answer. I talk only about received objects. So far I didn't send any. The issue (as I see it) is that the returned datetime is a "naive" object, and we live in a world with timezones, daylight saving schemes. And Python does not mix naive and timezone-aware objects. The options you suggest: a) Returning UTC objects. If there were a generic tz object describing this timezone this would be the best approach. Since coordination of time has to be referenced to UTC and the object could later be used with "astimezone(xxx)" to return objects adapted to the timezone to be displayed to users b) Option in suds to apply a tz object for returned objects. This can be possibly seen as an extension of a), since a general UTC tz object would be replaced by the tz object supplied by the user. But thinking of applications where the user can change the timezone, applying "astimezone(xxx)" would be required again. In my opinion "a" (given the existence of a generic tz object) is the optimal. And talking about a generic UTC tz object, this should be at least definable, since UTC does not have DST settings (UTC is fixed, it is only the countries moving away from it or getting closer to it with DST) Best regards Daniel On Tue, Mar 30, 2010 at 15:00, Jeff Ortel <jortel at redhat.com <https://admin.fedoraproject.org/mailman/listinfo/suds>> wrote: >* Hey Daniel,*>**>* Not sure I follow. Suds converts received xs:datetime to a python datetime*>* object that has been adjusted to the local timezone. When sending a*>* datetime, it is sent with TZ offset. Are you suggesting a suds /option/*>* that would return the xs:datetime in UTC instead of the local TZ? Or, an*>* options for suds to return a datetime object with tz_info set?*>**>* Thanks,*>**>* Jeff*>**>**>* On 03/29/2010 02:52 AM, Daniel Rodriguez wrote:*>**>>* Hi Jeff et al,*>>**>>* I was wondering what you and others think about always returning*>>* timezone-aware datetime objects. The default timezone would be UTC (GMT).*>>**>>* If the user of the library knows that the default timezone for an object*>>* is not UTC he can then use "replace" to change the timezone without*>>* changing the fields.*>>**>>* I personally would see it as positive, since I find terrible to rebuild*>>* a datetime object just to make the conversion from naive to*>>* timezone-aware.*>>**>>* Best regards*>>**>>* Daniel*>>**>>**>>**>>**>>* _______________________________________________*>>* suds mailing list*>>* suds at lists.fedoraproject.org <https://admin.fedoraproject.org/mailman/listinfo/suds>*>>* https://admin.fedoraproject.org/mailman/listinfo/suds*>>**>**>**>* _______________________________________________*>* suds mailing list*>* suds at lists.fedoraproject.org <https://admin.fedoraproject.org/mailman/listinfo/suds>*>* https://admin.fedoraproject.org/mailman/listinfo/suds*>

2 2

suds.client.Client generates a "Bus Error" in MacOS
by Daniel Rodriguez 28 Oct '10

28 Oct '10

Python 2.6.1-2.6.6 In the "clone" function of suds.client.Client. - - cp.update(deepcopy(mp)) which is the moment the unskinned options of the clone are updated with a deepcopy of the unskinned options of the cloned object. I really don't have much experience with MacOS and just tried it because someone wanted to try my application. My guess is that the error is generated due to some sort of infinite recursion, given that if I substitute the "deepcopy" with a "copy", at least the clone doesn't die. (Of course the options are no longer independent but linked, which in my case should be no problem) I wonder if anyone is using suds on Mac as has faced something similar. Best regards

2 4

consumer mailing lists
by Winnie washbasin 27 Oct '10

27 Oct '10

Order this week and save. Take any individual list for $99 or 3 for $249: HEALTHCARE > Doctors (34 different specialties) > Chiropractors > Alternative Medicine > Dentists > Veterinarians > Hospitals > Pharmaceutical Companies > Physical Therapists > Oncology Doctors > US Surgery Centers > Massage Therapists > Acupuncturists > Medical Equipment Suppliers > Mental Health Counselors > Psychologists BUSINESS LISTS > Real Estate Agents > US New Business Database > Financial Planners Database > Finance and Money Professionals Database PROFESSIONALS LISTS > USA Lawyers Database > Criminal Attorneys - 142,906 Send me an email here for samples and stats: maximumresults(a)gmx.us to terminate please send a blank message to purgefile(a)gmx.com

1 0

Unable to modify text in plugin
by Devin Venable 26 Oct '10

26 Oct '10

The plugin documentation and source indicates that the end user will be able to modify the text sent to sending. def sending(self, context): """ Suds will send the specified soap envelope. Provides the plugin with the opportunity to inspect/modify the message text it is sent. @param context: The send context. The I{envelope} is the envelope text. @type context: L{MessageContext} """ pass Setting context.envelope = 'something else' has no effect on the sent string. Is this a bug?

1 0

help needed on suds
by Gajendra PH 25 Oct '10

25 Oct '10

Hi, I am developing simple soap client using suds. I am facing problems in suds, as it is not identifying all attributes of the Methods present in the namespace. This problem is in suds version 0.3.7 and above. But, 0.3.6 is able to retrieve the complete information of the methods but its failing with the following error, Traceback (most recent call last): File "meetingspace_suds.py", line 34, in <module> result = client.service[' MeetingSpaceServiceSoap'].MeetingSpaceRequest(DateRange = dr, propertyKey='10196',eventKey=' ',isExhibit=0,isPostable=0,isBatchInitiated=1,roomGrouping=' ') File "/usr/local/lib/python2.6/dist-packages/suds-0.3.6-py2.6.egg/suds/client.py", line 234, in __getattr__ return self.__dict__[name] KeyError: '__getitem__' Also, see the difference between print of client when used 0.3.7 and 0.3.6 below. The arguments of the methods MeetingSpaceCharacteristicsRequest and MeetingSpaceRequest are different. But correct one is of version 0.3.6. *************************************************************************************************************************** Suds ( https://fedorahosted.org/suds/ ) version: 0.3.7 GA build: R580-20091016 Service ( MeetingSpaceProviderService ) tns=" http://htng.org/PWSWG/2007/01/DigitalSignage" Prefixes (2) ns0 = " http://htng.org/PWSWG/2007/01/DigitalSignage/MeetingSpaceRequest/Types" ns1 = " http://htng.org/PWSWG/2007/01/DigitalSignage/MeetingSpaceResponse/Types" Ports (2): (MeetingSpaceServiceSoap) Methods (2): MeetingSpaceCharacteristicsRequest() MeetingSpaceRequest(ns0:DateRange DateRange, ) Types (6): ns1:EventType ns1:GroupType ns1:MeetingSpaceType ns1:OtherRoomType ns1:PropertyType ns1:SubMeetingSpaceType (MeetingSpaceServiceSoap1) Methods (2): MeetingSpaceCharacteristicsRequest() MeetingSpaceRequest(ns0:DateRange DateRange, ) Types (6): ns1:EventType ns1:GroupType ns1:MeetingSpaceType ns1:OtherRoomType ns1:PropertyType ns1:SubMeetingSpaceType *************************************************************************************************************************** Suds ( https://fedorahosted.org/suds/ ) version: 0.3.6 GA build: R526-20090624 Service ( MeetingSpaceProviderService ) tns=" http://htng.org/PWSWG/2007/01/DigitalSignage" Prefixes (2) ns0 = " http://htng.org/PWSWG/2007/01/DigitalSignage/MeetingSpaceRequest/Types" ns1 = " http://htng.org/PWSWG/2007/01/DigitalSignage/MeetingSpaceResponse/Types" Ports (2): (MeetingSpaceServiceSoap) Methods (2): MeetingSpaceCharacteristicsRequest(xs:string propertyKey, ) MeetingSpaceRequest(ns0:DateRange DateRange, xs:string propertyKey, xs:string eventKey, xs:boolean isExhibit, xs:boolean isPostable, xs:boolean isBatchInitiated, xs:string roomGrouping, ) Types (6): ns1:EventType ns1:GroupType ns1:MeetingSpaceType ns1:OtherRoomType ns1:PropertyType ns1:SubMeetingSpaceType (MeetingSpaceServiceSoap1) Methods (2): MeetingSpaceCharacteristicsRequest(xs:string propertyKey, ) MeetingSpaceRequest(ns0:DateRange DateRange, xs:string propertyKey, xs:string eventKey, xs:boolean isExhibit, xs:boolean isPostable, xs:boolean isBatchInitiated, xs:string roomGrouping, ) Types (6): ns1:EventType ns1:GroupType ns1:MeetingSpaceType ns1:OtherRoomType ns1:PropertyType ns1:SubMeetingSpaceType ************************************************************************************************************************************************************************************************************** Any help on this is appreciated. Thanks, Gajendra

1 0

dvantage. He went into
by Kasprowicz Rakow 24 Oct '10

24 Oct '10

1 0

Will you bet a broad piece?' Then ye mau
by Molleda Meireles 23 Oct '10

23 Oct '10

1 0

[PATCH] Fix recursive import problem
by anatoly techtonik 22 Oct '10

22 Oct '10

Please, take a look at the fix for recursive imports problem. https://fedorahosted.org/suds/ticket/239#comment:17 Thanks. P.S. You may want to update this list coordinates on https://fedorahosted.org/suds/wiki#IRCEmail -- anatoly t.

1 0

wsdl exception: prefix (%s) not resolved
by Paddy O'Loughlin 22 Oct '10

22 Oct '10

Hi, I'm having an issue creating a client from a WSDL file. The wsdl I'm trying to use is at http://api5.silverpop.com/SoapApi?wsdl I'm using suds0.4 and python2.5.2 (though I've also tried it in 2.6 and encountered the same issue). Here's some code that generates the issue in the python repl: from suds.client import Client client = Client("http://api5.silverpop.com/SoapApi?wsdl") This generates the following exception information: Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/home/paddy/imp/lib/python2.5/site-packages/suds/client.py", line 112, in __init__ self.wsdl = reader.open(url) File "/home/paddy/imp/lib/python2.5/site-packages/suds/reader.py", line 152, in open d = self.fn(url, self.options) File "/home/paddy/imp/lib/python2.5/site-packages/suds/wsdl.py", line 158, in __init__ self.resolve() File "/home/paddy/imp/lib/python2.5/site-packages/suds/wsdl.py", line 207, in resolve c.resolve(self) File "/home/paddy/imp/lib/python2.5/site-packages/suds/wsdl.py", line 491, in resolve qref = qualify(op.input, self.root, definitions.tns) File "/home/paddy/imp/lib/python2.5/site-packages/suds/xsd/__init__.py", line 56, in qualify raise Exception('prefix (%s) not resolved' % p) Exception: prefix (sil) not resolved I've tried debugging it a bit using the information on the website, but I'm not familiar enough with the WSDL spec to understand what should be happening. I can see that the part of the wsdl that brings about the exception is: <wsdl:operation name="ForwardToFriend"> <wsdl:input message="sil:ForwardToFriendRequest" xmlns:sil="SilverpopApi:Engageservice"/> <wsdl:output message="sil:ForwardToFriendResponse" xmlns:sil="SilverpopApi:Engageservice"/> </wsdl:operation> It's unable to resolve the prefix "sil". But isn't it specified right in the attribute of the same tag? (xmlns:sil="SilverpopApi:Engageservice") Is there anything I ought to be doing to fix this issue? Regards, Paddy

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

suds October 2010