Python 2.4.2 gcc 3.4.4 Solaris 8 build issues
Hi, I encountered some build issues when compiling Python 2.4.4 on a Solaris 8 box using gcc 3.4.4: 1. Running configure detects that a C++-built main needs C++-linking. Therefore, Python gets linked with g++, creating a dependency on libstdc++. Some research showed up a rather elaborate discussion in the python-dev/c++-sig-archives, ending up in a patch that replaces the --with-cxx option with a --with-cxx-main switch and tries to set CXX to some sensible value in the generated Makefile even if Python gets built C-only. (SF #1324762 Compiling and linking main() with C++ compiler, by Christoph Ludwig; pending) Now, I am still not 100 % sure about what I need to do. I need C++-extensions, but I do not want to link anything statically with Python, i.e. everything will be dynamically imported extension modules. I *think* I can build Python C-only, avoiding possible runtime problems with C++-extensions that might have been built with different C++ compilers. Can anyony clear that up? 2. We have some stuff in non-standard locations here. To build properly, I need to tell this to configure (using CXX, CPPFLAGS, LD_LIBRARY_PATH). Unfortunately, none of this gets communicated to the setup.py step with its find_library_file() stuff, so it is also necessary to either modify setup.py or add a setup.cfg file. Is there some better way to do that? (Probably the Makefile template could be changed to supply setup.py with some appropriate command line options for build_ext, but I do not know the autotools stuff. Any recommendations for some good tutorial?) 3. The test_locale test fails: ./python Lib/test/test_locale.py '%f' % 1024 =? '1,024.00' ... no '%f' % 1024 == '1024.00' != '1,024.00' '%f' % 102 =? '102.00' ... yes '%f' % -42 =? '-42.00' ... yes '%+f' % -42 =? '-42.00' ... yes '%20.f' % -42 =? ' -42' ... yes '%+10.f' % -4200 =? '-4,200' ... no '%+10.f' % -4200 == '-4200' != '-4,200' '%-10.f' % 4200 =? '4,200 ' ... no '%-10.f' % 4200 == '4200 ' != '4,200 ' ' '.isspace() =? True ... yes '\xa0'.isspace() =? False ... no '\xa0'.isspace() == True != False '\xa1'.isspace() =? False ... yes '\xc0'.isalpha() =? False ... no '\xc0'.isalpha() == True != False '\xc0'.isalnum() =? False ... no '\xc0'.isalnum() == True != False '\xc0'.isupper() =? False ... no '\xc0'.isupper() == True != False '\xc0'.islower() =? False ... yes '\xec\xa0\xbc'.split() =? ['\xec\xa0\xbc'] ... no '\xec\xa0\xbc'.split() == ['\xec', '\xbc'] != ['\xec\xa0\xbc'] '\xed\x95\xa0'.strip() =? '\xed\x95\xa0' ... no '\xed\x95\xa0'.strip() == '\xed\x95' != '\xed\x95\xa0' '\xcc\x85'.lower() =? '\xcc\x85' ... no '\xcc\x85'.lower() == '\xec\x85' != '\xcc\x85' '\xed\x95\xa0'.upper() =? '\xed\x95\xa0' ... no '\xed\x95\xa0'.upper() == '\xcd\x95\xa0' != '\xed\x95\xa0' ?? Is this a known problem on Solaris? Thanks in advance for any hints, Holger Der Inhalt dieser E-Mail ist vertraulich. Falls Sie nicht der angegebene Empfänger sind oder falls diese E-Mail irrtümlich an Sie adressiert wurde, verständigen Sie bitte den Absender sofort und löschen Sie die E-Mail sodann. Das unerlaubte Kopieren sowie die unbefugte Übermittlung sind nicht gestattet. Die Sicherheit von Übermittlungen per E-Mail kann nicht garantiert werden. Falls Sie eine Bestätigung wünschen, fordern Sie bitte den Inhalt der E-Mail als Hardcopy an. The contents of this e-mail are confidential. If you are not the named addressee or if this transmission has been addressed to you in error, please notify the sender immediately and then delete this e-mail. Any unauthorized copying and transmission is forbidden. E-Mail transmission cannot be guaranteed to be secure. If verification is required, please request a hard copy version. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 2.4.2 gcc 3.4.4 Solaris 8 build issues [solved]
>Martin v. Löwis wrote: > >> 2. We have some stuff in non-standard locations here. To build >> properly, I need to tell this to configure (using CXX, CPPFLAGS, >> LD_LIBRARY_PATH). Unfortunately, none of this > gets communicated to >> the setup.py step with its find_library_file() stuff, so it is also >> necessary to either modify setup.py or add a setup.cfg file. >Why do you say that? If you set CC before invoking configure, >it will get into Makefile, and from there into setup.py. >More generally: setup.py will take everything from Makefile, >so just check whether Makefile looks right. Hmm, I just got it wrong. I did not see that settings like LDFLAGS are noticed by distutils. After quite some tries I can now happily build with - LD_LIBRARY_PATH set (needed to find libstdc++ during configure step) - LDFLAGS set to find the lib dirs - CPPFLAGS set to find the include dirs Then distutils adds the appropriate -Wl,-R stuff; I don´t even need LD_RUN_PATH. Before, I seem to always have left out LDFLAGS. >As for LD_LIBRARY_PATH: If it is set when setup.py is running, >it will certainly apply. However, I really recommend to use >crle(8) instead: > > crle -u -l /opt/sfw/lib > >Then, your users will never have to set LD_LIBRARY_PATH >for /opt/sfw/lib. Nice. I didn´t even know that feature. Reminds me of the possibilty to use relative RPATHs with $ORIGIN, which is (also) little under-documented. But then again I´m no compiler wizard. >> Der Inhalt dieser E-Mail ist vertraulich. >So ein Quatsch. Selbst Google hat jetzt eine Kopie dieser Mail: Wie wahr. Schon mal gegen Windmühlen gekämpft? ;-) Thanks a lot, Holger Der Inhalt dieser E-Mail ist vertraulich. Falls Sie nicht der angegebene Empfänger sind oder falls diese E-Mail irrtümlich an Sie adressiert wurde, verständigen Sie bitte den Absender sofort und löschen Sie die E-Mail sodann. Das unerlaubte Kopieren sowie die unbefugte Übermittlung sind nicht gestattet. Die Sicherheit von Übermittlungen per E-Mail kann nicht garantiert werden. Falls Sie eine Bestätigung wünschen, fordern Sie bitte den Inhalt der E-Mail als Hardcopy an. The contents of this e-mail are confidential. If you are not the named addressee or if this transmission has been addressed to you in error, please notify the sender immediately and then delete this e-mail. Any unauthorized copying and transmission is forbidden. E-Mail transmission cannot be guaranteed to be secure. If verification is required, please request a hard copy version. -- http://mail.python.org/mailman/listinfo/python-list
call of __del__ non-deterministic in python 2.4 (cpython)?
Hi all, I've recently run into a problem that I haven't seen with python 1.5.2 and python 2.3. It seems that under certain conditions __del__ does not get immediately called when a local variable goes out of scope. I ended up with deadlocks in a threaded application because a locked section was supposed to be entered from within __del__ but apparently the same thread (the main thread, in that case) was already holding that lock. The result looked really strange with the main thread entering the locked section and then suddenly the delayed call of __del__ taking control, also wanting to acquire the lock but never being able to. Unfortunately I fail to put together a minimal example. Anyway: Is relying on __del__ getting called immediately when the refcount drops to 0 a no-no? If so should that maybe be prominently stated in the docs? Cheers, Holger Der Inhalt dieser E-Mail ist vertraulich. Falls Sie nicht der angegebene Empfänger sind oder falls diese E-Mail irrtümlich an Sie adressiert wurde, verständigen Sie bitte den Absender sofort und löschen Sie die E-Mail sodann. Das unerlaubte Kopieren sowie die unbefugte Übermittlung sind nicht gestattet. Die Sicherheit von Übermittlungen per E-Mail kann nicht garantiert werden. Falls Sie eine Bestätigung wünschen, fordern Sie bitte den Inhalt der E-Mail als Hardcopy an. The contents of this e-mail are confidential. If you are not the named addressee or if this transmission has been addressed to you in error, please notify the sender immediately and then delete this e-mail. Any unauthorized copying and transmission is forbidden. E-Mail transmission cannot be guaranteed to be secure. If verification is required, please request a hard copy version. -- http://mail.python.org/mailman/listinfo/python-list
[unicode] inconvenient unicode conversion of non-string arguments
Hi there, I consider the behaviour of unicode() inconvenient wrt to conversion of non-string arguments. While you can do: >>> unicode(17.3) u'17.3' you cannot do: >>> unicode(17.3, 'ISO-8859-1', 'replace') Traceback (most recent call last): File "", line 1, in ? TypeError: coercing to Unicode: need string or buffer, float found >>> This is somehow annoying when you want to convert a mixed-type argument list to unicode strings, e.g. for a logging system (that's where it bit me) and want to make sure that possible raw string arguments are also converted to unicode without errors (although by force). Especially as this is a performance-critical part in my application so I really do not like to wrap unicode() into some custom tounicode() function that handles such cases by distinction of argument types. Any reason why unicode() with a non-string argument should not allow the encoding and errors arguments? Or some good solution to work around my problem? (Currently running on python 2.4.3) Regards, Holger Der Inhalt dieser E-Mail ist vertraulich. Falls Sie nicht der angegebene Empfänger sind oder falls diese E-Mail irrtümlich an Sie adressiert wurde, verständigen Sie bitte den Absender sofort und löschen Sie die E-Mail sodann. Das unerlaubte Kopieren sowie die unbefugte Übermittlung sind nicht gestattet. Die Sicherheit von Übermittlungen per E-Mail kann nicht garantiert werden. Falls Sie eine Bestätigung wünschen, fordern Sie bitte den Inhalt der E-Mail als Hardcopy an. The contents of this e-mail are confidential. If you are not the named addressee or if this transmission has been addressed to you in error, please notify the sender immediately and then delete this e-mail. Any unauthorized copying and transmission is forbidden. E-Mail transmission cannot be guaranteed to be secure. If verification is required, please request a hard copy version. -- http://mail.python.org/mailman/listinfo/python-list
Re: Re: inconvenient unicode conversion of non-string arguments
[EMAIL PROTECTED] schrieb am 13.12.2006 11:02:30: > > Holger Joukl wrote: > > Hi there, > > > > I consider the behaviour of unicode() inconvenient wrt to conversion of > > non-string > > arguments. > > While you can do: > > > > >>> unicode(17.3) > > u'17.3' > > > > you cannot do: > > > > >>> unicode(17.3, 'ISO-8859-1', 'replace') > > Traceback (most recent call last): > > File "", line 1, in ? > > TypeError: coercing to Unicode: need string or buffer, float found > > >>> > > [...] > > Any reason why unicode() with a non-string argument should not allow the > > encoding and errors arguments? > > There is reason: encoding is a property of bytes, it is not applicable > to other objects. Ok, but I still don't see why these arguments shouldn't simply be silently ignored for non-string arguments. > > Or some good solution to work around my problem? > > Do not put undecoded bytes in a mixed-type argument list. A rule of > thumb working with unicode: decode as soon as possible, encode as late > as possible. It's not always that easy when you deal with a tree data structure with the tree elements containing different data types and your user may decide to output root.element.subelement.whateverData. I have the problems in a logging mechanism, and it would vanish if unicode(, encoding, errors) would work and just ignore the obsolete arguments. Best regards, Holger Der Inhalt dieser E-Mail ist vertraulich. Falls Sie nicht der angegebene Empfänger sind oder falls diese E-Mail irrtümlich an Sie adressiert wurde, verständigen Sie bitte den Absender sofort und löschen Sie die E-Mail sodann. Das unerlaubte Kopieren sowie die unbefugte Übermittlung sind nicht gestattet. Die Sicherheit von Übermittlungen per E-Mail kann nicht garantiert werden. Falls Sie eine Bestätigung wünschen, fordern Sie bitte den Inhalt der E-Mail als Hardcopy an. The contents of this e-mail are confidential. If you are not the named addressee or if this transmission has been addressed to you in error, please notify the sender immediately and then delete this e-mail. Any unauthorized copying and transmission is forbidden. E-Mail transmission cannot be guaranteed to be secure. If verification is required, please request a hard copy version. -- http://mail.python.org/mailman/listinfo/python-list
Re: Re: call of __del__ non-deterministic in python 2.4 (cpython)?
[EMAIL PROTECTED] schrieb am 13.12.2006 11:09:13: > Holger Joukl wrote: > > > Anyway: Is relying on __del__ getting called immediately when the refcount > > drops to 0 a no-no? > > yes, but more importantly, relying on the refcount dropping to 0 when > something goes out of scope is a major no-no. In my particular use case I think can rule out the problematic situations, except for the object being referenced in the stack trace, but that won't put me into problems (and there were no exceptions at all when I ran into the deadlocks) > > If so should that maybe be prominently stated in the docs? > > is it perhaps the color that made you miss the big bold boxes in the > documentation? > > http://docs.python.org/ref/customization.html#l2h-177 > > I did read this but didn't think it applied to my situation. I'm quite sure that the refcount of the local variable is 1 before the local scope is left. So let me rephrase the question: Even if I can make sure that non of the problematic situtions apply, might it _still_ happen that __del__ gets called after some other code has already been "entered"? Thanks, Holger Der Inhalt dieser E-Mail ist vertraulich. Falls Sie nicht der angegebene Empfänger sind oder falls diese E-Mail irrtümlich an Sie adressiert wurde, verständigen Sie bitte den Absender sofort und löschen Sie die E-Mail sodann. Das unerlaubte Kopieren sowie die unbefugte Übermittlung sind nicht gestattet. Die Sicherheit von Übermittlungen per E-Mail kann nicht garantiert werden. Falls Sie eine Bestätigung wünschen, fordern Sie bitte den Inhalt der E-Mail als Hardcopy an. The contents of this e-mail are confidential. If you are not the named addressee or if this transmission has been addressed to you in error, please notify the sender immediately and then delete this e-mail. Any unauthorized copying and transmission is forbidden. E-Mail transmission cannot be guaranteed to be secure. If verification is required, please request a hard copy version. -- http://mail.python.org/mailman/listinfo/python-list
Re: Re: inconvenient unicode conversion of non-string arguments
[EMAIL PROTECTED] schrieb am 13.12.2006 11:37:03: > Holger Joukl wrote: > > > Ok, but I still don't see why these arguments shouldn't simply be silently > > ignored > > >>> import this > > > You probably refer to "Explicit is better than implicit.". In that particular case I still think it wouldn't hurt to allow the encoding/errors arguments to keep the unicode() signature consistent for all types of the first argument. I'd go with "Although practicality beats purity." ;-) Holger (But maybe I'm not aware of tricky-implementation issues...) Der Inhalt dieser E-Mail ist vertraulich. Falls Sie nicht der angegebene Empfänger sind oder falls diese E-Mail irrtümlich an Sie adressiert wurde, verständigen Sie bitte den Absender sofort und löschen Sie die E-Mail sodann. Das unerlaubte Kopieren sowie die unbefugte Übermittlung sind nicht gestattet. Die Sicherheit von Übermittlungen per E-Mail kann nicht garantiert werden. Falls Sie eine Bestätigung wünschen, fordern Sie bitte den Inhalt der E-Mail als Hardcopy an. The contents of this e-mail are confidential. If you are not the named addressee or if this transmission has been addressed to you in error, please notify the sender immediately and then delete this e-mail. Any unauthorized copying and transmission is forbidden. E-Mail transmission cannot be guaranteed to be secure. If verification is required, please request a hard copy version. -- http://mail.python.org/mailman/listinfo/python-list
Re: Re: inconvenient unicode conversion of non-string arguments
[EMAIL PROTECTED] schrieb am 13.12.2006 12:05:33: > Holger Joukl wrote: > > >>> Ok, but I still don't see why these arguments shouldn't simply be > >>> silently ignored > >> > >> >>> import this > > > > You probably refer to "Explicit is better than implicit.". > > "Errors should never pass silently." is a better match, I think. you're > trying to do an invalid operation. python tells you to fix your code. > > I'm not doing an invalid operation with unicode(17.3) What's invalid about unicode(17.3, "latin-1", "replace")? IMHO the encoding/errors args can only ever apply for string arguments so this could well fall back to unicode(17.3). Might be I'm overlooking something grave, but I'm still not convinced. But thanks for your advice, Holger Der Inhalt dieser E-Mail ist vertraulich. Falls Sie nicht der angegebene Empfänger sind oder falls diese E-Mail irrtümlich an Sie adressiert wurde, verständigen Sie bitte den Absender sofort und löschen Sie die E-Mail sodann. Das unerlaubte Kopieren sowie die unbefugte Übermittlung sind nicht gestattet. Die Sicherheit von Übermittlungen per E-Mail kann nicht garantiert werden. Falls Sie eine Bestätigung wünschen, fordern Sie bitte den Inhalt der E-Mail als Hardcopy an. The contents of this e-mail are confidential. If you are not the named addressee or if this transmission has been addressed to you in error, please notify the sender immediately and then delete this e-mail. Any unauthorized copying and transmission is forbidden. E-Mail transmission cannot be guaranteed to be secure. If verification is required, please request a hard copy version. -- http://mail.python.org/mailman/listinfo/python-list
Re: Stupid email disclaimers (was: [unicode] inconvenient unicodeconversion of non-string arguments)
[EMAIL PROTECTED] schrieb am 13.12.2006 23:10:38: > [...] > In all likelihood, the OP isn't choosing specifically to attach it; > these things are often done to *every* outgoing message at an > organisational level by people who don't think the issue through very > well. > > http://goldmark.org/jeff/stupid-disclaimers/> That's exactly the case. > Please, those with such badly-configured systems, discuss the issue of > public discussion forums with the boneheads who think these disclaimer > texts are a good idea and at least try to change that behaviour. Believe me I've tried, in subtle and not-so-subtle ways. They won't change it, it's stupid and that's that. > Alternatively, post from some other mail system that doesn't slap > these obnoxious blocks onto your messages. I would but my browser environment is different from the rest so I can not copy source text or attach files to mails I could write via web mail. That would render mailing lists quite unusable for me. This is going to change soon, hopefully. So my apologies for the disclaimer but I an not do anything about it right now. Holger And now for another mighty stupid disclaimer ;-): Der Inhalt dieser E-Mail ist vertraulich. Falls Sie nicht der angegebene Empfänger sind oder falls diese E-Mail irrtümlich an Sie adressiert wurde, verständigen Sie bitte den Absender sofort und löschen Sie die E-Mail sodann. Das unerlaubte Kopieren sowie die unbefugte Übermittlung sind nicht gestattet. Die Sicherheit von Übermittlungen per E-Mail kann nicht garantiert werden. Falls Sie eine Bestätigung wünschen, fordern Sie bitte den Inhalt der E-Mail als Hardcopy an. The contents of this e-mail are confidential. If you are not the named addressee or if this transmission has been addressed to you in error, please notify the sender immediately and then delete this e-mail. Any unauthorized copying and transmission is forbidden. E-Mail transmission cannot be guaranteed to be secure. If verification is required, please request a hard copy version. -- http://mail.python.org/mailman/listinfo/python-list
Re: Re: XML + SOAP + Webservices
Hi there, just about now I´ve started to write a little howto for the first steps with a python ZSI-based webservice to be consumed from C++ clients (gSOAP) and an Excel XP spreadsheet. More or less I am just documenting what I did, and I am by no means an expert on the subject, but still...might be helpful to you. I can probably post the first part this afternoon or tomorrow morning (will not be finished by then). Meanwhile, you might also want to check out the pywebsvcs mailing list on sourceforge. Cheers, H. Der Inhalt dieser E-Mail ist vertraulich. Falls Sie nicht der angegebene Empfänger sind oder falls diese E-Mail irrtümlich an Sie adressiert wurde, verständigen Sie bitte den Absender sofort und löschen Sie die E-Mail sodann. Das unerlaubte Kopieren sowie die unbefugte Übermittlung sind nicht gestattet. Die Sicherheit von Übermittlungen per E-Mail kann nicht garantiert werden. Falls Sie eine Bestätigung wünschen, fordern Sie bitte den Inhalt der E-Mail als Hardcopy an. The contents of this e-mail are confidential. If you are not the named addressee or if this transmission has been addressed to you in error, please notify the sender immediately and then delete this e-mail. Any unauthorized copying and transmission is forbidden. E-Mail transmission cannot be guaranteed to be secure. If verification is required, please request a hard copy version. -- http://mail.python.org/mailman/listinfo/python-list
Re: XML + SOAP + Webservices
This may be of some help for you. It´s unfinished business, though.
So far, the ZSI stuff has worked quite well for me, but as mentioned I am
also a web services beginner.
I am writing this in lyx so I might be able to post in other formats. For
the time being, this is
the first part in pure text.
Cheers,
Holger
>>>
Interoperable WSDL/SOAP web services introduction: Python ZSI , Excel
XP & gSOAP C/C++
Holger Joukl
LBBW Financial Markets Technologies
Abstract
Despite the hype & buzzword-storm, building web services servers and
clients still is no piece of cake. This is partly due to the relative
newness of technology. For the most part, though, this results from
the actual complexness of the protocols/specs, the toolkit magic
behind which this complexness is hidden, and the documentation gaps
that exist for the toolkits. This document is intended to be an
example-loaded simple tutorial, to ease the use for web services
newcomers (like I am one).
It features the Python ZSI module that is used to build the server
side machinery and clients that access the exposed services from
Python, MS Excel XP, and C/C++ using gSOAP.
Copyright © 2005 Holger Joukl. All rights reserved.
Redistribution and use in source (LyX, LaTeX) and 'compiled' forms
(SGML, HTML, PDF, PostScript, RTF and so forth) with or without
modification, are permitted provided that the following conditions are met:
1. Redistributions of source code (LyX, LaTeX) must retain the above
copyright notice, this list of conditions and the following
disclaimer as the first lines of this file unmodified.
2. Redistributions in compiled form (transformed to other DTDs,
converted to PDF, PostScript, RTF and other formats) must reproduce
the above copyright notice, this list of conditions and the
following disclaimer in the documentation and/or other materials
provided with the distribution.
THIS DOCUMENTATION IS PROVIDED "AS IS" AND ANY EXPRESS OR IMPLIED
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
IN NO EVENT SHALL THE FREEBSD DOCUMENTATION PROJECT BE LIABLE FOR ANY
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER
IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION,
EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
1 Introduction
We assume the reader is familiar with Python, C/C++ and MS
Excel/VisualBasic. While some basic concepts regarding WSDL, SOAP,
HTTP servers etc. might be touched this document is NOT a tutorial on
these. If you want to know more there´s plenty of stuff on the web.
Please note that currently, throughout most examples, certain host
names and ports are used - substitute them with the setup for your site..
Versions used:
* Python 2.3
* PyXML 0.8.3
* ZSI 1.6.1
* ...
To Describe: WS-I, rpc/literal
2 The SquareService
This first example will implement a service that exposes a function
which takes a double argument and returns the square of it (
x{}^{\textrm{2}} ) as a
double. I.e. this examples uses simple scalar datatypes, one single
argument and one single return value.
2.1 The SquareService WSDL
This is the WSDL file that determines the contract for the
SquareService, called SquareService.wsdl:
http://dev-b.handel-dev.local:8080/SquareService";
xmlns:tns="http://dev-b.handel-dev.local:8080/SquareService";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/";
xmlns="http://schemas.xmlsoap.org/wsdl/";>
the square method
http://schemas.xmlsoap.org/soap/http"/>
http://dev-b.handel-dev.local:8080/SquareService"/>
http://dev-b.handel-dev.local:8080/SquareService"/>
Returns x^2 (x**2, square(x)) for a given float
x
http://dev-b.handel-dev.local:8080/SquareService"/>
Comments:
* The style "rpc" and the use "literal" are used, to be WS-I-compliant.
WS-I only supports rpc/literal and document/literal.
2.2 A Python ZSI server for the SquareService
The Python ZSI package [key-1] is one of two pywebsvcs packages
implementing
web services for Python, namely SOAP messaging and WSDL capabilities.
It is powerful and very easy to get started with, but lacks some
documentation enhancements when it comes to WSDL-driven servic
