Re: connect four (game)
On 25/11/2017 16:07, Michael Torrie wrote: > On 11/25/2017 06:00 AM, bartc wrote: >> And there's a quite lot left of the rest of the program to worry about too! >> >> If you add 'window()' at the end of the program, then it seems to run on >> Python 3. I'd play around with it first before thinking up strategies >> for testing it. > > Actually, no. Unit testing ideally should be done for each and every > class as they are being written (before they are written in fact), no > matter how small and trivial the class. That way as you compose larger > and larger units of code, the chances of things being right is greater > compared to doing it the other way around. The way I write code isn't incrementally top down or bottom up. It's backwards and forwards. Feedback from different parts means the thing develops as a whole. Sometimes parts are split into distinct sections, sometimes different parts are merged. Sometimes you realise you're on the wrong track, and sections have to be redone or a different approach used, which can be done in the earlier stages. If I had to bother with such systematic tests as you suggest, and finish and sign off everything before proceeding further, then nothing would ever get done. (Maybe it's viable if working from an exacting specification that someone else has already worked out.) I've also found that many of the bugs that do appear, also do so in ways you never anticipated. Or in circumstances you would never have thought of. (I've always thought that programming is a bit like creating new laws. The same laws need to work for everyone and in any circumstances, but no one can foresee everything, and laws need to be tweaked and added to. Perhaps unit tests can apply there too...) > You may argue that testing doesn't matter for his small game, written > for his own education and amusement. The fact is that software in > general is of abysmal quality across the boards, and promoting a habit > of unit testing is good, even for trivial, home-grown stuff. I thought people were being hard on the OP. As for testing, I remember in a company I worked in, a complicated circuit was submitted to a company that would put it into a mass-produced chip. This company did massive numbers of emulated tests shown on a huge printout that showed that all combinations of inputs and outputs worked exactly as intended. Except the actual chip didn't work. As for the printout, the designer took it home and used it as an underlay for a new carpet. A rather expensive underlay. -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: connect four (game)
On 25/11/2017 23:49, Terry Reedy wrote: > On 11/25/2017 4:57 PM, namenobodywa...@gmail.com wrote: >> On Saturday, November 25, 2017 at 12:48:38 AM UTC-8, Terry Reedy wrote: >> >>> I did, and it looks buggy to me.â The top and left frame lines are >>> missing.â If I click a square, the bottom square in the column lights >>> up.â But then I have no idea whether those are your intentions or not. >> i hadn't noticed about the frame lines, but it's the same for me; but >> i'm hoping you meant to write that the TOP square in a column flashes >> when you "drop a token" down that column; > > All squares start white.â Only the bottom square turns red or black, > after perhaps a .3 second delay during which there is some jitter in > white squares above, which could be the effect of white flashing white. There are a couple of lines that look like this: self.grid.squarebuttons[column].flash() If you comment out those two lines, then the flashing disappears, and it still works. Of course, if I'd used unit tests, I'd have figured that out a lot sooner. I would just have had the somewhat bigger problem of devising a unit test that would detect this. -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: Argh!! Can't wrap my head around this Python stuff!
On 26/11/2017 09:09, Greg Tibbet wrote: > > I'm an old timer, have programmed in Fortran, C, C++, Perl, and a bit > of Java and trying to learn this new-fangled Python language! > > I've got a small program that uses PIL to create an image, draw some > primitives (rectanges, ellipses, etc...) and save it. Works fine... > no issues. > > I've found in the past, the best way to "really learn" the language > was to "dig into the guts" and understand it,.. I thought I was making > progress, but when looking into the PIL library to see what's going on > behind the scenes, I find the following code in ImageDraw.py > > def ellipse(self, xy, fill=None, outline=None): > """Draw an ellipse.""" > ink, fill = self._getink(outline, fill) > if fill is not None: > self.draw.draw_ellipse(xy, fill, 1) > <...snipped...> > > ellipse() uses the method self.draw.draw_ellipse() Okay, fine... > but WHERE is draw_ellipse defined?? What magic is happening there? > I've searched the entire PIL directory tree, and the ONLY two places > draw_ellipse is mentioned are right there in the ellipse() function... > WHAT am I missing?? Python isn't a very pure language in that much of the functionality that looks like it should be written in Python (because you imported a module just like you import any Python module), actually is written in something else, as has been pointed out. It's reasonable that some things need to be implemented using some foreign functions. But the boundary between Python and non-Python is blurred. Take this program: import sys and try and find sys.py in your installation. (This is an obstacle if, for example, you're thinking of implementing a Python interpreter. In theory, once you have it working, it should run any .py program. But the critical modules it needs don't have .py source code. And the interface to those non-Python functions isn't defined with special byte-code instructions. (It will be done /via/ those instructions, but the magic needed is on the other side of them. Calling into sys.fn() uses the same CALL_FUNCTION byte-code as calling into a regular Python function.) As I said, it's not pure. More of a jungle as you've found out.) -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: connect four (game)
On 26/11/2017 14:23, Chris Angelico wrote: > On Mon, Nov 27, 2017 at 1:11 AM, bartc wrote: >> The way I write code isn't incrementally top down or bottom up. It's >> backwards and forwards. Feedback from different parts means the thing >> develops as a whole. Sometimes parts are split into distinct sections, >> sometimes different parts are merged. >> >> Sometimes you realise you're on the wrong track, and sections have to be >> redone or a different approach used, which can be done in the earlier >> stages. >> >> If I had to bother with such systematic tests as you suggest, and finish and >> sign off everything before proceeding further, then nothing would ever get >> done. (Maybe it's viable if working from an exacting specification that >> someone else has already worked out.) > > Everyone in the world has the same problem, yet many of us manage to > write useful tests. I wonder whether you're somehow special in that > testing fundamentally doesn't work for you, or that you actually don't > need to write tests. Or maybe tests would still be useful for you too. > Could go either way. Testing everything comprehensively just wouldn't be useful for me who works on whole applications, whole concepts, not just a handful of functions with well-defined inputs and outputs. And even then, it might work perfectly, but be too slow, or they take up too much space. Take one example of a small program I've mentioned in the past, a jpeg decoder. I had to port this into several languages (one of which was Python actually). It was hard because I didn't know how it was meant to work. Only as a whole when the input is a .jpeg file, and the output might be a .ppm file that ought to look like the one produced by a working program, or the original jpeg displayed by a working viewer. (Which is not possible in all applications.) How to do an automatic test? Directly doing a binary compare on the output doesn't work because in jpeg, there can be differences of +/- 1 bit in the results. And even if the test detected a mismatch, then what? I now know there is a problem, but I could figure that out by looking at the output! And actually, after it ostensibly worked, there WAS a minor problem: some types of images exhibited excessive chroma noise around sharp transitions. The problem was traced to two lines that were in the wrong order (in the original program). I can't see how unit tests can have helped in any way at all, and it would probably have taken much longer. And THIS was a small, well-defined task which had already been written. >> Except the actual chip didn't work. As for the printout, the designer took >> it home and used it as an underlay for a new carpet. A rather expensive >> underlay. > > So there was something else wrong with the chip. I'm not sure what > your point is. The extensive testing was like unit testing, but needed to be even more thorough because of the commitment involved. It failed to spot a problem. And actually I had a similar problem with a new car. I took it back to the dealer, and they said they plugged the on-board computer into their analyser, which did all sorts of tests and said there was nothing wrong with it. But there was, and the problem has persisted for a decade [to do with the central locking]. I'm saying you can rely too much on these tests, and waste too much time on them. Perhaps that is a necessity in a large organisation or in a large team, where there is a leader to look at the big picture. It doesn't work for individuals working on one project. -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: connect four (game)
On 25/11/2017 16:07, Michael Torrie wrote: > On 11/25/2017 06:00 AM, bartc wrote: >> And there's a quite lot left of the rest of the program to worry about too! >> >> If you add 'window()' at the end of the program, then it seems to run on >> Python 3. I'd play around with it first before thinking up strategies >> for testing it. > > Actually, no. Unit testing ideally should be done for each and every > class as they are being written (before they are written in fact), no > matter how small and trivial the class. That way as you compose larger > and larger units of code, the chances of things being right is greater > compared to doing it the other way around. The way I write code isn't incrementally top down or bottom up. It's backwards and forwards. Feedback from different parts means the thing develops as a whole. Sometimes parts are split into distinct sections, sometimes different parts are merged. Sometimes you realise you're on the wrong track, and sections have to be redone or a different approach used, which can be done in the earlier stages. If I had to bother with such systematic tests as you suggest, and finish and sign off everything before proceeding further, then nothing would ever get done. (Maybe it's viable if working from an exacting specification that someone else has already worked out.) I've also found that many of the bugs that do appear, also do so in ways you never anticipated. Or in circumstances you would never have thought of. (I've always thought that programming is a bit like creating new laws. The same laws need to work for everyone and in any circumstances, but no one can foresee everything, and laws need to be tweaked and added to. Perhaps unit tests can apply there too...) > You may argue that testing doesn't matter for his small game, written > for his own education and amusement. The fact is that software in > general is of abysmal quality across the boards, and promoting a habit > of unit testing is good, even for trivial, home-grown stuff. I thought people were being hard on the OP. As for testing, I remember in a company I worked in, a complicated circuit was submitted to a company that would put it into a mass-produced chip. This company did massive numbers of emulated tests shown on a huge printout that showed that all combinations of inputs and outputs worked exactly as intended. Except the actual chip didn't work. As for the printout, the designer took it home and used it as an underlay for a new carpet. A rather expensive underlay. -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: connect four (game)
On 25/11/2017 23:49, Terry Reedy wrote: > On 11/25/2017 4:57 PM, namenobodywa...@gmail.com wrote: >> On Saturday, November 25, 2017 at 12:48:38 AM UTC-8, Terry Reedy wrote: >> >>> I did, and it looks buggy to me.â The top and left frame lines are >>> missing.â If I click a square, the bottom square in the column lights >>> up.â But then I have no idea whether those are your intentions or not. >> i hadn't noticed about the frame lines, but it's the same for me; but >> i'm hoping you meant to write that the TOP square in a column flashes >> when you "drop a token" down that column; > > All squares start white.â Only the bottom square turns red or black, > after perhaps a .3 second delay during which there is some jitter in > white squares above, which could be the effect of white flashing white. There are a couple of lines that look like this: self.grid.squarebuttons[column].flash() If you comment out those two lines, then the flashing disappears, and it still works. Of course, if I'd used unit tests, I'd have figured that out a lot sooner. I would just have had the somewhat bigger problem of devising a unit test that would detect this. -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: Argh!! Can't wrap my head around this Python stuff!
On 26/11/2017 09:09, Greg Tibbet wrote: > > I'm an old timer, have programmed in Fortran, C, C++, Perl, and a bit > of Java and trying to learn this new-fangled Python language! > > I've got a small program that uses PIL to create an image, draw some > primitives (rectanges, ellipses, etc...) and save it. Works fine... > no issues. > > I've found in the past, the best way to "really learn" the language > was to "dig into the guts" and understand it,.. I thought I was making > progress, but when looking into the PIL library to see what's going on > behind the scenes, I find the following code in ImageDraw.py > > def ellipse(self, xy, fill=None, outline=None): > """Draw an ellipse.""" > ink, fill = self._getink(outline, fill) > if fill is not None: > self.draw.draw_ellipse(xy, fill, 1) > <...snipped...> > > ellipse() uses the method self.draw.draw_ellipse() Okay, fine... > but WHERE is draw_ellipse defined?? What magic is happening there? > I've searched the entire PIL directory tree, and the ONLY two places > draw_ellipse is mentioned are right there in the ellipse() function... > WHAT am I missing?? Python isn't a very pure language in that much of the functionality that looks like it should be written in Python (because you imported a module just like you import any Python module), actually is written in something else, as has been pointed out. It's reasonable that some things need to be implemented using some foreign functions. But the boundary between Python and non-Python is blurred. Take this program: import sys and try and find sys.py in your installation. (This is an obstacle if, for example, you're thinking of implementing a Python interpreter. In theory, once you have it working, it should run any .py program. But the critical modules it needs don't have .py source code. And the interface to those non-Python functions isn't defined with special byte-code instructions. (It will be done /via/ those instructions, but the magic needed is on the other side of them. Calling into sys.fn() uses the same CALL_FUNCTION byte-code as calling into a regular Python function.) As I said, it's not pure. More of a jungle as you've found out.) -- bartc -- https://mail.python.org/mailman/listinfo/python-list
