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 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 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 27/11/2017 03:04, Michael Torrie wrote: > On 11/26/2017 08:39 AM, bartc wrote: >> 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. > > What makes you think that? Surely other decoders were doing the right > thing and you could compare your output against theirs? JPEGs may be > lossy but the path through the decoder should be deterministic. > > Or even if every decoder is slightly unique, at least yours should > output self-consistent data. The original used some floating point code, I changed that to use integer code (eg a combination of multiplying and shifting; it make a difference on compiled version, perhaps not so much in .py). But also (IIRC) there was a difference in taking the remainder of negative integer division, where different compilers may round up or down. So there can easily be differences when compared at the binary level, but which shouldn't be noticeable with the human eye. (https://pastebin.com/P7V1Bvkk https://pastebin.com/raw/P7V1Bvkk raw version with no ads, or colour) In other words, once you know you fixed > the chroma problem, you can use that jpeg as a unit test to make sure > future big fixes and enhancements don't break something else. > Regression testing is very important. Many times I've fixed a bug, only > to introduce new ones that broke formerly correct behavior. > > Anyway, unit testing is certainly a challenging concept, and I'm no more > good at it than you are. Some people are obsessed with having unit tests. Others are the same about using debuggers, especially in compiled code. I've never used either, but I do alright. Some of the stuff I do is unsuitable for those for technical reasons, but also some of the problems I've come across just don't fit into such patterns. People should use what works best for them, unless they're in a team where the have to use certain tools and working methods. -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: While, If, Count Statements
On 27/11/2017 12:54, Cai Gengyang wrote: > > Input : > > count = 0 > > if count < 5: >print "Hello, I am an if statement and count is", count > > while count < 10: >print "Hello, I am a while and count is", count >count += 1 > > Output : > > Hello, I am an if statement and count is 0 > Hello, I am a while and count is 0 > Hello, I am a while and count is 1 > Hello, I am a while and count is 2 > Hello, I am a while and count is 3 > Hello, I am a while and count is 4 > Hello, I am a while and count is 5 > Hello, I am a while and count is 6 > Hello, I am a while and count is 7 > Hello, I am a while and count is 8 > Hello, I am a while and count is 9 > > The above input gives the output below. Why isn't the output instead : > > Hello, I am an if statement and count is 0 > Hello, I am a while and count is 0 > Hello, I am an if statement and count is 1 > Hello, I am a while and count is 1 > Hello, I am an if statement and count is 2 > Hello, I am a while and count is 2 > Hello, I am an if statement and count is 3 > Hello, I am a while and count is 3 > Hello, I am an if statement and count is 4 > Hello, I am a while and count is 4 > Hello, I am a while and count is 5 > Hello, I am a while and count is 6 > Hello, I am a while and count is 7 > Hello, I am a while and count is 8 > Hello, I am a while and count is 9 Because the if-statement is only executed once, then it does the loop. Try: count = 0 while count < 10: if count < 5: print "Hello, I am an if statement and count is", count print "Hello, I am a while and count is", count count += 1 -- https://mail.python.org/mailman/listinfo/python-list
Re: connect four (game)
On 27/11/2017 13:57, Chris Angelico wrote: > On Mon, Nov 27, 2017 at 10:38 PM, bartc wrote: > Your decoder was straight-up buggy, and tests would have proven this. I created my Python version after the abysmal results from other Python decoders I tried which didn't work at all, gave the wrong results, didn't support other subsampling ratios, or hung. Or if they did work, they took forever. I suggest you compare my version with some of those. The first time I looked at a jpeg decoder, it was a massive C library of about 30 different source files. Sometimes you need to take short-cuts. My version generates images which are indistinguishable from those derived via other decoders. >> But also (IIRC) there was a difference in taking the remainder of negative >> integer division, where different compilers may round up or down. > > In every compiler, interpreter, and CPU that I've ever used, the > remainder has been well-defined. In what situation was it ill-defined, > such that different compilers could do different things? In certain C implementations, rounding the results of integer division could go up or down. This is a post from comp.lang.c from 2008: "Nate Eldredge" wrote in message news:8663mf144q@vulcan.lan... > Mr. Burns writes: > >> Hi group, >> >> suppose I have a grid of cells of size (R,C) and coordinates >> (0..R-1,0..C-1) and >> I'm translating pixel coordinates to grid coordinates by dividing by cell >> size. >> >> Now, all works well for values >= 0, but for values < 0 I'm getting >> inconsistent results. >> >> On one platform, division of negative numbers rounds towards negative >> infinity, i.e., (-1 / 10) gives -1. (this is what I want) >> >> On another platform (solaris), rounding is towards zero, and (-1 / 10) is >> 0! >> >> All numbers are plain ints. > > The C99 standard specifies truncation towards zero (like your Solaris > compiler). However, the previous C90 standard left it up to the > implementation to decide which way to round when one of the operands is > negative, as long as it is consistent with the % operator. Exactly what the problem was with my jpeg program where a number from my language and compiler ended up as 187, but on C compiled with gcc as 186, I can't remember. I /think/ it was to do with such rounding. This is not a big deal: one program ends up with a pixel value of 186 (in a range of 0 to 255), and another with 187. The true value in the original photo may have required a value somewhere between 186 and 187, so both values could be considered wrong! > Which, if I'm not misunderstanding the specs, is the case for pretty > much every compression scheme in current use - including JPEG. JPEG uses lossy compression. The resulting recovered data is an approximation of the original. > For myself, I don't write as many tests as I should. But I'm not going > to go around telling people that tests are a waste of time. I'm fairly certain the OP's program didn't work perfectly first time. So some procedure had to be followed to try it and decide if it behaved according to the specification they had in mind. I believe that process can also be called 'testing'. And in this case, involving a visual GUI, it really demands tests verified by a human rather than spending the next six months writing automatic test procedures that simulate mouse input and examine the pixels on the screen to see if they correspond to what should happen. > Your decoder was straight-up buggy, and tests would have proven this. How did YOU determine it was buggy; unit-tests? And did you just do what everyone else does? -- Bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: connect four (game)
On 27/11/2017 17:41, Chris Angelico wrote: > On Tue, Nov 28, 2017 at 2:14 AM, bartc wrote: >> JPEG uses lossy compression. The resulting recovered data is an >> approximation of the original. > > Ah but it is a perfect representation of the JPEG stream. Any given > compressed stream must always decode to the same output. The lossiness > is on the ENcoding, not the DEcoding. You make it sound as bad as currency calculations where different software must produce results that always match to the nearest cent. We're talking about perhaps +1 or -1 difference in the least significant bit of one channel of one pixels. If the calculation is consistent, then you will not know anything is amiss. By +1 or -1, I mean compared with the same jpeg converted by independent means. I also passed the same jpeg through another C program (not mine) using its own algorithms. There some pixels varied by up to +/- 9 from the others (looking at the first 512 bytes of the conversion to ppm). Here's my test image: https://github.com/bartg/langs/blob/master/card2.jpg (nothing naughty). Tell me what the definitive values of the pixels in this part of the image should be (I believe this corresponds to roughly the leftmost 180 pixels of the top line; there are two million pixels in all). And tell me WHY you think those are the definitive ones. Bear in mind also that this is not intended to be the world's most perfect software. But it does do a good enough job. And the other two Python versions I have, at the minute don't work at all. -- 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
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
