From letterrip at gmail.com Mon Mar 3 05:53:44 2014 From: letterrip at gmail.com (Tom M) Date: Sun, 2 Mar 2014 19:53:44 -0900 Subject: [Idle-dev] The Future of Python In-Reply-To: References: Message-ID: Regarding her comments on games. Python is a non starter for platform (Nintendo, PS3, Xbox) games - I discussed this with Erwin Coumans (created and develops the Bullet physics engine and also consults for most major physics engines) many years ago and he gave a number of reasons why major game developers are unlikely to ever use Python (this was quite a few years back but the comments as I recall were - lack of good embedding which she covers; too heavy a set of mandatory libraries; slow execution speed; high overhead) which was why he went with Lua for 'gamekit' (his hobby game engine based on Ogre and Bullet). Python is a non starter for mobile games (not available on most of the platforms in any reasonable manner) Since most games will originate for platforms or mobile, there isn't going to be much in the way of python used in games or likely to be used for games. She does make a good point that for hobbyists, one of the issues is making a bundled executable on windows platform, which is an issue for 'my first python game' type developers. Tom M. LetterRip On Wed, Feb 5, 2014 at 11:36 AM, phil jones wrote: > Interesting video : https://www.youtube.com/watch?v=d1a4Jbjc-vU > _______________________________________________ > IDLE-dev mailing list > IDLE-dev at python.org > https://mail.python.org/mailman/listinfo/idle-dev From glyph at twistedmatrix.com Wed Mar 5 00:29:12 2014 From: glyph at twistedmatrix.com (Glyph Lefkowitz) Date: Tue, 4 Mar 2014 15:29:12 -0800 Subject: [Idle-dev] The Future of Python In-Reply-To: References:

