Post by thread:[EE] Python experience (was [EE] Language suggesti

Below is a message I sent to PicList almost a month ago. I didn't realize that I sent it from the wrong account, and to the wrong e-mail (spam_OUTspamTakeThisOuTpiclist.com). Oops. :) ========== I just wanted to thank everyone who responded to my post about parsing a text file, and to share my experience. Since Python was recommended by the majority of responders, I decided to give it a try. I needed to convert some old PDF bank statements into a QIF that I could then import into Quicken. Initially, I was simply trying to fix the lines pasted from the PDF, and fed them to the csv2qif Excel macro: http://xl2qif.chez-alice.fr/links_en.php Unfortunately, Quicken did not like the format, but luckily the QIF turned out to be simple enough where I was able to decipher what the fields meant by looking at a "proper" QIF file, and writing a couple of lines in Python to create a simple converter. It took a bit of trying, but I did it -- and now I think I like Python. I was even able to add some icing which I wasn't planning for originally, like strip out unnecessary stuff from the transaction description ("Machine ID 0000000", etc), abbreviate long strings ("Credit Card Purchase" -> "CCP"), and extract the last four digits of the credit card for easy reference. I'd like to learn more about the language, can someone recommend a good book on Python? Also, are there any RAD tools for Python? If not, is it difficult to call Python executables (py2exe'd) from other programs? Vitaliy

Vitaliy <spam <at> maksimov.org> writes: > Python There is a good book on Python from O'Reilly, and there are several RADs: http://wiki.python.org/moin/GuiProgramming You wrote that 'touching non-rad tools' is not good. I disagree. Some text based programming tools yield amazing guis without any rad tools (but they can do rad). tcl/tk comes to mind here, and derivatives that use tk (including Python). The problem I see with py is that it is a very abstract high level language and it tries to be Haskell and other things. To understand this statement, one must look at a few web applications that appear short and nice, but *require* the Twisted framework, which is ... twisted. 2.5MB of Python source. Twisted has its own O'Reilly book and there is a picture of a tangle of snakes on the cover. That is not a coincidence. (I am not a py person) Peter P.

Peter P wrote: > You wrote that 'touching non-rad tools' is not good. I disagree. Some text > based > programming tools yield amazing guis without any rad tools (but they can > do > rad). tcl/tk comes to mind here, and derivatives that use tk (including > Python). I'm sure you can write good GUIs in Assembler, but my point is that the effort required is less with RAD. I'm sure some will disagree. That's OK, I know there are lots of people on this list who prefer a text based interface to point-and-click. I definitely prefer point-and-click, whenever practical. Vitaliy

Vitaly, I learned Python using Mark Pilgrim's "Dive Into Python" book which was recommended to me by a long-time Python programmer. Alden Vitaliy wrote: {Quote hidden}> Below is a message I sent to PicList almost a month ago. I didn't realize > that I sent it from the wrong account, and to the wrong e-mail > (spamKILLspampiclist.com). Oops. :) > > ========== > > I just wanted to thank everyone who responded to my post about parsing a > text file, and to share my experience. > > Since Python was recommended by the majority of responders, I decided to > give it a try. I needed to convert some old PDF bank statements into a QIF > that I could then import into Quicken. Initially, I was simply trying to fix > the lines pasted from the PDF, and fed them to the csv2qif Excel macro: > > http://xl2qif.chez-alice.fr/links_en.php > > Unfortunately, Quicken did not like the format, but luckily the QIF turned > out to be simple enough where I was able to decipher what the fields meant > by looking at a "proper" QIF file, and writing a couple of lines in Python > to create a simple converter. > > It took a bit of trying, but I did it -- and now I think I like Python. I > was even able to add some icing which I wasn't planning for originally, like > strip out unnecessary stuff from the transaction description ("Machine ID > 0000000", etc), abbreviate long strings ("Credit Card Purchase" -> "CCP"), > and extract the last four digits of the credit card for easy reference. > > I'd like to learn more about the language, can someone recommend a good book > on Python? > > Also, are there any RAD tools for Python? If not, is it difficult to call > Python executables (py2exe'd) from other programs? > > Vitaliy > >

