Controlling Excel with win32com
I'm starting to test a python application that creates an Excel workbook, then fills in values for some cells and formulas for other cells. The formulas involve circular references, which will cause Excel to take a little time to update and iterate through the successive approximations of finding a solution to the formulas. (The system should converge pretty well -- no bad behavior expected.) Since Excel runs as a com server in another window, is there anything that the python side of the win32com connection has to do to make sure that it is not calling Excel while Excel is busy recalculating or otherwise processing a previous request? Are the assignments to the cell Value and Formula properties synchronized for me somewhere? I think that I've noticed a run-sometimes/crash-sometimes behavior in this program, but I'm so clueless about what's going on behind the scenes with com that I haven't really tied it down. It seemed to get better behaved when I turned off automatic recalculation, but that does not seem to me to be a guarantee that there will be no timing problems if the messages are not queued somewhere and if there is not some other mechanism to keep things synchronized. What works best? TIA Al -- http://mail.python.org/mailman/listinfo/python-list
Re: IronPython 0.9 Released
EP wrote: > > yes, my apologies to all things Iron and or Python. > > "language" and "version" can be confusing if one stays up late without > coffee, or perhaps if one has not been debugging their English code properly. > Still, it's a bit of a PITB to me that it says XP and not Win2000. Al -- http://mail.python.org/mailman/listinfo/python-list
Re: PyChecker lives, version 0.8.15 released
Neal Norwitz wrote:
> Special thanks to Ken Pronovici. He did a lot of work for this
> release and helped ensure it occurred.
>
> Version 0.8.15 of PyChecker is available. It's been over a year since
> the last release. Wow, time really does fly. Since it's been so long
> I'm sure I screwed something up, treat it delicately. It may have bugs
> and erase your hard drive. If that happens, look on the bright side,
> you won't have any more bugs. :-)
>
> PyChecker is a tool for finding bugs in Python source code.
> It finds problems that are typically caught by a compiler for less
> dynamic languages, like C and C++. It is similar to lint.
>
> Comments, criticisms, new ideas, and other feedback is welcome.
>
> Since I expect there may be a bit more bugs than normal, I will try to
> put out another release in a few weeks. Please file bug reports
> including problems with installation, false positives, &c on Source Forge.
> You are welcome to use the mailling list to discuss anything pychecker
> related, including ideas for new checks.
>
> Changes from 0.8.14 to 0.8.15:
>
> * Fix spurious warning about catching string exceptions
> * Don't barf if there is # -*- encoding: ... -*- lines and unicode strings
> * setup.py was rewritten to honor --root, --home, etc options
> * Fix internal error on processing nested scopes
> * Fix constant tuples in Python 2.4
> * Don't warn about implicit/explicit returns in Python 2.4, we can't tell
> * Fix crash when __slots__ was an instance w/o __len__
> * Fix bug that declared {}.pop to only take one argument, it takes 1 or 2
> * Fix spurious warning when using tuples for exceptions
> * Fix spurious warning /
> * Fix spurious warnings for sets module about __cmp__, __hash__
> * Changed abstract check to require raising NotImplementedError
> rather than raising any error
> * Fix spurious warnings in Python 2.4 for Using is (not) None warnings
> * Fix spurious warnings for some instances of No class attribute found
> * Fix spurious warnings for implicit returns when using nested functions
>
> PyChecker is available on Source Forge:
> Web page: http://pychecker.sourceforge.net/
> Project page: http://sourceforge.net/projects/pychecker/
> Mailing List: [EMAIL PROTECTED]
>
> Neal
> --
> [EMAIL PROTECTED]
Not to complain, as this is a very useful one-of-a-kind tool, but it
does appear to use more memory than I can imagine how when you run it on
a substantial program. Like a few kilobytes per line of code, maybe.
It's slow, too, but that's ok for the usefulness of it, but trying to
let it run and do something else with someone else's code bloat (like MS
Word or something) in another window leads to something
indistinguishable from system meltdown. Any reason for hope of future
improvements in this regard?
Al
--
http://mail.python.org/mailman/listinfo/python-list
Re: Code to read Cobol data files
none wrote: > Hi, > Any one know of some code to read cobol data files > > thanks > timb I posted some here maybe 5+ years ago that would convert COBOL comp-3, comp-4, and comp-5 fields (as from Realia) to whatever. I suppose you can still find it in google somewhere. There was some help for cracking one of the other COBOL file formats at a site called Wotsit's file formats or something like that. This helped me access data out of ISAM files from one of the non-Realia desktop COBOLs. It was one of the more popular COBOL versions way back in the 1980's, but I don't recall anymore which one it was, but I'd guess RM Cobol if I had to. COBOL has/had an indexed file type defined in the language, and the COBOL vendors each implemented it independently, I think. So there are variations in both the coding of various field/record types and the way that the files are put together. But Python can handle it if you can figure out the rules. Al -- http://mail.python.org/mailman/listinfo/python-list
Article on Hi-Fi Myths
I learned Friday night that the hi-fi talk is our most popular tape. This page: http://www.belt.demon.co.uk/product/Cable_Controversy/Cable_Controversy.htm Gives a somewhat different take on the controversy, almost certainly bizarre. It's a long page and the interesting part is near the end. The conclusion is: "you just need to know what techniques to use to create a 'friendly', 'relaxing', energy pattern." Al -- http://mail.python.org/mailman/listinfo/python-list
Re: Working with Huge Text Files
I did some similar stuff way back about 12-15 years ago -- in 640k MS-DOS with gigabyte files on 33 MHz machines. I got good performance, able to bring up any record out of 10 million or so on the screen in a couple of seconds (not using Python, but that should not make much difference, maybe even some things in Python would make it work better.) Even though my files were text, I read them as random-access binary files. You need to be able to dive in at an arbitrary point in the file, read a chunk of data, split it up into lines, discarding any partial lines at the beginning and end, pull out the keys and see where you are. Even with a gigabyte of file, if you are reading a decent size chunk, you can binary search down to the spot you want in 15-20 tries or so. That's the first time, but after that you've got a better idea where to look. Use a dictionary to save the information from each chunk to give you an index to get a headstart on the next search. If you can keep 10k to 100k entries in your index, you can do 1000's of searches or so before you even have to worry about having too many index entries. I did learn that on 32-bit hardware, doing a binary search of a file over a gigabyte will fail if you calculate the next place to look as (a+b)/2, because a+b can be more than 2GB and overflow. You gotta do (a + (b-a)/2) Al -- http://mail.python.org/mailman/listinfo/python-list
Re: Working with Huge Text Files
Michael Hoffman wrote: [EMAIL PROTECTED] wrote: It will only be this simple if you can guarantee that the original file is actually sorted by the first field. And if not you can either sort the file ahead of time, or just keep reopening the files in append mode when necessary. You could sort them in memory in your Python program but given the size of these files I think one of the other alternatives would be simpler. There used to be a very nice sort program for PC's that came from someplace in Nevada. It cost less than $100 and could sort files faster than most programming languages could read or write them. For linux, you've gotta figure out the posix sort. If you do, please splain it to me. Al -- http://mail.python.org/mailman/listinfo/python-list
Re: Best GUI for small-scale accounting app?
Web browser "widgets" seem pretty limited to me, though. You don't even have something as simple as a combo box (i.e. an editable entry with a drop down), let alone the rich set of widgets something like wxwidgets offers. Also web development doesn't seem as coherent to me as development with a good GUI framework. I think it depends on your target audience. Many people love simplicity. wxPython has an HTML control that lets you do most of your UI web-like and just drop in the other wxWidgets kinds of controls here and there if you need to. The html control does most of the rendering and such, and you can do most of the user interaction with standard clickable links, etc, but you can also mix in the full boat of high-powered gizmos to perplex the users when you run out of other tactics and annoyances. Is it pretty? As a conglomerate with features of a desktop app and features of a browser-based app, it's kind of pretty like a platypus. Platypus, penguin, or python, there's many a way to lay an egg. Al -- http://mail.python.org/mailman/listinfo/python-list
ntvdm problem on win2k
I started having some problems running python programs (python 2.3) from the Win2k command line. I would get crashes with an NTVDM error. Even just executing python would cause it. I upgraded to python 2.3.5, and no difference. When I rearranged my path to move cygwin and a bunch of other stuff (.net, etc) after C:\python23, the problem went away. Is this problem known to anyone but me? Any diagnosis, solution of 12 or fewer steps, or support group? If I'm distributing python programs (python 2.3.5 packaged with py2exe) should I warn or notify the recipients that this is a possible problem with the programs? TIA Al -- http://mail.python.org/mailman/listinfo/python-list
Re: ntvdm problem on win2k
Here's some more info on this: When I use the Win2k feature to search for files, it turns up python.exe in the \cygwin\bin directory. The file size is shown as 24 bytes. Mighty small for an executable. The file is hidden. This is evidently the guy who was caussing the problem. Why does cygwin include a hidden file that hides python on the path? Al Christians wrote: I started having some problems running python programs (python 2.3) from the Win2k command line. I would get crashes with an NTVDM error. Even just executing python would cause it. I upgraded to python 2.3.5, and no difference. When I rearranged my path to move cygwin and a bunch of other stuff (.net, etc) after C:\python23, the problem went away. Is this problem known to anyone but me? Any diagnosis, solution of 12 or fewer steps, or support group? If I'm distributing python programs (python 2.3.5 packaged with py2exe) should I warn or notify the recipients that this is a possible problem with the programs? TIA Al -- http://mail.python.org/mailman/listinfo/python-list
Re: ntvdm problem on win2k
Alexander Schremmer wrote: Windows tries to execute the cygwin symbolic link and fails. Correcting your path works (as you said). One thing about that: I re-installed python (ie upgraded to python 2.3.5) and it did not solve the error. I assume that the python 2.3.5 installer is so well-mannered that it did not put itself at the head of the path, but saw that it was already in the path somewhere, and left itself there. This is nice, but it was disappointing, in that I did a fresh install to no avail. And, is it not fairly common for other installers of less refined software to add to the head of the path each time that they run, no matter how many times the same entry is repeated. So, by being very nice, python is sort of non-conformist or nearly eccentric, which I wish everyone would be. But how can one despise 99% of everything? When I installed cygwin, I checked it for python. It had something like python2.4.1.exe visible, but that symbolic link was not. No big deal. Al -- http://mail.python.org/mailman/listinfo/python-list
