Re: Increasing the diversity of people who write Python (was:
On Monday, November 27, 2017 at 8:07:47 PM UTC+5:30, Chris Angelico wrote:
> On Tue, Nov 28, 2017 at 1:25 AM, Rustom Mody wrote:
> > You could go one step more sophisticated and use TeX-input method
> > (C-x RET C-\)
> > After which \'e will collapse as ÄC
> > â £Yeah ok but how the ^)*^$# am I to remember the mantra \'e?!â Ø you may
ask
> > Trueâ | So as you rightly do,
> > - pick it up from google
> > - put emacs into tex input mode
> > - paste from google into emacs
> > - place point on the new char and type C-u C-x =
> > Among other things emacs will helpfully inform you (among other things)
> > to input: type "\'{e}" or "\'e" with TeX input method
>
> Which is closely related to the Compose key input method that I use.
> First, you assign a key on your keyboard to be Compose (at least on
> all my systems, there isn't one by default); I use the key between
> left Ctrl and left Alt.
Ha Ha So you wont speak the unspeakable?â¿!â¡
I also have my compose set (to Capslock) And I entered those chars above with
C?? and C!! where C is Capslock
I most frequently use that for âçÆ (C=>) âåÆ (C->) â1 (C^1) âéü (C_1) etc One
can find other goodies at /usr/share/X11/locale/en_US.UTF-8/Compose
I didn't start with mentioning that to Skip because his basic requirement (as I
got it) was that
- input method should be OS-neutral
- emacs can be assumed
And so the only OS-non-neutrality that I am aware of is that sometimes Alt
works as Meta (gui-emacsen) and sometimes not terminal/text emacsen (typically,
though I believe some ppl successfully tweak this also) And so M-x can mean
Alt-x (chord) or ESC-x (sequence) and a few such anomalies But beyond that
emacsen should be same for all OSes (modulo versions)
--
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
While, If, Count Statements
Input : count = 0 if count < 5: print "Hello, I am an if statement and count is", count while count < 10: print "Hello, I am a while and count is", count count += 1 Output : Hello, I am an if statement and count is 0 Hello, I am a while and count is 0 Hello, I am a while and count is 1 Hello, I am a while and count is 2 Hello, I am a while and count is 3 Hello, I am a while and count is 4 Hello, I am a while and count is 5 Hello, I am a while and count is 6 Hello, I am a while and count is 7 Hello, I am a while and count is 8 Hello, I am a while and count is 9 The above input gives the output below. Why isn't the output instead : Hello, I am an if statement and count is 0 Hello, I am a while and count is 0 Hello, I am an if statement and count is 1 Hello, I am a while and count is 1 Hello, I am an if statement and count is 2 Hello, I am a while and count is 2 Hello, I am an if statement and count is 3 Hello, I am a while and count is 3 Hello, I am an if statement and count is 4 Hello, I am a while and count is 4 Hello, I am a while and count is 5 Hello, I am a while and count is 6 Hello, I am a while and count is 7 Hello, I am a while and count is 8 Hello, I am a while and count is 9 -- 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â1 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? > â1 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: Increasing the diversity of people who write Python (was:
On Friday, November 24, 2017 at 10:11:24 PM UTC+5:30, Skip Montanaro wrote:
> > Because if I already can't understand the words, it will be more useful
> > to me to be able to type them reliably at a keyboard, for replication,
> > search, discussion with others about the code, etc.
>
> I am probably not alone in my Americo-centric world where I can't even
> easily type accented Latin-1 characters. I happen to be using Linux as
> I type this, but type at a Windows keyboard at work (ugh) and have
> long been a user of Macs (still have one or two at home). Might the
> problem be further multiplied by the number of different ways I have
> of entering text? Would Emacs running on Linux, but displaying on
> Windows be different than Chrome running directly on Linux?
I strongly suspect that any recent emacs will have M-x insert-char (earlier it
was called ucs-insert) default bound C-x 8 RET (yeah thats clunky) which will
accept at the minibuffer input
At which point the hex for ÄC which is e9 can be entered â ö yeah its
unreasonable to expect to remember that! Its more reasonable to remember that
that is an e acute; And e itself is a latin lower case letter All of which
becomes entering (in the minibuffer) LATIN SMALL LETTER E ACUTE
- upper case not required; emacs will upcase it for you
- And will also provide some tab/star expansion help
ie *letter e acuteTAB
expands to
LATIN *L LETTER E ACUTE
Further TAB-prodding will give you these choices LATIN CAPITAL LETTER E ACUTE
(Äë) LATIN CAPITAL LETTER E WITH ACUTE (Äë)
LATIN CAPITAL LETTER E WITH CIRCUMFLEX AND ACUTE (áº1)
LATIN CAPITAL LETTER E WITH MACRON AND ACUTE (á,û)
LATIN SMALL LETTER E ACUTE (ÄC) LATIN SMALL LETTER E WITH ACUTE (ÄC)
LATIN SMALL LETTER E WITH CIRCUMFLEX AND ACUTE (ế)
LATIN SMALL LETTER E WITH MACRON AND ACUTE (á,ù)
You could go one step more sophisticated and use TeX-input method (C-x RET C-\)
After which \'e will collapse as ÄC
â £Yeah ok but how the ^)*^$# am I to remember the mantra \'e?!â Ø you may ask
Trueâ | So as you rightly do,
- pick it up from google
- put emacs into tex input mode
- paste from google into emacs
- place point on the new char and type C-u C-x =
Among other things emacs will helpfully inform you (among other things)
to input: type "\'{e}" or "\'e" with TeX input method
--
https://mail.python.org/mailman/listinfo/python-list
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 27/11/2017 17:41, Chris Angelico wrote: > On Tue, Nov 28, 2017 at 2:14 AM, bartc wrote: >> JPEG uses lossy compression. The resulting recovered data is an >> approximation of the original. > > Ah but it is a perfect representation of the JPEG stream. Any given > compressed stream must always decode to the same output. The lossiness > is on the ENcoding, not the DEcoding. You make it sound as bad as currency calculations where different software must produce results that always match to the nearest cent. We're talking about perhaps +1 or -1 difference in the least significant bit of one channel of one pixels. If the calculation is consistent, then you will not know anything is amiss. By +1 or -1, I mean compared with the same jpeg converted by independent means. I also passed the same jpeg through another C program (not mine) using its own algorithms. There some pixels varied by up to +/- 9 from the others (looking at the first 512 bytes of the conversion to ppm). Here's my test image: https://github.com/bartg/langs/blob/master/card2.jpg (nothing naughty). Tell me what the definitive values of the pixels in this part of the image should be (I believe this corresponds to roughly the leftmost 180 pixels of the top line; there are two million pixels in all). And tell me WHY you think those are the definitive ones. Bear in mind also that this is not intended to be the world's most perfect software. But it does do a good enough job. And the other two Python versions I have, at the minute don't work at all. -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: Benefits of unicode identifiers (was: Allow additional separator
On Monday, November 27, 2017 at 6:48:56 PM UTC+5:30, Rustom Mody wrote: > Having said that I should be honest to mention that I saw your post first on > my phone where the î, showed but the gØÜ« showed as a rectangle something like âî$ > > I suspect that îö OTOH would have workedâ | dunno Yeah îö shows whereas gØÜ« doesn't (on my phone) And âî$ does show but much squatter than the replacement char the phone shows when it cant display a char -- https://mail.python.org/mailman/listinfo/python-list
Re: connect four (game)
On 11/27/17 1:57 PM, bartc wrote: > On 27/11/2017 17:41, Chris Angelico wrote: >> On Tue, Nov 28, 2017 at 2:14 AM, bartc wrote: >>> JPEG uses lossy compression. The resulting recovered data is an >>> approximation of the original. >> >> Ah but it is a perfect representation of the JPEG stream. Any given >> compressed stream must always decode to the same output. The lossiness >> is on the ENcoding, not the DEcoding. > > You make it sound as bad as currency calculations where different > software must produce results that always match to the nearest cent. > > We're talking about perhaps +1 or -1 difference in the least > significant bit of one channel of one pixels. If the calculation is > consistent, then you will not know anything is amiss. > > By +1 or -1, I mean compared with the same jpeg converted by > independent means. > > I also passed the same jpeg through another C program (not mine) using > its own algorithms. There some pixels varied by up to +/- 9 from the > others (looking at the first 512 bytes of the conversion to ppm). > > Here's my test image: > https://github.com/bartg/langs/blob/master/card2.jpg (nothing naughty). > > Tell me what the definitive values of the pixels in this part of the > image should be (I believe this corresponds to roughly the leftmost > 180 pixels of the top line; there are two million pixels in all). And > tell me WHY you think those are the definitive ones. > > Bear in mind also that this is not intended to be the world's most > perfect software. But it does do a good enough job. And the other two > Python versions I have, at the minute don't work at all. > > Surely the details of JPEG decompression, and the possible presence of flaws in certain decoders, is beyond the scope of this thread? --Ned. -- 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: Increasing the diversity of people who write Python (was:
On 27 November 2017 at 18:13, Skip Montanaro wrote: >> If you have a Windows key, you can assign it to be >> the Compose key. > > Would this be true on a machine running Windows? My work environment > has me developing on Linux, with a Windows desktop. It's not clear to > me that any sort of xmodmap shennanigans would work. Won't Windows > itself always gobble up that key? Programs can access the Windows key. IIRC, there is a utility that provides compose-key functionality on Windows. I can't recall the name right now and it's on my other PC, not this one, but I'll try to remember to post the name tomorrow... Paul -- https://mail.python.org/mailman/listinfo/python-list
Re: I have framework on python with pyunit, facing below issue while
On 11/27/17 8:13 AM, jaya.bir...@gmail.com wrote: > Please let me know anyone aware about the issue > > > Traceback (most recent call last): > File "testrunner.py", line 447, in > testrunner_obj.main() > File "testrunner.py", line 433, in main > self.result() > File "testrunner.py", line 310, in result > result = runner.run(self.suite) > File "/auto/PyUnit/PyUnit-0.3/utils/framework/HTMLTestRunner.py", line 720, in run > test(result) > File "/usr/lib/python2.7/unittest/suite.py", line 70, in __call__ > return self.run(*args, **kwds) > File "/usr/lib/python2.7/unittest/suite.py", line 108, in run > test(result) > File "/usr/lib/python2.7/unittest/suite.py", line 70, in __call__ > return self.run(*args, **kwds) > File "/usr/lib/python2.7/unittest/suite.py", line 108, in run > test(result) > File "/usr/lib/python2.7/unittest/suite.py", line 70, in __call__ > return self.run(*args, **kwds) > File "/usr/lib/python2.7/unittest/suite.py", line 100, in run > self._handleClassSetUp(test, result) > File "/usr/lib/python2.7/unittest/suite.py", line 153, in _handleClassSetUp > self._addClassOrModuleLevelException(result, e, errorName) > File "/usr/lib/python2.7/unittest/suite.py", line 198, in _addClassOrModuleLevelException > result.addError(error, sys.exc_info()) > File â £/auto/PyUnit/PyUnit-0.3/utils/framework/HTMLTestRunner.py", line 633, in addError > output = self.complete_output() > File â £/autoPyUnit/PyUnit-0.3/utils/framework/HTMLTestRunner.py", line 591, in complete_output > return self.outputBuffer.getvalue() > AttributeError: '_TestResult' object has no attribute 'outputBuffer' It's hard to say without seeing all your code, but I notice PyUnit 0.3 in your traceback.â If that's the PyUnit I think it is, PyUnit 1.4.1 was released 16(!) years ago, and has been in the standard library as unittest since version 2.1.â Are you running ancient versions of your test infrastructure? --Ned. -- https://mail.python.org/mailman/listinfo/python-list
Re: Increasing the diversity of people who write Python (was:
On Tue, Nov 28, 2017 at 5:13 AM, Skip Montanaro wrote: >> If you have a Windows key, you can assign it to be >> the Compose key. > > Would this be true on a machine running Windows? My work environment > has me developing on Linux, with a Windows desktop. It's not clear to > me that any sort of xmodmap shennanigans would work. Won't Windows > itself always gobble up that key? Now that, I can't tell you about. As mentioned, the specific system I was using was provided by X11, so it wouldn't work on anything else. (Don't know about Wayland; I think it might have an equivalent.) For other window managers, you'd have to find some alternative. ChrisA -- 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
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
Re: Increasing the diversity of people who write Python (was:
> I strongly suspect that any recent emacs will have M-x insert-char > (earlier it was called ucs-insert) default bound C-x 8 RET (yeah thats clunky) > which will accept at the minibuffer input I tried C-x 8 e acute TAB and was prompted with "E-acute". I don't know why it would have capitalized the "e". Still, I plowed ahead and hit RET which yielded an "Invalid character" message in the minibuffer. Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: Increasing the diversity of people who write Python (was:
On Tue, Nov 28, 2017 at 1:55 AM, Rustom Mody wrote:
> On Monday, November 27, 2017 at 8:07:47 PM UTC+5:30, Chris Angelico wrote:
>> On Tue, Nov 28, 2017 at 1:25 AM, Rustom Mody wrote:
>> > You could go one step more sophisticated and use TeX-input method
>> > (C-x RET C-\)
>> > After which \'e will collapse as ÄC
>> > â £Yeah ok but how the ^)*^$# am I to remember the mantra \'e?!â Ø you may
ask
>> > Trueâ | So as you rightly do,
>> > - pick it up from google
>> > - put emacs into tex input mode
>> > - paste from google into emacs
>> > - place point on the new char and type C-u C-x =
>> > Among other things emacs will helpfully inform you (among other things)
>> > to input: type "\'{e}" or "\'e" with TeX input method
>>
>> Which is closely related to the Compose key input method that I use.
>> First, you assign a key on your keyboard to be Compose (at least on
>> all my systems, there isn't one by default); I use the key between
>> left Ctrl and left Alt.
>
> Ha Ha So you wont speak the unspeakable?â¿!â¡
Heh, you mean the term "Windows key"? It's not appropriate on keyboards that
don't have an actual Windows logo on it. There are other names for it, but I
figured the easiest way was to describe its location :D
But yes, that key. If you have a Windows key, you can assign it to be the
Compose key. Or, of course, you could redefine left control, so that Ctrl-X is
with the right key and Compose-X is with the left one. Or any other key you
like.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Increasing the diversity of people who write Python (was:
> If you have a Windows key, you can assign it to be > the Compose key. Would this be true on a machine running Windows? My work environment has me developing on Linux, with a Windows desktop. It's not clear to me that any sort of xmodmap shennanigans would work. Won't Windows itself always gobble up that key? Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: connect four (game)
On Nov 27, 2017 7:08 AM, "Chris Angelico" wrote: In every compiler, interpreter, and CPU that I've ever used, the remainder has been well-defined. In what situation was it ill-defined, such that different compilers could do different things? In C89 the result of integer division and modulo with negative operands were implementation-defined -- the result of division could be either floored or truncated, and the modulo result also varied to match. This was fixed in C99, with division results always being truncated (whereas Python uses the floor). -- https://mail.python.org/mailman/listinfo/python-list
Re: connect four (game)
On Tue, Nov 28, 2017 at 2:14 AM, bartc wrote: > JPEG uses lossy compression. The resulting recovered data is an > approximation of the original. Ah but it is a perfect representation of the JPEG stream. Any given compressed stream must always decode to the same output. The lossiness is on the ENcoding, not the DEcoding. ChrisA -- 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
Re: Benefits of unicode identifiers (was: Allow additional separator
On Monday, November 27, 2017 at 3:43:20 PM UTC+5:30, Antoon Pardon wrote: > Op 23-11-17 om 19:42 schreef Mikhail V: > > Chris A wrote: > > > >>> On Fri, Nov 24, 2017 at 1:10 AM, Mikhail V wrote: > >>> > Chris A wrote: > > Fortunately for the world, you're not the one who decided which > characters were permitted in Python identifiers. The ability to use > non-English words for function/variable names is of huge value; the > ability to use a hyphen is of some value, but not nearly as much. > >>> Fortunately for the world we have Chris A. Who knows what is > >>> fortunate and of huge values. > >>> So is there any real world projects example of usage of non-latin scripts > >>> in identifiers? Or is it still only a plan for the new world? > > > >> Yes, I've used them personally. And I know other people who have. > > > > Oh, I though it would be more impressive showcase for 'huge value'. > > If we drop the benefit of the bare fact that you can do it, or you just > > don't know English, how would describe the practical benefit? > > If you don't know english, then programming at all will be just too hard. > > (or one must define a new whole language specially for some local script) > > Well maybe the value is not huge, but I really appreciate the possibility. > Being able to write something like below, makes things a lot more clear > for me. > > Po = Pc + R * Vec(cos(î,o), sin(î,o)) > Pe = Pc + R * Vec(cos(î,e), sin(î,e)) > gØÜ«î, = î,e - î,o > gØÜ«P = Pe - Po Yeahâ | This is important And Ive tried to elaborate such suggestions here http://blog.languager.org/2014/04/unicoded-python.html [includes some of your suggestions!] I should emphasize that the details there range between straightforward and facetious. The general sense of going beyond ASCII is not facetious at all In fact its ridiculous in the reverse direction: just as FORTRAN and COBOL believed that programming IN ALL UPPERCASE was somehow kosher, likewise a 2017 language believing that sticking to ASCII is sound is faintly ridiculous. But that brings me to the opposite point: I feel its important to distinguish â ÿparochial/sectarian unicodeâ Ö from â ÿuniversal unicodeâ Ö. More on the distinction http://blog.languager.org/2015/03/whimsical-unicode.htm l More on the universal aspect: http://blog.languager.org/2015/02/universal-unico de.html Having said that I should be honest to mention that I saw your post first on my phone where the î, showed but the gØÜ« showed as a rectangle something like âî$ I suspect that îö OTOH would have workedâ | dunno So yes, there can be non-trivial logistic problems going beyond ASCII As there are problems with errant mail-clients transmitting indentation-sensitive languages and so on! -- https://mail.python.org/mailman/listinfo/python-list
Re: connect four (game)
On Mon, Nov 27, 2017 at 10:38 PM, bartc wrote: > On 27/11/2017 03:04, Michael Torrie wrote: >> >> On 11/26/2017 08:39 AM, bartc wrote: >>> >>> The problem was traced to two lines that were in the wrong order (in the >>> original program). I can't see how unit tests can have helped in any way >>> at all, and it would probably have taken much longer. >> >> >> What makes you think that? Surely other decoders were doing the right >> thing and you could compare your output against theirs? JPEGs may be >> lossy but the path through the decoder should be deterministic. >> >> Or even if every decoder is slightly unique, at least yours should >> output self-consistent data. > > > The original used some floating point code, I changed that to use integer > code (eg a combination of multiplying and shifting; it make a difference on > compiled version, perhaps not so much in .py). The JPEG spec says what a given file should decode to. So you can use a reference implementation to confirm that your code is correctly decoding. Even if you might legitimately encode the same image in different ways, each of those encoded files should decode to one exact image, regardless of which decoder is used. Your decoder was straight-up buggy, and tests would have proven this. > But also (IIRC) there was a difference in taking the remainder of negative > integer division, where different compilers may round up or down. In every compiler, interpreter, and CPU that I've ever used, the remainder has been well-defined. In what situation was it ill-defined, such that different compilers could do different things? > Some people are obsessed with having unit tests. Others are the same about > using debuggers, especially in compiled code. > > I've never used either, but I do alright. Some of the stuff I do is > unsuitable for those for technical reasons, but also some of the problems > I've come across just don't fit into such patterns. > > People should use what works best for them, unless they're in a team where > the have to use certain tools and working methods. Yep, and if "producing buggy code that fails to comply with the spec" is what works best for you, then please don't tell us that we're advocating the wrong thing. Testing might not fix everything, but it does help, especially in those easy cases where you're working with a pure function that has a single correct output for a given input. Which, if I'm not misunderstanding the specs, is the case for pretty much every compression scheme in current use - including JPEG. For myself, I don't write as many tests as I should. But I'm not going to go around telling people that tests are a waste of time. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Increasing the diversity of people who write Python (was:
On Tue, Nov 28, 2017 at 1:25 AM, Rustom Mody wrote:
> You could go one step more sophisticated and use TeX-input method
> (C-x RET C-\)
> After which \'e will collapse as ÄC
> â £Yeah ok but how the ^)*^$# am I to remember the mantra \'e?!â Ø you may
ask
> Trueâ | So as you rightly do,
> - pick it up from google
> - put emacs into tex input mode
> - paste from google into emacs
> - place point on the new char and type C-u C-x =
> Among other things emacs will helpfully inform you (among other things)
> to input: type "\'{e}" or "\'e" with TeX input method
Which is closely related to the Compose key input method that I use. First, you
assign a key on your keyboard to be Compose (at least on all my systems, there
isn't one by default); I use the key between left Ctrl and left Alt. Then you
have certain key sequences available that involve holding Compose and pressing
something, and then pressing something else. In the same way that you might
press Ctrl-X, Q to do something, you could press Compose-T, M to produce âäø.
Sounds complicated, but it's not. It's right enough. All your accented letters
can be created with Compose-accent, letter - eg Compose-apostrophe, e => ÄC, or
Compose-backtick, a => Ä .
Not sure what systems that's supported on. I use Debian GNU/Linux with Xfce; I
believe the Compose key handling is all done by X11, so it should be fairly
widely available at least on Linux-derived systems.
ChrisA
--
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: connect four (game)
On 27/11/2017 13:57, Chris Angelico wrote: > On Mon, Nov 27, 2017 at 10:38 PM, bartc wrote: > Your decoder was straight-up buggy, and tests would have proven this. I created my Python version after the abysmal results from other Python decoders I tried which didn't work at all, gave the wrong results, didn't support other subsampling ratios, or hung. Or if they did work, they took forever. I suggest you compare my version with some of those. The first time I looked at a jpeg decoder, it was a massive C library of about 30 different source files. Sometimes you need to take short-cuts. My version generates images which are indistinguishable from those derived via other decoders. >> But also (IIRC) there was a difference in taking the remainder of negative >> integer division, where different compilers may round up or down. > > In every compiler, interpreter, and CPU that I've ever used, the > remainder has been well-defined. In what situation was it ill-defined, > such that different compilers could do different things? In certain C implementations, rounding the results of integer division could go up or down. This is a post from comp.lang.c from 2008: "Nate Eldredge" wrote in message news:8663mf144q@vulcan.lan... > Mr. Burns writes: > >> Hi group, >> >> suppose I have a grid of cells of size (R,C) and coordinates >> (0..R-1,0..C-1) and >> I'm translating pixel coordinates to grid coordinates by dividing by cell >> size. >> >> Now, all works well for values >= 0, but for values < 0 I'm getting >> inconsistent results. >> >> On one platform, division of negative numbers rounds towards negative >> infinity, i.e., (-1 / 10) gives -1. (this is what I want) >> >> On another platform (solaris), rounding is towards zero, and (-1 / 10) is >> 0! >> >> All numbers are plain ints. > > The C99 standard specifies truncation towards zero (like your Solaris > compiler). However, the previous C90 standard left it up to the > implementation to decide which way to round when one of the operands is > negative, as long as it is consistent with the % operator. Exactly what the problem was with my jpeg program where a number from my language and compiler ended up as 187, but on C compiled with gcc as 186, I can't remember. I /think/ it was to do with such rounding. This is not a big deal: one program ends up with a pixel value of 186 (in a range of 0 to 255), and another with 187. The true value in the original photo may have required a value somewhere between 186 and 187, so both values could be considered wrong! > Which, if I'm not misunderstanding the specs, is the case for pretty > much every compression scheme in current use - including JPEG. JPEG uses lossy compression. The resulting recovered data is an approximation of the original. > For myself, I don't write as many tests as I should. But I'm not going > to go around telling people that tests are a waste of time. I'm fairly certain the OP's program didn't work perfectly first time. So some procedure had to be followed to try it and decide if it behaved according to the specification they had in mind. I believe that process can also be called 'testing'. And in this case, involving a visual GUI, it really demands tests verified by a human rather than spending the next six months writing automatic test procedures that simulate mouse input and examine the pixels on the screen to see if they correspond to what should happen. > Your decoder was straight-up buggy, and tests would have proven this. How did YOU determine it was buggy; unit-tests? And did you just do what everyone else does? -- Bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: Benefits of unicode identifiers (was: Allow additional separator
Op 23-11-17 om 19:42 schreef Mikhail V: > Chris A wrote: > >>> On Fri, Nov 24, 2017 at 1:10 AM, Mikhail V wrote: >>> Chris A wrote: Fortunately for the world, you're not the one who decided which characters were permitted in Python identifiers. The ability to use non-English words for function/variable names is of huge value; the ability to use a hyphen is of some value, but not nearly as much. >>> Fortunately for the world we have Chris A. Who knows what is >>> fortunate and of huge values. >>> So is there any real world projects example of usage of non-latin scripts >>> in identifiers? Or is it still only a plan for the new world? > >> Yes, I've used them personally. And I know other people who have. > > Oh, I though it would be more impressive showcase for 'huge value'. > If we drop the benefit of the bare fact that you can do it, or you just > don't know English, how would describe the practical benefit? > If you don't know english, then programming at all will be just too hard. > (or one must define a new whole language specially for some local script) Well maybe the value is not huge, but I really appreciate the possibility. Being able to write something like below, makes things a lot more clear for me. Po = Pc + R * Vec(cos(î,o), sin(î,o)) Pe = Pc + R * Vec(cos(î,e), sin(î,e)) gØÜ«î, = î,e - î,o gØÜ«P = Pe - Po -- Antoon Pardon. -- https://mail.python.org/mailman/listinfo/python-list
Re: connect four (game)
On Monday, November 27, 2017 at 12:12:24 PM UTC+5:30, Chris Angelico wrote: > 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â1 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? I know how to drive a carâ | and various two-wheelers. I not so sure of a bus/truckâ | I suppose I could get one from here to there at a pinchâ | without killing someoneâ | though not quite sure of that! Doesn't translate into knowing how to 'drive' planes or bullock-carts gcc is tested with dejagnu. Do you imagine that knowing python's unittest or nose directly translates into dejagnu expertise? And even if we stay with industry-strength programs â ö gcc, linux-kernel, CPython, KDE â ö do you imagine that testing one helps in testing the other? I doubt it (though I am hardly an expert with testing frameworks) Once again let me end by saying that testing and TDD are good ideas And it would be nice if there was more of it in/for python [See http://osherove.com/tdd-kata-1/ one of the first hits that google gives (me) for TDD python, and you find the python example actually shows Ruby!] -- https://mail.python.org/mailman/listinfo/python-list
Re: While, If, Count Statements
On 11/27/17 7:54 AM, Cai Gengyang wrote: > Input : > > count = 0 > > if count < 5: >print "Hello, I am an if statement and count is", count > > while count < 10: >print "Hello, I am a while and count is", count >count += 1 > > Output : > > Hello, I am an if statement and count is 0 > Hello, I am a while and count is 0 > Hello, I am a while and count is 1 > Hello, I am a while and count is 2 > Hello, I am a while and count is 3 > Hello, I am a while and count is 4 > Hello, I am a while and count is 5 > Hello, I am a while and count is 6 > Hello, I am a while and count is 7 > Hello, I am a while and count is 8 > Hello, I am a while and count is 9 > > The above input gives the output below. Why isn't the output instead : > > Hello, I am an if statement and count is 0 > Hello, I am a while and count is 0 > Hello, I am an if statement and count is 1 > Hello, I am a while and count is 1 > Hello, I am an if statement and count is 2 > Hello, I am a while and count is 2 > Hello, I am an if statement and count is 3 > Hello, I am a while and count is 3 > Hello, I am an if statement and count is 4 > Hello, I am a while and count is 4 > Hello, I am a while and count is 5 > Hello, I am a while and count is 6 > Hello, I am a while and count is 7 > Hello, I am a while and count is 8 > Hello, I am a while and count is 9 It's easy to imagine that this sets up a rule that remains in effect for the rest of the program: â â â if count < 5: â â â â â â â print "Hello, I am an if statement and count is", count But that's not how Python (and most other programming languages) works.â Python reads statements one after another, and executes them as it encounters them.â When it finds the if-statement, it evaluates the condition, and if it is true *at that moment*, it executes the contained statements.â Then it forgets all about that if-statement, and moves on to the next statement. --Ned. -- https://mail.python.org/mailman/listinfo/python-list
Re: While, If, Count Statements
On 27/11/2017 12:54, Cai Gengyang wrote: > > Input : > > count = 0 > > if count < 5: >print "Hello, I am an if statement and count is", count > > while count < 10: >print "Hello, I am a while and count is", count >count += 1 > > Output : > > Hello, I am an if statement and count is 0 > Hello, I am a while and count is 0 > Hello, I am a while and count is 1 > Hello, I am a while and count is 2 > Hello, I am a while and count is 3 > Hello, I am a while and count is 4 > Hello, I am a while and count is 5 > Hello, I am a while and count is 6 > Hello, I am a while and count is 7 > Hello, I am a while and count is 8 > Hello, I am a while and count is 9 > > The above input gives the output below. Why isn't the output instead : > > Hello, I am an if statement and count is 0 > Hello, I am a while and count is 0 > Hello, I am an if statement and count is 1 > Hello, I am a while and count is 1 > Hello, I am an if statement and count is 2 > Hello, I am a while and count is 2 > Hello, I am an if statement and count is 3 > Hello, I am a while and count is 3 > Hello, I am an if statement and count is 4 > Hello, I am a while and count is 4 > Hello, I am a while and count is 5 > Hello, I am a while and count is 6 > Hello, I am a while and count is 7 > Hello, I am a while and count is 8 > Hello, I am a while and count is 9 Because the if-statement is only executed once, then it does the loop. Try: count = 0 while count < 10: if count < 5: print "Hello, I am an if statement and count is", count print "Hello, I am a while and count is", count count += 1 -- https://mail.python.org/mailman/listinfo/python-list
Re: connect four (game)
On 27/11/2017 03:04, Michael Torrie wrote: > On 11/26/2017 08:39 AM, bartc wrote: >> The problem was traced to two lines that were in the wrong order (in the >> original program). I can't see how unit tests can have helped in any way >> at all, and it would probably have taken much longer. > > What makes you think that? Surely other decoders were doing the right > thing and you could compare your output against theirs? JPEGs may be > lossy but the path through the decoder should be deterministic. > > Or even if every decoder is slightly unique, at least yours should > output self-consistent data. The original used some floating point code, I changed that to use integer code (eg a combination of multiplying and shifting; it make a difference on compiled version, perhaps not so much in .py). But also (IIRC) there was a difference in taking the remainder of negative integer division, where different compilers may round up or down. So there can easily be differences when compared at the binary level, but which shouldn't be noticeable with the human eye. (https://pastebin.com/P7V1Bvkk https://pastebin.com/raw/P7V1Bvkk raw version with no ads, or colour) In other words, once you know you fixed > the chroma problem, you can use that jpeg as a unit test to make sure > future big fixes and enhancements don't break something else. > Regression testing is very important. Many times I've fixed a bug, only > to introduce new ones that broke formerly correct behavior. > > Anyway, unit testing is certainly a challenging concept, and I'm no more > good at it than you are. Some people are obsessed with having unit tests. Others are the same about using debuggers, especially in compiled code. I've never used either, but I do alright. Some of the stuff I do is unsuitable for those for technical reasons, but also some of the problems I've come across just don't fit into such patterns. People should use what works best for them, unless they're in a team where the have to use certain tools and working methods. -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: connect four (game)
On Mon, Nov 27, 2017 at 9:01 PM, wrote: > On Sunday, November 26, 2017 at 7:09:25 PM UTC-8, Michael Torrie wrote: > >> 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. > > they're not sentinels; they're the maximum and minimum of the extended real numbers; the point is that, no matter how boards are evaluated (which is, of course, subject to change), a won game is always the most valuable and a lost game is always the least valuable; ordinary real numbers could be used for the purpose, but in that case i would have to figure out the maximum and minimum of the heuristic values the script assigns and then add/subtract one (for example) to get the value of a won/lost game > Or you could use the floating-point values for positive and negative infinity, which already compare as you need with all integers and floats. But that's up to you. 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)
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â1 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 â1 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)
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: [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: 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
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
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
[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: 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 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: 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 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 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: 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: Compile Python 3 interpreter to force 2-byte unicode
Mody) 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: [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: connect four (game)
On 25/11/2017 16:07, Michael Torrie wrote: > On 11/25/2017 06:00 AM, bartc wrote: >> And there's a quite lot left of the rest of the program to worry about too! >> >> If you add 'window()' at the end of the program, then it seems to run on >> Python 3. I'd play around with it first before thinking up strategies >> for testing it. > > Actually, no. Unit testing ideally should be done for each and every > class as they are being written (before they are written in fact), no > matter how small and trivial the class. That way as you compose larger > and larger units of code, the chances of things being right is greater > compared to doing it the other way around. The way I write code isn't incrementally top down or bottom up. It's backwards and forwards. Feedback from different parts means the thing develops as a whole. Sometimes parts are split into distinct sections, sometimes different parts are merged. Sometimes you realise you're on the wrong track, and sections have to be redone or a different approach used, which can be done in the earlier stages. If I had to bother with such systematic tests as you suggest, and finish and sign off everything before proceeding further, then nothing would ever get done. (Maybe it's viable if working from an exacting specification that someone else has already worked out.) I've also found that many of the bugs that do appear, also do so in ways you never anticipated. Or in circumstances you would never have thought of. (I've always thought that programming is a bit like creating new laws. The same laws need to work for everyone and in any circumstances, but no one can foresee everything, and laws need to be tweaked and added to. Perhaps unit tests can apply there too...) > You may argue that testing doesn't matter for his small game, written > for his own education and amusement. The fact is that software in > general is of abysmal quality across the boards, and promoting a habit > of unit testing is good, even for trivial, home-grown stuff. I thought people were being hard on the OP. As for testing, I remember in a company I worked in, a complicated circuit was submitted to a company that would put it into a mass-produced chip. This company did massive numbers of emulated tests shown on a huge printout that showed that all combinations of inputs and outputs worked exactly as intended. Except the actual chip didn't work. As for the printout, the designer took it home and used it as an underlay for a new carpet. A rather expensive underlay. -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: connect four (game)
On 26/11/2017 14:23, Chris Angelico wrote: > On Mon, Nov 27, 2017 at 1:11 AM, bartc wrote: >> The way I write code isn't incrementally top down or bottom up. It's >> backwards and forwards. Feedback from different parts means the thing >> develops as a whole. Sometimes parts are split into distinct sections, >> sometimes different parts are merged. >> >> Sometimes you realise you're on the wrong track, and sections have to be >> redone or a different approach used, which can be done in the earlier >> stages. >> >> If I had to bother with such systematic tests as you suggest, and finish and >> sign off everything before proceeding further, then nothing would ever get >> done. (Maybe it's viable if working from an exacting specification that >> someone else has already worked out.) > > Everyone in the world has the same problem, yet many of us manage to > write useful tests. I wonder whether you're somehow special in that > testing fundamentally doesn't work for you, or that you actually don't > need to write tests. Or maybe tests would still be useful for you too. > Could go either way. Testing everything comprehensively just wouldn't be useful for me who works on whole applications, whole concepts, not just a handful of functions with well-defined inputs and outputs. And even then, it might work perfectly, but be too slow, or they take up too much space. Take one example of a small program I've mentioned in the past, a jpeg decoder. I had to port this into several languages (one of which was Python actually). It was hard because I didn't know how it was meant to work. Only as a whole when the input is a .jpeg file, and the output might be a .ppm file that ought to look like the one produced by a working program, or the original jpeg displayed by a working viewer. (Which is not possible in all applications.) How to do an automatic test? Directly doing a binary compare on the output doesn't work because in jpeg, there can be differences of +/- 1 bit in the results. And even if the test detected a mismatch, then what? I now know there is a problem, but I could figure that out by looking at the output! And actually, after it ostensibly worked, there WAS a minor problem: some types of images exhibited excessive chroma noise around sharp transitions. The problem was traced to two lines that were in the wrong order (in the original program). I can't see how unit tests can have helped in any way at all, and it would probably have taken much longer. And THIS was a small, well-defined task which had already been written. >> Except the actual chip didn't work. As for the printout, the designer took >> it home and used it as an underlay for a new carpet. A rather expensive >> underlay. > > So there was something else wrong with the chip. I'm not sure what > your point is. The extensive testing was like unit testing, but needed to be even more thorough because of the commitment involved. It failed to spot a problem. And actually I had a similar problem with a new car. I took it back to the dealer, and they said they plugged the on-board computer into their analyser, which did all sorts of tests and said there was nothing wrong with it. But there was, and the problem has persisted for a decade [to do with the central locking]. I'm saying you can rely too much on these tests, and waste too much time on them. Perhaps that is a necessity in a large organisation or in a large team, where there is a leader to look at the big picture. It doesn't work for individuals working on one project. -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: 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: 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: 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
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: 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: 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!
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: 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: 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: 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: 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 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
Multiprocessing interactive processes with connections
I want to process a bunch of processes that all talk to each other. I've
figured out how to do this using queues with the main process as the mail
handler, but I'd rather have them talk directly. If I use connections, then I
can pass the pipes to the processes, but there doesn't seem to be anything
analogous to queue, so it looks like I need to divide each process into two
threads, one of which does nothing but mail handling.
Is this correct?
FWIW, a small, unoptimized, test of the working "mailhandler" approach is:
## Multiprocessing: main thread as post office.
# This is a bit clumsy, but it works.
from multiprocessing import Process, Queue from queue import Empty
def f(i, lim, q_rcv, q_snd):
for j in range(lim):
if i != j:
q_snd.put([i, "message from process {0} to proess
{1}".format(i, j), j])
if not q_rcv.empty():
val = q_rcv.get()
print (val)
q_snd.put([i, "done"])
while (not q_recv.empty()):
val = q_rcv.get()
print (val, " :: ", i)
if val == "done": return
if __name__ == '__main__':
ps = []
qs = []
q_recv = Queue()
for i in range(3):
q = Queue()
qs.append (q)
ps.append (Process(target=f, args=(i, 3, q, q_recv)) )
for p in ps:
p.start()
dones = 0
try:
v = q_recv.get(True, 1)
while (v):
print ("v = ", v)
if v[1] == "done":
dones = dones + 1
else:
if len(v) == 3:
assert v[2] < len(qs), "unexpected value"
qs[v[2]].put(v[1])
else:
print ("error: ", v, " was an unexpected value.")
v = q_recv.get(True, 1)
except Empty:
print ("1: Timeout of maine receive queue")
for q in qs:
q.put("done")
try:
v = q_recv.get(True, 1)
while (v):
print ("2: v = ", v)
if v[1] == "done":
dones = dones + 1
else:
if len(v) == 3:
assert v[3] < len(qs), "2: unexpected value"
qs[v[3]].put(v[2])
else:
print ("2: error: ", v, " was an unexpected value.")
v = q_recv.get(True, 1)
except Empty:
print ("2: Timeout of maine receive queue")
for i in range(len(qs)):
qs[i].close();
qs[i] = None
--
https://mail.python.org/mailman/listinfo/python-list
Re: Class - error return
On 06/09/2016 11:23, Peter Otten wrote: > If so look at > >> > ...: def __str__(self): >> > ...: return "Visitor: %i, Contacts: %i % >> > (self.visits,self.contacts)" > once more. Where are the quotes? Where should the be? > > > I solved the problem. thank you Peter -- https://mail.python.org/mailman/listinfo/python-list
Re: Python on a MacBook Pro (not my machine)
"nf7" writes: > MacVim is the best text editor... fighting talk! :) -- https://mail.python.org/mailman/listinfo/python-list
Re: personal library
patrick vrijlandt writes: > Thanks. Do you all agree that Mercurial is the way to go, or is there > another "distributed version control system" that I should shortlist? git is popular too. In the long run it's probably worth getting experience with both. -- https://mail.python.org/mailman/listinfo/python-list
extending dictonary
Is there any way to extend the dictonary in such manner that I can insert muliplay value to each keys and return one of the value as the default value. I would like to have similar syste that I drawed out below. tree[nucelotide_postionc][nucleotide]=default(value subtree) This should be returned when doing lookup without any tree[nucelotide_postionc][nucleotide]=Postive value tree[nucelotide_postionc][nucleotide]=Negative value -- http://mail.python.org/mailman/listinfo/python-list
question about tree in python
How should I write a tree using diconary. I have used a dictonary to
make a tree.
tree={best:collections.defaultdict(lambda:default)} in a id3 tree.
Is there a way to multple values and when then only return on type of
values.
I tried this apporach but it did not work.
class Tree:
def __init__(self):
pass
def ini(self,default_tree,d_attr):
self.tree={d_attr:collections.defaultdict(lambda:default_tree)}
self.tree_A={d_attr:collections.defaultdict(lambda:default_tree)}
self.tree_I={d_attr:collections.defaultdict(lambda:default_tree)}
self.tree_p={d_attr:collections.defaultdict(lambda:default_tree)}
self.tree_n={d_attr:collections.defaultdict(lambda:default_tree)}
return self.tree
def __call__(self,best,val,subtree):
self.tree[best][val]=subtree
def
input_tree(self,best,val,subtree,postive,negative,attribute_value,info_gain):
tree=self.tree
print best
print val
tree[best][val]=subtree
print self.tree
self.tree_A[best][val]= attribute_value
self.tree_I[best][val]= info_gain
self.tree_p[best][val]= postive
self.tree_n=negative
tree=self.tree
return tree
--
http://mail.python.org/mailman/listinfo/python-list
Re: Problem Python 2.6.1 vs 2.6 & pyWin32
Hi! I noted, also, than, in some cases, Python26.dll is not copied in %WINDIR%\system32 After that, external softs don't find the DLL. But it's a detail, because it's easy to copy the DLL with install scripts. @-salutations -- Michel Claveau -- http://mail.python.org/mailman/listinfo/python-list
Re: Problem Python 2.6.1 vs 2.6 & pyWin32
Hi! Thank you very much for your answer. I appreciate many to receive an answer of somebody as you. But I, always, install Python 2.6.1 "for all users" (and, on Vista, UAC is always deactivated). After some tests, the problem seems a bit more complex: call the Python-COM-servers run OK, from Python-Scripts. But it is not possible from others languages (but, I only try JScript, VBScript, JS.Net, ObjectPAL, Autoit). For the moment, I back my install procedures to Python 2.6 ; and, I hope a "global" solution for 2.6.1 @-salutations -- Michel Claveau -- http://mail.python.org/mailman/listinfo/python-list
Problem Python 2.6.1 vs 2.6 & pyWin32
Hi, all! I have several softwares using Python+PyWin32, often as COMèserver. Ok with Python 2.5.x. I want migrate to Python 2.6. But when I install python-2.6.1.msi + pywin32-212.win32-py2.6, my softs don't run. Tried on five machines (two XP & three Vista). But... if I install python-2.6.msi , IT'S OK!!! And, if I installl 2.6.1 once again, after 2.6, ... don't run ???!!! ;-((( In reality, soft run, but COM server can not be used. I get these messages : File "C:\Python26\Lib\site-packages\win32com\server\policy.py", line 728, in resolve_func module = _import_module(mname) File "C:\Python26\Lib\site-packages\win32com\server\policy.py", line 747, in _import_module __import__(mname) File "C:\Ponx\ponx.py", line 54, in import socket File "C:\Python26\lib\socket.py", line 46, in import _socket : DLL load failed: Le module spécifié est introuvable. "Erreur non spécifiée" (with call from JScript test, or VBScript test). (These tests run OK with 2.6 or 2.5.x) I am very disappointed. Help me, please. Thanks in advance. *** and sorry for my bad english *** @-salutations -- Michel Claveau -- http://mail.python.org/mailman/listinfo/python-list