> I'm sure you can write good GUIs in Assembler, but my point is that the > effort required is less with RAD. > > There is a lot of stuff in between assembler and rad. my opinion is that rad is great for quick throwaway guis but for doing a polished gui it doesn't really save you that much work as you end up doing quite a bit of UI related stuff from code anyway. Also IMO rad tools tend to encorage an unstructured copy and paste approach while working from code encorages elimination of duplication. finally there is the issue of version control, if your form format is not text based or your builder has a habbit of rearranging the sections for no good reason it is going to be a PITA to maintain your project through a version control system.

peter green wrote: >> I'm sure you can write good GUIs in Assembler, but my point is that the >> effort required is less with RAD. > finally there is the issue of version control, if your form format is not > text based or your builder has a habbit of rearranging the sections for > no good reason it is going to be a PITA to maintain your project through > a version control system. This is not only a question of version control, it is also a question of debugging and making your code work well. If such a tool rearranges lines for no good reason, then file history and diffs between revisions are practically meaningless -- which is a huge setback for any product maintenance efforts and for writing code with low bug counts. FWIW, I have found VS2003 to play rather "nice" in this regard. Gerhard

peter green wrote: >> I'm sure you can write good GUIs in Assembler, but my point is that the >> effort required is less with RAD. >> >> > There is a lot of stuff in between assembler and rad. > > my opinion is that rad is great for quick throwaway guis but for doing a > polished gui it doesn't really save you that much work as you end up > doing quite a bit of UI related stuff from code anyway. I've worked on two large, many-year, professional apps with Delphi and observed some others. It certainly doesn't prevent writing code, but IME it makes creating and evolving the UI much easier than large commercial apps I've done in (say) C++/MFC. And much easier to understand someone else's code, too. > Also IMO rad > tools tend to encorage an unstructured copy and paste approach while > working from code encorages elimination of duplication. I think programmers who "get" code reuse are happy making reusable visual components, and those who don't are happy cutting and pasting vast sections of code. > finally there is the issue of version control, if your form format is > not text based or your builder has a habbit of rearranging the sections > for no good reason it is going to be a PITA to maintain your project > through a version control system. These are definitely considerations for any GUI builder, but all-text forms have been in Delphi for years; I've never seen them rearranged for no good reason. I think they're rearranged if you change creation order, but that's no different than doing the same thing in code. -- Timothy J. Weber http://timothyweber.org

Core Python Programming for me, was pretty good, a little light on threading and IPC but not too bad. Alden Hart wrote: {Quote hidden}> Vitaly, > > I learned Python using Mark Pilgrim's "Dive Into Python" book which was > recommended to me by a long-time Python programmer. > > Alden > > Vitaliy wrote: > >> Below is a message I sent to PicList almost a month ago. I didn't realize >> that I sent it from the wrong account, and to the wrong e-mail >> (.....spamKILLspam.....piclist.com). Oops. :) >> >> ========== >> >> I just wanted to thank everyone who responded to my post about parsing a >> text file, and to share my experience. >> >> Since Python was recommended by the majority of responders, I decided to >> give it a try. I needed to convert some old PDF bank statements into a QIF >> that I could then import into Quicken. Initially, I was simply trying to fix >> the lines pasted from the PDF, and fed them to the csv2qif Excel macro: >> >> http://xl2qif.chez-alice.fr/links_en.php >> >> Unfortunately, Quicken did not like the format, but luckily the QIF turned >> out to be simple enough where I was able to decipher what the fields meant >> by looking at a "proper" QIF file, and writing a couple of lines in Python >> to create a simple converter. >> >> It took a bit of trying, but I did it -- and now I think I like Python. I >> was even able to add some icing which I wasn't planning for originally, like >> strip out unnecessary stuff from the transaction description ("Machine ID >> 0000000", etc), abbreviate long strings ("Credit Card Purchase" -> "CCP"), >> and extract the last four digits of the credit card for easy reference. >> >> I'd like to learn more about the language, can someone recommend a good book >> on Python? >> >> Also, are there any RAD tools for Python? If not, is it difficult to call >> Python executables (py2exe'd) from other programs? >> >> Vitaliy >> >> >> > >

