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
