Re: [Tutor] unwanted 'zero' ending
On 27/06/13 07:40, Jim Mooney wrote: I've been staring at this program for hours, I'm not surprised. It's very cluttered. Take the constant definitions out of the function. Take the internal function out of the function. Create a few more helper functions and then get rid of the "helpful comments" that only describe what a function should be doing (get triplets etc) Then there is a confusion of how you print stuff. The bigger multiples (thousand up) are defined in data but the hundreds are defined inline. And I never did find where zero got printed because it was all too confusing. By the way, how large is Python's standard GUI input allowed to be, and can you expand it without resorting to tkinter? TKinter *is* Python's standard GUI toolkit. What do you mean? -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] unwanted 'zero' ending
> > TKinter *is* Python's standard GUI toolkit. > > What do you mean? > > I just meant, how many characters are allowed on the input screen you > normally get when you put input() in a program, There is no "input screen" in normal use, it appears on stdout in the console. How are you running your Python programs? Alan G.___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] unwanted 'zero' ending
> Since the program has an error And needs simplification (no doubt > interdependent), but it would be hard to do both at once, this brings > up a good general question: Is it best, in such cases, to correct the > error, then simplify, or simplify, then correct the error? In general I'd simplify first since that will help me see the wood from the trees and help me find the error. Indeed simplifying the code may remove the error... But once simplified - including writing helper functions - you can then test each subfunction independently without having to test the whole program in one go. That alone makes it easier to find the error. Alan g.___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] unwanted 'zero' ending
On 27/06/13 18:30, Peter Otten wrote:
Jim Mooney wrote:
On 27 June 2013 00:43, Alan Gauld wrote:
Take the constant definitions out of the function
Since the program has an error And needs simplification (no doubt
interdependent), but it would be hard to do both at once, this brings
up a good general question: Is it best, in such cases, to correct the
error, then simplify, or simplify, then correct the error?
That depends. Ideally you'd have unittests to ensure that you aren't
introducing new errors with the simplification process.
So if you don't have them already now is the time to formalize your ad-hoc
tests.
Unit tests are great, but the learning curve is rather steep. I recommend that
you start with doctests.
When you write a function, add a docstring ("documentation string") that
explains what the function does. Include examples showing how it is expected to work:
def num_to_name(number):
"""Return the English name of int number.
>>> num_to_name(42)
'forty-two'
>>> num_to_name(3579)
'three thousand five hundred and seventy-nine'
"""
[code goes here as normal]
The examples must be formatted as if they were copied and pasted from the standard
Python interpreter, complete with leading >>> prompt. The doctest module will
detect those examples, run them, and report on any errors. From the shell:
python -m doctest "C:/path/to/module/to/test.py"
If there are no errors, doctest won't print anything, otherwise it will print
any errors. An error is:
* anything that raises an exception;
* anything that returns something other than the example shown.
To see all the tests as they run:
python -m doctest "C:/path/to/module/to/test.py" --verbose
Once you get used to the quirks of doctest, and there are a few, I hope you
will love it as much as I do. They make both great documentation and good tests!
--
Steven
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
[Tutor] True to False and Other things!
In my game, I am trying to make it so when the enemy's health equals 0, the player advances. I used a while statement and a true or false variable. When the enemy health is less than or equal to 0, the program exits the while statement. It does not work. It keeps going. How could I fix this? ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] True to False and Other things!
On 06/27/2013 09:27 AM, Jack Little wrote: In my game, I am trying to make it so when the enemy's health equals 0, the player advances. I used a while statement and a true or false variable. When the enemy health is less than or equal to 0, the program exits the while statement. It does not work. It keeps going. How could I fix this? You could try changing the value of that true/false variable inside the loop. Have you made the dozens of changes suggested by various people here? And as another hint, do you understand what local variables are, and that local variables in one function do not normally have any effect on local variables in another? I suggest you temporarily forget the larger program, and write a small one that demonstrates your symptom. Write a while-loop inside a function that tests some variable. Write a body of that loop which changes the variable, presumably when some condition changes. And see if it ever terminates. If it shows the same symptom, and you cannot see the reason, then post it here. The entire program. And explain clearly what you expected and in what way it did something different. In case you can't tell, the explanation you gave above was not clear. You said that the program exits the loop, and then you said the loop kept going. Presumably one of them was an EXPECTATION and the other was reality. Of course, there are some other things you could have meant, like that the program kept going after the loop. But I doubt it. -- DaveA ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Need help appending data to a logfile
On 06/27/2013 10:55 AM, Matt D wrote:
On 06/27/2013 10:36 AM, Matt D wrote:
You asked about a "save-as" feature. Why isn't that as simple as
copying the current contents of the saved csv file? Or do you not know
how you would go about copying?
Hi. So I have the logger working, meaning the correct data is being
written to the 'internal' file 'logfile.txt' which is opened like this:
self.logfile = open('logfile.txt', 'a')
And I have the button that starts the file dialog like this:
#open file dialog -
def openFile(self, evt):
with wx.FileDialog(self, "Choose a file", os.getcwd(), "",
"*.*", wx.OPEN) as dlg:
if dlg.ShowModal() == wx.ID_OK:
path = dlg.GetPath()
mypath = os.path.basename(path)
with open(mypath, "a") as f:
Is there a simple way to copy what is in the 'internal' logfile.txt to
the file that the user chooses from the button?
Thanks!
shutil.copy(src, dst)
See: http://docs.python.org/2/library/shutil.html#shutil.copy
I forgot to mention i have the 'with open(mypath, "a") as f: commented
out because it was making an indentation error that i could not fix.
It was indented, and should not have been. The extra indentation
FOLLOWS the with statement, it's not correct to indent the line itself.
Line it up with mypath=
Isn't the rule for indentation simple enough? If a line ends with a
colon, you indent the next line. And keep indenting till the scope of
that colon ends. I don't know of any exceptions, but if there are any,
they're rare. Anyway, when the compiler complains, there aren't many
choices on how to change the line, so experimentation should teach you
pretty quickly.
Maybe you're getting confused about indentation because your editor
doesn't handle tabs correctly. If you mix tabs and spaces, you'll drive
yourself crazy, at least with 2.x Python 3 tells you about it with a
new error. The easy answer (and my strong preference) is to never use
tabs in Python sources. Expand all your existing tabs (to 4 column
intervals), and tell your editor to always expand the tab key when entering.
I suggest you fix this problem first, and understand the fix, before
going off and using shutil.copy().
--
DaveA
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Need help appending data to a logfile
On 06/27/2013 12:33 PM, Matt D wrote: I forgot to mention i have the 'with open(mypath, "a") as f: commented out because it was making an indentation error that i could not fix. It was indented, and should not have been. The extra indentation FOLLOWS the with statement, it's not correct to indent the line itself. Line it up with mypath= Isn't the rule for indentation simple enough? If a line ends with a colon, you indent the next line. And keep indenting till the scope of that colon ends. I don't know of any exceptions, but if there are any, they're rare. Anyway, when the compiler complains, there aren't many choices on how to change the line, so experimentation should teach you pretty quickly. Maybe you're getting confused about indentation because your editor doesn't handle tabs correctly. If you mix tabs and spaces, you'll drive yourself crazy, at least with 2.x Python 3 tells you about it with a new error. The easy answer (and my strong preference) is to never use tabs in Python sources. Expand all your existing tabs (to 4 column intervals), and tell your editor to always expand the tab key when entering. I suggest you fix this problem first, and understand the fix, before going off and using shutil.copy(). Thanks! I do have 'with open(mypath, "a") as f:' lined up with the mypath line above (not sure why it indented with the paste to email) and I already replaced all tabs with spaces. seriously there is not one single tab in the whole program. but when that line is not commented out the program bails with the indentation error, other wise its fine. . So i don't know what i can do about that. Thanks! What text editor are you using? Can you literally move the cursor one column at a time and see what column each of those two lines are in? It's a little hard to imagine your email program converting all those spaces to tabs. If it were my file, and I got to this point, I'd be using a dump program to look at the actual file. Or I'd configure my text editor for 40-column tabs, to make them very visible and very obnoxious. In Linux, use tweak, or any of dozens of others. Likewise there are lots in Windows -- no idea what one to suggest. -- DaveA ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Need help appending data to a logfile
On 06/27/2013 05:09 PM, Matt D wrote: On 06/27/2013 12:54 PM, Dave Angel wrote: On 06/27/2013 12:33 PM, Matt D wrote: I forgot to mention i have the 'with open(mypath, "a") as f: commented out because it was making an indentation error that i could not fix. It was indented, and should not have been. The extra indentation FOLLOWS the with statement, it's not correct to indent the line itself. Line it up with mypath= Isn't the rule for indentation simple enough? If a line ends with a colon, you indent the next line. And keep indenting till the scope of that colon ends. I don't know of any exceptions, but if there are any, they're rare. Anyway, when the compiler complains, there aren't many choices on how to change the line, so experimentation should teach you pretty quickly. Maybe you're getting confused about indentation because your editor doesn't handle tabs correctly. If you mix tabs and spaces, you'll drive yourself crazy, at least with 2.x Python 3 tells you about it with a new error. The easy answer (and my strong preference) is to never use tabs in Python sources. Expand all your existing tabs (to 4 column intervals), and tell your editor to always expand the tab key when entering. I suggest you fix this problem first, and understand the fix, before going off and using shutil.copy(). Thanks! I do have 'with open(mypath, "a") as f:' lined up with the mypath line above (not sure why it indented with the paste to email) and I already replaced all tabs with spaces. seriously there is not one single tab in the whole program. but when that line is not commented out the program bails with the indentation error, other wise its fine. . So i don't know what i can do about that. Thanks! What text editor are you using? Can you literally move the cursor one column at a time and see what column each of those two lines are in? It's a little hard to imagine your email program converting all those spaces to tabs. If it were my file, and I got to this point, I'd be using a dump program to look at the actual file. Or I'd configure my text editor for 40-column tabs, to make them very visible and very obnoxious. In Linux, use tweak, or any of dozens of others. Likewise there are lots in Windows -- no idea what one to suggest. I use gedit. Yes sir, its all spaces, I'm not putting you on there are no tabs in my .py file. none. I am pretty sure if i knew how to put the proper code after the 'with open()' thing, indented of course, that the indentation error would be gone. But Ive been looking at the shutil thing and i can not figure out how to write the right code to go after the 'open with()' that will make whats in 'logfile.txt' get appended into whatever file the user opens. So you're saying that the exception was on the following line? Why didn't you say so? I just assumed you had clipped the remaining lines of the function when you posted it. So, the way to get rid of this new indentation error is to add a pass statement inside the with clause. Indent it by 4 columns. If that works, then you'll know how to deal with it next time. As for the shutil.copy() function, how complex can it be? It takes two file names, source and destination. It does not need a with statement since it wants strings, not file handles. You might get into trouble on some OS's with the source file already open, but since you open it with append, it should be trivial to close and reopen it. -- DaveA ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
[Tutor] python / gtk / Webkit app wrapper.
Greetings all,
Was wondering if one of you fine python wizards could help me with trying
to fix a python / gtk / Webkit app wrapper.
Here is a simple version of what I am trying to do.
http://pastebin.com/2zi0SgfT
The HUGE hurdle I am having is activating the Webkit spell checker for
forms.
from gtkspellcheck import SpellChecker
window = gtk.Window(gtk.WindowType(0))
view = gtk.TextView()
spellchecker = SpellChecker(view)
works fine for a text / editor type window but
win = gtk.Window(gtk.WindowType(0))
web = webkit.WebView()
spellchecker = SpellChecker(web)
returns
Traceback (most recent call last):
File "main_wrapper.py", line 24, in
spellchecker = SpellChecker(web)
File "/usr/local/lib/python2.7/dist-packages/gtkspellcheck/spellcheck.py",
line 222, in __init__
self.buffer_initialize()
File "/usr/local/lib/python2.7/dist-packages/gtkspellcheck/spellcheck.py",
line 258, in buffer_initialize
self._buffer = self._view.get_buffer()
AttributeError: 'webkit.WebView' object has no attribute 'get_buffer'
I also tried this and it appears to run ie no errors BUT does not highlight
misspellings?
settings = webkit.WebSettings()
settings.set_property('enable-spell-checking', True)
Any help would be greatly appreciated
Darin
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] python / gtk / Webkit app wrapper.
On 27/06/13 22:57, Darin Lawson Hosking wrote: Greetings all, Was wondering if one of you fine python wizards could help me with trying to fix a python / gtk / Webkit app wrapper. This list is for people learning the Python language and its standard library. For info on GTk and Webkit you should probably try more specialised fora or possibly the main Python mailing list/newsgroup. Otherwise its a matter of pure luck whether anyone here knows about those libraries. -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] unwanted 'zero' ending
On 06/27/2013 07:39 PM, Jim Mooney wrote:
On 27 June 2013 05:38, Steven D'Aprano wrote:
Unit tests are great, but the learning curve is rather steep. I recommend that
you start with doctests.
I tried a simple one and it worked, but a puzzlement. Does it Only
test what you've hard-coded?
Precisely. There's no way that it could test anything else, since it
has no way of reading your mind to see what you intended.
That is, here is a simple test:
def doubler(inp):
'''Return a doubled number or string
>>> doubler(24)
48
>>> doubler('zark')
'zarkzark'
'''
return inp * 2
This works on 24 or 'zark' as input when I run
C:\Python33\Jimprogs>python -m doctest
"C:/python33/jimprogs/docstringtest.py" --verbose'
and doctest prints:
48
zarkzark
And it fails if I put 'this doesn't work' as the return value of the function:
1 items had failures:
2 of 2 in docstringtest.
***Test Failed*** 2 failures.
Although that doesn't tell me much.
But it also works on different input --> 189 and 'plantagenet,' to print:
378
plantagenetplantagenet
It's odd to me that it doesn't fail on what I haven't hardcoded.
I don't see how docstring could figure what I might be doing, so I
assume that although it returns anything valid, it Only tests on the
hardcoded values, 24 and 'zark'. Is this correct? In which case it
seems like a lot of hard coding would be needed unless you tested only
endpoints or what might be problematic.
Or is it doing something more?
Nope. it is limited to the tests you write. And those tests are
necessarily fairly simple. That's why there are other testing frameworks
which support much more, with a much higher learning curve. But you'd
be surprised how much code that's written that gets no useful repeatable
testing at all. Or how much software that has tests which are seldom
run before a release.
I've seen software released for which the source code didn't even exist,
and couldn't readily exist... "Hack something together, just get it
'working'" That was when i was just transferring into a department, and
it never happened again.
--
DaveA
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] python / gtk / Webkit app wrapper.
Thank you both for the response
Alan - This is my first python program (actually first anything, besides
simple one line shell scripts) and if I broke protocol I do apologize.
eryksun - that did it after pulling out the indention after I copy pasted
:) BUT it is missing the (right click suggested spellings menu)
Now off to find that :) if you happen to know of some docs on where I could
find that I would appreciate a lead.
Thank you again
Darin
On Thu, Jun 27, 2013 at 7:07 PM, eryksun wrote:
> On Thu, Jun 27, 2013 at 5:57 PM, Darin Lawson Hosking
> wrote:
> >
> > I also tried this and it appears to run ie no errors BUT does not
> highlight
> > misspellings?
> >
> > settings = webkit.WebSettings()
> > settings.set_property('enable-spell-checking', True)
>
> Try:
>
> web = webkit.WebView()
> web.open('...')
> settings = web.get_settings()
> settings.set_property('enable-spell-checking', True)
> settings.set_property('spell-checking-languages', 'en_GB')
>
> Replace 'en_GB' with your desired language_country code.
>
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] unwanted 'zero' ending
On 06/27/2013 09:32 PM, Jim Mooney wrote: On 27 June 2013 17:05, Dave Angel Nope. it is limited to the tests you write. And those tests are necessarily fairly simple. Hmm, so it seems a lot of trouble for a few hardcoded tests I could run myself from the IDE interpreter window. NO. You're completely missing the point. If you don't automate your tests, you'll be neither consistent nor thorough. You want tests that can be run identically three months from now when you're not sure you even remember what that function does. or ten minutes from now when you change some other function that breaks the way this one works. Or better yet, I could code a loop with some random input, and some extreme cases, and work the function out myself. I guess there is no easy substitute for simply beating up your functions with a slew of garbage, since you're the one who understands them ;') The only substitute for "beating up your functions" is hiring someone else to do it for you. They'll catch things you'll miss, simply because they aren't prejudiced by the "knowledge" that "it must be right." But if all they do is interactive testing, then you've still missed the boat. And you might be amazed what you can accomplish with "simple tests." Most trivial example could be a testing function, whose expected output is either pass or fail. You put a two-line doctest on it, and now your real function gets a real workout. But you can also call things inside a list comprehension, and test that all(mycomp) is True. And so on. Only when you outgrow doctest do you need a testing harness. And at that point, you might actually understand why you need it. -- DaveA ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] unwanted 'zero' ending
On 28/06/13 11:32, Jim Mooney wrote:
On 27 June 2013 17:05, Dave Angel
Nope. it is limited to the tests you write. And those tests are necessarily
fairly simple.
Hmm, so it seems a lot of trouble for a few hardcoded tests I could
run myself from the IDE interpreter window. Or better yet, I could
code a loop with some random input, and some extreme cases, and work
the function out myself. I guess there is no easy substitute for
simply beating up your functions with a slew of garbage, since you're
the one who understands them ;')
I'm afraid that you've missed the point, sorry :-)
Or actually, multiple points.
Firstly, doctests are *documentation first*, and tests secondly. They show by example
what the function does. It is a real pain reading five pages of documentation and at the
end you say, "yes, but what does this function actually *do*???" Examples can
help to make it clear.
The only thing worse than no examples are examples that are wrong.
doubler("3.1415")
6.283
Do you see the subtle bug? If you write a wrong example, you may never realise
it is wrong, and your users will be confused and distressed. Sometimes your
users are *you*, and you wrote the software a long time ago and don't remember
what it is supposed to do but you can't get it to work like the examples show...
But if you do it as a doctest, you will find out that the example is wrong
because the test will fail the first time you run it. Then you can fix the
example while it is still fresh in your mind.
Another point that you missed is that doctests are *automated*, which is much
better than manual testing. Sure, you can always do your own testing at the
interactive interpreter. For instance, I might sit down to test my statistics
module. I can call up the interactive interpreter, and sit down for an hour and
a half and run tests like this:
import statistics
statistics.mean([1, 2, 5, 4, 7, 1, 9, 2])
statistics.stdev([4, 7, 0, 1, 2, 3, 3, 3, 7, 3])
statistics.stdev([])
and so on. And then, tomorrow, when I've made some changes to the code, I have
to do the whole thing again. Over and over again. Who the hell can be bothered?
Certainly not me. That's why testing doesn't happen, or if it does happen, it's
only the most ineffective, obvious, simple tests, the ones which are the least
likely to pick up bugs.
And of course I can't use my own module to test that my module is getting the
right answers! Having to calculate the expected answers by hand (or at least
using a different program) is a lot of work, and I don't want to have to do
that work more than once. If I'm sensible, I'll write the answers down
somewhere, together with the question of course. But then I'm likely to lose
the paper, and even if I don't, I still have to re-type it into the interpreter.
But with *automated tests*, I only need to pre-calculate the answers once, put
them into a suite of tests, and the computer can run them over and over again.
I can start off with one test, and then over time add more tests, until I have
five hundred. And the computer can run all five hundred of them in the time I
could manually do one or two.
Instead of needing the discipline to spend an hour or three manually
calculating results and comparing them to the module's results in an ad hoc
manner, I only need the discipline to run a couple of simple commands such as:
python -m doctest statistics.py
python -m unittest statistics_tests.py
or equivalent.
Any tests are better than no tests, and doctest is a good way to get started
with a few, low-impact, easy-to-use tests without the learning curve of
unittest.
--
Steven
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
