Re: I have anaconda, but Pycharm can't find it
You need to set the Python interpreter for the project to be the Anaconda one. See https://www.jetbrains.com/help/pycharm/configuring-python-interpreter.html On Monday, November 27, 2017 at 1:56:58 AM UTC+2, C W wrote: > Hello all, > > I am a first time PyCharm user. I have Python 3 and Anaconda installed. > They work together on Sublime Text, but not on Pycharm. > > Pycharm tells me it cannot find modules numpy, matplotlib, etc. > > What should I do? I tried to set the interpreter environment, and a few > other options, none seem to work. > > This is the typical solution, but it does not work > https://stackoverflow.com/questions/35623776/import-numpy-on-pycharm > > Thanks, > > -Mike -- https://mail.python.org/mailman/listinfo/python-list
Re: connect four (game)
On Mon, Nov 27, 2017 at 3:04 PM, Rustom Mody wrote: >> Aviators have pinned down the best solution to this, I think. A pilot >> is not expected to be perfect; he is expected to follow checklists. A >> preflight checklist. A departure checklist. A landing checklist. >> Everything that needs to be done right is mentioned on the list, and >> you just go through the list and make sure you've done everything. > > And thats where the analogy breaks down. > Presumably a 50 person short-flight and a 600-person transcontinental may have > at least something in common in their pilot-checklists > What common will you find in a multi-million line OS, a thousand line script > and a student prime-numbers first-program? You locate a pure function. I can pretty much guarantee that the first two will have a number of them, and the third one may or may not, but almost certainly should. Pure functions are the easiest to unit-test. Then you build up from there. > No I am not dissing on testing and TDD; just that universality¹ of computing > devices > is something that our civilization is nowhere near understanding, leave alone > dealing with — two programs can be more far apart than a bullock cart and a > jet. > And yet they are both programs ... so? > ¹ Ive seen CS PhDs ask a student why a student didnt incorporate some > error-checking > into his compiler which amounted to solving the halting problem. > More mundanely I see students have a hard time seeing their phones and their > laptops as 'the same' Again: so? Testing methodologies don't require that. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: connect four (game)
On Monday, November 27, 2017 at 9:08:42 AM UTC+5:30, Chris Angelico wrote: > On Mon, Nov 27, 2017 at 1:55 PM, Michael Torrie wrote: > > On 11/26/2017 07:11 AM, bartc wrote: > >>> 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. > > > > I wasn't being hard on the OP. My observation is about the state of > > *all* software. My software especially, your software, Microsoft's > > software. It all is of rather poor quality compared to the rigors of > > other industries like civil engineering, manufacturing, etc. > > Not all software is poor quality compared to all examples of those > industries. You'll find the equivalent of software bugs in a lot of > hardware situations; the difference with software is that we have 100% > perfect reproduction in the end-user products, so we call it a design > flaw instead of a production artifact. (How often do you buy a box of > something and find that a couple of them just break?) Even in > large-scale civil engineering projects, there are plenty of > stupidities. The house I'm living in has a place where the tiled floor > doesn't quite align with the wall that it meets, and I can't figure > out why; somewhere, two things that ought to have been parallel just > aren't. Bridges have been known to crack, cars break down for no good > reason, your hamburger just doesn't taste right today. > > Aviators have pinned down the best solution to this, I think. A pilot > is not expected to be perfect; he is expected to follow checklists. A > preflight checklist. A departure checklist. A landing checklist. > Everything that needs to be done right is mentioned on the list, and > you just go through the list and make sure you've done everything. And thats where the analogy breaks down. Presumably a 50 person short-flight and a 600-person transcontinental may have at least something in common in their pilot-checklists What common will you find in a multi-million line OS, a thousand line script and a student prime-numbers first-program? No I am not dissing on testing and TDD; just that universality¹ of computing devices is something that our civilization is nowhere near understanding, leave alone dealing with — two programs can be more far apart than a bullock cart and a jet. And yet they are both programs ¹ Ive seen CS PhDs ask a student why a student didnt incorporate some error-checking into his compiler which amounted to solving the halting problem. More mundanely I see students have a hard time seeing their phones and their laptops as 'the same' -- https://mail.python.org/mailman/listinfo/python-list
Re: connect four (game)
On Mon, Nov 27, 2017 at 1:55 PM, Michael Torrie wrote: > On 11/26/2017 07:11 AM, bartc wrote: >>> 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. > > I wasn't being hard on the OP. My observation is about the state of > *all* software. My software especially, your software, Microsoft's > software. It all is of rather poor quality compared to the rigors of > other industries like civil engineering, manufacturing, etc. Not all software is poor quality compared to all examples of those industries. You'll find the equivalent of software bugs in a lot of hardware situations; the difference with software is that we have 100% perfect reproduction in the end-user products, so we call it a design flaw instead of a production artifact. (How often do you buy a box of something and find that a couple of them just break?) Even in large-scale civil engineering projects, there are plenty of stupidities. The house I'm living in has a place where the tiled floor doesn't quite align with the wall that it meets, and I can't figure out why; somewhere, two things that ought to have been parallel just aren't. Bridges have been known to crack, cars break down for no good reason, your hamburger just doesn't taste right today. Aviators have pinned down the best solution to this, I think. A pilot is not expected to be perfect; he is expected to follow checklists. A preflight checklist. A departure checklist. A landing checklist. Everything that needs to be done right is mentioned on the list, and you just go through the list and make sure you've done everything. Interestingly enough, that approximately corresponds to unit testing (or maybe integration testing) - you design a suite of tests, and every time you do something, you make sure all the tests pass. Neither test suites nor checklists can prevent all problems - but they CAN prevent the same problems from cropping up again and again. (Which is kinda important when you're dealing with airliners carrying hundreds of people. They crash very rarely because the crew follow their checklists religiously, and when they do, there's an investigation that can result in new tests being added.) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: connect four (game)
On 11/25/2017 12:58 PM, namenobodywa...@gmail.com wrote: > the idea is that there should be exactly one object posinf (positive > infinity) that compares as strictly greater than any number ever considered, > and exactly one object neginf that compares as strictly less; as the code > stands now there is no reason not to use +/-70 in that capacity; the > "infinity" class is there so that the game-playing parts of the code (which > at present are intentionally as primitive as possible) can be modified more > smoothly later; the single place where "infinity" is instantiated is in the > function "getvalue", which returns the value of a finished game: > > def getvalue(winner,accessibles): > return Infinity(+1) if winner == ex else Infinity(-1) if winner == oh > else 0 if not accessibles else None > > if ex has won then the value of the game is posinf; if oh has won then it's > neginf; if the game is tied (no winner but no accessible columns remaining) > then the value of the game is zero; otherwise the game is not finished and > its finished value is None So you are using this Infinity class as a sentinel value of some kind? Representing game state? There may be an easier way than a full on custom type. Sometimes just a sentinel object is sufficient. Or an enumeration. -- https://mail.python.org/mailman/listinfo/python-list
Re: connect four (game)
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. 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. -- https://mail.python.org/mailman/listinfo/python-list
Re: connect four (game)
On 11/26/2017 07:11 AM, bartc wrote: >> 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. I wasn't being hard on the OP. My observation is about the state of *all* software. My software especially, your software, Microsoft's software. It all is of rather poor quality compared to the rigors of other industries like civil engineering, manufacturing, etc. > 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. That's unfortunately, but seems to reinforce the notion that adequate testing is required. Clearly for a microchip, theoretically testing the chip's "software" (for lack of a better term) was not adequate. An analogy to our software situation is that someone tested the algorithm, but not the actual, in-use implementation of the algorithm. -- https://mail.python.org/mailman/listinfo/python-list
Re: [META] Why are duplicate posts coming through?
On Monday, November 27, 2017 at 5:35:09 AM UTC+5:30, Skip Montanaro wrote: > Chris, > > Please forward one or two to me. Mark Sapiro and I have been banging on the > SpamBayes instance which supports the Usenet gateway. I suppose it's > possible some change caused the problem you're seeing. > > Skip > > On Nov 26, 2017 5:22 PM, "Chris Angelico" wrote: > > Not sure whether this is an issue for -owner or not; apologies if not. > > I'm seeing a whole lot of reasonably-recent posts getting re-sent, > with "nospam" attached to the posters' names. And they're getting > re-sent multiple times. Sometimes the posts have encoding problems > (small amounts of mojibake). > > What's going on? Is there something going haywire with the news/mail > gateway? Is there a rogue client re-posting a bunch of news? Somebody > testing something? And the spam continues unabated Except that the subject lines are changed -- https://mail.python.org/mailman/listinfo/python-list
Re: nospam ** infinity?
On Mon, Nov 27, 2017 at 12:14 PM, Skip Montanaro wrote: >> There seems to be a gateway loop of some sort going on. >> I'm seeing multiple versions of the same posts in >> comp.lang.python with different numbers of "nospam"s >> prepended to the email address. > > This is the second thread about this. I was thinking it might be > related to recent changes to the gate_news process on mail.python.org, > but this fingerprint looks nothing like what gate_news does. > > Looking at a somewhat long-ish thread: > > https://groups.google.com/d/topic/comp.lang.python/YoxLtkzlt_o/discussion > > I see a couple posts from Chris Angelico, only some of which have a > "nospam" preface. It would seem that someone was trying to mark > certain posters as "not spammy," (I'm sure Chris is flattered) and > somehow posts with that private marking leaked out of the user's > system starting in the past twelve hours or so. > > Newsreader configuration problem? More likely, someone was trying to obscure the email addresses, but managed to tag my name instead. Definitely looks like some sort of automation failure. The only question is, whose? If it's not from gate_news, there's someone here on the list/ng that is (probably accidentally) reposting everything. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: nospam ** infinity?
> There seems to be a gateway loop of some sort going on. > I'm seeing multiple versions of the same posts in > comp.lang.python with different numbers of "nospam"s > prepended to the email address. This is the second thread about this. I was thinking it might be related to recent changes to the gate_news process on mail.python.org, but this fingerprint looks nothing like what gate_news does. Looking at a somewhat long-ish thread: https://groups.google.com/d/topic/comp.lang.python/YoxLtkzlt_o/discussion I see a couple posts from Chris Angelico, only some of which have a "nospam" preface. It would seem that someone was trying to mark certain posters as "not spammy," (I'm sure Chris is flattered) and somehow posts with that private marking leaked out of the user's system starting in the past twelve hours or so. Newsreader configuration problem? Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: [META] Why are duplicate posts coming through?
On Mon, Nov 27, 2017 at 11:04 AM, Skip Montanaro wrote: > Chris, > > Please forward one or two to me. Mark Sapiro and I have been banging on the > SpamBayes instance which supports the Usenet gateway. I suppose it's > possible some change caused the problem you're seeing. > > Skip Sent a couple through. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Pros and cons of Python sources?
On 26Nov2017 10:00, nospam.Martin Schöön wrote: Den 2017-11-26 skrev Cameron Simpson : On 25Nov2017 08:34, rusi wrote: On Saturday, November 25, 2017 at 9:45:07 PM UTC+5:30, Michael Torrie wrote: The problem with mixing repository-installed packages with pip-installed packages is that there's always a chance a Debian update will overwrite a pip package, possibly with an older version. Or a pip-installed package might bring in a new version that's not compatible with some debian-installed package, breaking something. On (recent?) debian/ubuntu pip seems to use the 'user-scheme' which means pip runs without sudo and installs in ~/.local/lib So I dont believe literal overwriting would occur Though the point should be made that one should run pip as oneself, and try to avoid doing it as the root user (including avoiding sudo). Many UNIX/Linux/etc users believe "installs" should be done as root, and in this case that is easily avoided, with all its potential for damage to the vendor supplied environment. Hmm, I seem to remember not being able to install packages with pip unless I did sudo pip. And this is exactly what I'm warning about. Many Linux users see some kind of failure and just stick sudo on the front of the command. It is almost always the wrong things to do, leading to effects in the OS install area instead of being safely contained within one's home directory or work area. Instead of reaching straight for sudo, look at pip's manual or help. You will find that: pip install --user ... installs modules local to your home directory, avoiding troublesome installs into the OS area. Cheers, Cameron Simpson (formerly c...@zip.com.au) -- https://mail.python.org/mailman/listinfo/python-list
Re: [META] Why are duplicate posts coming through?
Chris, Please forward one or two to me. Mark Sapiro and I have been banging on the SpamBayes instance which supports the Usenet gateway. I suppose it's possible some change caused the problem you're seeing. Skip On Nov 26, 2017 5:22 PM, "Chris Angelico" wrote: Not sure whether this is an issue for -owner or not; apologies if not. I'm seeing a whole lot of reasonably-recent posts getting re-sent, with "nospam" attached to the posters' names. And they're getting re-sent multiple times. Sometimes the posts have encoding problems (small amounts of mojibake). What's going on? Is there something going haywire with the news/mail gateway? Is there a rogue client re-posting a bunch of news? Somebody testing something? ChrisA -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
nospam ** infinity?
There seems to be a gateway loop of some sort going on. I'm seeing multiple versions of the same posts in comp.lang.python with different numbers of "nospam"s prepended to the email address. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
I have anaconda, but Pycharm can't find it
Hello all, I am a first time PyCharm user. I have Python 3 and Anaconda installed. They work together on Sublime Text, but not on Pycharm. Pycharm tells me it cannot find modules numpy, matplotlib, etc. What should I do? I tried to set the interpreter environment, and a few other options, none seem to work. This is the typical solution, but it does not work https://stackoverflow.com/questions/35623776/import-numpy-on-pycharm Thanks, -Mike -- https://mail.python.org/mailman/listinfo/python-list
Merits of otherwise of test-first (Re: connect four (game))
bartc wrote: 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. I had this experience with Pyrex (the precursor to Cython). The various parts are so interdependent that it doesn't really make sense to test individual classes or methods on their own. It would require a huge amount of scaffolding and wouldn't really prove much. Instead, what I did was write tests for units of *functionality*. (Can it compile an assignment statement? An expression that adds two things? Subtracts them? etc.) I wrote a very large number of them, plus a test framework to run them and compare the output with known good output. I can't claim that I always wrote the tests *first* (sometimes I did, sometimes I didn't). But I never had any trouble motivating myself to write the tests. Partly this is because the way my test framework worked, there was very little difference between a manual test and an automated one. I had to write a test file to test it at all, and having done that, it was just as easy to save it away together with its output so that it became part of the automated test suite. It was also partly because the benefits of having a comprehensive automatic test suite were so blindingly obvious in that project. Its complexity meant that it was particularly easy to break something accidentally when adding a new feature. If that happened, the tests would almost certainly pick it up immediately. Without those tests, I would never have been able to develop it to the point I did. 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. Testing obviously isn't guaranteed to find all problems in a system with complex behaviour, but that doesn't mean testing is useless. It would have been hugely more risky to go ahead and build the chip without testing the design at all! BTW, hardware is a bit different from software. It's possible for a design to be *logically* correct and pass all the simulations, but for the hardware to fail for messy physics- related reasons. (Charles Moore tells a story like that about one of his Forth chips. A transistor driving a particular signal was too small, and if you executed a particular instruction too many times in too short a time interval, it would overheat and produce incorrect results.) -- Greg -- https://mail.python.org/mailman/listinfo/python-list
[META] Why are duplicate posts coming through?
Not sure whether this is an issue for -owner or not; apologies if not. I'm seeing a whole lot of reasonably-recent posts getting re-sent, with "nospam" attached to the posters' names. And they're getting re-sent multiple times. Sometimes the posts have encoding problems (small amounts of mojibake). What's going on? Is there something going haywire with the news/mail gateway? Is there a rogue client re-posting a bunch of news? Somebody testing something? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: connect four (game)
On Mon, Nov 27, 2017 at 10:08 AM, Gregory Ewing wrote: > Chris Angelico wrote: > >> On Mon, Nov 27, 2017 at 1:11 AM, bartc wrote: > >> >>> >>> 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 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. > > > I think the point is that a strict test-first discipline goes > against the grain of exploratory programming. > > When you're not sure how to approach a problem, it's useful > to be able to quickly try things out. If you have to write a > bunch of tests for every little thing before you can write > the code for it, you can end up writing a lot of tests for > code that never ends up getting used. That's a good way to > kill all your enthusiasm for a project. I agree, and that's why I don't tend to go for TDD. But writing tests afterwards is a good thing, something I think bartc seems to disagree with. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: connect four (game)
Chris Angelico wrote: On Mon, Nov 27, 2017 at 1:11 AM, bartc wrote: > 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 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. I think the point is that a strict test-first discipline goes against the grain of exploratory programming. When you're not sure how to approach a problem, it's useful to be able to quickly try things out. If you have to write a bunch of tests for every little thing before you can write the code for it, you can end up writing a lot of tests for code that never ends up getting used. That's a good way to kill all your enthusiasm for a project. Also, stopping to write tests all the time interrupts your flow of thought. You're deep into details of the solution, you realise you need class X, then you have to stop and write tests for X. That makes you think a lot about all the details of X, and by the time you're finished you've lost track of the big picture. I don't think anyone disputes that having a reasonably complete set of tests is a good thing. The argument is about whether it's strictly necessary to write the tests *first* in all cases. Maybe you find it's a useful discipline that helps ensure the tests get written. That's fine, but it doesn't mean that *everyone* should be forced to do it that way all the time, even if they're just programming for a hobby. That's confusing the desired end result with a particular means of achieving it. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: connect four (game)
bartc wrote: (Maybe it's viable if working from an exacting specification that someone else has already worked out.) In my experience, for anything non-trivial that hasn't been done before, these "exacting specifications" never exist. Even if someone handles wnat they *think* are exact and complete specifications, they're not. :-) -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Stopping an iterator and continuing later
november nihal wrote: I should have added I switch off the machine when I stop. ( I dont have options to keep it in a sleep mode or in hibernation ) The iterator returned by itertools.combinations is pickleable: >>> from pickle import dumps, loads >>> from itertools import combinations >>> c = combinations([1,2,3,4,5], 2) >>> next(c) (1, 2) >>> next(c) (1, 3) >>> next(c) (1, 4) >>> s = dumps(c) >>> d = loads(s) >>> next(d) (1, 5) -- Greg -- 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: 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: Argh!! Can't wrap my head around this Python stuff!
On Sunday, November 26, 2017 at 4:10:12 AM UTC-5, 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?? > > Thanks! > -Stumpy (aka Greg) I'm googlesmart when it comes to Python. I used to know C. I practically knew what the assembly language would look like when it compiled. There was no internet and searching through books can be really laborious so you almost had to really know it to use it. But with Python, I don't start from first principles. I google what I want to do, download the appropriate packages and read through the examples. It can be really frustrating when you get bugs, because you don't know what's going on deep down in the code. -- 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: 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: Compile Python 3 interpreter to force 2-byte unicode
On Sunday, November 26, 2017 at 3:43:29 AM UTC+5:30, Chris Angelico wrote: > On Sun, Nov 26, 2017 at 9:05 AM, wojtek.mula wrote: > > Hi, my goal is to obtain an interpreter that internally > > uses UCS-2. Such a simple code should print 65535: > > > > import sys > > print sys.maxunicode > > > > This is enabled in Windows, but I want the same in Linux. > > What options have I pass to the configure script? > > Why do you want to? What useful value do you have in creating this > buggy interpreter? I see that you are familiar with this bug: https://bugs.python.org/issue13153 And I see it or something very close is still buggy in python 3.5 [No it does not allow me to paste an SMP char but if I open a file containing one it crashes and rather messily â ö no way to close the idle other than killing the shell] No thats not a diatribe against idle; just that its reasonable to want python to support work-arounds for reasonably common bugs in the current unicode-ecosystem -- https://mail.python.org/mailman/listinfo/python-list
Re: Stopping an iterator and continuing later (Posting On Python-List P
On Saturday, 25 November 2017 20:59:02 UTC, Lawrence Dâ ÖOliveiro wrote: > On Sunday, November 26, 2017 at 6:43:05 AM UTC+13, novembe...@gmail.com wrote: > > I worked out how to use iterators to generate values one at a time > > then ran into a second problem which is time. Is it possible to > > save an iterator so that i can continue from where I stopped? > > Yes. Just stop calling it. Then, when you start again, you will get the values continuing from that point. I should have added I switch off the machine when I stop. ( I dont have options to keep it in a sleep mode or in hibernation ) NN -- https://mail.python.org/mailman/listinfo/python-list
Re: Stopping an iterator and continuing later
r...@zedat.fu-berlin.de (Stefan Ram) writes: >Then you can use pickle or custom methods to save and >restore the object, or get the state from an iterator >and create a new iterator with that state later. One does not always have to write a custom class, for example: main.py import pickle r = range( 9 ) i = iter( r ) del r next( i ) next( i ) next( i ) bytes = pickle.dumps( i ) del i i = pickle.loads( bytes ) print( next( i )) del i del pickle transcript 3 -- https://mail.python.org/mailman/listinfo/python-list
Re: Compile Python 3 interpreter to force 2-byte unicode
On 11/25/17 5:05 PM, wojtek.m...@gmail.com wrote: > Hi, my goal is to obtain an interpreter that internally > uses UCS-2. Such a simple code should print 65535: > >import sys >print sys.maxunicode > > This is enabled in Windows, but I want the same in Linux. > What options have I pass to the configure script? > You say you want Python 3, but you also say you have maxunicode == 65535 on Windows.â That must be Python 2.â Python 3 always has maxunicode == 1114111. Can you say more about what you need to do? --Ned. -- https://mail.python.org/mailman/listinfo/python-list
Re: Compile Python 3 interpreter to force 2-byte unicode
On 11/25/2017 5:12 PM, Chris Angelico wrote: > On Sun, Nov 26, 2017 at 9:05 AM, wrote: >> Hi, my goal is to obtain an interpreter that internally >> uses UCS-2. Such a simple code should print 65535: >> >>import sys >>print sys.maxunicode >> >> This is enabled in Windows, but I want the same in Linux. >> What options have I pass to the configure script? You must be trying to compile 2.7. There may be Linux distributions that compile this way. If you want to use, or ever encounter, non-BMP chars, using surrogate pairs is problematical. By my reading of the official UCS-2 docs, Python's old 16-bit unicode implementation is not fully compliant. Others have claimed that is it not a UCS-2 implementation. > Why do you want to? What useful value do you have in creating this > buggy interpreter? > Ever since Python 3.3, that has simply not been an > option. The bug has been solved. If you want to seriously work with unicode, many recommend using modern Python. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Compile Python 3 interpreter to force 2-byte unicode
On Sun, Nov 26, 2017 at 10:59 AM, Terry Reedy wrote: > On 11/25/2017 5:12 PM, Chris Angelico wrote: >> >> On Sun, Nov 26, 2017 at 9:05 AM, wrote: >>> >>> Hi, my goal is to obtain an interpreter that internally >>> uses UCS-2. Such a simple code should print 65535: >>> >>>import sys >>>print sys.maxunicode >>> >>> This is enabled in Windows, but I want the same in Linux. >>> What options have I pass to the configure script? > > > You must be trying to compile 2.7. There may be Linux distributions that > compile this way. If you want to use, or ever encounter, non-BMP chars, > using surrogate pairs is problematical. By my reading of the official UCS-2 > docs, Python's old 16-bit unicode implementation is not fully compliant. > Others have claimed that is it not a UCS-2 implementation. See subject line. OP wishes to compile Python 3 (and almost certainly not 3.1 or 3.2) with the bugginess of Python 2's narrow builds. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: connect four (game)
On Sat, 25 Nov 2017 12:26:52 -0800, namenobodywants wrote: > On Friday, November 24, 2017 at 8:07:07 AM UTC-8, Chris Angelico wrote: > >> This is the kind of function that needs a docstring and some comments. >> What exactly is this doing? What are the "lines" of the board? What's >> the difference between "linear" and "lines"? What exactly is it >> returning? > > producing documentation is an extremely difficult task for me, but i've > come up with the following: > > """ > makelines(length,numrows,numcolumns) IS THE LIST OF ALL LISTS L, WITH > LENGTH length, OF COORDINATES FROM A numrows x numcolumns MATRIX, SUCH > THAT THE ENTRIES OF L ALL LIE IN A LINE: > > LET horizontal BE ALL THE APPROPRIATE-LENGTH LISTS WHOSE ENTRIES LIE IN > A HORIZONTAL LINE LET vertical BE ALL THE APPROPRIATE-LENGTH LISTS WHOSE > ENTRIES LIE IN A VERTICAL LINE LET downward BE ALL THE > APPROPRIATE-LENGTH LISTS WHOSE ENTRIES LIE IN A DOWNWARD-SLOPING > DIAGONAL LINE LET upward BE ALL THE APPROPRIATE-LENGTH LISTS WHOSE > ENTRIES LIE IN AN UPWARD-SLOPING DIAGONAL LINE THEN > makelines(length,numrows,numcolumns) IS THE UNION OF ALL THE > AFOREMENTIONED SETS """ > > def makelines(length,numrows,numcolumns): > horizontal = [[(i, j+k) for k in range(length)] for i in > range(numrows) for j in range(numcolumns)] > vertical = [[(i+k, j) for k in range(length)] for i in > range(numrows) for j in range(numcolumns)] downward = [[(i+k, j+k) > for k in range(length)] for i in range(numrows) for j in > range(numcolumns)] > upward = [[(i+k, j-k) for k in range(length)] for i in > range(numrows) for j in range(numcolumns)] linear = horizontal + > vertical + downward + upward return [line for line in linear if > all(i in range(6) and j in range(7) for (i,j) in line)] > > def getlines(board): > coordlines = makelines(4,6,7) ## GLOBAL return [[board[square] for > square in line] for line in coordlines > > > i tried to remove all the superfluous spaces from that, but lining up > code vertically is very helpful to me, so i don't think i can really > dispense with the practice > > peace stm the documentation should come after the def statement that way is becomes a "Doc String" & can be accessed using the help function you may also want to check out the recommended way of structuring a doc string, it could help you with your difficulty in writing them (a problem shared by many) -- This door is baroquen, please wiggle Handel. (If I wiggle Handel, will it wiggle Bach?) -- Found on a door in the MSU music building -- https://mail.python.org/mailman/listinfo/python-list
Re: Argh!! Can't wrap my head around this Python stuff!
On 26Nov2017 01:09, Greg Tibbet wrote: >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?? "ellispse()" is a method in the ImageDraw class. Looking at the __init__ method of that class we see: self.draw = Image.core.draw(self.im, blend) so "self.draw" in your code above is the result of "Image.core.draw(self.im, blend)". "Image" is the Image module imported at the top of ImageDraw.py. So we hop over to Image.py, which has this code: try: # If the _imaging C module is not present, you can still use # the "open" function to identify files, but you cannot load # them. Note that other modules should not refer to _imaging # directly; import Image and use the Image.core variable instead. import _imaging core = _imaging del _imaging except ImportError, v: core = _imaging_not_installed() if str(v)[:20] == "Module use of python" and warnings: # The _imaging C module is present, but not compiled for # the right version (windows only). Print a warning, if # possible. warnings.warn( "The _imaging extension was built for another version " "of Python; most PIL functions will be disabled", RuntimeWarning ) Now the import works (because you'd get exceptions otherwise), so code which matters is that the top of that: import _imaging core = _imaging del _imaging So "core" is a reference to the "_imaging" module (and the name "_imaging" has been discarded). So... The name Image.core is now a reference to that module. So back in ImageDraw, the call to "Image.core.draw()" called the function "draw" from the _imaging module, which presumably returns some kind of drawing object, and _that_ object has a "draw_ellispe" method. Now, dynamic languages like Python don't lend themselves to screamingly fast compute, so expensive stuff like drawing graphics is usually done by hooking into special purpose libraries written in C or something that compiles to efficient machine level code (C++, Go, what have you). You can ship C code with Python to be compiled on the target and presented to Python as a library, and by convention such modules are named with a leading underscore. So we can expect that _imaging is a C code module. And if you go up a level you'll find _imaging.c, with a draw_ellipse function inside it. Cheers, Cameron Simpson (formerly c...@zip.com.au) -- https://mail.python.org/mailman/listinfo/python-list
Re: Argh!! Can't wrap my head around this Python stuff!
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??
The first argument of ellipse(), self is a strong hint that it is a method. If
you look into ImageDraw.py, located at
>>> import PIL.ImageDraw
>>> PIL.ImageDraw.__file__
'/usr/lib/python3/dist-packages/PIL/ImageDraw.py'
on my machine, you'll find the class of the same name, ImageDraw, and in its
initializer there's an assignment to the self.draw attribute:
self.draw = Image.core.draw(self.im, blend)
Image is another module
>>> PIL.ImageDraw.Image
and if you look for the name 'core' in that module you'll find
from PIL import _imaging as core
>>> PIL.ImageDraw.Image.core
That would be the right time to say "Argh" with any number of exclamation marks
for those who don't know C, but since you are familiar with that language
there's nothing to stop you from downloading the PIL (or rather the pillow)
source and look into the implementation. Once you have the complete code
https://pypi.python.org/pypi/Pillow/4.3.0
https://python-pillow.org/
https://github.com/python-pillow/Pillow
$ git clone https://github.com/python-pillow/Pillow.git
...you can use traditional tools:
$ find Pillow/ -name \*.c -print0 | xargs -0 grep draw_ellipse
Pillow/_imaging.c:_draw_ellipse(ImagingDrawObject* self, PyObject* args)
Pillow/_imaging.c:{"draw_ellipse", (PyCFunction)_draw_ellipse, 1},
Rinse and repeat ;)
--
https://mail.python.org/mailman/listinfo/python-list
C-api: Executing several scripts as __main__: globals are gone
Hello,
in PyInstaller we execute several Python scripts one after each other. The
primary use of this is to run some setup prior to the actual appication. Up to
now all scripts shared the same global variables, which worked well for 15
years, but now showed an error. The new code (scratched below) now deletes
sys.modules['__main__'], so the next script will get a fresh module and fresh
globals. This leads to an obscure error:
If a setup-script hooks into something, this hook does not see it's own
script's/module's globals. Thus running the scripts below (setup first, then
main), fails with:
Traceback (most recent call last):
â File "main-script", line 2, in
â File "setup-script", line 3, in do_it
NameError: global name 'sys' is not defined
Same effect for any other identifier defined globally in setup-script, e.g
global functions (which is worse then just a missing import).
I tried keeping a reference to the module (to avoid garbage-collection) both in
the C-code and in the setup-script. But this did not solve the issue, the
effect is the same. I also read through the CPython source but did not spot
anything useful. Additionally, this issue only occurs with Python 2.7 and 3.3,
Python 3.4 and up are okay.
Any ideas?
8<-- C-code scratch!! pseudo-code --- sys_modules =
PyImport_GetModuleDict(); for each entry in archive {
â â â data = Get_data_out_of_the_archive()
â â â code = PyMarshal_ReadObjectFromString(data)
/* execute as '__main__ for compatibility */
â â â module = PyImport_ExecCodeModule("__main__", code);
â â â Py_DECREF(module);
â â â /* remove '__main__' from sys.modules */
â â â PyObject_DelItem(sys_modules, "__main__");
}
..8<---
Now if a have these two scripts (these are examples:
..8< setup-script --
import sys
def do_it()
print(sys.modules)
sys.do_it = do_it
..8<-
and
..8< main-script --
import sys
sys.do_it()
..8<---
--
Regards
Hartmut Goebel
| Hartmut Goebel | h.goe...@crazy-compilers.com |
| www.crazy-compilers.com | compilers which you thought are impossible |
--
https://mail.python.org/mailman/listinfo/python-list
Re: Pros and cons of Python sources?
(Martin =?UTF-8?Q?Sch=C3=B6=C3=B6n?=) Den 2017-11-26 skrev Cameron Simpson : > On 25Nov2017 08:34, rusi wrote: >>On Saturday, November 25, 2017 at 9:45:07 PM UTC+5:30, Michael Torrie wrote: >>> The problem with mixing repository-installed packages with pip-installed >>> packages is that there's always a chance a Debian update will overwrite >>> a pip package, possibly with an older version. Or a pip-installed >>> package might bring in a new version that's not compatible with some >>> debian-installed package, breaking something. >> >>On (recent?) debian/ubuntu pip seems to use the 'user-scheme' >>which means pip runs without sudo and installs in ~/.local/lib >>So I dont believe literal overwriting would occur > > Though the point should be made that one should run pip as oneself, and try to > avoid doing it as the root user (including avoiding sudo). Many UNIX/Linux/etc > users believe "installs" should be done as root, and in this case that is > easily avoided, with all its potential for damage to the vendor supplied > environment. Hmm, I seem to remember not being able to install packages with pip unless I did sudo pip. Follow-up question: Is there a way to find out which packages were installed using pip and which are from Debian's repo? pip list seems to list everything. /Martin -- https://mail.python.org/mailman/listinfo/python-list
Re: Argh!! Can't wrap my head around this Python stuff!
Greg Tibbet wrote: > 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?? The C sources. Not all of PIL is ritten in Python. draw_ellipse() is a thin wrapper for ImagingDrawEllips(). See PIL/_imaging.c: https://github.com/python-pillow/Pillow/_imaging.c Which again is in libimage/Draw.c: https://github.com/python-pillow/Pillow/blob/13d84993717cffd64a2e1d7e3e6edb1 85973d559/libImaging/Draw.c calling ellipse(). -- --gv -- https://mail.python.org/mailman/listinfo/python-list
Re: Compile Python 3 interpreter to force 2-byte unicode
Le dimanche 26 novembre 2017 05:53:55 UTC+1, Rustom Mody a ÄCcritâ : > On Sunday, November 26, 2017 at 3:43:29 AM UTC+5:30, Chris Angelico wrote: > > On Sun, Nov 26, 2017 at 9:05 AM, wojtek.mula wrote: > > > Hi, my goal is to obtain an interpreter that internally > > > uses UCS-2. Such a simple code should print 65535: > > > > > > import sys > > > print sys.maxunicode > > > > > > This is enabled in Windows, but I want the same in Linux. > > > What options have I pass to the configure script? > > > > Why do you want to? What useful value do you have in creating this > > buggy interpreter? > > I see that you are familiar with this bug: https://bugs.python.org/issue13153 > > And I see it or something very close is still buggy in python 3.5 > [No it does not allow me to paste an SMP char but if I open a file containing > one it crashes and rather messily â ö no way to close the idle other than killing > the shell] > > No thats not a diatribe against idle; just that its reasonable to want python > to support work-arounds for reasonably common bugs in the current unicode-ecosystem Yes, it's a little bit extraordinary, to see a language which is supposed to work internally in a "UCS-2/UTF-16" (very quoted) mode with a graphical toolkit also woking in a "UCS-2/UTF-16" succeeds to raise UTF-8 errors (!). Patches over patches over patches over pathches ... will never solve what is wrong by design. As semi correctly pointed, for serious Unicode works use serious tools with a correct Unicode implementation. There are even tools, where the following is printable: >>> >>> '\ud800\udc00'.isprintable() False >>> -- https://mail.python.org/mailman/listinfo/python-list
Re: Argh!! Can't wrap my head around this Python stuff!
Greg Tibbet writes: >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! Which actually is older than Java. >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? Depends on the nature of â»selfâ«. Usually, the answer would be that it's defined in a superclass. But with Python, one could also decrypt a string and then feed the result to â»execâ« to dynamically add methods to an object whose source code is well hidden. Looking into the matter, it turns out, however, ... â»_draw_ellipseâ« is defined in the language C in the file â»_imaging.câ« and then mapped to â»draw_ellipseâ« via PyMethodDef which is part of Python's C API. -- https://mail.python.org/mailman/listinfo/python-list
Argh!! Can't wrap my head around this Python stuff!
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?? Thanks! -Stumpy (aka Greg) -- https://mail.python.org/mailman/listinfo/python-list
Re: connect four (game)
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. > if you really meant the bottom one then i'm totally baffled that it could be the top one for me and the bottom one for you ... is that something that can happen because of a bug? I am running on Windows 10 from IDLE (which should not affect your code) with 3.7.0a2 with tk 8.6.6. The OS and tk version could have an effect, though top versus bottom is hard to fathom. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: connect four (game)
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; if you really meant the bottom one then i'm totally baffled that it could be the top one for me and the bottom one for you ... is that something that can happen because of a bug? sorry if you were offended by what i wrote before; i didn't understand what you meant peace stm -- https://mail.python.org/mailman/listinfo/python-list
Re: Compile Python 3 interpreter to force 2-byte unicode
On Sun, Nov 26, 2017 at 9:05 AM, wrote: > Hi, my goal is to obtain an interpreter that internally > uses UCS-2. Such a simple code should print 65535: > > import sys > print sys.maxunicode > > This is enabled in Windows, but I want the same in Linux. > What options have I pass to the configure script? Why do you want to? What useful value do you have in creating this buggy interpreter? Ever since Python 3.3, that has simply not been an option. The bug has been solved. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: connect four (game)
On Friday, November 24, 2017 at 8:07:07 AM UTC-8, Chris Angelico wrote: > This is the kind of function that needs a docstring and some comments. > What exactly is this doing? What are the "lines" of the board? What's > the difference between "linear" and "lines"? What exactly is it > returning? producing documentation is an extremely difficult task for me, but i've come up with the following: """ makelines(length,numrows,numcolumns) IS THE LIST OF ALL LISTS L, WITH LENGTH length, OF COORDINATES FROM A numrows x numcolumns MATRIX, SUCH THAT THE ENTRIES OF L ALL LIE IN A LINE: LET horizontal BE ALL THE APPROPRIATE-LENGTH LISTS WHOSE ENTRIES LIE IN A HORIZONTAL LINE LET vertical BE ALL THE APPROPRIATE-LENGTH LISTS WHOSE ENTRIES LIE IN A VERTICAL LINE LET downward BE ALL THE APPROPRIATE-LENGTH LISTS WHOSE ENTRIES LIE IN A DOWNWARD-SLOPING DIAGONAL LINE LET upward BE ALL THE APPROPRIATE-LENGTH LISTS WHOSE ENTRIES LIE IN AN UPWARD-SLOPING DIAGONAL LINE THEN makelines(length,numrows,numcolumns) IS THE UNION OF ALL THE AFOREMENTIONED SETS """ def makelines(length,numrows,numcolumns): horizontal = [[(i, j+k) for k in range(length)] for i in range(numrows) for j in range(numcolumns)] vertical = [[(i+k, j) for k in range(length)] for i in range(numrows) for j in range(numcolumns)] downward = [[(i+k, j+k) for k in range(length)] for i in range(numrows) for j in range(numcolumns)] upward = [[(i+k, j-k) for k in range(length)] for i in range(numrows) for j in range(numcolumns)] linear = horizontal + vertical + downward + upward return [line for line in linear if all(i in range(6) and j in range(7) for (i,j) in line)] def getlines(board): coordlines = makelines(4,6,7) ## GLOBAL return [[board[square] for square in line] for line in coordlines i tried to remove all the superfluous spaces from that, but lining up code vertically is very helpful to me, so i don't think i can really dispense with the practice peace stm -- https://mail.python.org/mailman/listinfo/python-list
Compile Python 3 interpreter to force 2-byte unicode
Hi, my goal is to obtain an interpreter that internally uses UCS-2. Such a simple code should print 65535: import sys print sys.maxunicode This is enabled in Windows, but I want the same in Linux. What options have I pass to the configure script? w. -- 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 Saturday, November 25, 2017 at 5:00:12 AM UTC-8, bartc wrote: > Actually I've no idea what these tests are supposed to prove. me neither; i think you guys may be getting me out of my depth now > They are to do with one class called 'infinity', which is never used in the rest > of the program apart from one line. > > I established that within a few seconds, and I would concentrate on what > 'infinity' is actually for, rather than go to considerable lengths to > test a class that may not actually be needed. my current version of "infinity" looks like this class Infinity: def __init__(self,signum): self.signum = (+1) if signum > 0 else (-1) def __repr__(self): return '+oo' if self.signum == (+1) else '-oo' def __lt__(self,other): return self.signum == (-1) def __le__(self,other): return self.signum == (-1) def __gt__(self,other): return self.signum == (+1) def __ge__(self,other): return self.signum == (+1) def __eq__(self,other): return isinstance(other,Infinity) and self.signum == other.signum the idea is that there should be exactly one object posinf (positive infinity) that compares as strictly greater than any number ever considered, and exactly one object neginf that compares as strictly less; as the code stands now there is no reason not to use +/-70 in that capacity; the "infinity" class is there so that the game-playing parts of the code (which at present are intentionally as primitive as possible) can be modified more smoothly later; the single place where "infinity" is instantiated is in the function "getvalue", which returns the value of a finished game: def getvalue(winner,accessibles): return Infinity(+1) if winner == ex else Infinity(-1) if winner == oh else 0 if not accessibles else None if ex has won then the value of the game is posinf; if oh has won then it's neginf; if the game is tied (no winner but no accessible columns remaining) then the value of the game is zero; otherwise the game is not finished and its finished value is None peace stm -- https://mail.python.org/mailman/listinfo/python-list
Re: Argh!! Can't wrap my head around this Python stuff!
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??
The first argument of ellipse(), self is a strong hint that it is a method. If
you look into ImageDraw.py, located at
>>> import PIL.ImageDraw
>>> PIL.ImageDraw.__file__
'/usr/lib/python3/dist-packages/PIL/ImageDraw.py'
on my machine, you'll find the class of the same name, ImageDraw, and in its
initializer there's an assignment to the self.draw attribute:
self.draw = Image.core.draw(self.im, blend)
Image is another module
>>> PIL.ImageDraw.Image
and if you look for the name 'core' in that module you'll find
from PIL import _imaging as core
>>> PIL.ImageDraw.Image.core
That would be the right time to say "Argh" with any number of exclamation marks
for those who don't know C, but since you are familiar with that language
there's nothing to stop you from downloading the PIL (or rather the pillow)
source and look into the implementation. Once you have the complete code
https://pypi.python.org/pypi/Pillow/4.3.0
https://python-pillow.org/
https://github.com/python-pillow/Pillow
$ git clone https://github.com/python-pillow/Pillow.git
...you can use traditional tools:
$ find Pillow/ -name \*.c -print0 | xargs -0 grep draw_ellipse
Pillow/_imaging.c:_draw_ellipse(ImagingDrawObject* self, PyObject* args)
Pillow/_imaging.c:{"draw_ellipse", (PyCFunction)_draw_ellipse, 1},
Rinse and repeat ;)
--
https://mail.python.org/mailman/listinfo/python-list
Re: connect four (game)
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. 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. -- https://mail.python.org/mailman/listinfo/python-list
Re: Argh!! Can't wrap my head around this Python stuff!
On 26Nov2017 01:09, Greg Tibbet wrote: >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?? "ellispse()" is a method in the ImageDraw class. Looking at the __init__ method of that class we see: self.draw = Image.core.draw(self.im, blend) so "self.draw" in your code above is the result of "Image.core.draw(self.im, blend)". "Image" is the Image module imported at the top of ImageDraw.py. So we hop over to Image.py, which has this code: try: # If the _imaging C module is not present, you can still use # the "open" function to identify files, but you cannot load # them. Note that other modules should not refer to _imaging # directly; import Image and use the Image.core variable instead. import _imaging core = _imaging del _imaging except ImportError, v: core = _imaging_not_installed() if str(v)[:20] == "Module use of python" and warnings: # The _imaging C module is present, but not compiled for # the right version (windows only). Print a warning, if # possible. warnings.warn( "The _imaging extension was built for another version " "of Python; most PIL functions will be disabled", RuntimeWarning ) Now the import works (because you'd get exceptions otherwise), so code which matters is that the top of that: import _imaging core = _imaging del _imaging So "core" is a reference to the "_imaging" module (and the name "_imaging" has been discarded). So... The name Image.core is now a reference to that module. So back in ImageDraw, the call to "Image.core.draw()" called the function "draw" from the _imaging module, which presumably returns some kind of drawing object, and _that_ object has a "draw_ellispe" method. Now, dynamic languages like Python don't lend themselves to screamingly fast compute, so expensive stuff like drawing graphics is usually done by hooking into special purpose libraries written in C or something that compiles to efficient machine level code (C++, Go, what have you). You can ship C code with Python to be compiled on the target and presented to Python as a library, and by convention such modules are named with a leading underscore. So we can expect that _imaging is a C code module. And if you go up a level you'll find _imaging.c, with a draw_ellipse function inside it. Cheers, Cameron Simpson (formerly c...@zip.com.au) -- https://mail.python.org/mailman/listinfo/python-list
Re: Compile Python 3 interpreter to force 2-byte unicode
On Sunday, November 26, 2017 at 1:00:19 AM UTC+1, Terry Reedy wrote: > You must be trying to compile 2.7. There may be Linux distributions > that compile this way. You're right, I need 2.7. Any hint which distro has got these settings? > If you want to seriously work with unicode, many recommend using modern > Python. I have to fix a bug in my C extension that appears only in UCS-2 python (i.e. Windows). I can reboot to Windows and debug there, but it's pain in a neck for various reasons. w. -- https://mail.python.org/mailman/listinfo/python-list
Re: Compile Python 3 interpreter to force 2-byte unicode
Le dimanche 26 novembre 2017 05:53:55 UTC+1, Rustom Mody a ÄCcritâ : > On Sunday, November 26, 2017 at 3:43:29 AM UTC+5:30, Chris Angelico wrote: > > On Sun, Nov 26, 2017 at 9:05 AM, wojtek.mula wrote: > > > Hi, my goal is to obtain an interpreter that internally > > > uses UCS-2. Such a simple code should print 65535: > > > > > > import sys > > > print sys.maxunicode > > > > > > This is enabled in Windows, but I want the same in Linux. > > > What options have I pass to the configure script? > > > > Why do you want to? What useful value do you have in creating this > > buggy interpreter? > > I see that you are familiar with this bug: https://bugs.python.org/issue13153 > > And I see it or something very close is still buggy in python 3.5 > [No it does not allow me to paste an SMP char but if I open a file containing > one it crashes and rather messily â ö no way to close the idle other than killing > the shell] > > No thats not a diatribe against idle; just that its reasonable to want python > to support work-arounds for reasonably common bugs in the current unicode-ecosystem Yes, it's a little bit extraordinary, to see a language which is supposed to work internally in a "UCS-2/UTF-16" (very quoted) mode with a graphical toolkit also woking in a "UCS-2/UTF-16" succeeds to raise UTF-8 errors (!). Patches over patches over patches over pathches ... will never solve what is wrong by design. As semi correctly pointed, for serious Unicode works use serious tools with a correct Unicode implementation. There are even tools, where the following is printable: >>> >>> '\ud800\udc00'.isprintable() False >>> -- https://mail.python.org/mailman/listinfo/python-list
Re: Argh!! Can't wrap my head around this Python stuff!
On Sunday, November 26, 2017 at 4:10:12 AM UTC-5, 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?? > > Thanks! > -Stumpy (aka Greg) I'm googlesmart when it comes to Python. I used to know C. I practically knew what the assembly language would look like when it compiled. There was no internet and searching through books can be really laborious so you almost had to really know it to use it. But with Python, I don't start from first principles. I google what I want to do, download the appropriate packages and read through the examples. It can be really frustrating when you get bugs, because you don't know what's going on deep down in the code. -- https://mail.python.org/mailman/listinfo/python-list
Re: connect four (game)
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. > 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. So there was something else wrong with the chip. I'm not sure what your point is. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Stopping an iterator and continuing later
r...@zedat.fu-berlin.de (Stefan Ram) writes: >Then you can use pickle or custom methods to save and >restore the object, or get the state from an iterator >and create a new iterator with that state later. One does not always have to write a custom class, for example: main.py import pickle r = range( 9 ) i = iter( r ) del r next( i ) next( i ) next( i ) bytes = pickle.dumps( i ) del i i = pickle.loads( bytes ) print( next( i )) del i del pickle transcript 3 -- 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!
Greg Tibbet wrote: > 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?? The C sources. Not all of PIL is ritten in Python. draw_ellipse() is a thin wrapper for ImagingDrawEllips(). See PIL/_imaging.c: https://github.com/python-pillow/Pillow/_imaging.c Which again is in libimage/Draw.c: https://github.com/python-pillow/Pillow/blob/13d84993717cffd64a2e1d7e3e6edb1 85973d559/libImaging/Draw.c calling ellipse(). -- --gv -- https://mail.python.org/mailman/listinfo/python-list
Re: Stopping an iterator and continuing later (Posting On Python-List P
On Saturday, 25 November 2017 20:59:02 UTC, Lawrence Dâ ÖOliveiro wrote: > On Sunday, November 26, 2017 at 6:43:05 AM UTC+13, novembe...@gmail.com wrote: > > I worked out how to use iterators to generate values one at a time > > then ran into a second problem which is time. Is it possible to > > save an iterator so that i can continue from where I stopped? > > Yes. Just stop calling it. Then, when you start again, you will get the values continuing from that point. I should have added I switch off the machine when I stop. ( I dont have options to keep it in a sleep mode or in hibernation ) NN -- https://mail.python.org/mailman/listinfo/python-list
Re: Argh!! Can't wrap my head around this Python stuff!
Greg Tibbet writes: >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! Which actually is older than Java. >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? Depends on the nature of â»selfâ«. Usually, the answer would be that it's defined in a superclass. But with Python, one could also decrypt a string and then feed the result to â»execâ« to dynamically add methods to an object whose source code is well hidden. Looking into the matter, it turns out, however, ... â»_draw_ellipseâ« is defined in the language C in the file â»_imaging.câ« and then mapped to â»draw_ellipseâ« via PyMethodDef which is part of Python's C API. -- https://mail.python.org/mailman/listinfo/python-list
Re: connect four (game)
On Sat, 25 Nov 2017 12:26:52 -0800, namenobodywants wrote: > On Friday, November 24, 2017 at 8:07:07 AM UTC-8, Chris Angelico wrote: > >> This is the kind of function that needs a docstring and some comments. >> What exactly is this doing? What are the "lines" of the board? What's >> the difference between "linear" and "lines"? What exactly is it >> returning? > > producing documentation is an extremely difficult task for me, but i've > come up with the following: > > """ > makelines(length,numrows,numcolumns) IS THE LIST OF ALL LISTS L, WITH > LENGTH length, OF COORDINATES FROM A numrows x numcolumns MATRIX, SUCH > THAT THE ENTRIES OF L ALL LIE IN A LINE: > > LET horizontal BE ALL THE APPROPRIATE-LENGTH LISTS WHOSE ENTRIES LIE IN > A HORIZONTAL LINE LET vertical BE ALL THE APPROPRIATE-LENGTH LISTS WHOSE > ENTRIES LIE IN A VERTICAL LINE LET downward BE ALL THE > APPROPRIATE-LENGTH LISTS WHOSE ENTRIES LIE IN A DOWNWARD-SLOPING > DIAGONAL LINE LET upward BE ALL THE APPROPRIATE-LENGTH LISTS WHOSE > ENTRIES LIE IN AN UPWARD-SLOPING DIAGONAL LINE THEN > makelines(length,numrows,numcolumns) IS THE UNION OF ALL THE > AFOREMENTIONED SETS """ > > def makelines(length,numrows,numcolumns): > horizontal = [[(i, j+k) for k in range(length)] for i in > range(numrows) for j in range(numcolumns)] > vertical = [[(i+k, j) for k in range(length)] for i in > range(numrows) for j in range(numcolumns)] downward = [[(i+k, j+k) > for k in range(length)] for i in range(numrows) for j in > range(numcolumns)] > upward = [[(i+k, j-k) for k in range(length)] for i in > range(numrows) for j in range(numcolumns)] linear = horizontal + > vertical + downward + upward return [line for line in linear if > all(i in range(6) and j in range(7) for (i,j) in line)] > > def getlines(board): > coordlines = makelines(4,6,7) ## GLOBAL return [[board[square] for > square in line] for line in coordlines > > > i tried to remove all the superfluous spaces from that, but lining up > code vertically is very helpful to me, so i don't think i can really > dispense with the practice > > peace stm the documentation should come after the def statement that way is becomes a "Doc String" & can be accessed using the help function you may also want to check out the recommended way of structuring a doc string, it could help you with your difficulty in writing them (a problem shared by many) -- This door is baroquen, please wiggle Handel. (If I wiggle Handel, will it wiggle Bach?) -- Found on a door in the MSU music building -- 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: Pros and cons of Python sources?
Den 2017-11-26 skrev Cameron Simpson : > On 25Nov2017 08:34, rusi wrote: >>On Saturday, November 25, 2017 at 9:45:07 PM UTC+5:30, Michael Torrie wrote: >>> The problem with mixing repository-installed packages with pip-installed >>> packages is that there's always a chance a Debian update will overwrite >>> a pip package, possibly with an older version. Or a pip-installed >>> package might bring in a new version that's not compatible with some >>> debian-installed package, breaking something. >> >>On (recent?) debian/ubuntu pip seems to use the 'user-scheme' >>which means pip runs without sudo and installs in ~/.local/lib >>So I dont believe literal overwriting would occur > > Though the point should be made that one should run pip as oneself, and try to > avoid doing it as the root user (including avoiding sudo). Many UNIX/Linux/etc > users believe "installs" should be done as root, and in this case that is > easily avoided, with all its potential for damage to the vendor supplied > environment. Hmm, I seem to remember not being able to install packages with pip unless I did sudo pip. Follow-up question: Is there a way to find out which packages were installed using pip and which are from Debian's repo? pip list seems to list everything. /Martin -- https://mail.python.org/mailman/listinfo/python-list
Re: Compile Python 3 interpreter to force 2-byte unicode
26.11.17 01:59, Terry Reedy D¿D,ÑêDµ: > On 11/25/2017 5:12 PM, Chris Angelico wrote: >> On Sun, Nov 26, 2017 at 9:05 AM,â wrote: >>> Hi, my goal is to obtain an interpreter that internally >>> uses UCS-2. Such a simple code should print 65535: >>> >>> â â import sys >>> â â print sys.maxunicode >>> >>> This is enabled in Windows, but I want the same in Linux. >>> What options have I pass to the configure script? > > You must be trying to compile 2.7.â There may be Linux distributions > that compile this way. UCS-2 is the default in 2.7. But most Linux distributions build it with UCS-4. -- https://mail.python.org/mailman/listinfo/python-list
Re: Argh!! Can't wrap my head around this Python stuff!
Le 26/11/17 Ä 10:09, Greg Tibbet a ÄCcritâ : > 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?? > > Thanks! > -Stumpy (aka Greg) Hi, It's not defined in Python module but in Pillow-3.5/Pillow-master/libImaging/Draw.c ... line 748 Vincent -- 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: Compile Python 3 interpreter to force 2-byte unicode
On Sun, Nov 26, 2017 at 3:53 PM, Rustom Mody wrote: > On Sunday, November 26, 2017 at 3:43:29 AM UTC+5:30, Chris Angelico wrote: >> On Sun, Nov 26, 2017 at 9:05 AM, wojtek.mula wrote: >> > Hi, my goal is to obtain an interpreter that internally >> > uses UCS-2. Such a simple code should print 65535: >> > >> > import sys >> > print sys.maxunicode >> > >> > This is enabled in Windows, but I want the same in Linux. >> > What options have I pass to the configure script? >> >> Why do you want to? What useful value do you have in creating this >> buggy interpreter? > > I see that you are familiar with this bug: https://bugs.python.org/issue13153 > > And I see it or something very close is still buggy in python 3.5 > [No it does not allow me to paste an SMP char but if I open a file containing > one it crashes and rather messily â ö no way to close the idle other than killing > the shell] > > No thats not a diatribe against idle; just that its reasonable to want python > to support work-arounds for reasonably common bugs in the current unicode-ecosystem No, that issue is about IDLE (and, AIUI, is actually a Tcl/Tk limitation). I'm talking about how Windows Pythons up to 3.2 could take a single character and treat it as two, or could reverse a string and make it actually not contain code points any more, or get all the subscripts off by one (or more than one). That didn't happen on the Linux builds. They had the lesser problem that all strings consumed large amounts of memory. As of Python 3.3, neither problem exists on either platform. You can't compile them back in. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
C-api: Executing several scripts as __main__: globals are gone
Hello,
in PyInstaller we execute several Python scripts one after each other. The
primary use of this is to run some setup prior to the actual appication. Up to
now all scripts shared the same global variables, which worked well for 15
years, but now showed an error. The new code (scratched below) now deletes
sys.modules['__main__'], so the next script will get a fresh module and fresh
globals. This leads to an obscure error:
If a setup-script hooks into something, this hook does not see it's own
script's/module's globals. Thus running the scripts below (setup first, then
main), fails with:
Traceback (most recent call last):
â File "main-script", line 2, in
â File "setup-script", line 3, in do_it
NameError: global name 'sys' is not defined
Same effect for any other identifier defined globally in setup-script, e.g
global functions (which is worse then just a missing import).
I tried keeping a reference to the module (to avoid garbage-collection) both in
the C-code and in the setup-script. But this did not solve the issue, the
effect is the same. I also read through the CPython source but did not spot
anything useful. Additionally, this issue only occurs with Python 2.7 and 3.3,
Python 3.4 and up are okay.
Any ideas?
8<-- C-code scratch!! pseudo-code --- sys_modules =
PyImport_GetModuleDict(); for each entry in archive {
â â â data = Get_data_out_of_the_archive()
â â â code = PyMarshal_ReadObjectFromString(data)
/* execute as '__main__ for compatibility */
â â â module = PyImport_ExecCodeModule("__main__", code);
â â â Py_DECREF(module);
â â â /* remove '__main__' from sys.modules */
â â â PyObject_DelItem(sys_modules, "__main__");
}
..8<---
Now if a have these two scripts (these are examples:
..8< setup-script --
import sys
def do_it()
print(sys.modules)
sys.do_it = do_it
..8<-
and
..8< main-script --
import sys
sys.do_it()
..8<---
--
Regards
Hartmut Goebel
| Hartmut Goebel | h.goe...@crazy-compilers.com |
| www.crazy-compilers.com | compilers which you thought are impossible |
--
https://mail.python.org/mailman/listinfo/python-list
Re: Compile Python 3 interpreter to force 2-byte unicode
On Sunday, November 26, 2017 at 3:43:29 AM UTC+5:30, Chris Angelico wrote: > On Sun, Nov 26, 2017 at 9:05 AM, wojtek.mula wrote: > > Hi, my goal is to obtain an interpreter that internally > > uses UCS-2. Such a simple code should print 65535: > > > > import sys > > print sys.maxunicode > > > > This is enabled in Windows, but I want the same in Linux. > > What options have I pass to the configure script? > > Why do you want to? What useful value do you have in creating this > buggy interpreter? I see that you are familiar with this bug: https://bugs.python.org/issue13153 And I see it or something very close is still buggy in python 3.5 [No it does not allow me to paste an SMP char but if I open a file containing one it crashes and rather messily â ö no way to close the idle other than killing the shell] No thats not a diatribe against idle; just that its reasonable to want python to support work-arounds for reasonably common bugs in the current unicode-ecosystem -- https://mail.python.org/mailman/listinfo/python-list
Re: Compile Python 3 interpreter to force 2-byte unicode
On 11/25/17 5:05 PM, wojtek.m...@gmail.com wrote: > Hi, my goal is to obtain an interpreter that internally > uses UCS-2. Such a simple code should print 65535: > >import sys >print sys.maxunicode > > This is enabled in Windows, but I want the same in Linux. > What options have I pass to the configure script? > You say you want Python 3, but you also say you have maxunicode == 65535 on Windows.â That must be Python 2.â Python 3 always has maxunicode == 1114111. Can you say more about what you need to do? --Ned. -- https://mail.python.org/mailman/listinfo/python-list
Argh!! Can't wrap my head around this Python stuff!
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?? Thanks! -Stumpy (aka Greg) -- https://mail.python.org/mailman/listinfo/python-list
Re: Pros and cons of Python sources?
On 25Nov2017 08:34, rusi wrote: >On Saturday, November 25, 2017 at 9:45:07 PM UTC+5:30, Michael Torrie wrote: >> The problem with mixing repository-installed packages with pip-installed >> packages is that there's always a chance a Debian update will overwrite >> a pip package, possibly with an older version. Or a pip-installed >> package might bring in a new version that's not compatible with some >> debian-installed package, breaking something. > >On (recent?) debian/ubuntu pip seems to use the 'user-scheme' >which means pip runs without sudo and installs in ~/.local/lib >So I dont believe literal overwriting would occur Though the point should be made that one should run pip as oneself, and try to avoid doing it as the root user (including avoiding sudo). Many UNIX/Linux/etc users believe "installs" should be done as root, and in this case that is easily avoided, with all its potential for damage to the vendor supplied environment. Cheers, Cameron Simpson (formerly c...@zip.com.au) -- https://mail.python.org/mailman/listinfo/python-list
Re: Compile Python 3 interpreter to force 2-byte unicode
On Sun, Nov 26, 2017 at 10:59 AM, Terry Reedy wrote: > On 11/25/2017 5:12 PM, Chris Angelico wrote: >> >> On Sun, Nov 26, 2017 at 9:05 AM, wrote: >>> >>> Hi, my goal is to obtain an interpreter that internally >>> uses UCS-2. Such a simple code should print 65535: >>> >>>import sys >>>print sys.maxunicode >>> >>> This is enabled in Windows, but I want the same in Linux. >>> What options have I pass to the configure script? > > > You must be trying to compile 2.7. There may be Linux distributions that > compile this way. If you want to use, or ever encounter, non-BMP chars, > using surrogate pairs is problematical. By my reading of the official UCS-2 > docs, Python's old 16-bit unicode implementation is not fully compliant. > Others have claimed that is it not a UCS-2 implementation. See subject line. OP wishes to compile Python 3 (and almost certainly not 3.1 or 3.2) with the bugginess of Python 2's narrow builds. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: connect four (game)
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. > if you really meant the bottom one then i'm totally baffled that it could be the top one for me and the bottom one for you ... is that something that can happen because of a bug? I am running on Windows 10 from IDLE (which should not affect your code) with 3.7.0a2 with tk 8.6.6. The OS and tk version could have an effect, though top versus bottom is hard to fathom. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Compile Python 3 interpreter to force 2-byte unicode
On 11/25/2017 5:12 PM, Chris Angelico wrote: > On Sun, Nov 26, 2017 at 9:05 AM, wrote: >> Hi, my goal is to obtain an interpreter that internally >> uses UCS-2. Such a simple code should print 65535: >> >>import sys >>print sys.maxunicode >> >> This is enabled in Windows, but I want the same in Linux. >> What options have I pass to the configure script? You must be trying to compile 2.7. There may be Linux distributions that compile this way. If you want to use, or ever encounter, non-BMP chars, using surrogate pairs is problematical. By my reading of the official UCS-2 docs, Python's old 16-bit unicode implementation is not fully compliant. Others have claimed that is it not a UCS-2 implementation. > Why do you want to? What useful value do you have in creating this > buggy interpreter? > Ever since Python 3.3, that has simply not been an > option. The bug has been solved. If you want to seriously work with unicode, many recommend using modern Python. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: connect four (game)
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; if you really meant the bottom one then i'm totally baffled that it could be the top one for me and the bottom one for you ... is that something that can happen because of a bug? sorry if you were offended by what i wrote before; i didn't understand what you meant peace stm -- https://mail.python.org/mailman/listinfo/python-list
Re: Compile Python 3 interpreter to force 2-byte unicode
On Sun, Nov 26, 2017 at 9:05 AM, wrote: > Hi, my goal is to obtain an interpreter that internally > uses UCS-2. Such a simple code should print 65535: > > import sys > print sys.maxunicode > > This is enabled in Windows, but I want the same in Linux. > What options have I pass to the configure script? Why do you want to? What useful value do you have in creating this buggy interpreter? Ever since Python 3.3, that has simply not been an option. The bug has been solved. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: connect four (game)
On Saturday, November 25, 2017 at 5:00:12 AM UTC-8, bartc wrote: > Actually I've no idea what these tests are supposed to prove. me neither; i think you guys may be getting me out of my depth now > They are to do with one class called 'infinity', which is never used in the rest > of the program apart from one line. > > I established that within a few seconds, and I would concentrate on what > 'infinity' is actually for, rather than go to considerable lengths to > test a class that may not actually be needed. my current version of "infinity" looks like this class Infinity: def __init__(self,signum): self.signum = (+1) if signum > 0 else (-1) def __repr__(self): return '+oo' if self.signum == (+1) else '-oo' def __lt__(self,other): return self.signum == (-1) def __le__(self,other): return self.signum == (-1) def __gt__(self,other): return self.signum == (+1) def __ge__(self,other): return self.signum == (+1) def __eq__(self,other): return isinstance(other,Infinity) and self.signum == other.signum the idea is that there should be exactly one object posinf (positive infinity) that compares as strictly greater than any number ever considered, and exactly one object neginf that compares as strictly less; as the code stands now there is no reason not to use +/-70 in that capacity; the "infinity" class is there so that the game-playing parts of the code (which at present are intentionally as primitive as possible) can be modified more smoothly later; the single place where "infinity" is instantiated is in the function "getvalue", which returns the value of a finished game: def getvalue(winner,accessibles): return Infinity(+1) if winner == ex else Infinity(-1) if winner == oh else 0 if not accessibles else None if ex has won then the value of the game is posinf; if oh has won then it's neginf; if the game is tied (no winner but no accessible columns remaining) then the value of the game is zero; otherwise the game is not finished and its finished value is None peace stm -- https://mail.python.org/mailman/listinfo/python-list
Compile Python 3 interpreter to force 2-byte unicode
Hi, my goal is to obtain an interpreter that internally uses UCS-2. Such a simple code should print 65535: import sys print sys.maxunicode This is enabled in Windows, but I want the same in Linux. What options have I pass to the configure script? w. -- https://mail.python.org/mailman/listinfo/python-list
Re: connect four (game)
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. 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. -- https://mail.python.org/mailman/listinfo/python-list
Re: connect four (game)
On Friday, November 24, 2017 at 8:07:07 AM UTC-8, Chris Angelico wrote: > This is the kind of function that needs a docstring and some comments. > What exactly is this doing? What are the "lines" of the board? What's > the difference between "linear" and "lines"? What exactly is it > returning? producing documentation is an extremely difficult task for me, but i've come up with the following: """ makelines(length,numrows,numcolumns) IS THE LIST OF ALL LISTS L, WITH LENGTH length, OF COORDINATES FROM A numrows x numcolumns MATRIX, SUCH THAT THE ENTRIES OF L ALL LIE IN A LINE: LET horizontal BE ALL THE APPROPRIATE-LENGTH LISTS WHOSE ENTRIES LIE IN A HORIZONTAL LINE LET vertical BE ALL THE APPROPRIATE-LENGTH LISTS WHOSE ENTRIES LIE IN A VERTICAL LINE LET downward BE ALL THE APPROPRIATE-LENGTH LISTS WHOSE ENTRIES LIE IN A DOWNWARD-SLOPING DIAGONAL LINE LET upward BE ALL THE APPROPRIATE-LENGTH LISTS WHOSE ENTRIES LIE IN AN UPWARD-SLOPING DIAGONAL LINE THEN makelines(length,numrows,numcolumns) IS THE UNION OF ALL THE AFOREMENTIONED SETS """ def makelines(length,numrows,numcolumns): horizontal = [[(i, j+k) for k in range(length)] for i in range(numrows) for j in range(numcolumns)] vertical = [[(i+k, j) for k in range(length)] for i in range(numrows) for j in range(numcolumns)] downward = [[(i+k, j+k) for k in range(length)] for i in range(numrows) for j in range(numcolumns)] upward = [[(i+k, j-k) for k in range(length)] for i in range(numrows) for j in range(numcolumns)] linear = horizontal + vertical + downward + upward return [line for line in linear if all(i in range(6) and j in range(7) for (i,j) in line)] def getlines(board): coordlines = makelines(4,6,7) ## GLOBAL return [[board[square] for square in line] for line in coordlines i tried to remove all the superfluous spaces from that, but lining up code vertically is very helpful to me, so i don't think i can really dispense with the practice peace stm -- 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: Argh!! Can't wrap my head around this Python stuff!
On Sunday, November 26, 2017 at 4:10:12 AM UTC-5, 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?? > > Thanks! > -Stumpy (aka Greg) I'm googlesmart when it comes to Python. I used to know C. I practically knew what the assembly language would look like when it compiled. There was no internet and searching through books can be really laborious so you almost had to really know it to use it. But with Python, I don't start from first principles. I google what I want to do, download the appropriate packages and read through the examples. It can be really frustrating when you get bugs, because you don't know what's going on deep down in the code. -- https://mail.python.org/mailman/listinfo/python-list
Re: connect four (game)
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. > 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. So there was something else wrong with the chip. I'm not sure what your point is. ChrisA -- 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: 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: Argh!! Can't wrap my head around this Python stuff!
Le 26/11/17 à 10:09, Greg Tibbet a écrit : 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?? Thanks! -Stumpy (aka Greg) Hi, It's not defined in Python module but in Pillow-3.5/Pillow-master/libImaging/Draw.c ... line 748 Vincent -- https://mail.python.org/mailman/listinfo/python-list
Re: Stopping an iterator and continuing later (Posting On Python-List Prohibited)
On Saturday, 25 November 2017 20:59:02 UTC, Lawrence D’Oliveiro wrote: > On Sunday, November 26, 2017 at 6:43:05 AM UTC+13, novembe...@gmail.com wrote: > > I worked out how to use iterators to generate values one at a time > > then ran into a second problem which is time. Is it possible to > > save an iterator so that i can continue from where I stopped? > > Yes. Just stop calling it. Then, when you start again, you will get the > values continuing from that point. I should have added I switch off the machine when I stop. ( I dont have options to keep it in a sleep mode or in hibernation ) NN -- https://mail.python.org/mailman/listinfo/python-list
Re: connect four (game)
On Sat, 25 Nov 2017 12:26:52 -0800, namenobodywants wrote: > On Friday, November 24, 2017 at 8:07:07 AM UTC-8, Chris Angelico wrote: > >> This is the kind of function that needs a docstring and some comments. >> What exactly is this doing? What are the "lines" of the board? What's >> the difference between "linear" and "lines"? What exactly is it >> returning? > > producing documentation is an extremely difficult task for me, but i've > come up with the following: > > """ > makelines(length,numrows,numcolumns) IS THE LIST OF ALL LISTS L, WITH > LENGTH length, OF COORDINATES FROM A numrows x numcolumns MATRIX, SUCH > THAT THE ENTRIES OF L ALL LIE IN A LINE: > > LET horizontal BE ALL THE APPROPRIATE-LENGTH LISTS WHOSE ENTRIES LIE IN > A HORIZONTAL LINE LET vertical BE ALL THE APPROPRIATE-LENGTH LISTS WHOSE > ENTRIES LIE IN A VERTICAL LINE LET downward BE ALL THE > APPROPRIATE-LENGTH LISTS WHOSE ENTRIES LIE IN A DOWNWARD-SLOPING > DIAGONAL LINE LET upward BE ALL THE APPROPRIATE-LENGTH LISTS WHOSE > ENTRIES LIE IN AN UPWARD-SLOPING DIAGONAL LINE THEN > makelines(length,numrows,numcolumns) IS THE UNION OF ALL THE > AFOREMENTIONED SETS """ > > def makelines(length,numrows,numcolumns): > horizontal = [[(i, j+k) for k in range(length)] for i in > range(numrows) for j in range(numcolumns)] > vertical = [[(i+k, j) for k in range(length)] for i in > range(numrows) for j in range(numcolumns)] downward = [[(i+k, j+k) > for k in range(length)] for i in range(numrows) for j in > range(numcolumns)] > upward = [[(i+k, j-k) for k in range(length)] for i in > range(numrows) for j in range(numcolumns)] linear = horizontal + > vertical + downward + upward return [line for line in linear if > all(i in range(6) and j in range(7) for (i,j) in line)] > > def getlines(board): > coordlines = makelines(4,6,7) ## GLOBAL return [[board[square] for > square in line] for line in coordlines > > > i tried to remove all the superfluous spaces from that, but lining up > code vertically is very helpful to me, so i don't think i can really > dispense with the practice > > peace stm the documentation should come after the def statement that way is becomes a "Doc String" & can be accessed using the help function you may also want to check out the recommended way of structuring a doc string, it could help you with your difficulty in writing them (a problem shared by many) -- This door is baroquen, please wiggle Handel. (If I wiggle Handel, will it wiggle Bach?) -- Found on a door in the MSU music building -- 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: Argh!! Can't wrap my head around this Python stuff!
On 26Nov2017 01:09, Greg Tibbet wrote: 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?? "ellispse()" is a method in the ImageDraw class. Looking at the __init__ method of that class we see: self.draw = Image.core.draw(self.im, blend) so "self.draw" in your code above is the result of "Image.core.draw(self.im, blend)". "Image" is the Image module imported at the top of ImageDraw.py. So we hop over to Image.py, which has this code: try: # If the _imaging C module is not present, you can still use # the "open" function to identify files, but you cannot load # them. Note that other modules should not refer to _imaging # directly; import Image and use the Image.core variable instead. import _imaging core = _imaging del _imaging except ImportError, v: core = _imaging_not_installed() if str(v)[:20] == "Module use of python" and warnings: # The _imaging C module is present, but not compiled for # the right version (windows only). Print a warning, if # possible. warnings.warn( "The _imaging extension was built for another version " "of Python; most PIL functions will be disabled", RuntimeWarning ) Now the import works (because you'd get exceptions otherwise), so code which matters is that the top of that: import _imaging core = _imaging del _imaging So "core" is a reference to the "_imaging" module (and the name "_imaging" has been discarded). So... The name Image.core is now a reference to that module. So back in ImageDraw, the call to "Image.core.draw()" called the function "draw" from the _imaging module, which presumably returns some kind of drawing object, and _that_ object has a "draw_ellispe" method. Now, dynamic languages like Python don't lend themselves to screamingly fast compute, so expensive stuff like drawing graphics is usually done by hooking into special purpose libraries written in C or something that compiles to efficient machine level code (C++, Go, what have you). You can ship C code with Python to be compiled on the target and presented to Python as a library, and by convention such modules are named with a leading underscore. So we can expect that _imaging is a C code module. And if you go up a level you'll find _imaging.c, with a draw_ellipse function inside it. Cheers, Cameron Simpson (formerly c...@zip.com.au) -- https://mail.python.org/mailman/listinfo/python-list
Re: Argh!! Can't wrap my head around this Python stuff!
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??
The first argument of ellipse(), self is a strong hint that it is a method.
If you look into ImageDraw.py, located at
>>> import PIL.ImageDraw
>>> PIL.ImageDraw.__file__
'/usr/lib/python3/dist-packages/PIL/ImageDraw.py'
on my machine, you'll find the class of the same name, ImageDraw, and in its
initializer there's an assignment to the self.draw attribute:
self.draw = Image.core.draw(self.im, blend)
Image is another module
>>> PIL.ImageDraw.Image
and if you look for the name 'core' in that module you'll find
from PIL import _imaging as core
>>> PIL.ImageDraw.Image.core
That would be the right time to say "Argh" with any number of exclamation
marks for those who don't know C, but since you are familiar with that
language there's nothing to stop you from downloading the PIL (or rather the
pillow) source and look into the implementation. Once you have the complete
code
https://pypi.python.org/pypi/Pillow/4.3.0
https://python-pillow.org/
https://github.com/python-pillow/Pillow
$ git clone https://github.com/python-pillow/Pillow.git
...you can use traditional tools:
$ find Pillow/ -name \*.c -print0 | xargs -0 grep draw_ellipse
Pillow/_imaging.c:_draw_ellipse(ImagingDrawObject* self, PyObject* args)
Pillow/_imaging.c:{"draw_ellipse", (PyCFunction)_draw_ellipse, 1},
Rinse and repeat ;)
--
https://mail.python.org/mailman/listinfo/python-list
C-api: Executing several scripts as __main__: globals are gone
Hello,
in PyInstaller we execute several Python scripts one after each other.
The primary use of this is to run some setup prior to the actual
appication. Up to now all scripts shared the same global variables,
which worked well for 15 years, but now showed an error. The new code
(scratched below) now deletes sys.modules['__main__'], so the next
script will get a fresh module and fresh globals. This leads to an
obscure error:
If a setup-script hooks into something, this hook does not see it's own
script's/module's globals. Thus running the scripts below (setup first,
then main), fails with:
Traceback (most recent call last):
File "main-script", line 2, in
File "setup-script", line 3, in do_it
NameError: global name 'sys' is not defined
Same effect for any other identifier defined globally in setup-script,
e.g global functions (which is worse then just a missing import).
I tried keeping a reference to the module (to avoid garbage-collection)
both in the C-code and in the setup-script. But this did not solve the
issue, the effect is the same. I also read through the CPython source
but did not spot anything useful. Additionally, this issue only occurs
with Python 2.7 and 3.3, Python 3.4 and up are okay.
Any ideas?
8<-- C-code scratch!! pseudo-code ---
sys_modules = PyImport_GetModuleDict();
for each entry in archive {
data = Get_data_out_of_the_archive()
code = PyMarshal_ReadObjectFromString(data)
/* execute as '__main__ for compatibility */
module = PyImport_ExecCodeModule("__main__", code);
Py_DECREF(module);
/* remove '__main__' from sys.modules */
PyObject_DelItem(sys_modules, "__main__");
}
..8<---
Now if a have these two scripts (these are examples:
..8< setup-script --
import sys
def do_it()
print(sys.modules)
sys.do_it = do_it
..8<-
and
..8< main-script --
import sys
sys.do_it()
..8<---
--
Regards
Hartmut Goebel
| Hartmut Goebel | h.goe...@crazy-compilers.com |
| www.crazy-compilers.com | compilers which you thought are impossible |
--
https://mail.python.org/mailman/listinfo/python-list
Re: Pros and cons of Python sources?
Den 2017-11-26 skrev Cameron Simpson : > On 25Nov2017 08:34, rusi wrote: >>On Saturday, November 25, 2017 at 9:45:07 PM UTC+5:30, Michael Torrie wrote: >>> The problem with mixing repository-installed packages with pip-installed >>> packages is that there's always a chance a Debian update will overwrite >>> a pip package, possibly with an older version. Or a pip-installed >>> package might bring in a new version that's not compatible with some >>> debian-installed package, breaking something. >> >>On (recent?) debian/ubuntu pip seems to use the 'user-scheme' >>which means pip runs without sudo and installs in ~/.local/lib >>So I dont believe literal overwriting would occur > > Though the point should be made that one should run pip as oneself, and try > to > avoid doing it as the root user (including avoiding sudo). Many > UNIX/Linux/etc > users believe "installs" should be done as root, and in this case that is > easily avoided, with all its potential for damage to the vendor supplied > environment. Hmm, I seem to remember not being able to install packages with pip unless I did sudo pip. Follow-up question: Is there a way to find out which packages were installed using pip and which are from Debian's repo? pip list seems to list everything. /Martin -- https://mail.python.org/mailman/listinfo/python-list
Re: Argh!! Can't wrap my head around this Python stuff!
Greg Tibbet wrote: 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?? The C sources. Not all of PIL is ritten in Python. draw_ellipse() is a thin wrapper for ImagingDrawEllips(). See PIL/_imaging.c: https://github.com/python-pillow/Pillow/_imaging.c Which again is in libimage/Draw.c: https://github.com/python-pillow/Pillow/blob/13d84993717cffd64a2e1d7e3e6edb185973d559/libImaging/Draw.c calling ellipse(). -- --gv -- https://mail.python.org/mailman/listinfo/python-list
Argh!! Can't wrap my head around this Python stuff!
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?? Thanks! -Stumpy (aka Greg) -- https://mail.python.org/mailman/listinfo/python-list
