Undelivered Mail Returned to Sender
by Mail Delivery System
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
13 years, 5 months
Timezone aware objects - Revisited
by Daniel Rodriguez
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*>
13 years, 5 months
suds.client.Client generates a "Bus Error" in MacOS
by Daniel Rodriguez
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
13 years, 5 months
consumer mailing lists
by Winnie washbasin
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
13 years, 5 months
Unable to modify text in plugin
by Devin Venable
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?
13 years, 5 months
help needed on suds
by Gajendra PH
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
13 years, 6 months
wsdl exception: prefix (%s) not resolved
by Paddy O'Loughlin
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
13 years, 6 months
