Re: Help please with code to find and move files.
> path = r"c:\\" I don't know if this is the whole problem, but this line should read r'c:\' (one backslash). -- http://mail.python.org/mailman/listinfo/python-list
Re: Help please with code to find and move files.
> > after changing i got this > > path = r"c:\" > ^ > SyntaxError: EOL while scanning single-quoted string Sorry about that. You can't end with a backslash - my bad. I just tried this in the interpreter and 'c:' works. -- http://mail.python.org/mailman/listinfo/python-list
vim newb - indenting python comments
I'm just starting to use vim. It has helped me do a lot of repetitive editing of Python files. One problem I have is that the >> indent in normal mode doesn't work when a line starts with the # character. Any idea what I'm doing wrong? Thanks in advance for your help. -- http://mail.python.org/mailman/listinfo/python-list
Re: vim newb - indenting python comments
On Jan 4, 7:07 pm, Tim Chase <[EMAIL PROTECTED]> wrote: > > One problem I have is that the >> indent in normal mode doesn't work > > when a line starts with the # character. Any idea what I'm doing > > wrong? > > In short, ">>" *does* indent in normal mode (I presume you > accurately mean "Normal" mode, rather than "Insert" mode). The > question becomes why doesn't it work in your particular copy of Vim? > > To evidence this, start vim with > > vim -u NONE myfile.py > > (which bypasses startup files) and you'll see that >> does indeed > shift commented lines. It worked just as you described. > > To track down the problem, you'll need to provide a little more > info. Starting Vim the way you normally do, pointed at a > problematic python file, what is the output of > > :scriptnames There are 16 in all. I feel a bit foolish in that I had no idea these were being loaded (sourced?). > > What mappings do you have defined: > > :nmap > > (particularly any mappings for ">" and its kin). > > What are your filetype settings: > > :filetype > > What are your settings for 'indentkeys', 'indentexpr', > 'shiftwidth', 'tabstop', 'expandtab' and 'filetype' > > :set indentkeys? indentexpr? sw? ts? et? ft? > > Which version of Vim are you using: > > :version 7.1 under Cygwin on Windows XP > > Hopefully some of those will point you at the problem child. > Otherwise, drop by the Vim mailing list and there are a lot of > other smart cookies there that may have other ideas. > > -tkc Thanks; this is already really helpful. I'm going to try to sift through those 16 scripts and try to familiarize myself with vim customization a bit more. I may be back, but you've given me some help to get over the hump and start learning the tool. Thanks again. -- http://mail.python.org/mailman/listinfo/python-list
Re: Porting VB apps to Python for Window / Linux use
On Oct 19, 12:51 am, Stef Mientki <[EMAIL PROTECTED]> wrote: > Lawrence D'Oliveiro wrote: > > In message <[EMAIL PROTECTED]>, Dotan > > Cohen wrote: > > >> I often see mention of SMBs that either want to upgrade their Windows > >> installations, or move to Linux, but cannot because of inhouse VB > >> apps. > > > Probably best to leave those legacy VB apps alone and develop new > > replacements in a more open, cross-platform language, like Python. > > Sorry but for GUI design, Python is pre-historic ;-) > Stef Some folks below mention wxPython, which (I think) works pretty decently. Another option is IronPython, the dot net based version of Python. Much of it runs under Mono on Linux. The dot Net Windows and controls look decent in both environments (Windows and Linux), and aren't that difficult to code. IronPython has a mailing list; you might want to cross-post there. -- http://mail.python.org/mailman/listinfo/python-list
Re: CAD.py
[EMAIL PROTECTED] wrote: > r> I am currently looking to create a small CAD program with python. > > Instead of starting from scratch how about extending PythonCAD instead: > > http://www.pythoncad.org/ > > Skip ThanCAD might have a few ideas too. Carl T. -- http://mail.python.org/mailman/listinfo/python-list
Re: Grandchildren of TestCase don't work
Gustavo Narea wrote: > Hello, everyone. > > Why do unitest.TestCase grand-grandchildren not work? > > I've created a unittest.TestCase descendant, which contains the setUp() and > tearDown() for testing some components of a web framework. Every > application based on this framework should subclass this base class once, > and the rest of the test cases must also subclass the base TestCase of the > application (which is a direct descendant of my descendant of TestCase). > > But grandchildren of my TestCase don't work, and I get this weird error: > > File "/usr/lib/python2.5/unittest.py", line 248, in run > > testMethod = getattr(self, self._testMethodName) > > AttributeError: 'TestDatabaseGrandChildTesting' object has no > > attribute '_testMethodName' > > Isn't it possible to use grand-grandchildren of unittest.TestCase? > > Please use this file to reproduce it: http://paste.turbogears.org/paste/4721 > > Thanks in advance. > -- > Gustavo Narea. > http://gustavonarea.net/ > > Get rid of unethical constraints! Switch to Freedomware: > http://softwareliberty.com/ I could be wrong, but I think I saw this crossposted on the TIP list - not sure which one was first. -- http://mail.python.org/mailman/listinfo/python-list