Message-ID: On Mar 2, 2014, at 8:53 PM, Tom M wrote: > Regarding her comments on games. > > Python is a non starter for platform (Nintendo, PS3, Xbox) games - I > discussed this with Erwin Coumans (created and develops the Bullet > physics engine and also consults for most major physics engines) many > years ago and he gave a number of reasons why major game developers > are unlikely to ever use Python (this was quite a few years back but > the comments as I recall were - lack of good embedding which she > covers; too heavy a set of mandatory libraries; slow execution speed; > high overhead) which was why he went with Lua for 'gamekit' (his > hobby game engine based on Ogre and Bullet). This is a very real perception in the game development community, but is also mostly an issue of configuration and build toolchain. Console games can be and have been built with Python with no particular detriment to performance. (Case in point: you don't know which ones they are.) > Python is a non starter for mobile games (not available on most of the > platforms in any reasonable manner) Also not true. Play around with some of the simple 2D demos included with and you'll see what I mean. Heck, in Pythonista itself, there's an "export to Xcode" button, so you can make a game jam game right there on your iPad, and actually ship it on the app store, as long as you have a mac to bounce the final build process off of. > Since most games will originate for platforms or mobile, there isn't > going to be much in the way of python used in games or likely to be > used for games. So, this is basically all nonsense but I completely understand where it's coming from, and I understand how it's nearly impossible to arrive at my perspective without decades of folk knowledge of the Python community's history. In fact, the main thing that makes Python still interesting to me after all this time is its complete versatility. You can put it just about anywhere. But there needs to be better community support for these sorts of things. (And the place to start with game developers is not to create a professional toolchain for PS4 developmen, but rather, as you point out...) > She does make a good point that for hobbyists, one of the issues is > making a bundled executable on windows platform, which is an issue for > 'my first python game' type developers. This is absolutely the problem. The toolchain for making some code that you can share has evolved so much and requires so much arcane understanding of history (distutils, modulefinder, importlib, setuptools no distribute no setuptools again, easy_install no pip no actually easy_install because windows no actually pip with wheels) that it's basically impossible. _technically_ the problem is all relatively straightforward and tools exist to do all the things you need, you just need to know which 9000 things to avoid and ignore while you're doing it. Would anyone be interested in working with me on a project to create a build platform to make shippable artifacts out of Python scripts easily? -glyph -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4124 bytes Desc: not available URL: From ether.joe at gmail.com Wed Mar 5 22:18:03 2014 From: ether.joe at gmail.com (Sean Felipe Wolfe) Date: Wed, 5 Mar 2014 13:18:03 -0800 Subject: [Idle-dev] The Future of Python In-Reply-To: References:

Message-ID: > On Mar 2, 2014, at 8:53 PM, Tom M wrote: > > Regarding her comments on games. > > Python is a non starter for mobile games (not available on most of the > platforms in any reasonable manner) > There's a pygame for android project which works in a basic sort of way. I think one or two games are out there on the android market as well. I poked around with it a few years ago and it worked okay. I was actually super excited to get involved and then other things came up. http://pygame.renpy.org/changelog.html#pygame-subset-for-android-0-9-6 From ether.joe at gmail.com Wed Mar 5 22:40:53 2014 From: ether.joe at gmail.com (Sean Felipe Wolfe) Date: Wed, 5 Mar 2014 13:40:53 -0800 Subject: [Idle-dev] picking up some IDLE bugs Message-ID: Hello all, I'm setting aside some time each week to pick up some issues from the queue and help out.I thought I'd start by working some issues that need testing. Good news is, I have access to osx, linux and windows 7 as well, so I should be able to provide a broad testing environment. I'm wondering, as new features are developed, tested, and approved, which release do they end up in for implementation? Do new features always go to the next pending release ... which as of now is 3.4, yes? I'm getting started with this one: http://bugs.python.org/issue694339 IDLE: Dedenting with Shift+Tab Seems like a useful feature and I've wanted it myself for a while. Second question -- how do we determine when an issue has sufficient testing and is ready for release? Do we discuss it here or on the bug tracker and take it on a case by case basis? Also, would it be ok to add a 'test-windows' type keyword to issues which are waiting for a windows test? Does keywords act as a 'tag' type functionality? Thanks! -- A musician must make music, an artist must paint, a poet must write, if he is to be ultimately at peace with himself. - Abraham Maslo From tjreedy at udel.edu Thu Mar 6 00:48:16 2014 From: tjreedy at udel.edu (Terry Reedy) Date: Wed, 05 Mar 2014 18:48:16 -0500 Subject: [Idle-dev] picking up some IDLE bugs In-Reply-To: References: Message-ID: On 3/5/2014 4:40 PM, Sean Felipe Wolfe wrote: > Hello all, Hi. > I'm setting aside some time each week to pick up some issues from the > queue and help out.I thought I'd start by working some issues that > need testing. Good news is, I have access to osx, linux and windows 7 > as well, so I should be able to provide a broad testing environment. That will be helpful. > > I'm wondering, as new features are developed, tested, and approved, > which release do they end up in for implementation? Do new features > always go to the next pending release ... which as of now is 3.4, yes? New features go into the next version that is still in the alpha stages. Once the first beta is released, that is it for that version. So 'as of now' is now 3.5. But Idle has a special rule. See PEP434 http://legacy.python.org/dev/peps/pep-0434/ > I'm getting started with this one: > http://bugs.python.org/issue694339 IDLE: Dedenting with Shift+Tab I did not know that worked to indent a region, and agree with the others that , commonly interpreted as 'backtab' should then do the opposite. I do not know Tk events well enough to understand Roger Serwy's comment, so I do not know how easy it would be to revise the patch. > Seems like a useful feature and I've wanted it myself for a while. That is a 'little' feature that would fall under the PEP. > Second question -- how do we determine when an issue has sufficient > testing and is ready for release? That is ultimately decided by a core developer with repository push priviliges (subject to possible rollback, which is very rare). The amount of testing I would want depends on the issue. For a keybinding issue like this, I would like testing on all 3 systems before pushing. For internal logic that should be system independent, my own machine should be enough -- especially with a automated test that runs on the buildbots. > Do we discuss it here or on the bug > tracker and take it on a case by case basis? Issue tracker, on a case-by-case basis. I would like to see more 'idle-ideas' discussion here, though more practical than some of the discussion on python-ideas list. Such discussion should if there is sufficient support for an idea before posting it to the tracker and turn vague ideas into a concrete proposals that could actually be implemented in a patch. > Also, would it be ok to add a 'test-windows' type keyword to issues > which are waiting for a windows test? Does keywords act as a 'tag' > type functionality? Since I am on Windows, osx testing is more of an issue now. -- Terry Jan Reedy From ether.joe at gmail.com Thu Mar 27 06:10:58 2014 From: ether.joe at gmail.com (Sean Felipe Wolfe) Date: Wed, 26 Mar 2014 22:10:58 -0700 Subject: [Idle-dev] fix indentation and find non-ascii Message-ID: Hey everybody, I was working with a new programmer today and ran into a couple issues which I'd love to see IDLE be able to address: 1) non-asciii charcters: Strip all non-ascii characters. I've found copy/paste on sample code from a website, sometimes picks up spurious non-ascii bits. It would be great to have a pull-down menu function which forces the script to save only ascii and discard the rest. Maybe there is already a way to do this? 2) Fix indentation: it would be great to have the equivalent of vim's "gg=G" sequence to automatically fix indentation issues. I thought we had this already actually? But digging through the menus I didn't see anything. Whaddya think? -- A musician must make music, an artist must paint, a poet must write, if he is to be ultimately at peace with himself. - Abraham Maslow From tjreedy at udel.edu Fri Mar 28 01:00:28 2014 From: tjreedy at udel.edu (Terry Reedy) Date: Thu, 27 Mar 2014 20:00:28 -0400 Subject: [Idle-dev] fix indentation and find non-ascii In-Reply-To: References: Message-ID: On 3/27/2014 1:10 AM, Sean Felipe Wolfe wrote: > Hey everybody, > > I was working with a new programmer today and ran into a couple issues > which I'd love to see IDLE be able to address: > > 1) non-asciii charcters: Strip all non-ascii characters. I've found > copy/paste on sample code from a website, sometimes picks up spurious > non-ascii bits. The problem I have had is spurious ascii chars, such as line #s or prompts. There is a proposal for an option to auto-strip '>>>' and '...' prompts. I would like a way to strip line numbers in text lines. There is a separate proposal to add line #s *beside* but not in text lines. In Py 3, Python code *is* unicode, so non-ascii chars may be an essential part of the code. If copying picks up non-code, it seems to me that this would be the fault of the user selection, the presentation format making selection of only code impossible (as with the Idle shell and some line-numbered windows), the browser, or the website. What case are you referring to? Also, see below. > It would be great to have a pull-down menu function > which forces the script to save only ascii and discard the rest. If you mean save to disk, that would be wrong. Modifying text in an edit window should be separate from saving. > Maybe there is already a way to do this? I am sure not. > 2) Fix indentation: it would be great to have the equivalent of vim's > "gg=G" sequence to automatically fix indentation issues. How do you expect a non-vim user to have any idea what you mean? > I thought we had this already actually? There are indent related options on the preference dialog and editor format menu. Without knowing what you want ... There is a proposal to add a generic extension that could run 3rd party code analyzers on the contents of an edit window and display results in an output window. Your post suggests that a useful (and simpler) enhancement would be a generic way to apply a line-transformation function to all the lines of a block (default = whole file). All the options listed on the editor format menu (except reformat paragraph) fit the following pattern. (I believe the ones that do not say 'region' only modify the whole file.) def replace_lines(func, file_slice) for line in file_slice: I believe both of your requests also fit this pattern. I do not know whether any of the existing functions use a common loop like the above, but the visible enhancement would be to load funcs from a file that users can edit. Then users like you could extend Idle simply by adding line transformation functions that do exactly what you want, without waiting for someone like be to be persuaded to add it and without writing a full-blown extension like idlelib/FormatParagraph.py, which is much harder than writing just the transform function. This would be much more powerful than adding a macro recording facility. Such an enhancement should also make it easy to bring up an argument input box, such as with Format / Tabify Region. -- Terry Jan Reedy From ether.joe at gmail.com Fri Mar 28 07:19:39 2014 From: ether.joe at gmail.com (Sean Felipe Wolfe) Date: Thu, 27 Mar 2014 23:19:39 -0700 Subject: [Idle-dev] fix indentation and find non-ascii In-Reply-To: References: Message-ID: Here's the circumstances that brought this up. I was helping a new programming student walk through some example code, having him both type manually as well as copy + paste from the site and we would talk it over. When it came time to run the module, we ran into a few typos, a few indentation errors, a capitalization error, no problem, easy fixes. But the script kept failing on two points: one, it claimed that we were using non-ascii and needed to declare the file as UTF-8. Two, it continued to say there was an indentation error after we'd checked it closely. I eventually exported the file to vim, but there were no indentation problems. What we ended up doing, was to delete the offending line and type it manually on a new line. This ended up being much more complicated than it needed to be, in my opinion. A big reason why I enjoy Python is the emphasis on simplicity. We were trying to do a simple task. I think IDLE could add value here by providing convenience features to get a script back to a simple state, both by fixing indentation as well as resetting to a dead-simple charset, do deal with things like accented characters or stylized curly-quotes. Simple is good and I think IDLE could help simplify here. That's the overall intent of my suggestions. On Thu, Mar 27, 2014 at 5:00 PM, Terry Reedy wrote: > On 3/27/2014 1:10 AM, Sean Felipe Wolfe wrote: >> >> Hey everybody, >> >> I was working with a new programmer today and ran into a couple issues >> which I'd love to see IDLE be able to address: >> >> 1) non-asciii charcters: Strip all non-ascii characters. I've found >> copy/paste on sample code from a website, sometimes picks up spurious >> non-ascii bits. > > > The problem I have had is spurious ascii chars, such as line #s or prompts. > There is a proposal for an option to auto-strip '>>>' and '...' prompts. I > would like a way to strip line numbers in text lines. There is a separate > proposal to add line #s *beside* but not in text lines. > > In Py 3, Python code *is* unicode, so non-ascii chars may be an essential > part of the code. If copying picks up non-code, it seems to me that this > would be the fault of the user selection, the presentation format making > selection of only code impossible (as with the Idle shell and some > line-numbered windows), the browser, or the website. What case are you > referring to? > > Also, see below. > > >> It would be great to have a pull-down menu function >> >> which forces the script to save only ascii and discard the rest. > > > If you mean save to disk, that would be wrong. Modifying text in an edit > window should be separate from saving. > > >> Maybe there is already a way to do this? > > > I am sure not. > > >> 2) Fix indentation: it would be great to have the equivalent of vim's >> "gg=G" sequence to automatically fix indentation issues. > > > How do you expect a non-vim user to have any idea what you mean? > > >> I thought we had this already actually? > > > There are indent related options on the preference dialog and editor format > menu. Without knowing what you want ... > > There is a proposal to add a generic extension that could run 3rd party code > analyzers on the contents of an edit window and display results in an output > window. Your post suggests that a useful (and simpler) enhancement would be > a generic way to apply a line-transformation function to all the lines of a > block (default = whole file). All the options listed on the editor format > menu (except reformat paragraph) fit the following pattern. (I believe the > ones that do not say 'region' only modify the whole file.) > > def replace_lines(func, file_slice) > for line in file_slice: > > > I believe both of your requests also fit this pattern. > > I do not know whether any of the existing functions use a common loop like > the above, but the visible enhancement would be to load funcs from a file > that users can edit. Then users like you could extend Idle simply by adding > line transformation functions that do exactly what you want, without waiting > for someone like be to be persuaded to add it and without writing a > full-blown extension like idlelib/FormatParagraph.py, which is much harder > than writing just the transform function. This would be much more powerful > than adding a macro recording facility. > > Such an enhancement should also make it easy to bring up an argument input > box, such as with Format / Tabify Region. > > -- > Terry Jan Reedy > > _______________________________________________ > IDLE-dev mailing list > IDLE-dev at python.org > https://mail.python.org/mailman/listinfo/idle-dev -- A musician must make music, an artist must paint, a poet must write, if he is to be ultimately at peace with himself. - Abraham Maslow From tjreedy at udel.edu Sun Mar 30 03:11:44 2014 From: tjreedy at udel.edu (Terry Reedy) Date: Sat, 29 Mar 2014 21:11:44 -0400 Subject: [Idle-dev] fix indentation and find non-ascii In-Reply-To: References: Message-ID: On 3/28/2014 2:19 AM, Sean Felipe Wolfe wrote: > Here's the circumstances that brought this up. > > I was helping a new programming student walk through some example > code, having him both type manually as well as copy + paste from the > site and we would talk it over. > > When it came time to run the module, we ran into a few typos, a few > indentation errors, a capitalization error, no problem, easy fixes. > But the script kept failing on two points: one, it claimed that we > were using non-ascii and needed to declare the file as UTF-8. Since Py3 expects utf-8 by default, were you using 2.x? If so, I recommend you have new students start with the latest 3.x, partly to avoid some unicode problems. > Two, it continued to say there was an > indentation error after we'd checked itclosely. 'It' is Python, not Idle. > I eventually exported the file to vim, but there were no indentation problems. This suggest that there was some other syntax-like problem that caused the indentation to seem wrong. But I cannot comment without the code. > What we ended up doing, was to delete the offending line and type it > manually on a new line. > > This ended up being much more complicated than it needed to be, I have no idea what you mean. Typing a line is pretty simple. > I think IDLE could add value here by providing convenience features to > get a script back to a simple state, both by fixing indentation I do not know what you mean by 'fix' indentation but no code can read your mind. In any case, this is not specifically an Idle issue. I already agree that we should make it easier to run or create editing tools. Perhaps Tools/Scripts/reindent.py will do what you need. That and anything like it should be accessible from Idle. > well as resetting to a dead-simple charset, do deal with things like > accented characters These are legal, especially in Python 3. I am willing to highlight, but not blindly remove (and see comment below). > or stylized curly-quotes. If a site publishes code mangled with substitute chars, you should complain to the site. But besides that, the ability to run str.translate on editor window text is a plausible idea. -- Terry Jan Reedy From billperkins at birdlandobservatory.net Sat Mar 29 23:00:18 2014 From: billperkins at birdlandobservatory.net (birdlandbill) Date: Sat, 29 Mar 2014 22:00:18 -0000 Subject: [Idle-dev] Fwd: Idle working on OS 10.9.2? References: <6DD8080F-F2D0-4B3E-B979-645DFF679457@birdlandobservatory.net> Message-ID: <76CC1763-0970-40FA-8A53-50D79E659C41@birdlandobservatory.net> Begin forwarded message: > From: birdlandbill > Subject: Idle working on OS 10.9.2? > Date: March 29, 2014 at 4:38:28 PM CDT > To: idle-dev at python.ord > > It isn?t on my computer. Worked on 10.8.5, but haven?t been successful in getting Idle 2.7.6 working on two different Macs with 10.9.2. Can start python 2.7.6 in terminal window by typing python from the home directory. Entering idle at the home directory results in > > python version 2.7.6 can?t run /usr/bin/idle. Try the alternative(s): > /usr/bin/idle2.7 (uses python 2.7) > > /usr/bin/idle2.7 exists in /usr/bin as does /usr/bin/idle > > Idle 2.7.6 exists in the Applications folder, but does not execute when selected. > > As an experiment, I downloaded Python 3.4. I can launch it from the version appropriate Idle file in the Applications folder. I was able to do this with Idle 2.7.6 in OS 10.8.5. > > Just wondering if anyone has been able to run Idle 2.7.6 on OS 10.9.2 and, if not, how that might be accomplished. > > If I?ve sent this note to the wrong party, would you please let me know who it should be directed to? > > Thank you, > > Bill Perkins -------------- next part -------------- An HTML attachment was scrubbed... URL: