win32com.client documentation?
I am a unix person, not new to Python, but new to Python programming on windows. Does anyone know where to find documentation on win32com.client? I have successfully installed this module and implemented some example code. But a comprehensive explanation of the objects and methods available is nowhere to be found. I have been able to find a somewhat out-of-date O'Reilly book, nothing more. I want to be able to script the creation of Excel spreadsheets and Word documents, interract with Access data bases, and so forth. -- http://mail.python.org/mailman/listinfo/python-list
strange transliteration in win32com.client
Is this the place to ask a win32com.client question? I am a unix person trying to run on windows, so I have little familiarity with this module. I have this code: import win32com.client An Access connection def connect(data_source, user, pwd, mdw): connAccess = win32com.client.Dispatch(r'ADODB.Connection') SOURCE=%s;USER ID=%s;PASSWORD=%s;Jet OLEDB:System Database=%s; % (data_source, user, pwd, mdw) connAccess.Open(DSN) return connAccess I when I call this, running my program from the windows command line on the C:\ drive, with data_source='\\Hqwhslfs001\office\risk oversight \myaccessdb.mdb', which is the fully specified drive name, it comes back with: File C:\Python25\lib\site-packages\win32com\client\dynamic.py, line 258, in _ApplyTypes_ result = self._oleobj_.InvokeTypes(*(dispid, LCID, wFlags, retType, argTypes) + args) pywintypes.com_error: (-2147352567, 'Exception occurred.', (0, 'Microsoft JET Database Engine', 'c:\\Hqwhslfs001\\office\risk oversight\\myaccess.mdb' is not a valid path. Make sure that the path name is spelled correctly and that you are connected to the server on which the file resides., None, 5003044, -2147467259), None) Please note the strange insertion of double slashes in the indicated 'not valid path.' Also the insertion of 'c:' and the strange leading double quotation mark. When I call it with data_source = 'V:\risk oversight\myassessdb.mdb', which reflects how this same drive is mapped on my machine, I get: File C:\Python25\lib\site-packages\win32com\client\dynamic.py, line 258, in _ApplyTypes_ result = self._oleobj_.InvokeTypes(*(dispid, LCID, wFlags, retType, argTypes) + args) pywintypes.com_error: (-2147352567, 'Exception occurred.', (0, 'Microsoft JET Database Engine', 'v:\\\risk oversight\ \myaccessdb.mdb' is not a valid path. Make sure that the path name is spelled correctly and that you are connected to the server on which the file resides., None, 5003044, -2147467259), None) Note the weird transliteration of data_source. I am powerless to understand this. -- http://mail.python.org/mailman/listinfo/python-list
subclass of integers
I would like to construct a class that includes both the integers and None. I desire that if x and y are elements of this class, and both are integers, then arithmetic operations between them, such as x+y, return the same result as integer addition. However if either x or y is None, these operations return None. It's simple enough to construct a subclass of integers that behave in this way: class Nint(int): def __add__(self,other): if (other != None): return self+other else: return None def __radd__(self,other): if (other != None): return other+self else: return None #...and so forth However I have not been able to figure out how to make it so that None, as well as an integer, could be an element of my class. My preliminary impression is that I have to override int.__new__; but I am uncertain how to do that and have been unable to find anything on the web explaining that. Indeed I haven't been able to find much about __new__ at all. Overriding this method of built-in classes seems to be quite unusual. I would very much appreciate anyone's help. -- http://mail.python.org/mailman/listinfo/python-list
Re: subclass of integers
On Sep 14, 10:30 am, Mark Morss [EMAIL PROTECTED] wrote: I would like to construct a class that includes both the integers and None. I desire that if x and y are elements of this class, and both are integers, then arithmetic operations between them, such as x+y, return the same result as integer addition. However if either x or y is None, these operations return None. It's simple enough to construct a subclass of integers that behave in this way: class Nint(int): def __add__(self,other): if (other != None): return self+other else: return None def __radd__(self,other): if (other != None): return other+self else: return None #...and so forth However I have not been able to figure out how to make it so that None, as well as an integer, could be an element of my class. My preliminary impression is that I have to override int.__new__; but I am uncertain how to do that and have been unable to find anything on the web explaining that. Indeed I haven't been able to find much about __new__ at all. Overriding this method of built-in classes seems to be quite unusual. I would very much appreciate anyone's help. I meant of course that arithmetic operations between integer elements would return the same result as the corresponding integer operations, not necessarily addition. -- http://mail.python.org/mailman/listinfo/python-list
Re: The best platform and editor for Python
On Jul 1, 3:30 pm, Sönmez Kartal [EMAIL PROTECTED] wrote: Emacs is the best for anything for me. Me too. Also, as pointed out by some others, a debugger is not really all that necessary for an interpreted language like Python. Hi, For experienced with Pyhton users, which developing software and enviroment would you suggest for Pyhton programming? Compiler+Editor +Debugger. Also what are your suggestions for beginners of Pyhton programming? Thank you. -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Python compared to other language
On May 20, 5:02 pm, Bruno Desthuilliers Ruby is probably far better than Python at sys-admin tasks. Why, pray tell? I don't know much about Ruby, but I know that Python is the language that Gentoo uses for package management, which certainly qualifies as a sys-admin task. -- http://mail.python.org/mailman/listinfo/python-list
Re: Fortran vs Python - Newbie Question
On Mar 26, 12:59 pm, Erik Johnson [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] OK... I've been told that Both Fortran and Python are easy to read, and are quite useful in creating scientific apps for the number crunching, but then Python is a tad slower than Fortran because of its a high level language nature, so what are the advantages of using Python for creating number crunching apps over Fortran?? Thanks Chris So, after reading much of animated debate here, I think few would suggest that Python is going to be faster than FORTRAN when it comes to raw execution speed. Numeric and SciPy are Python modules that are geared towards numerical computing and can give substantial performance gians over plain Python. A reasonable approach (which has already been hinted at here), is to try to have the best of both world by mixing Python and FORTRAN - doing most of the logic and support code in Python and writing the raw computing routines in FORTRAN. A reasonable approach might be to simply make your application work in Python, then use profiling to identify what parts are slowest and move those parts into a complied language such as FORTRAN or C if overall performance is not fast enough. Unless your number crunching project is truly massive, you may find that Python is a lot faster than you thought and may be plenty fast enough on it's own. So, there is a tradeoff of resources between development time, execution time, readability, understandability, maintainability, etc. psyco is a module I haven't seen mentioned here - I don't know a lot about it, but have seen substantial increases in performance in what little I have used it. My understanding is that it produces multiple versions of functions tuned to particular data types, thus gaining some advantage over the default, untyped bytecode Python would normally produce. You can think of it as a JIT compiler for Python (but that's not quite what it is doing). The home page for that module is here: http://psyco.sourceforge.net/ Hope that help, -ej The question as originally framed was a little ignorant, of course. Python and Fortran are by no means subtitutes. Python is interpreted, comprehensively interroperates with just about anything, and is relatively slow. Fortran is compiled, interoperates with almost nothing and is blindingly fast. So it is like a battle between an elephant and a whale. If there is possible substitution, and hence competition, it is between Python+Numpy/Scipy on the one hand and Python+Fortran, via F2PY, on the other. My personal taste is to do things in Fortran when I can. It is really pretty simple to write well-structured, clear code in Fortran 95, and I don't find it troublesome to compile before I run. I don't find type declarations to be a nuisance; on the contrary, I think they're very useful for good documentation. Also I am somewhat mistrustful of Numpy/Scipy, because when I visit their forums, almost all the chatter is about bugs and/or failure of some function to work on some operating system. Perhaps I am wrong, but Python+Numpy/Scipy looks a little unstable. I understand that the purpose of Numpy/Scipy is to make it possible to do large-scale numerical computation in Python (practically all serious numerical computation these days is large-scale) without paying too much of a penalty in speed (relative to doing the same thing with a compiled language), but I have not yet been persuaded to take the trouble to learn the special programming vocabulary, essential tricks, and so forth, necessar for Numpy/Scipy when Fortran is ready to hand, very well established, and definitely faster. I do value Python very much for what it was designed for, and I do plan eventually to hook some of my Fortran code to Python via F2PY, so that interoperability with spreadsheets, OLAP and the like on the front and back ends of my information flow. Maybe somebody reading this will be able to convince me to look again at Numpy/Scipy, but for the time being I will continue to do my serious numerical computation in Fortran. -- http://mail.python.org/mailman/listinfo/python-list
Re: Fortran vs Python - Newbie Question
On Mar 27, 12:55 pm, Jaap Spies [EMAIL PROTECTED] wrote: Mark Morss wrote: Maybe somebody reading this will be able to convince me to look again at Numpy/Scipy, but for the time being I will continue to do my serious numerical computation in Fortran. What I am missing in this discussion is a link to Pyrex to speed up Python: Pyrex is almost Python with the speed of compiled C.http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/ Pyrex is adapted in SAGE (Software for Algebra and Geometry Experimentation) as Sagex:http://modular.math.washington.edu/sage/ Jaap Well, the discussion was about Python vs. Fortran, and Pyrex, as I understand it, is a tool for linking C to Python. So I am not sure of the relevance of Pyrex to this particular discussion. F2PY is the leading tool for linking Fortran to Python, and I did mention that. -- http://mail.python.org/mailman/listinfo/python-list
Re: Help Required for Choosing Programming Language
On Feb 16, 4:22 pm, [EMAIL PROTECTED] wrote: I am VB6 programmer and wants to start new programming language but i am unable to deciced. i have read about Python, Ruby and Visual C++. but i want to go through with GUI based programming language like VB.net so will you please guide me which GUI based language has worth with complete OOPS Characteristics will wait for the answer hope to have a right direction from you Programmer Regards Iftikhar [EMAIL PROTECTED] Good grief. I suppose it is Microsoft to whom we owe the idea that there could be such a thing as a GUI based programming language. -- http://mail.python.org/mailman/listinfo/python-list
Re: About alternatives to Matlab
The [F#] source is avaliable, but it's under Microsoft's Shared Source license, which isn't quite an open source license. There are some restrictions on commercial usage. You can call me a bigot, but it will be engraved upon my tombstone that I never used a proprietary Microsoft language. [EMAIL PROTECTED] wrote: Paul Rubin wrote: Jon Harrop [EMAIL PROTECTED] writes: F# runs under Linux with Mono. Interesting, where do I get it, and is there source? I've never been interested in Mono but maybe this is a reason. How does the compiled code compare to OCaml or MLton code? The source is avaliable, but it's under Microsoft's Shared Source license, which isn't quite an open source license. There are some restrictions on commercial usage. http://research.microsoft.com/fsharp/fsharp-license.txt -- http://mail.python.org/mailman/listinfo/python-list
Re: About alternatives to Matlab
I doubt that anyone would dispute that even as boosted by Numpy/Scipy, Python will almost certainly be notably slower than moderately well-written code in a compiled language. The reason Numpy exists, however, is not to deliver the best possible speed, but to deliver enough speed to make it possible to solve large numerical problems with the powerful and flexible Python language. As observed by Hans Latangen in _Python Scripting for Computational Science_, 2nd ed., Springer 2005, scientific computing is more than number crunching: Very often programming is about shuffling data in and out of different tools, converting one data format to another, extracting numerical data from a text, and administering numerical experiments involving a large number of data files and directories. Such tasks are much faster to accomplish in a language like Python than in Fortran, C, C++ or Java. He might well have mentioned the importance of developing nice-looking reports once the analysis is complete, and that development is simpler and more flexible in Python than a compiled language. In principle, I agree that heavy-duty number-crunching, at least if it has to be repeated again and again, should be accomplished by means of a compiled language. However, if someone has to solve many different problems just one time, or just a few times (for example if you are an engineering consultant), there is an excellent argument for using Python + Numpy. Unless it affects feasibility, I opine, computational speed is important primarily in context of regular production, e.g., computing the daily value at risk in a commodity trading portfolio, or making daily weather predictions. I am aware of the power and flexibility of the OCaml language, and particularly that an OCaml user can easily switch back and forth between interpreted and compiled implementation. I'm attacted to OCaml and, indeed, I'm in the process of reading Smith's (unfortunately not very well-written) _Practical OCaml_. However, I also understand that OCaml supports only double-precision implementation of real numbers; that its implementation of arrays is a little clunky compared to Fortran 95 or Numpy (and I suspect not as fast as Fortran's); and that the available libraries, while powerful, are by no means as comprehensive as those available for Python. For example, I am unaware of the existance of an HDF5 interface for OCaml. In summary, I think that OCaml is an excellent language, but I think that the question of whether to use it in preference to Python+Numpy for general-purpose numerical analysis must rest on much more than its computational speed. Jon Harrop wrote: Filip Wasilewski wrote: Besides of that this code is irrelevant to the original one and your further conclusions may not be perfectly correct. Please learn first about the topic of your benchmark and different variants of wavelet transform, namely difference between lifting scheme and dwt, and try posting some relevant examples or use other topic for your benchmarks. Your lifting implementation is slightly longer and slower than the non-lifting one but its characteristics are identical. For n=2^25 I get: 1.88s C++ (816 non-whitespace bytes) 2.00s OCaml (741 b) 2.33s F# (741 b) 9.83s Your Python (1,002 b) The original python was 789 bytes. Neglecting this issues, I wonder if it is equally easy to juggle arbitrary multidimensional arrays in a statically typed language and do operations on selected axis directly from the interactive interpreter like in the NumPy example from my other post - http://groups.google.com/group/comp.lang.python/msg/a71a5bf00a88ad57 ? I don't know much OCaml so it would be great if you could elaborate on this. It is probably just as easy. Instead of dynamic typing you have parametric polymorphism. If you want to make your function generic over arithmetic type then you can pass in the arithmetic operators. 0.56s C++ (direct arrays) 0.61s F# (direct arrays) 0.62s OCaml (direct arrays) 1.38s OCaml (slices) 2.38s Python (slices) 10s Mathematica 5.1 Note that all implementations are safe (e.g. C++ uses a.at(i) instead of a[i]). So why not use C++ instead of all others if the speed really matters? What is your point here? 1. Benchmarks should not just include two inappropriate languages. 2. Speed aside, the other languages are more concise. Could you please share full benchmark code, so we could make conclusions too? I'll paste the whole programs at the end... I would like to get to know about your benchmark methodology. I wonder if you are allocating the input data really dynamically or whether it's size is a priori knowledge for the compiler. The knowledge is there for the compiler to use but I don't believe any of them exploit it. In this specific context (discrete wavelet transform benchmark), I'd have said that speed was the most important thing after correctness. Not
Re: About alternatives to Matlab
Hans Langtangen, rather. Mark Morss wrote: I doubt that anyone would dispute that even as boosted by Numpy/Scipy, Python will almost certainly be notably slower than moderately well-written code in a compiled language. The reason Numpy exists, however, is not to deliver the best possible speed, but to deliver enough speed to make it possible to solve large numerical problems with the powerful and flexible Python language. As observed by Hans Latangen in _Python Scripting for Computational Science_, 2nd ed., Springer 2005, scientific computing is more than number crunching: Very often programming is about shuffling data in and out of different tools, converting one data format to another, extracting numerical data from a text, and administering numerical experiments involving a large number of data files and directories. Such tasks are much faster to accomplish in a language like Python than in Fortran, C, C++ or Java. He might well have mentioned the importance of developing nice-looking reports once the analysis is complete, and that development is simpler and more flexible in Python than a compiled language. In principle, I agree that heavy-duty number-crunching, at least if it has to be repeated again and again, should be accomplished by means of a compiled language. However, if someone has to solve many different problems just one time, or just a few times (for example if you are an engineering consultant), there is an excellent argument for using Python + Numpy. Unless it affects feasibility, I opine, computational speed is important primarily in context of regular production, e.g., computing the daily value at risk in a commodity trading portfolio, or making daily weather predictions. I am aware of the power and flexibility of the OCaml language, and particularly that an OCaml user can easily switch back and forth between interpreted and compiled implementation. I'm attacted to OCaml and, indeed, I'm in the process of reading Smith's (unfortunately not very well-written) _Practical OCaml_. However, I also understand that OCaml supports only double-precision implementation of real numbers; that its implementation of arrays is a little clunky compared to Fortran 95 or Numpy (and I suspect not as fast as Fortran's); and that the available libraries, while powerful, are by no means as comprehensive as those available for Python. For example, I am unaware of the existance of an HDF5 interface for OCaml. In summary, I think that OCaml is an excellent language, but I think that the question of whether to use it in preference to Python+Numpy for general-purpose numerical analysis must rest on much more than its computational speed. Jon Harrop wrote: Filip Wasilewski wrote: Besides of that this code is irrelevant to the original one and your further conclusions may not be perfectly correct. Please learn first about the topic of your benchmark and different variants of wavelet transform, namely difference between lifting scheme and dwt, and try posting some relevant examples or use other topic for your benchmarks. Your lifting implementation is slightly longer and slower than the non-lifting one but its characteristics are identical. For n=2^25 I get: 1.88s C++ (816 non-whitespace bytes) 2.00s OCaml (741 b) 2.33s F# (741 b) 9.83s Your Python (1,002 b) The original python was 789 bytes. Neglecting this issues, I wonder if it is equally easy to juggle arbitrary multidimensional arrays in a statically typed language and do operations on selected axis directly from the interactive interpreter like in the NumPy example from my other post - http://groups.google.com/group/comp.lang.python/msg/a71a5bf00a88ad57 ? I don't know much OCaml so it would be great if you could elaborate on this. It is probably just as easy. Instead of dynamic typing you have parametric polymorphism. If you want to make your function generic over arithmetic type then you can pass in the arithmetic operators. 0.56s C++ (direct arrays) 0.61s F# (direct arrays) 0.62s OCaml (direct arrays) 1.38s OCaml (slices) 2.38s Python (slices) 10s Mathematica 5.1 Note that all implementations are safe (e.g. C++ uses a.at(i) instead of a[i]). So why not use C++ instead of all others if the speed really matters? What is your point here? 1. Benchmarks should not just include two inappropriate languages. 2. Speed aside, the other languages are more concise. Could you please share full benchmark code, so we could make conclusions too? I'll paste the whole programs at the end... I would like to get to know about your benchmark methodology. I wonder if you are allocating the input data really dynamically or whether it's size is a priori knowledge for the compiler. The knowledge is there for the compiler to use but I don't believe any of them exploit
Re: About alternatives to Matlab
Carl, I agree with practically everything you say about the choice between Python and functional languages, but apropos of Ocaml, not these remarks: In the same way that a screwdriver can't prevent you from driving a nail. Give me a break, we all know these guys (Haskell especially) are designed to support functional first and other paradigms second. Way second. That's quite enough imposing for me. ... And let's face it, functional languages are (or seem to be) all about purity. As you will see if you look at some OCaml references (there are a number that are available on the OCaml website) that OCaml goes a very long way toward facilitating imperative, procedural methods. It's possible to write perfectly good code in OCaml and not use functional methods. The OCaml people are fond of saying OCaml isn't pure. Indeed, the need for speed is one very good reason to choose and imperative style over a functional one. Carl Banks wrote: Jon Harrop wrote: Carl Banks wrote: 0.56s C++ (direct arrays) 0.61s F# (direct arrays) 0.62s OCaml (direct arrays) 1.38s OCaml (slices) 2.38s Python (slices) 10s Mathematica 5.1 [snip] 1.57s Python (in-place) So, optimized Python is roughly the same speed as naive Ocaml optimized Ocaml is roughly the same speed as C++ Absolutely not: Optimized Python is 14% slower than badly written OCaml. I'd call that roughly the same speed. Did you use any sort of benchmark suite that miminized testing error, or did you just run it surrounded by calls to the system timer like I did? If the latter, then it's poor benchmark, and 10% accuracy is better than you can expect. (Naive tests like that tend to favor machine code.) Given the problem, rather than the Python solution, nobody would write OCaml code like that. Unoptimised but well-written OCaml/C/C++ is 2.5-2.8x faster than the fastest Python so far whilst also requiring about half as much code. Frankly, I have a hard time believing anyone would naively write the Ocaml code like the optimized version you posted. You'd know better than I, though. Optimising the C++ by hoisting the O(log n) temporary array allocations into one allocation makes it another 20% faster. I'm sure there are plenty more optimisations... There aren't any complicated types in the above code. In fact, there are only two types: float and float array. You're vastly underestimating the complexity of numpy objects. They have an awful lot going on under the covers to make it look simple on the surface. There's all kinds of type-checking and type-conversions. A JIT that folds loops together would have to have knowledge of that process, and it's a lot of knowledge to have. That is not easy. My suggestion doesn't really have anything to do with numpy. If you had such a JIT you wouldn't use numpy in this case. That's my point, using numpy encouraged the programmer to optimise in the wrong direction in this case (to use slices instead of element-wise operations). Ok, I can see that. We have a sort of JIT compiler, psyco, that works pretty well but I don't think it's as fast for large arrays as a good numpy solution. But it has more to deal with than a JIT for a statically typed language. I was referring to the slicing specifically, nothing to do with functional programming. My F# and OCaml code are now basically identical to the C++ code. It is pretty strong thing to say that anything is fundamentally bad just because it's not fast as something else. Fundamental badness ought to run deeper than some superficial, linear measure. The slice based approach is not only slower, it is longer, more obfuscated and more difficult to optimise. That doesn't just apply to Python and numpy, it also applies to Matlab, Mathematica etc. Which begs the question, if you were writing in a compiled language like F# would you ever use slices? If I was writing in F#? I absolutely would, because some problems are most cleanly, readably, and maintainably done with slices. I don't have any speed-lust, and I don't waste time making things fast if they don't need to be. I would rather spend my time designing and implementing the system, and optimizing things that actually need it. I don't want to spend my time tracking down some stupid indexing error. If it was critical for it to be fast, then I'd pull out the stops and write it as efficiently as possible. In my experience, a typical middle size program will have half a dozen or so subroutines where it's critical to be as fast as possible. Will any other F# people do it? I don't know if they all have speed-lust, or if they'd all deliberately avoid slicing to prove some kind of point about functional programming and/or non-machine-compiled languages, but I assume there'd be some who would do it for the same reasons I'd do it. Now, I was going to write
