editing XML via DOM
Hi, I'm new to Python and XML but still I want to create something that includes creating and editing XML using Python. Now I'm looking for a little example program that does (some of) this to set me on my way. Is there something like this available or can somebody give me some example lines that creates and saves some XML data? Cheers, Jaco -- http://mail.python.org/mailman/listinfo/python-list
Re: python intergration bus ?
Tonino wrote: Hi, Just an interested question - I friend is testing a few JAVA intergration bus's that will be used to intergrate his companies services - I was wondering if there was a python intergration bus ? other than maybe Pyro ? Thanks Tonino Hello Tonino There is a Python module (http://www.python.org/other/spread/) for Spread (http://www.spread.org/ ) that is worth looking at. There is also some work on a rpc module using spread. http://pyhacks.suddenthinks.com/spreadrpc/, never worked with this one though. There is a great module for IBM's websphere mq, pymqi ( http://pymqi.sourceforge.net/) by L Smithson. This obviously depends on using the Commercial websphere MQ product though. If web services are an option you can also have a look at Clarence (http://clarens.sourceforge.net) and / or http://pywebsvcs.sourceforge.net/ I've previously stumbled accross some others at sourceforge, but this should get you started. jaco -- http://mail.python.org/mailman/listinfo/python-list
Re: How can I get the names of the files in a directory?
have a look at the glob module Sara Fwd <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 01/15/2005 03:10 PM To python-list@python.org cc Subject How can I get the names of the files in a directory? Can you guys also help me find a module that looks in a directory and print out the names of the files in there? __ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
SAP IDOC with python
Hello there I'm tinkering with parsing SAP IDOC's using Python. (initially reading possibly creating later on) I can get a C header file someCode.h from SAP describing the contents / structure of a document. I wondered if this file in conjunction with SWIG will be any use? Any one got any experience suggestions on this? thanks in advance jaco -- http://mail.python.org/mailman/listinfo/python-list
suse 9 python has no distutils.core ?
Hello there I'm trying to install some modules onto a Suse 9 box at work (for the first time). But I'm getting -- no module named distutils.core when I try and run python setup.py install ? the default distro is python 2.3.3 I've tried the latest rpm distro I could find on rpmfind.net, but I still got the same problem? I've looked on google and saw other people seem to have the same problem, but I have not seen any solutions. I'm busy downloading the 2.4 source distro - will this solve the problem? is there a solution to the problem? thanks for your time jaco -- http://mail.python.org/mailman/listinfo/python-list
leave
I will be out of the office starting 2005/03/20 and will not return until 2005/04/02. I will respond to your message when I return. This email and all contents are subject to the following disclaimer: "http://www.clover.co.za/disclaimer"; -- http://mail.python.org/mailman/listinfo/python-list
multithreading - managing transactions and sequence of processing
Hello there question: I'm looking for information / patterns / recipe's for implementing a multi threaded program (multiple producers / consumers) that will manage transactions and maintain sequence across the different threads. background: I'm busy writing an adapter taking messages from ibm websphere mq using pymqi and inserting these messages into a database (after some processing, the messages come in as xml). If I comment out the database .execute bit of the code, i process hundreds of messages per second, the database slows the whole process down to around 60 - 100 messages per second. I'm hoping to speed this up some by having 2 threads reading the messages from mq, and another populating the database - at least then the database bit will never have to wait for me to fetch another message. (i'm thinking of later adding a second thread for the databse as well). The challenge is that these messages need to be processed in exact sequence and transactionally. (ie. the thread that fetched a message will have to wait for confirmation that the message has successfully been inserted into the database before committing the transaction, in mq terms the message will only really be deleted then.) I've started implementing a kind of state machine using dictionary's to facilitate this, but I'm now concerned that - there is a better way - i might get bitten with dictionary processing updating / setting of values not necessarily being thread safe. I've looked at this recipe http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/302997 as a possible replacement for dictionary's but I'm not even sure if I'm using it correctly. thank you jaco -- http://mail.python.org/mailman/listinfo/python-list
Undefined calling conventions in Python.h
Hi there, This is my first post over here and I hope someone can give me some guidance. I'm trying to embed Python into a Visual C++ 2008 application and I'm getting linker problems. I've compiled a DLL of the Python source code using the pythoncode VC++ project in the PCbuild folder of the source download and this works 100% without any warnings etc. I've done this in Debug and Release mode without any problems. When I include python_install_path\include\Python.h in my application (with the linking setup correctly to the .lib and .dll files generated by myself) it builds fine. However as soon as I try to call any Python function (Py_Exit for example) I get linker errors as shown below: 1>application.obj : error LNK2031: unable to generate p/invoke for "extern "C" void __clrcall Py_Exit(int)" (?Py_Exit@@[EMAIL PROTECTED]); calling convention missing in metadata 1>frmPythonInterface.obj : error LNK2031: unable to generate p/invoke for "extern "C" void __clrcall Py_Exit(int)" (?Py_Exit@@[EMAIL PROTECTED]); calling convention missing in metadata I'm probably missing something but I can't find any calling convention details in Python.h or the other headers included in this file. In my VC++ DLL project I've specified the calling convention as __stdcall. I know the __clrcall naming convention has to do with managed code in VC+ + but thats as far as my knowledge on that goes. Should I define the calling conventions manually? Or is there a setting wrong somewhere in my application project? If anybody can give some guidance it would be greatly appreciated. Thanks Jaco -- http://mail.python.org/mailman/listinfo/python-list
Re: Undefined calling conventions in Python.h
On Jul 23, 9:59 am, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Jaco Naude wrote:
> > 1>application.obj : error LNK2031: unable to generate p/invoke for
> > "extern "C" void __clrcall Py_Exit(int)" (?Py_Exit@@[EMAIL PROTECTED]);
> > calling convention missing in metadata
> > 1>frmPythonInterface.obj : error LNK2031: unable to generate p/invoke
> > for "extern "C" void __clrcall Py_Exit(int)" (?Py_Exit@@[EMAIL PROTECTED]);
> > calling convention missing in metadata
>
> > I'm probably missing something but I can't find any calling convention
> > details in Python.h or the other headers included in this file.
>
> the precence of name mangling indicates that your compiler doesn't
> understand that Python's a C library, and therefore uses C calling
> conventions. have you managed to override the defaults in some odd
> way?
>
>
good point. I agree that the problem is probably due to name mangling.
I'm not sure how its possible to tell the application that the DLL is
a C dll? I've looked at the DLL using Dependency Walker and the
functions in the DLL are clean (Thus no name mangling used).
How do I tell Visual C++ that the DLL is a C dll? I thought it should
be in Python.h but this line appears at the top of the file:
/* Since this is a "meta-include" file, no #ifdef __cplusplus / extern
"C" { */
Thanks for the help
Jaco
--
http://mail.python.org/mailman/listinfo/python-list
Re: Undefined calling conventions in Python.h
On Jul 23, 12:16 pm, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Jaco Naude wrote:
> > good point. I agree that the problem is probably due to name mangling.
> > I'm not sure how its possible to tell the application that the DLL is
> > a C dll? I've looked at the DLL using Dependency Walker and the
> > functions in the DLL are clean (Thus no name mangling used).
>
> > How do I tell Visual C++ that the DLL is a C dll? I thought it should
> > be in Python.h but this line appears at the top of the file:
>
> > /* Since this is a "meta-include" file, no #ifdef __cplusplus / extern
> > "C" { */
>
> All the individual includes are wrapped in the usual
>
> #ifdef __cplusplus
> extern "C" {
> #endif
>
> stuff, so the compiler should default to C bindings, without you having
> to do anything. Unfortunately, I haven't used VS 2008, but I find it
> hard to believe that they've messed this up completely, and a quick
> googling indicates that people are using it with Python without trouble.
>
> Maybe there's some override in your project settings caused by some
> other parts of your project? (or an #undef __cplusplus somewhere, perhaps?)
>
>
I've figured out that the names in the DLL are not mangled by looking
into the DLL using dependancy walker. I also figured out that the
problem is on the application's side and not on the dll's side.
What Visual C++ is doing is that it is looking for mangled names since
it does not know the DLL contains C functions. I've managed to work
around this by declaring the Python functions as follows before using
them in the C++ application side:
extern "C"
{
void Py_Initialize(void);
}
This seems to work and the C++ application side is not looking for
mangled names any more. Is this the right way of doing it? It seems
unnecessary to have to declare each Python function you want to use
using the extern "C" way as shown above.
It is probably more of a C++ question it turns out, but I would think
that someone in the Python group would use the Python DLL in C++. The
documentation also suggest that there is no extra work needed when
using C++ rather than C.
Thanks for the help so far.
Jaco
--
http://mail.python.org/mailman/listinfo/python-list
Re: Undefined calling conventions in Python.h
On Jul 23, 1:10 pm, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Jaco Naude wrote:
> > What Visual C++ is doing is that it is looking for mangled names since
> > it does not know the DLL contains C functions. I've managed to work
> > around this by declaring the Python functions as follows before using
> > them in the C++ application side:
>
> > extern "C"
> > {
> > void Py_Initialize(void);
> > }
>
> > This seems to work and the C++ application side is not looking for
> > mangled names any more. Is this the right way of doing it? It seems
> > unnecessary to have to declare each Python function you want to use
> > using the extern "C" way as shown above.
>
> Eh, are you saying that you're not including the Python.h file? Because
> it does exactly that, for each and every public function in the C API.
>
> > It is probably more of a C++ question it turns out, but I would think
> > that someone in the Python group would use the Python DLL in C++. The
> > documentation also suggest that there is no extra work needed when
> > using C++ rather than C.
>
> Oh, but I do that all the time, without doing any extra work. Both
> embedding Python in C++ programs and existing it with C++ extensions.
> And I'm definitely not alone.
>
> Here's an actual session, using the version of Visual Studio I happen to
> have on this machine (2003, I think) from the command line:
>
> > more test.cc
>
> #include "Python.h"
> #include
>
> main()
> {
> Py_Initialize();
> PyRun_SimpleString("print 'hello'\n");
> Py_Finalize();
>
> std::cout << "world\n";
>
> }
>
> > cl cl -EHsc -MD -I \python25\include test.cc \python25\libs\python25.lib
> Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077
> for 80x86
> Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.
>
> ...
>
> > test
> hello
> world
>
> If you cannot get the same console program to work in your compiler
> setup, something's wrong with your configuration.
>
>
Ok that's probably good news, although it points out that there is
something wrong with my configuration since that does not work. I
would rather sort out the problem that having to defined each function
with a extern "C" command.
That said, let me double check something which might be causing
problems since you will be familiar with this. Which Python.h file do
you include when including the DLL in your programs? The one in the
source distribution of the one in the installation distribution? I've
been including the one in the installation distribution all along.
When I try to include the one in the source distribution it gets up to
the point where it looks for the following include:
#include "pyconfig.h"
This file is not in the same directory as the Python.h file in the
source distribution. Because of this I just used Python.h in the
installation distribution.
Thanks again,
Jaco
--
http://mail.python.org/mailman/listinfo/python-list
Re: Undefined calling conventions in Python.h
On Jul 23, 1:50 pm, Jaco Naude <[EMAIL PROTECTED]> wrote:
> On Jul 23, 1:10 pm, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
>
>
>
> > Jaco Naude wrote:
> > > What Visual C++ is doing is that it is looking for mangled names since
> > > it does not know the DLL contains C functions. I've managed to work
> > > around this by declaring the Python functions as follows before using
> > > them in the C++ application side:
>
> > > extern "C"
> > > {
> > > void Py_Initialize(void);
> > > }
>
> > > This seems to work and the C++ application side is not looking for
> > > mangled names any more. Is this the right way of doing it? It seems
> > > unnecessary to have to declare each Python function you want to use
> > > using the extern "C" way as shown above.
>
> > Eh, are you saying that you're not including the Python.h file? Because
> > it does exactly that, for each and every public function in the C API.
>
> > > It is probably more of a C++ question it turns out, but I would think
> > > that someone in the Python group would use the Python DLL in C++. The
> > > documentation also suggest that there is no extra work needed when
> > > using C++ rather than C.
>
> > Oh, but I do that all the time, without doing any extra work. Both
> > embedding Python in C++ programs and existing it with C++ extensions.
> > And I'm definitely not alone.
>
> > Here's an actual session, using the version of Visual Studio I happen to
> > have on this machine (2003, I think) from the command line:
>
> > > more test.cc
>
> > #include "Python.h"
> > #include
>
> > main()
> > {
> > Py_Initialize();
> > PyRun_SimpleString("print 'hello'\n");
> > Py_Finalize();
>
> > std::cout << "world\n";
>
> > }
>
> > > cl cl -EHsc -MD -I \python25\include test.cc \python25\libs\python25.lib
> > Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077
> > for 80x86
> > Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.
>
> > ...
>
> > > test
> > hello
> > world
>
> > If you cannot get the same console program to work in your compiler
> > setup, something's wrong with your configuration.
>
> >
>
> Ok that's probably good news, although it points out that there is
> something wrong with my configuration since that does not work. I
> would rather sort out the problem that having to defined each function
> with a extern "C" command.
>
> That said, let me double check something which might be causing
> problems since you will be familiar with this. Which Python.h file do
> you include when including the DLL in your programs? The one in the
> source distribution of the one in the installation distribution? I've
> been including the one in the installation distribution all along.
> When I try to include the one in the source distribution it gets up to
> the point where it looks for the following include:
>
> #include "pyconfig.h"
>
> This file is not in the same directory as the Python.h file in the
> source distribution. Because of this I just used Python.h in the
> installation distribution.
>
> Thanks again,
> Jaco
I only saw your last message after posting my previous one. Ok, so the
problem is definitely with the include file Python.h. As I said in my
last post, I might be including the wrong one. I would appreciate it
if you can tell me which one it the correct one to use: The one in the
source distribution or the one in the release distribution
(installation done from the .msi file).
Thanks
Jaco
--
http://mail.python.org/mailman/listinfo/python-list
Re: Undefined calling conventions in Python.h
On Jul 23, 2:08 pm, Ben Sizer <[EMAIL PROTECTED]> wrote:
> On Jul 23, 11:43 am, Jaco Naude <[EMAIL PROTECTED]> wrote:
>
> > What Visual C++ is doing is that it is looking for mangled names since
> > it does not know the DLL contains C functions. I've managed to work
> > around this by declaring the Python functions as follows before using
> > them in the C++ application side:
>
> > extern "C"
> > {
> > void Py_Initialize(void);
>
> > }
>
> You should put the extern block around the #include call
> rather than individual functions, as surely the C calling convention
> should apply to everything within.
>
> > It is probably more of a C++ question it turns out, but I would think
> > that someone in the Python group would use the Python DLL in C++.
>
> More of a Visual C++ question specifically, since the __clrcall prefix
> is a MS specific extension (http://msdn.microsoft.com/en-us/library/
> ec7sfckb(VS.80).aspx). If you're not using managed code in your app,
> disable it in the project/build options. If you are, then perhaps you
> just need to specify that you're not with this DLL, though I've never
> had to deal with anything like that myself.
>
> --
> Ben Sizer
Fredrik, thanks for the help. I'm not sure why but it seems to work
now even if I don't include the extern "C" command. It also works with
both Python.h files (after I copied pyconfig.h from the PC folder). So
it seems like everything is working now.
Ben, Thanks for the reply. Good suggestion to place the extern "C"
around the include. I will remember that. It turns out that it works
without that as well in the end. As for the question on managed code:
My application do use managed code. I've been able to turn this off
when I created the Python DLL and it seems to work.
Thanks for all the help,
All the best
Jaco
--
http://mail.python.org/mailman/listinfo/python-list