In my experience I've found Python to be way cool and wonderfully cross-platform (i.e., Linux as well as Windows), not to mention free <grin>. Perfect for real-time PC interaction with PIC via serial port (my favorite, so quick, easy, cheap, and bulletproof) or USB. Unfortunately GUI support is not its strength, but I'd recommend wxWindows (recently renamed "wxWidgets" over tk, although I can't comment on its (advertised) cross-platform strength, as I use in only on Windows. Works well, powerful, no major bugs, and free. Only complaint is limited number of UI widgets and a slightly 'dated' appearance; i.e., looks more like MFC vintage rather than new .Net stuff. But if this is a serious objection for you you need to pay Microsoft small fortune for .Net compilers and spend a few months teaching yourself C# and either Windows Forms or asp.net. And good luck talking directly to RS232 or USB ports in .net. Give me Python any day of the week unless you're writing an ERP app! Don --------------------------------------------------- Don Rahmlow TC2 Consulting Services http://www.tc2.net "Where business, people, and technology intersect!" 207.553.3000 --------------------------------------------------- {Original Message removed}

On 10/11/07, Don Rahmlow <EraseMEdrahmlowspam_OUTTakeThisOuTtc2.net> wrote: > In my experience I've found Python to be way cool and wonderfully > cross-platform (i.e., Linux as well as Windows), not to mention free <grin>. > Perfect for real-time PC interaction with PIC via serial port (my favorite, > so quick, easy, cheap, and bulletproof) or USB. pyserial and pyusb are both quite nice. I found a bug in pyusb and did some tests and the author is so kind to put my name (along with Mark Rages) in the list of contributors. pyusb is at http://pyusb.berlios.de/. The other libusb wrapper is in the BitPim project. Mark Rages is using that wrapper in pyk (Python based PICkit 2 host application). http://www.bitpim.org/pyxr/c/projects/bitpim/src/native/usb/ Personally I like pyusb more. > Unfortunately GUI support is not its strength, but I'd recommend wxWindows > (recently renamed "wxWidgets" over tk, although I can't comment on its > (advertised) cross-platform strength, as I use in only on Windows. Works > well, powerful, no major bugs, and free. Only complaint is limited number of > UI widgets and a slightly 'dated' appearance; i.e., looks more like MFC > vintage rather than new .Net stuff. I briefly looked at wxWidgets and gave up. I actually asked my youngest brother to write a GUI for me with wxWidgets but he did not liked it either. He preferred to use ncurse under Unix/Linux. He works for ZTE, a leading telecom equipment provider in China (http://en.wikipedia.org/wiki/ZTE). > But if this is a serious objection for > you you need to pay Microsoft small fortune for .Net compilers and spend a > few months teaching yourself C# and either Windows Forms or asp.net. And > good luck talking directly to RS232 or USB ports in .net. Even I am also a fan of Python but you are not correct on C# with RS232 and USB. DotNet 2.0 comes with free components for serial communications. http://msdn2.microsoft.com/library/30swa673(en-us,vs.80).aspx You can use the free Visual Studio 2005 Express Edition to use the serial components. There are way more examples of USB examples in C# than in Python. Just look at http://www.lvr.com and you will know this (usb and serial communication under dotnet). If you object, take the challenge to write a Python wrapper for WinUSB. ;-) Just kidding and you do not need to take the challenge. http://forum.microchip.com/tm.aspx?m=283064 http://forum.microchip.com/tm.aspx?m=264046 Xiaofan