Re: Second posting - Howto connect to MsSQL
Hello, John Fabiani wrote: > Are there others using Python to connect MsSQL? At the moment I'd > accept even a windows solution - although, I'm looking for a Linux > solution. You'll need to get one out of each category: 1) ODBC manager: unixOdbc or iOdbc 2) Python ODBC wrapper: mxOdbc (www.egenix.com) 3) ODBC driver: either a commercial one or the freetds driver (www.freetds.org) HTH, aa -- Andreas Ames | Programmer | Comergo GmbH | Voice: +49 69 7505 3213 | andreas . ames AT comergo . com -- http://mail.python.org/mailman/listinfo/python-list
RE: How do you implement this Python idiom in C++
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
g] On Behalf Of [EMAIL PROTECTED]
> Sent: Thursday, July 27, 2006 5:51 PM
> Subject: How do you implement this Python idiom in C++
>
> I am no C++ expert but i guess there might be some in the Python and
> C++ newsgroups.
You could try sth. like this:
#include
template class Counted {
static int count;
public:
Counted() { ++count; }
Counted(const Counted&) { ++count; }
~Counted() { --count; }
template friend int getCount(V&);
};
template int Counted::count = 0;
// Curious class definitions
class CountedClass : private Counted {};
class CountedClass2 : private Counted {};
class CountedClass3 : public CountedClass, private Counted {};
template
int getCount(T &)
{
return Counted::count;
}
using namespace std;
int main() {
CountedClass a;
cout << getCount(a) << endl;// 1
CountedClass b;
cout << getCount(b) << endl;// 2
CountedClass3 c;
cout << getCount(c) << endl;// 1
cout << getCount(a) << endl;// 3 and should be 2??
}
Your last assertion ('should be 2') is questionable, IMHO. I think the above
code has it right in this case rather than your python version (after all c isA
CountedClass, isn't it?).
cheers,
aa
--
Andreas Ames | Programmer | Comergo GmbH |
Voice: +49 69 7505 3213 | ames AT avaya DOT com
--
http://mail.python.org/mailman/listinfo/python-list
RE: Singleton Class Exception
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > g] On Behalf Of Dan Lenski > Sent: Monday, November 13, 2006 7:05 PM > Subject: Re: Singleton Class Exception > > dischdennis wrote: > > the line "raise Singleton.__single" invokes in my class the > following > > error: > > > > exceptions must be classes, instances, or strings (deprecated), not > > PurchaseRequisitionController > > Denis, > Jason's explanation is correct! You are trying to use the Singleton I don't think so. The op wrote that he uses 2.4.3. So I guess, the problem is, that PurchaseRequisitionController inherits (directly or not) from 'object'. Although new style classes are allowed as exceptions in 2.5, an additional requirement is, that the exception must inherit from BaseException (or must not be a new style class instance at all, as before). cheers, aa -- Andreas Ames | Programmer | Comergo GmbH | Voice: +49 69 7505 3213 | ames AT avaya DOT com -- http://mail.python.org/mailman/listinfo/python-list
RE: Python and STL efficiency
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > g] On Behalf Of Ray > Sent: Wednesday, August 23, 2006 4:28 PM > Subject: Re: Python and STL efficiency > > > Tim N. van der Leeuw wrote: > > With the nr of loops corrected, Python on my laptop > performs worse than > > C++ under all circumstances, by a factor of about 2: > > *Phew* > > Great to know that my model of how the world works is still correct! > (at least in relation to Python and C++!) :) If you're really eager to see python succeed with this 'test' or 'benchmark', if you will, you can look at the results with VC7.1. It clearly shows that much depends on the STL implementation, you use. I use the implementations posted by Maric Michaud in http://mail.python.org/pipermail/python-list/2006-August/357593.html. The tests, for which I appended 'with hash', use a hash_set instead of a plain set. 1) vc71 with dinkumware STL (which is vc's default STL): print_occurence_of_strings What do you know? chicken crosses road fool so long... print_occurence_of_unique_strings What do you know? chicken crosses road fool so long... print_occurence_of_unique_strings_compared_by_address What do you know? chicken crosses road fool so long... print_occurence_of_strings_with_hash What do you know? chicken crosses road fool so long... print_occurence_of_unique_strings_with_hash What do you know? chicken crosses road fool so long... strings : 10.921 < Oops ... unique strings : 1.047 compared by address : 0.328 strings with hash : 11.484 < Oooops ... unique strings with hash : 1.016 2) vc7.1 with STLport 5.02: print_occurence_of_strings What do you know? chicken crosses road fool so long... print_occurence_of_unique_strings What do you know? chicken crosses road fool so long... print_occurence_of_unique_strings_compared_by_address What do you know? chicken crosses road fool so long... print_occurence_of_strings_with_hash<--- reorders fool What do you know? chicken crosses road so long... print_occurence_of_unique_strings_with_hash <--- reorders so long... What do you know? chicken crosses road fool strings : 2.156 unique strings : 0.953 compared by address : 0.187 strings with hash : 2.078 unique strings with hash : 0.922 This seems to substantiate this post http://sourceforge.net/mailarchive/forum.php?thread_id=30201462&forum_id=46178. 3) python 4.2 (python test.py; interestingly this is faster than with -OO) so long... What do you know fool chicken crosses road Elapsed: 2.278332 seconds It seems the unification of the strings via hash is not significantly better (compared to memcpy or whatever is used). The results for the dinkumware STL are dominated by the sheer number of calls to HeapAlloc/HeapFree and to EnterCriticalSection/LeaveCriticalSection (I compiled with multithreading and linked statically). The python version won't be concerned with the latter, I guess (although just by importing 'threading' performance gets about 3.5% worse). STLport uses for example InterlockedExchange (obviously in the default allocator) and several orders of magnitude fewer calls to the heap allocation API. It all boils down to the fact that I can write C++ or even assembler programs that perform worse (by any degree I want) than a functionally equivalent python program. That's a trivial insight and it certainly doesn't provide evidence that python 'is faster' than c++/assembler. Even if that's just because it *isn't* and can't be. I always wonder where this rage comes from to prove oneself or whomever that python is the best programming language in any regard as if it hadn't enough other advantages. It is certainly not the fastest/most memory efficient tool out there. One of the biggest advantages of python to me is that, even if I run into a hotspot, the transition from python to C/C++ is so easy. That means that in spite of its warts (GIL, memory efficiency ...) I don't easily come to a dead end using python. This fact lets me use python's great strengths (like programmer efficiency etc.) without tossing and turning sleeplessly in my bed. cheers, aa -- Andreas Ames | Programmer | Comergo GmbH | Voice: +49 69 7505 3213 | ames AT avaya DOT com -- http://mail.python.org/mailman/listinfo/python-list
Re: Another source of time for the logging package?
Skip Montanaro wrote: > Before I get out my scalpel, has anyone found a non-invasive way to > do this (or already done the surgery and would be willing to share > it)? While I'm not sure you would call the following 'non-invasive' I've used it in a similar situation: class MyLogRecord(logging.LogRecord): def __init__(*args, **kwargs): logging.LogRecord.__init__(self, *args, **kwargs) self.created = time_warp() # get the time you need class MyLogger(logging.Logger): def makeRecord(self, *args, **kwargs): return MyLogRecord(*args, **kwargs) Then I call logging.setLoggerClass(MyLogger) before the relevant loggers are created. HTH, aa -- Andreas Ames | Programmer | Comergo GmbH | Voice: +49 69 7505 3213 | andreas . ames AT comergo . com -- http://mail.python.org/mailman/listinfo/python-list
RE: dynamic library loading, missing symbols
Some random notes below ... > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > g] On Behalf Of [EMAIL PROTECTED] > Sent: Wednesday, January 10, 2007 1:26 AM > Subject: dynamic library loading, missing symbols > > The reason for the complication is that I don't have control over how > the library does dlopen() or how the code that calls dlopen was > compiled. I am, however, able to control the build process for the > Boost.Python wrapper and the original C++ code that the Boost.Python > wraps. I've tried as many linker tricks as I can think of to get this > to work. Both the boost wrapper and the C++ code that it wraps are > built using --export-dynamic. * Make sure the exported symbols are marked "extern C" * Otherwise (you export C++ symbols), make sure the exporting component uses *exactly* the same compiler (version, ABI-influencing flags and all) as the importing component. * IMHO, C++ .sos are principally painful and almost unbearable, if you have (non-source) third party components involved. * Use nm to find the exact names of the exported and imported symbols (as already suggested). > > Is there a way to set at runtime what directories or libraries the > linker should search for these symbols? I have set LD_LIBRARY_PATH > correctly, but that didn't seem to affect anything. > > For reference, I am running on Gentoo linux 2.6.11.12 with gcc 3.4.4 > > I'm interested in any ideas that might help, but the ideal one should > work on any *nix system and not just linux. * You might read http://people.redhat.com/drepper/dsohowto.pdf, which I found very useful. There are ways described, how to control the way, the dynamic loader resolves symbols, all with their resp. caveats. * Nevertheless it only describes ELF-based systems, and mostly systems using Drepper's own .so-loader. * Portability to e.g. Windows is a almost impossible for you, because it doesn't support undefined symbols in .sos (and Drepper suggests on ELF-based systems this should only be used if absolutely unavoidable, IIRC). NB: There is a project on SF which claimes to provide this feature on Windows, but I haven't tried and it limits your choice of tools (http://edll.sf.net/). cheers, aa -- Andreas Ames | Programmer | Comergo GmbH | Voice: +49 711 13586 7789 | ames AT avaya DOT com -- http://mail.python.org/mailman/listinfo/python-list
RE: dynamic library loading, missing symbols
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > g] On Behalf Of [EMAIL PROTECTED] > Sent: Wednesday, January 10, 2007 8:52 PM > Subject: Re: dynamic library loading, missing symbols > > I suppose this means that any subsequent libraries dlopened will not > see any of the symbols in my module? Have you already checked the output of LD_DEBUG=all or sth. like that? cheers, aa -- Andreas Ames | Programmer | Comergo GmbH | Voice: +49 711 13586 7789 | ames AT avaya DOT com -- http://mail.python.org/mailman/listinfo/python-list
RE: MinGW and Python
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > g] On Behalf Of sturlamolden > Sent: Tuesday, April 25, 2006 2:27 PM > Subject: Re: MinGW and Python > > > Robert Kern wrote: > > > - gcc does not optimize particularly well. > > That is beyond BS. The more recent gcc releases optimize as > well as any > commercial compiler. GCC 4 may even optimize better than MSVC. Not to talk of standard compliance (msvc-c99 anyone?). cheers, aa -- Andreas Ames | Programmer | Comergo GmbH | Voice: +49 69 7505 3213 | ames AT avaya . com -- http://mail.python.org/mailman/listinfo/python-list
RE: MinGW and Python
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > g] On Behalf Of Ross Ridge > Sent: Thursday, April 27, 2006 8:53 PM > Subject: Re: MinGW and Python > > > No one is working on removing MinGW's depency on MSVCRT.DLL. There is certainly work underway to ease the use of msvcrXX in mingw built binaries. It's already possible to do it today with some tweaking, but I seem to remember that this was already mentioned in this thread. For example: http://sourceforge.net/mailarchive/message.php?msg_id=7374474 I don't think it is a technical problem that prevents a mingw-python from being distributed, I rather see (in no particular order): 1) psychological issues: 'convenient IDE', 'better debugger' 2) legal issues: redistribution of msvcrXX 3) 'economical' issues: no one seems to be willing to reliably support a mingw-python No. 2 could be a show-stopper. There remains one technical issue that isn't a killer but would be inconvenient, IMHO: Can pywin32 be made working with a mingw-python (I'm quite sure it can't be made building on it)? I'd appreciate any datapoints about that ... cheers, aa -- Andreas Ames | Programmer | Comergo GmbH | Voice: +49 69 7505 3213 | ames AT avaya . com -- http://mail.python.org/mailman/listinfo/python-list
RE: MinGW and Python
> -Original Message- > From: "Martin v. Löwis" [mailto:[EMAIL PROTECTED] > Sent: Friday, April 28, 2006 6:20 PM > Subject: Re: MinGW and Python > > It all depends on what CRT version you link Python with. If you > use mingw32 to link Python with msvcr71.dll, nothing would change > for pywin32 compared to Python 2.4. OTOH, nothing would change > for anybody else, either. I'm more concerned that it might expose some C++ code (symbols) to other python code but I haven't looked at pywin32's implementation so I can't really tell. If it does, one shouldn't use it with _any_ compiler other than the one used to build pywin32. Even a mix of different ms-compilers would be dangerous, IMHO. cheers, aa -- Andreas Ames | Programmer | Comergo GmbH | Voice: +49 69 7505 3213 | ames AT avaya . com -- http://mail.python.org/mailman/listinfo/python-list
RE: multi-threaded c++ callback problem
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> g] On Behalf Of pydev
> Sent: Tuesday, April 11, 2006 9:23 PM
> Subject: multi-threaded c++ callback problem
>
> void pyCallEventCallback( CALL hCall,
> LINE hLine,
> CALLSTATE_MAJOR eMajor,
> CALLSTATE_MINOR eMinor,
> PyObject* def )
> {
> if( !PyCallable_Check( def ) )
> {
> PyErr_SetString( PyExc_TypeError, "Need a callable object!" );
> return;
> }
> printf( "EventCallback hCall: %i, hLine: %i, eMajor: %i,
> eMinor: %i\n", hCall, hLine, eMajor, eMinor);
> PyObject* arglist = Py_BuildValue("()", hCall, hLine,
> eMajor, eMinor);
>
> // if i comment out next line it works!
> PyEval_CallObject( def, arglist );
>
> Py_XDECREF(arglist);
> }
> //---//
Wild guess because of lack of context:
It's a race condition because you haven't acquired the GIL before calling
pyCallEventCallback. You can do so by using PyEval_SaveThread and friends.
You have to make sure to call PyEval_InitThreads somewhere, e.g. when embedding
from within the interpreter initialisation boilerplate, when extending for
instance from within the extension module initialisation.
cheers,
aa
--
Andreas Ames | Programmer | Comergo GmbH |
Voice: +49 69 7505 3213 | ames AT avaya . com
--
http://mail.python.org/mailman/listinfo/python-list
RE: From Python to c++
Hello Marco,
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> g] On Behalf Of Marco Aschwanden
> Sent: Tuesday, March 21, 2006 8:43 PM
> Subject: From Python to c++
>
> parsed = {
> "name":["Mac", "Mike"],
> "age":[25, 55],
> "place":["Zurich", "Oslo"]
> }
>
> map >
>
> I want to build the map of lists dynamically - it can have
> many fields or
> just one... and I would like to have simple interface (as
> Python offers).
If you can predetermine the possible types of the data fields at compile time
(I don't know how to avoid this constraint anyway because you need to convert
the string data to the field types, as well in Python as in C++) you could use:
std::map< std::string, boost::variant< std::string, int, bool > > parsed;
if your predetermined types are string, int, bool.
For more info, see http://www.boost.org/.
HTH,
aa
--
Andreas Ames | Programmer | Comergo GmbH |
Voice: +49 69 7505 3213 | ames AT avaya . com
--
http://mail.python.org/mailman/listinfo/python-list
How to get pyMinGW?
Hi all, the download link on http://jove.prohosting.com/iwave/ipython/pyMinGW.html seems to be broken. Can anybody provide another link? Is there a current version for python 2.4.3 available? TIA, aa -- Andreas Ames | Programmer | Comergo GmbH | Voice: +49 69 7505 3213 | ames AT avaya . com -- http://mail.python.org/mailman/listinfo/python-list
