Thanks Dieter for your wise words. On the workstations where they will not upgrade the Redhat verion, I will rewrite the script in Perl, I know Perl better than Python but I prefer Python by a mile.
When these old workstations are updated, they can use my super dooper Python script. Thanks again for your answer. Jerry Rocteur [email protected] > On 29 Nov 2014, at 20:14, Dieter Maurer <[email protected]> wrote: > > Jerry Rocteur wrote at 2014-11-28 15:45 +0100: >> ... >> I was running on Python 2.7 and it works great there but now I have to >> deploy the script on some Redhat workstations running python 2.4.3 >> (which I am not allowed to upgrade) >> >> When I create my client in my script I do it like this: >> >> url = 'https://system.globalsign.com/cr/ws/GasOrderService?wsdl' >> proxy = {'https': proxylog + ":" + proxypass + '@proxyhost.int:9999'} >> globalClient = Client(url, proxy=proxy) >> >> >> This works GREAT on 2.7 but when I run it on 2.4 I get: >> >> File "/usr/lib64/python2.4/urllib2.py", line 580, in proxy_open >> if '@' in host: >> TypeError: iterable argument required > > Looks like your "urllib2" is too old for "suds". > >> I'm Googling it and I can see there are other ways to connect but >> can't seem to get the syntax. > > I do think that a different syntax will help you. > > > Usually, the easiest thing in such situations is to use a sufficiently modern > Python version. > > While you are not allowed to upgrade the system Python, > you might be allowed to install a separate modern Python for this > task. Likely, you need some so called development packages installed > into your Redhat to be able to compile such a private Python version > yourself. It might not work, as "https" requires a working "_ssl" > which in turn may want a sufficiently modern "OpenSSL" library > and if you are unlucky your Redhat might have a too old one > - but it is likely worth to try. > > > Perhaps, you are able to convince your administrators to upgrade > their Redhat version (and then, maybe, get a modern Python version > as a byproduct) - especially, in case the "OpenSSL" library > turns out to be too old. This library has seen quite some serious > security issues - that's why there are quite frequent important > new versions. Sticking to old "OpenSSL" versions can present > a significant risk. Upgrading the library regularly is highly advicable. > > > If these approaches are impossible for you, then you likely > will need debugging to find out what precisely went wrong where > and fix it. > > Debugging is very powerful but complex, too. Expect that you will > need considerable time to learn it. However, once you have done so, > it may help you in the future in many occasions. > > There are IDEs (Integrated Development Environments) which support > Python debugging through a GUI (Graphical User Interface). You > still need to learn the elementary tools in the debugging toolbox > but the GUI assists you with the details. Colleagues of mine have > used the commercial (!) WingIDE, there is also a Python plugin for > the "Eclipse" IDE (originally for Java/C/C++ development) and "Komodo" > (and likely others). > > If you cannot get an IDE with Python debugging support, you > might use Python's "pdb" ("Python DeBugger") module. Its part > of the standard Python runtime library. You are not guided by a > graphical user interface but must remember the details about the > various debugging commands. It might be enough... > > With a debugger, you will be able to find out what "host" is > in the above error situation (I suspect it to be "None" rather than > a string). Moving "up" from the error place to the callers (one of the > standard debugging commands), you can find out where the wrong "hosts" > comes from. Looking at the code, you might be able to find out why > it got wrong and how to change things to get it correct. > Likely, the place for this change is somewhere in "suds" or "urllib2". > > If you are unlucky, your administrators will not let you change the code > directly where it needs fixing. You might need tricks to get > your fix incorporated into your program context. > There are essentially two approaches: module shadowing and monkey patches - > both potentially dangerous. With "module shadowing", you substitute > some (not fully functional) module with one of your own -- in the > easiest case via a special "PYTHONPATH" envvar or by inserting > your own code directories at the beginning of "sys.path" during > startup. With a monkey patch, you modify/replace (not fully functional) > functions, methods or classes at runtime (usually during startup) by > your own. > > > Let me stress it again. With high likelyhood, the by far most efficient > way to get your problem solved it to use a modern Python version - > ideally by upgrading the OS version (and get a modern Python as a byproduct) > or by a separate modern Python installation specially for your > own task. These approaches likely will cost some hours of work > (for your administrators and/or you) > Analysing in detail what went wrong and how to get it right > may have costs in the order of days (rather than hours) -- however, > you might get along without support from sometimes reluctant administrators. > > Ask for help from your project leader to get a decision which approach > should be followed. This way, he will at least not be surprised > when you take a long time to finish your task. > > > > > -- > Dieter _______________________________________________ Soap mailing list [email protected] https://mail.python.org/mailman/listinfo/soap
