Re: Awful code of the week
On Sun, Aug 7, 2016 at 4:54 PM, Steven D'Aprano wrote: > Seen in the office IRC channel: > > > (13:23:07) fred: near_limit = [] > (13:23:07) fred: near_limit.append(1) > (13:23:07) fred: near_limit = len(near_limit) > (13:23:09) fred: WTF > > > > Speaks for itself. The Real WTF is that it needs to have a type declaration. near_limit: Union[int,list] There, fixed. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python slang
Marco Sulla via Python-list: > Well, they are the most used languages. They weren't when Python was created. Python's terms raise/except and self were normal for the time. C++ was the odd one out. throw/catch and this are Stroustrup's inventions, no other language used those terms. It was only later that language designers fell into the notion that it was crucial for a new language's success to look as much like C++ as possible. regards, Anders -- https://mail.python.org/mailman/listinfo/python-list
Re: How do I make a game in Python ?
Games are great. I guess I would like to invent animated games that can teach students how to solve mathematical, physics, engineering , Go and programming puzzles, basic financial literacy and investing techniques through interesting and enriching games and puzzles and university admissions interviews ... Create a piece of software like this, get users to test it ... then when the feedback streams in, iterate the product accordingly based on user feedback ... On Sunday, August 7, 2016 at 12:02:56 PM UTC+8, Chris Angelico wrote: > On Sun, Aug 7, 2016 at 1:14 PM, Michael Torrie wrote: > > On 08/06/2016 03:51 PM, Cai Gengyang wrote: > >> As in, any recommended websites that helps users create complex games in > >> Python ? > > > > I imagine you create a complex game in Python the same way you'd do it > > in just about any other language. Thus any website on game design would > > be broadly applicable. And I'm sure there are a wide variety of topics > > that are relevant. Logic, game play, artificial intelligence, user > > interface, physics engines, and so forth. > > > > What you need to learn depends on what you already know and have > > experience in. The programming language is really only a part of > > developing "complex games." You'd probably want to start with simple, > > even child-like games first. Asking how to program complex games is a > > bit like asking how to build a car. > > Three of my students just recently put together a game (as their > first-ever collaborative project, working on different parts of the > project simultaneously), so I can tell you broadly how you would go > about it: > > 1) SCOPE. This is incredibly important. With the student project, they > had to have something demonstrable by Friday 5PM, so they had just > five days to get something working. But even when you don't have a > hard cut-off like that, you should scope back hard - brutally, even - > so you can get something workable as early as possible. > > 2) Pin down exactly what the *point* of your game is. What is the > fundamental thing you're trying to do? In their case, it was: Click on > the red squares before they turn back to white, then watch for another > square to turn red. As you develop, you'll mess around with everything > else, but don't mess with that. > > 3) Build a very basic project, managed in source control (git/hg/bzr > etc), and get it to the point of being testable. I don't mean unit > tests (although if you're a fan of TDD, you might well go that route), > but be able to fire up your game and actually run it. Commit that. > > 4) Progressively add features, constantly committing to source > control. Whenever your game isn't runnable, STOP and debug it until it > is. It's just way too hard to debug something that you can't even run. > > 5) Eventually, you'll get bored of the project or be forced to move on > to something else. At that point, the game is done. :) > > ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Error running the exe file in Windows "Failed to execute script pyi_rth_pkgres"
Hi,
I have created a simple Python program including the following packages:
import numpy as np
import matplotlib.pyplot as plt
import pandas as pd
if __name__ == '__main__':
print("Hi!")
I have created the installation package using PyInstaller with the
following command line:
pyinstaller --onedir --name=appname --windowed "C:\appname.py"
The required folders (build and dist) and the spec file are created
properly with no errors. When I run the appname.exe file I got the error
"Failed to execute script pyi_rth_pkgres".
I'm using the following now:
- Anaconda3 4.1.1.64-bit
- Python 3.5.2
- PyInstaller 3.2
- Windows 10 64-bit
Any help is very appreciated. Feel free to contact me at any time you need.
Thank you,
Ernest Bonat, Ph.D.
Senior Software Engineer
Senior Data Scientist
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python slang
On 2016-08-06, Chris Angelico wrote: > On Sun, Aug 7, 2016 at 5:37 AM, Bernd Nawothnig > wrote: >>> But SQL's NULL is a cross between C's NULL, IEEE's NaN, Cthulhu, and >>> Emrakul. >> >> SQL NULL has the semantic of "unknown". So if one or both operands of >> a comparison (or any other operation) are unknown the result is >> unknown too. And that means NULL. > > That's not entirely accurate, and it doesn't explain why NULL > sometimes behaves as if it's a genuine value, and sometimes as if it's > completely not there. For instance, taking the average of a column of > values ignores NULLs completely, and COUNT(column) is the same as > COUNT(column) WHERE column IS NOT NULL; but in some situations it > behaves more like NaN: > > rosuav=> select null or true, null or false, null and true, null and false; > ?column? | ?column? | ?column? | ?column? > --+--+--+-- > t| NULL | NULL | f > (1 row) > > Anything "or true" has to be true, so NULL OR TRUE is true. And then > there are the times when NULL acts like a completely special value, > for instance in a foreign key - it means "there isn't anything on the > other end of this relationship", and is perfectly legal. Or in a > SELECT DISTINCT, where NULL behaves just like any other value - if > there are any NULL values in the column, you get back exactly one NULL > in the result. Thanks for that additions and corrections. Bernd -- no time toulouse -- https://mail.python.org/mailman/listinfo/python-list
Re: How do I make a game in Python ?
On 08/07/2016 08:47 AM, Cai Gengyang wrote: > Games are great. I guess I would like to invent animated games that > can teach students how to solve mathematical, physics, engineering , > Go and programming puzzles, basic financial literacy and investing > techniques through interesting and enriching games and puzzles and > university admissions interviews ... Create a piece of software like > this, get users to test it ... then when the feedback streams in, > iterate the product accordingly based on user feedback ... I'm sure you could probably google for some resources about Python game development. Google shows this link, for example, though I cannot vouch for whether or not it would be helpful: https://inventwithpython.com/chapters/ It claims to be a book that leads you through some game development using Python. Bear in mind that must start simple and work your way into more complex things. If you think you can pick up Python and develop a "complex game" in short order, you'll be very disappointed. It's along process. Even what you described could take years to fully develop. But if you have patience and an aptitude for learning you can without a doubt accomplish it. I think text-only number games are a great place to start honing your skills. -- https://mail.python.org/mailman/listinfo/python-list
Re: Awful code of the week
On 7 August 2016 at 16:54, Steven D'Aprano < [email protected]> wrote: > Seen in the office IRC channel: > > > (13:23:07) fred: near_limit = [] > (13:23:07) fred: near_limit.append(1) > (13:23:07) fred: near_limit = len(near_limit) > (13:23:09) fred: WTF > Assuming you'e not talking about the semantics of this specific code (which could be reduced to near_limit = 1), I have to say I've been guilty of reusing a name in precisely this way - set up the structure using the name, then set the name to a calculated value. I would only do this when I'm totally uninterested in the structure itself - it's purely a way to get to the final result, but getting to that final result requires several steps that justifies an intermediate name binding. It avoids namespace pollution (but of course that can be fixed with del) and avoids having to think up another name for a very temporary structure (names are hard). And I would include a comment explaining the reuse of the name. The alternative would be something like (replace first line by something complex ...): near_limit_list = [1] near_limit = len(near_limit_list) del near_limit_list Tim Delaney -- https://mail.python.org/mailman/listinfo/python-list
Re: Win32 API in pywin32
On Sunday, August 7, 2016 at 4:59:39 PM UTC+12, Rustom Mody wrote: > To be fair my head spins in Linux-land trying to work out what all these > 32's and 64's mean: mingw-w64-x86-64 The package descriptions tell you: mingw-w64 - Development environment targeting 32- and 64-bit Windows mingw-w64-common - Common files for Mingw-w64 mingw-w64-i686-dev - Development files for MinGW-w64 targeting Win32 mingw-w64-tools - Development tools for 32- and 64-bit Windows mingw-w64-x86-64-dev - Development files for MinGW-w64 targeting Win64 -- https://mail.python.org/mailman/listinfo/python-list
Re: Ned Batchelder: Loop Like A Native
On Sunday, August 7, 2016 at 1:26:48 PM UTC+12, Ned Batchelder wrote: > I'm merely pointing out that your concern about multiple ways to exit loops > sounds like exactly what was discussed here two months ago. And one could point out that your presentation on Python loops sounds exactly like every other discussion on Python loops. > Is there any reason to think there is new material to discuss? There are always new things to learn, even about such basic things as loops. Though some don’t seem to like it when I point this out... -- https://mail.python.org/mailman/listinfo/python-list
Re: Ned Batchelder: Loop Like A Native
On Sunday, August 7, 2016 at 6:52:45 PM UTC-4, Lawrence D’Oliveiro wrote: > On Sunday, August 7, 2016 at 1:26:48 PM UTC+12, Ned Batchelder wrote: > > I'm merely pointing out that your concern about multiple ways to exit loops > > sounds like exactly what was discussed here two months ago. > > And one could point out that your presentation on Python loops sounds exactly > like every other discussion on Python loops. If you feel like my presentation was worthless, that would certainly be something we could discuss here, respectfully. I hope you don't actually feel that way. If Mark had posted this link in June, and then again now, I think it would be reasonable for someone to say, "This was just posted in June, why repost it now?" > > > Is there any reason to think there is new material to discuss? > > There are always new things to learn, even about such basic things as loops. > Though some don’t seem to like it when I point this out... We had a long thread about your point only two months ago. Is there something new to add to it? I thought you made your point then, and had a long discussion about it. You'll have to decide if you think there are new points to be made. This list has had difficulty in the past with people who try to start the same topics over and over again, because people didn't agree with them the last three (or ten or twenty) times they brought it up. It's unpleasant and noisy, and pollutes the tone of other conversations. I don't mean to put you into that category. If you have new ideas about loop termination that didn't get an airing in June, I'm sure people will be interested to discuss them. --Ned. -- https://mail.python.org/mailman/listinfo/python-list
Re: Ned Batchelder: Loop Like A Native
On Saturday, August 6, 2016 at 10:43:01 PM UTC-5, Steven D'Aprano wrote: > Yes. The two ways of ending the loop are distinct and different: > > - reach the end, and stop; > - bail out early. > > > When you read a book, there are two ways of stopping: > > - reach the end, and run out of pages to read, so you stop; > - give up reading early, and just put the book away. > > (Or possibly throw the book across the room.) > > > Why would you treat these two cases in the same way? > > interested = True > for page in book: > if interested: > read(page) > if bored_now(): > interested = False This algorithm does not exit early when `interested` becomes false, instead, it iterates every page of the book regardless of the value of `interested`. Was this intentional, or merely a mistake? > finished = False > while not finished: > try: > page = next(book) > except StopIteration: > finished = True > else: > read(page) > if bored_now(): > finished = True That kind of code, whilst being "somewhat" idiomatic python, is horrific. If the intent is to iterate the pages of a book until the end is reached *OR* until the "reader's interest wanes", then a simple for-loop will suffice. for page in book: isReaderInterested = reader.read_page(page) if not isReaderInterested: break Simple is better than complex. -- https://mail.python.org/mailman/listinfo/python-list
Re: make an object read only
On Thursday, August 4, 2016 at 7:03:32 PM UTC-5, Lawrence D’Oliveiro wrote: > As GvR has said: “we’re all consenting adults here”. But as we've learned from animal farm, some are more consenting than others. -- https://mail.python.org/mailman/listinfo/python-list
Re: Win32 API in pywin32
On Thursday, August 4, 2016 at 6:50:28 PM UTC-5, [email protected] wrote: > According to Python.org Mark Hammond has an Add-on > (pywin32) that supports Win32 and COM. Does anyone know if > the Add-on covers all Win32 API functions, and if not is > there a list of the subset of Win32 API functions it does > include? Of course, it's called the "PyWin32 docs". -- https://mail.python.org/mailman/listinfo/python-list
Re: Win32 API in pywin32
On Thursday, August 4, 2016 at 6:58:05 PM UTC-5, Lawrence D’Oliveiro wrote: > On Friday, August 5, 2016 at 11:50:28 AM UTC+12, [email protected] wrote: > > According to Python.org Mark Hammond has an Add-on (pywin32) that supports > > Win32 and COM. > > Are people still using Win32? I thought Windows went 64-bit years ago. Windows, like python after it, may have incremented it's software, but not all the little lemmings are just blindly flinging themselves off the cliff after it. Win32 boxes will be around for a long time. -- https://mail.python.org/mailman/listinfo/python-list
Re: Awful code of the week
On Mon, 8 Aug 2016 08:03 am, Tim Delaney wrote: > On 7 August 2016 at 16:54, Steven D'Aprano < > [email protected]> wrote: > >> Seen in the office IRC channel: >> >> >> (13:23:07) fred: near_limit = [] >> (13:23:07) fred: near_limit.append(1) >> (13:23:07) fred: near_limit = len(near_limit) >> (13:23:09) fred: WTF >> > > Assuming you'e not talking about the semantics of this specific code > (which could be reduced to near_limit = 1), That's exactly it. They're three consecutive lines of code. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: Ned Batchelder: Loop Like A Native
On Mon, 8 Aug 2016 09:19 am, Rick Johnson wrote: > On Saturday, August 6, 2016 at 10:43:01 PM UTC-5, Steven D'Aprano wrote: > >> Yes. The two ways of ending the loop are distinct and different: >> >> - reach the end, and stop; >> - bail out early. >> >> >> When you read a book, there are two ways of stopping: >> >> - reach the end, and run out of pages to read, so you stop; >> - give up reading early, and just put the book away. >> >> (Or possibly throw the book across the room.) >> >> >> Why would you treat these two cases in the same way? >> >> interested = True >> for page in book: >> if interested: >> read(page) >> if bored_now(): >> interested = False > > This algorithm does not exit early when `interested` becomes false, > instead, it iterates every page of the book regardless of the value of > `interested`. Was this intentional, or merely a mistake? I said: "Why would you treat these two cases in the same way?", then showed a code snippet which treats the two cases in the same way (i.e. iterates over every page of the book). Of course it was intentional. > >> finished = False >> while not finished: >> try: >> page = next(book) >> except StopIteration: >> finished = True >> else: >> read(page) >> if bored_now(): >> finished = True > > That kind of code, whilst being "somewhat" idiomatic python, is horrific. Of course it is horrific. And I don't think it is even the slightest bit Pythonic. There may (very unlikely, but theoretically possible) be occasions where you have no choice but to write code like this, but if so you wouldn't describe it as idiomatic Python code. > If the intent is to iterate the pages of a book until the end is reached > *OR* until the "reader's interest wanes", then a simple for-loop will > suffice. That's exactly the sort of thing that Lawrence is objecting to, because (and I quote the part of my email you deleted): "A loop like [example with break] actually has two different ways to terminate. Is there any good reason for them to be written two different ways?" > for page in book: > isReaderInterested = reader.read_page(page) > if not isReaderInterested: > break > > Simple is better than complex. Precisely. I'm showing the horrible code you have to write to avoid writing two different ways of terminating a loop with two fundamentally different ways of terminating. Lawrence, if you're still reading, I hope I am not misrepresenting your position here. If you think that there is an alternative way of writing this code which avoids two exits from the loop but without having to write such unidiomatic (if not idiotic) code, please tell us what you would do. There is one clean way for doing this: use itertools. def interesting(page): """Return True if the page is interesting, False if boring.""" for page in itertools.takewhile(interesting, book): reader.read_page(page) but it's not always easy to re-write the code to match that idiom. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Running Python from the source repo
I have cloned the Python source repo, and build CPython, as described here: https://docs.python.org/devguide/ Now a little bit later, I want to update the repo, so I run: hg fetch to get and apply any changes. How do I know if I need to rebuild Python? I don't want to have to rebuild after every fetch, because that's quite time consuming (I estimate about five minutes on my machine, just long enough to be a distraction but not long enough to get into something else). Plus the time to run the tests (significantly longer). What do others do? -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: Running Python from the source repo
On Mon, Aug 8, 2016 at 12:11 PM, Steven D'Aprano wrote: > I have cloned the Python source repo, and build CPython, as described here: > > https://docs.python.org/devguide/ > > > Now a little bit later, I want to update the repo, so I run: > > hg fetch > > to get and apply any changes. How do I know if I need to rebuild Python? I > don't want to have to rebuild after every fetch, because that's quite time > consuming (I estimate about five minutes on my machine, just long enough to > be a distraction but not long enough to get into something else). Plus the > time to run the tests (significantly longer). > > What do others do? I use 'hg pull -u' - that's the same as 'hg fetch' right? After that, I just 'make'. It won't rebuild everything, only what's changed. If you 'make' and immediately 'make' again, it's pretty quick - at least, it is on my Linux box, where it's cheap to 'stat' a bunch of files to see if they've changed. On other systems, it might be a bit slower, but it certainly won't take as long as a full build from scratch. The only time a full rebuild is needed is if something really fundamental has changed. I just pulled now, and the first build took 1m39s, which involved a reconfigure and a good bit of chugging; then a rebuild looked like this: rosuav@sikorsky:~/cpython$ time make running build running build_ext running build_scripts copying and adjusting /home/rosuav/cpython/Tools/scripts/pydoc3 -> build/scripts-3.6 copying and adjusting /home/rosuav/cpython/Tools/scripts/idle3 -> build/scripts-3.6 copying and adjusting /home/rosuav/cpython/Tools/scripts/2to3 -> build/scripts-3.6 copying and adjusting /home/rosuav/cpython/Tools/scripts/pyvenv -> build/scripts-3.6 changing mode of build/scripts-3.6/pydoc3 from 644 to 755 changing mode of build/scripts-3.6/idle3 from 644 to 755 changing mode of build/scripts-3.6/2to3 from 644 to 755 changing mode of build/scripts-3.6/pyvenv from 644 to 755 renaming build/scripts-3.6/pydoc3 to build/scripts-3.6/pydoc3.6 renaming build/scripts-3.6/idle3 to build/scripts-3.6/idle3.6 renaming build/scripts-3.6/2to3 to build/scripts-3.6/2to3-3.6 renaming build/scripts-3.6/pyvenv to build/scripts-3.6/pyvenv-3.6 real 0m0.148s user 0m0.108s sys 0m0.028s rosuav@sikorsky:~/cpython$ So normally just run 'make' and let it do its work. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
