Re: Python and IDEs [was Re: Python 3 is killing Python]
By the way, you keep replying to people, and quoting them, but deleting their name. Please leave the attribution in place, so we know who you are replying to. That's what the References:-Header is there for. The References header is for the benefit of news and mail clients, not human readers. Any half-decent news client will happily display a thread tree for you. Based on that References:-Header. It is rude to deliberately refuse to give attributes: So please stop being rude, and follow the convention of both email and usenet (as well as broader society) to give attribution to those you quote. I've been using mail and news for over 20 years now, you definitely don't need to teach me anything. End of subthread. Good Bye, Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
Because on such operating systems, each and every application is an entirely self-contained package that doesn't need any packages or installers to use it. For people who have never used such a system it's probably difficult to see the advantages. That's the whole point. The problem is that the ones who decide (well, they pretend to, but actually can't, because they don't know the alternatives) are always people who are not even clueless. Ha! I love it. I presume that's an allusion to that-other-Wolfgang's apocryphal not even wrong comment. :) Exactly. And it's also an allusion to that statement that knowledge means to know what you don't know. Sincerely, Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
Wolfgang Keller wrote: I've been using mail and news for over 20 years now, you definitely don't need to teach me anything. Except common courtesy. You may have been rude for over 20 years, but I don't have to put up with it for a second longer. Good Bye, Agreed. *plonk* -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
On 13/08/2014 11:42, Wolfgang Keller wrote: By the way, you keep replying to people, and quoting them, but deleting their name. Please leave the attribution in place, so we know who you are replying to. That's what the References:-Header is there for. The References header is for the benefit of news and mail clients, not human readers. Any half-decent news client will happily display a thread tree for you. Based on that References:-Header. It is rude to deliberately refuse to give attributes: So please stop being rude, and follow the convention of both email and usenet (as well as broader society) to give attribution to those you quote. I've been using mail and news for over 20 years now, you definitely don't need to teach me anything. Very funny. It strikes me that your knowledge of using mail and news is akin to that of our resident unicode expert's knowledge of the FSR. End of subthread. The subthread ends when people want it to end, not when you state that it has ended. It will not end until you stop being so downright rude in refusing to give attribution to those you quote. Good Bye, Good riddance. Ditto Steven D'Aprano's *plonk* Wolfgang -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
Thankfully, all actually user-friendly operating systems (MacOS, TOS, RiscOS, probably AmigaOS, MacOS X) spare(d) their users the bottomless cesspit of package management and/or installers. Because on such operating systems, each and every application is an entirely self-contained package that doesn't need any packages or installers to use it. You mean everyone has to reinvent the proverbial wheel AND worry about dependency collisions? Yeah, that's a heavenly thought. You should get a clue in stead of just fantasizing up assumptions based on ignorance. I've worked with a number of operating systems, a number of dependency management systems, and a number of absences of such systems. I stand by my earlier statements in this thread, Then you seem to have a problem with elementary logical reasoning. Your above statement (about re-inventing the wheel AND worrying about dependency collisions) is totally illogical nonsense. Just one issue: MacOS application have always been far more compact (both on disk and in RAM) than comparable Windows or Unix counterparts. Despite the fact that they where GUI applications since MacOS 1.0. No one has to re-invent any more wheels to develop a MacOS X application than he has to do for a Windows or Linux application. In fact, usually, there are less wheels to re-invent for MacOS X. Next: The self-contained nature of applications is obviously exactly what *eliminates* dependency collisions. Sincerely, Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
Linux was made by geeks who didn't have a clue of ergonomics for screenworkers and didn't care to get one. I can only repeat what you said earlier: You should get a clue in stead [sic] of just fantasizing up assumptions based on ignorance. I daresay that Linus Torvalds spends more time in front of a computer screen than most 9 to 5 screenworkers. He's a developer, not a usual screenworker. By the way, you keep replying to people, and quoting them, but deleting their name. Please leave the attribution in place, so we know who you are replying to. That's what the References:-Header is there for. Sincerely, Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
On Mon, 11 Aug 2014 11:08:43 +0200, Wolfgang Keller wrote: By the way, you keep replying to people, and quoting them, but deleting their name. Please leave the attribution in place, so we know who you are replying to. That's what the References:-Header is there for. Sincerely, Wolfgang Which is not normally visible unless you go looking for it Also despite the problems it causes there are still an large number of posters that use Google groups probably cant see those headers even if they wished. Common courtesy (or netiquet if you prefer) would be to follow the conventions of the group you are posting to. -- You definitely intend to start living sometime soon. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
On Mon, Aug 11, 2014 at 7:37 PM, alister alister.nospam.w...@ntlworld.com wrote: On Mon, 11 Aug 2014 11:08:43 +0200, Wolfgang Keller wrote: By the way, you keep replying to people, and quoting them, but deleting their name. Please leave the attribution in place, so we know who you are replying to. That's what the References:-Header is there for. Which is not normally visible unless you go looking for it Also despite the problems it causes there are still an large number of posters that use Google groups probably cant see those headers even if they wished. Common courtesy (or netiquet if you prefer) would be to follow the conventions of the group you are posting to. Additionally, the References header is good for at most one level in. Can you see, by looking at my post here, who Alister is quoting? Yes, easily, because his attribution line is part of the text that I've quoted. Can you see who Wolfgang is quoting? No, because there's no attribution line. It's completely impractical to dig through the References header (Alister's post has nineteen message IDs in References, and presumably mine will add a twentieth) to find out who quoted whom three levels ago. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
On 11/08/2014 10:08, Wolfgang Keller wrote: By the way, you keep replying to people, and quoting them, but deleting their name. Please leave the attribution in place, so we know who you are replying to. That's what the References:-Header is there for. Sincerely, Wolfgang The references header is conspicious by its absence. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
On 2014-08-06, Wolfgang Keller felip...@gmx.net wrote: Because on such operating systems, each and every application is an entirely self-contained package that doesn't need any packages or installers to use it. For people who have never used such a system it's probably difficult to see the advantages. That's the whole point. The problem is that the ones who decide (well, they pretend to, but actually can't, because they don't know the alternatives) are always people who are not even clueless. Ha! I love it. I presume that's an allusion to that-other-Wolfgang's apocryphal not even wrong comment. :) -- Grant Edwards grant.b.edwardsYow! I want to mail a at bronzed artichoke to gmail.comNicaragua! -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
On 2014-08-11, Wolfgang Keller felip...@gmx.net wrote: [somebody, but we don't know who, wrote]... By the way, you keep replying to people, and quoting them, but deleting their name. Please leave the attribution in place, so we know who you are replying to. That's what the References:-Header is there for. Your over-confidence in Usenet, mailing list archives, news-to-mail gateways, and various client applications is showing... -- Grant Edwards grant.b.edwardsYow! Can I have an IMPULSE at ITEM instead? gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
Wolfgang Keller wrote: By the way, you keep replying to people, and quoting them, but deleting their name. Please leave the attribution in place, so we know who you are replying to. That's what the References:-Header is there for. The References header is for the benefit of news and mail clients, not human readers. Giving attribution in the body of your text is for the benefit of people reading your reply, and I maintain that people are far more important than your news or mail client. It is rude to deliberately refuse to give attributes: - you're saying that the person you are replying to doesn't deserve to have their identity acknowledged even in passing; - you're saying that you expect all of your readers to spend significant time and effort to follow the machine references in the headers if they want to understand who you are talking to, just to save you the one-off cost of turning on the phrase used when replying, which every mail and news client I know of supports (including Sylpheed); - you are saying that anyone reading this forum via unthreaded web archives don't matter; - and anyone who (for one reason or another) is missing some of the referenced posts, possibly because they have expired, or were never delivered in the first place. So please stop being rude, and follow the convention of both email and usenet (as well as broader society) to give attribution to those you quote. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Quoting and attribution (was: Python and IDEs [was Re: Python 3 is killing Python])
On 2014-08-12 10:11, Steven D'Aprano wrote: It is rude to deliberately refuse to give attributes While I find this true for first-level attribution, I feel far less obligation to attribute additional levels (and the verbosity they entail). If the reader is really that interested in who said what, then they can go back to previous posts to disinter that information. I find that On 2013-12-14 Ian Paul Freely wrote: On 2014-12-11 Xavier Onasis wrote: On 2014-12-10 Pat McCann wrote: On 2014-12-09 Mike Easter wrote: Lunch for Mary's birthday? How's Wednesday? Wed is good, what time? Earlier is better for me. 11:30? How about at that little Greek place on 4th Street? could just credit Ian and snip out the other attributions for the sake of quoting just the parts that I find matter. On 2013-12-14 Ian Paul Freely wrote: Lunch for Mary's birthday? How's Wednesday? Wed is good, what time? Earlier is better for me. 11:30? How about at that little Greek place on 4th Street? If I really care about who was associated with more historical comments, I'll pull up my message history and read the details. -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: Quoting and attribution (was: Python and IDEs [was Re: Python 3 is killing Python])
On Mon, 11 Aug 2014 19:27:25 -0500, Tim Chase wrote: On 2014-08-12 10:11, Steven D'Aprano wrote: It is rude to deliberately refuse to give attributes While I find this true for first-level attribution, I feel far less obligation to attribute additional levels (and the verbosity they entail). If the reader is really that interested in who said what, then they can go back to previous posts to disinter that information. I cannot disagree with that. I consider that the first-level attribution MUST be given, second-level SHOULD be given, and third- and subsequent levels MAY be given, where MUST/SHOULD/MAY have their conventional meanings from RFC 2119. https://www.ietf.org/rfc/rfc2119.txt With one proviso: if you respond *directly* to something quoted at the Nth-level, for any N, (as opposed to merely leaving it in to establish context), then you MUST given an attribution. Even if that attribution is just Sorry, I don't know who said this, you ought to make an honest effort to give credit to those you quote directly. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Quoting and attribution (was: Python and IDEs [was Re: Python 3 is killing Python])
On Tue, Aug 12, 2014 at 12:07 PM, Steven D'Aprano st...@pearwood.info wrote: I cannot disagree with that. I consider that the first-level attribution MUST be given, second-level SHOULD be given, and third- and subsequent levels MAY be given, where MUST/SHOULD/MAY have their conventional meanings from RFC 2119. https://www.ietf.org/rfc/rfc2119.txt That's fair. It's also very easy to give first-level attribution (just set your client up properly and that's that), while giving second-level means carefully retaining it from upstream. If it's easy (if you're quoting the beginning of the quote), then it's still of value, but it's not as important as first-level. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Quoting and attribution (was: Python and IDEs [was Re: Python 3 is killing Python])
On 2014-08-12 02:07, Steven D'Aprano wrote: It is rude to deliberately refuse to give attributes While I find this true for first-level attribution, I feel far less obligation to attribute additional levels (and the verbosity they entail). I cannot disagree with that. I consider that the first-level attribution MUST be given, second-level SHOULD be given, and third- and subsequent levels MAY be given With one proviso: if you respond *directly* to something quoted at the Nth-level, for any N, (as opposed to merely leaving it in to establish context), then you MUST given an attribution. For these case, I tend to do it interlinearly with my response, e.g. while you have some good points, I still lean towards Terry's recommendation to frobniculate the hammerjammer rather than have a long list of attributions at the top of the email. -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
Thankfully, all actually user-friendly operating systems (MacOS, TOS, RiscOS, probably AmigaOS, MacOS X) spare(d) their users the bottomless cesspit of package management and/or installers. Because on such operating systems, each and every application is an entirely self-contained package that doesn't need any packages or installers to use it. You mean everyone has to reinvent the proverbial wheel AND worry about dependency collisions? Yeah, that's a heavenly thought. You should get a clue in stead of just fantasizing up assumptions based on ignorance. Sincerely, Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
Because on such operating systems, each and every application is an entirely self-contained package that doesn't need any packages or installers to use it. For people who have never used such a system it's probably difficult to see the advantages. That's the whole point. The problem is that the ones who decide (well, they pretend to, but actually can't, because they don't know the alternatives) are always people who are not even clueless. I.e. they are totally clueless, *and* psychotically self-convinced of their omnicompetence. Sincerely, Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
I've worked with both. Quite honestly, I really wish that other operating systems had gone down this route. MS didn't possibly to make it harder to steal software, From the perspective of the computer-literate, proficient screenworker, MS always got and gets everything completely wrong. and Unix...well, *nix has the concept of the distribution that will manage all of this for you. We all know the problems that this causes. Linux was made by geeks who didn't have a clue of ergonomics for screenworkers and didn't care to get one. Sincerely, Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
On Wed, Aug 6, 2014 at 10:38 PM, Wolfgang Keller felip...@gmx.net wrote: Thankfully, all actually user-friendly operating systems (MacOS, TOS, RiscOS, probably AmigaOS, MacOS X) spare(d) their users the bottomless cesspit of package management and/or installers. Because on such operating systems, each and every application is an entirely self-contained package that doesn't need any packages or installers to use it. You mean everyone has to reinvent the proverbial wheel AND worry about dependency collisions? Yeah, that's a heavenly thought. You should get a clue in stead of just fantasizing up assumptions based on ignorance. I've worked with a number of operating systems, a number of dependency management systems, and a number of absences of such systems. I stand by my earlier statements in this thread, and I think I have a fairly good clue about what does and doesn't work in terms of installers. There is one way to avoid most of the duplication and still make every application perfectly self-contained. You simply decree that there are no dependencies permitted except for the base OS itself and what it provides. As long as that's a rich enough set of tools, everything can work (that's what seems to be happening on mobile platforms, for instance). But it does mean that any unusual dependencies have to be considered part of the app, and that means duplication. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
Wolfgang Keller wrote: Linux was made by geeks who didn't have a clue of ergonomics for screenworkers and didn't care to get one. I can only repeat what you said earlier: You should get a clue in stead [sic] of just fantasizing up assumptions based on ignorance. I daresay that Linus Torvalds spends more time in front of a computer screen than most 9 to 5 screenworkers. By the way, you keep replying to people, and quoting them, but deleting their name. Please leave the attribution in place, so we know who you are replying to. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Unfortunately, software development on Windows is something of a ghetto, compared to the wide range of free tools available for Linux. Outside of a few oases like Microsoft's own commercial development tools, it's hard to do development on Windows. Hard, but not impossible, of course, and there are quite a few resources available for the Windows user willing to download installers from the Internet. For Python users, the IDEs from Wingware and Activestate are notable: https://wingware.com/ http://komodoide.com/ I missed this thread when it started, so please forgive me if this has been covered, but by dismissing Microsoft you look to have skipped over a very powerful Python IDE for Windows, namely PTVS. Microsoft's PTVS is Windows only :-( and completely free (gratuit), partly free (libre): PTVS itself is Apache licensed and the required Visual Studio is of course closed source but PTVS now runs on the latest free versions of Visual Studio Express 2013 for Web or Visual Studio Express 2013 for Desktop (which includes C++). Some of the features: works with CPython (2.x or 3.x) or IronPython. Full support for virtualenv, packages can be installed directly from PTVS individually or from requirements.txt. Intellisense uses a completion database generated in the background from the standard library and all installed libraries. It offers context sensitive completion which does a pretty good job of inferring the type of local variables based on the types of the values used to call the function. Refactoring (Rename, Extract Method, Add Import, Remove unused imports) Interactive windows for all installed Python versions (can use standard shell or IPython) Debugging locally or remotely including Linux and OS X targets (in fact they claim that anything capable of running Python can be debugged). Mixed mode Python and C++ debugging. Profiling (CPython only). Automatic test discovery for tests using unittest. Support for PyLint. Automatic deployment to Windows Azure. Extensive support for Django (including Intellisense and debugging for templates and various Django specific commands such as sync db and admin shell). -- Duncan Booth -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
Duncan Booth wrote: Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Unfortunately, software development on Windows is something of a ghetto, compared to the wide range of free tools available for Linux. I remember writing this. But I don't remember when it was. Presumably some time in the last six months :-) Outside of a few oases like Microsoft's own commercial development tools, it's hard to do development on Windows. Hard, but not impossible, of course, and there are quite a few resources available for the Windows user willing to download installers from the Internet. For Python users, the IDEs from Wingware and Activestate are notable: https://wingware.com/ http://komodoide.com/ I missed this thread when it started, so please forgive me if this has been covered, but by dismissing Microsoft you look to have skipped over a very powerful Python IDE for Windows, namely PTVS. Never heard of it :-) Which is not surprising, since I'm not a Windows developer. [snip feature list] Nice. How does one get it? If I gave the impression that one cannot do development on Windows, that was not my intent. I tried to indicate that the difference was a matter of degree, not impossibility. One of the reasons why so many of the core developers for Python use Linux is that they got frustrated with the speed humps on Windows, the poor out of the box experience for developers (compare what dev tools you get with Windows by default versus what you get on Linux by default), but that might also be somewhat self-selecting: people who are happy with Windows development tend to stick to VB, Java, C, .Net etc. while those who prefer lighter weight more agile environments migrate to Linux. I don't know. But I do know that the existence of good quality Windows development tools for Python is good news for the community, so thank you for mentioning this. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Duncan Booth wrote: Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Unfortunately, software development on Windows is something of a ghetto, compared to the wide range of free tools available for Linux. I remember writing this. But I don't remember when it was. Presumably some time in the last six months :-) Outside of a few oases like Microsoft's own commercial development tools, it's hard to do development on Windows. Hard, but not impossible, of course, and there are quite a few resources available for the Windows user willing to download installers from the Internet. For Python users, the IDEs from Wingware and Activestate are notable: https://wingware.com/ http://komodoide.com/ I missed this thread when it started, so please forgive me if this has been covered, but by dismissing Microsoft you look to have skipped over a very powerful Python IDE for Windows, namely PTVS. Never heard of it :-) Which is not surprising, since I'm not a Windows developer. [snip feature list] Nice. How does one get it? 1) Get a Windows 8.1 VM, or a real PC if that's more convenient. 2) Download and install either Microsoft Visual Studio Express 2013 with Update 3 for Web or Microsoft Visual Studio Express 2013 with Update 3 for Windows Desktop from http://www.visualstudio.com/downloads/download-visual-studio-vs N.B. If you just download the original versions without update 3 you'll have to apply all updates before proceeding so easier to use the latest versions from the get go. 3) Download and install PTVS 2.1 Beta 2 from https://pytools.codeplex.com/releases Note that you need at least PTVS 2.1 Beta and VS Express 2013 with at least Update 2 to be able to install with just free tools. Earlier versions will refuse to install. There may be more intermediate steps of applying updates, but that's par for the Microsoft course. If you try this out in conjunction with a Microsoft Azure account then be sure to also install the Azure SDK. Documentation is at https://pytools.codeplex.com/documentation There's a Django tutorial at http://pytools.codeplex.com/wikipage? title=Django%20Web%20Site/Cloud%20Service%20Tutorial which gives quite a good walkthrough. If I gave the impression that one cannot do development on Windows, that was not my intent. I tried to indicate that the difference was a matter of degree, not impossibility. One of the reasons why so many of the core developers for Python use Linux is that they got frustrated with the speed humps on Windows, the poor out of the box experience for developers (compare what dev tools you get with Windows by default versus what you get on Linux by default), but that might also be somewhat self-selecting: people who are happy with Windows development tend to stick to VB, Java, C, .Net etc. while those who prefer lighter weight more agile environments migrate to Linux. I don't know. But I do know that the existence of good quality Windows development tools for Python is good news for the community, so thank you for mentioning this. So far they seem to have kept a pretty low profile; I suspect largely because until recently PTVS only worked with the pay versions of Visual Studio. -- Duncan Booth -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
On Tue, Aug 5, 2014 at 12:25 PM, Duncan Booth duncan.booth@invalid.invalid wrote: So far they seem to have kept a pretty low profile; I suspect largely because until recently PTVS only worked with the pay versions of Visual Studio. Not true. When it didn't work with the free express versions of VS, it worked with the free Visual Studio Shell (that people have also not heard about :) So there has always been some free way of running PTVS. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
Am 03.08.2014 02:04, schrieb Gregory Ewing: MRAB wrote: RISC OS didn't have a menu bar at the top of each window either; its menus were all pop-up. You didn't have to keep flicking the mouse at all! The main reason for having a menu bar is discoverability. The idea is that you can browse through the menus and get a feel for what commands are potentially available to you. That's not so easy to do when everything is hidden in contextual menus. This was not a problem with the RISC OS menu concept. Only some menu items were depending on the mouse position. Actually the menu items were easier to discover as the non-applicable items were not hidden but greyed out. Regards, Dietmar -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
On Sat, Aug 02, Gregory Ewing wrote: MacOSX doesn't currently have an automatic dependency manager, but if it did, things would still be a lot neater and tidier than they are in Linux or Windows, where what is conceptually a single object (a package) gets split up and its parts scattered around several obscure locations. How does a package differ? Its a package here and there. Just use the correct tools to inspect a package, like 'rpm -qliv $package' to see what a package is all about. Olaf -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
Chris Angelico wrote: The easier target for the mouse argument is valuable ONLY when you use the mouse to access the menu bar. If you use the keyboard (and take advantage of mnemonic letters), it's much more useful to have the menu bar attached to its window. Seems to me that if you use the keyboard for everything, it doesn't matter where the menu bar is. Unless you're talking about the way you can use the keyboard to make menus drop down in Windows... but that's not the way Mac menu shortcuts work. The menu doesn't visually drop down when you invoke a Mac menu command with the keyboard. In the rare case of an app that runs without any windows, incidentally, how do you tell the system that you want that app's menu bar instead of (say) Finder, which comes up when you click on the desktop? In classic MacOS, there was a menu of running applications in the top right corner. In MacOSX, you click on the app's icon in the dock. Also, while completely windowless applications might be rare, it's not rare for an app to have some commands that pertain to the app itself, and not to any particular window, e.g. New. It's more logical for those to appear in a user interface element that's not tied to a window. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
Olaf Hering wrote: How does a package differ? Its a package here and there. Just use the correct tools to inspect a package, like 'rpm -qliv $package' to see what a package is all about. Splitting the package up creates a problem, which you then need to invent a special tool to solve. Seems to me it's simpler not to create the problem in the first place. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
On Sat, Aug 2, 2014 at 9:33 PM, Gregory Ewing greg.ew...@canterbury.ac.nz wrote: Chris Angelico wrote: The easier target for the mouse argument is valuable ONLY when you use the mouse to access the menu bar. If you use the keyboard (and take advantage of mnemonic letters), it's much more useful to have the menu bar attached to its window. Seems to me that if you use the keyboard for everything, it doesn't matter where the menu bar is. Unless you're talking about the way you can use the keyboard to make menus drop down in Windows... but that's not the way Mac menu shortcuts work. The menu doesn't visually drop down when you invoke a Mac menu command with the keyboard. There are two forms of shortcut key. One is a direct-action keystroke that immediately does the same thing that you can do using the menus (say, Ctrl-O is the same as File... Open). With those, the menu is completely unnecessary, except as a list of available keystrokes; it could just as easily be a help screen that says Press Ctrl-O to open a file, so the menu's actual location is quite arbitrary. Downside: There's only so many keystrokes available, and not all of them have memorable meanings. It's usually best to keep this to the few most common functions (opening a file, yes, but not reinterpret this file as ISO-8859-3, unless you make that configurable per user). But the other form, usually described as menu mnemonics, is where you press Alt-F to bring up the _File menu, and then O to activate _Open. (In OS/2, those would be ~File and ~Open; in GTK, the mnemonic is preceded by an underscore. Windows 3.1 used an ampersand, and I believe Win32 does the same thing. It's a little awkward when you have an invoicing screen and you put something like PO Shipping as your customer name, and suddenly Alt-O takes you someplace different. The tilde has the advantage that it doesn't often come up accidentally; the underscore makes sense because the mnemonic is underlined; I have no idea why an ampersand should be used. But I digress.) When you work this way, you aren't grabbing the mouse, so the advantage of not needing to aim so carefully doesn't exist; but if the menu comes up right near where your eyes are already focused, you need to move _them_ less distance - and that means you can focus on the menu more quickly, plus it emphasizes that the visual change (opening the menu) occurred in your current program, not in something else. In Xfce, I can press Alt-F1 to open up the main Applications Menu. That's at the top of the screen (in fact, top left corner), so it gets the throw the mouse benefit; I think I use the mouse with that a lot more often than I use the mouse with a program's own menu, because there's more likely to be something unusual in there. If I install a new piece of software, I have to figure out where it's landed in the menu; but Gypsum's four menus aren't changing unexpectedly, so I'm happy using Alt-O, V to open up Advanced Options. In the rare case of an app that runs without any windows, incidentally, how do you tell the system that you want that app's menu bar instead of (say) Finder, which comes up when you click on the desktop? In classic MacOS, there was a menu of running applications in the top right corner. In MacOSX, you click on the app's icon in the dock. Okay. So you need to first click on something in the dock - that's the thing down the bottom of the screen, right? - and then go all the way up to the top of the screen to use its menu bar. I think I'd much rather have a popup menu - right-click the program's dock icon and get the menu right there where the mouse already is. Oh wait, that requires people to understand more than a single mouse button, so it's contrary to Mac philosophy :) Also, while completely windowless applications might be rare, it's not rare for an app to have some commands that pertain to the app itself, and not to any particular window, e.g. New. It's more logical for those to appear in a user interface element that's not tied to a window. Sure, but those elements are usually rare enough that they can be stuck on the window anyway. Audacity has a New that opens up a new window, and it's slightly surprising the first couple of times, but after that you get used to it. It's not a big enough issue to warrant a change of UI. It is an issue, yes, but I wouldn't warp anything around it any more than I'd warp my UI around the possibility of a user having no screen or keyboard and is using the mouse blind. Sure it happens (I've done it, and I know what I could code to make it easier!), but not often. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
On 2014-08-02 01:00, Gregory Ewing wrote: MRAB wrote: [snip] And don't mention the menu bar across the top, separated from the window to which it belonged. That seems to be a matter of taste. There are some advantages to the menu-bar-at-top model. It's an easier target to hit, because you can just flick the mouse up to the top. It only takes up space once, instead of once per window. It makes it possible for an app to be running without having any windows, and still be able to interact with it. RISC OS didn't have a menu bar at the top of each window either; its menus were all pop-up. You didn't have to keep flicking the mouse at all! -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
In article c42o1nfbrq...@mid.individual.net, Gregory Ewing greg.ew...@canterbury.ac.nz wrote: And don't mention the menu bar across the top, separated from the window to which it belonged. That seems to be a matter of taste. There are some advantages to the menu-bar-at-top model. It's an easier target to hit, because you can just flick the mouse up to the top. It only takes up space once, instead of once per window. It makes it possible for an app to be running without having any windows, and still be able to interact with it. In the old days, we had really small screens (the original Mac had a 9 inch screen with 512 x 342 resolution). Most application windows filled most of the screen, so there really wasn't much difference between per-desktop and per-window menu bars. These days, I'm running multiple 24 inch monitors. The single menu bar paradigm starts to break down in an environment like that. I find I tend to put the few windows I'm actively using near the top of my primary screen (the one with the menu bar), and use the second screen to hold windows I'm not interacting with much. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
MRAB wrote: RISC OS didn't have a menu bar at the top of each window either; its menus were all pop-up. You didn't have to keep flicking the mouse at all! The main reason for having a menu bar is discoverability. The idea is that you can browse through the menus and get a feel for what commands are potentially available to you. That's not so easy to do when everything is hidden in contextual menus. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
Chris Angelico wrote: It's a little awkward when you have an invoicing screen and you put something like PO Shipping as your customer name, and suddenly Alt-O takes you someplace different. An app that did that would be seriously broken, wouldn't it? The should only be interpreted that way in menu items, etc., not in user data. but if the menu comes up right near where your eyes are already focused, you need to move _them_ less distance But putting the menu bar at the top of the window doesn't guarantee that it will be near where your eyes are. If you have a window taking up most of the screen and you're editing something near the bottom, a menu bar at the top of the window is nearly as far away as one at the top of the screen. It would make more sense to pop the menu up near the text cursor. There's no law that says a menu summoned by keystroke has to appear in the same place as one summoned by mouse. In any case, when you use a shortcut sequence, do you really *look* at the menu that comes up, or do you just memorise the appropriate alt-sequence? If you use it frequently, I suspect the latter. If you don't use it very often, having to look away doesn't matter so much. Okay. So you need to first click on something in the dock - that's the thing down the bottom of the screen, right? - and then go all the way up to the top of the screen to use its menu bar. Because of the throw the mouse effect, going *all* the way to the top takes a tiny fraction of a second and is almost effortless. Going any lesser distance takes *much* longer. I think I'd much rather have a popup menu - right-click the program's dock icon and get the menu right there where the mouse already is. Dock icons do have a contextual menu, but it's just a menu of windows. Fitting all of the app's menus in there would require hierarchical menus, which are an abomination you don't want to get me started on. :-) Oh wait, that requires people to understand more than a single mouse button, so it's contrary to Mac philosophy :) The Mac philosophy on that seems to be widely misunderstood. Having only one button on my mouse doesn't mean there's only one thing I can do with it. I can shift-click, option- click, command-click, and nowadays control-click, plus any combination of those. That's enough for anyone to keep in their head, I would have thought. There's also one concrete advantage to using modifiers instead of extra mouse buttons: you can provide feedback by changing the cursor when a modifier is held down. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
Roy Smith wrote: These days, I'm running multiple 24 inch monitors. The single menu bar paradigm starts to break down in an environment like that. Yes, that's an issue. However, even on a large screen, most of my windows are at least half a screen high, putting their tops a considerable distance from where I'm working. And the targeting effect means that a target at the top of the screen is still easier to hit than one half way up. Multiple screens are a problem. Probably what should happen is for the menu bar to move to the screen holding the currently active window, instead of being tied to one primary screen. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
On Sun, Aug 3, 2014 at 10:01 AM, Gregory Ewing greg.ew...@canterbury.ac.nz wrote: Chris Angelico wrote: It's a little awkward when you have an invoicing screen and you put something like PO Shipping as your customer name, and suddenly Alt-O takes you someplace different. An app that did that would be seriously broken, wouldn't it? The should only be interpreted that way in menu items, etc., not in user data. Mnemonics can also be used on text labels, and then they apply to the adjacent field - for instance, you could have _Name followed by an entry field for the Name, and hitting Alt-N will take you to that field. The app I'm talking about used a label to show the customer's name, and we had exactly that issue (although more often with couples' names - for instance, if we had an order from John and Mary Smith, but didn't know their full names, we'd identify them as JM Smith, and voila, Alt-M would take us to... whatever field came after the display of the name (which was the address). To be quite honest, that particular program was a lot more broken than that. But still, it did drive home the value of using ~ instead of for that job. And of course, _ makes enough sense that we can accept its potential for collisions. (Plus it's usually possible to disable underscore interpretation. Or, more properly, you have to explicitly enable their interpretation; in GTK, I have to call set_use_underline(1) before it'll create a mnemonic.) but if the menu comes up right near where your eyes are already focused, you need to move _them_ less distance But putting the menu bar at the top of the window doesn't guarantee that it will be near where your eyes are. If you have a window taking up most of the screen and you're editing something near the bottom, a menu bar at the top of the window is nearly as far away as one at the top of the screen. Putting it at the top of the window cannot possibly make it further away than putting it at the top of the screen. It's potentially going to be a lot closer, but at its worst, it'll be just as bad (modulo the title bar's height). It would make more sense to pop the menu up near the text cursor. There's no law that says a menu summoned by keystroke has to appear in the same place as one summoned by mouse. Sure. And I know of plenty of applications where that's possible. The standard used to be Shift-F10 to bring up a context menu, identical to right-clicking the mouse except that the menu appears at the object you're working on rather than at the mouse's location. These days, you often get something like that on the Menu key (aka the other Windows key, on some keyboards); same result. But that's a context menu, not the pull-down menu; although it's common to have the same menu items on them. In any case, when you use a shortcut sequence, do you really *look* at the menu that comes up, or do you just memorise the appropriate alt-sequence? If you use it frequently, I suspect the latter. If you don't use it very often, having to look away doesn't matter so much. If I'm using Alt-F, O as a command keystroke, then sure, it doesn't make any difference where the menu is. But often I'll pull down a menu, then look at it to figure out what I want to hit. Once my eye has found it, I'll press its underlined letter, so I still don't use the mouse; but I do need it to have a mnemonic, and I need the entire menu to be near my eye. Okay. So you need to first click on something in the dock - that's the thing down the bottom of the screen, right? - and then go all the way up to the top of the screen to use its menu bar. Because of the throw the mouse effect, going *all* the way to the top takes a tiny fraction of a second and is almost effortless. Going any lesser distance takes *much* longer. Right, but it still takes time. Also, if your mouse is set fast enough to go all the way from the bottom to the top of the screen in less than 0.1s, then either your screen is fairly small (may have been true in the past, but is getting pretty rare now), or you seriously penalize any going-less-distance operations. In fact, it becomes self-perpetuating: if you set the mouse fast, it becomes really important to use the edges and avoid the middle, and if applications always use the edges and never the middle, it's really important to set your mouse faster. Conversely, slower mouse settings mean it's easier to be precise with interior movements, while reducing the advantage of the borders. But no matter how fast you set the mouse, it still takes a nonzero time to move it to a specific position. The absolute easiest place to reach is... where you already are. Put the menu there! That's what popup menus are for. I think I'd much rather have a popup menu - right-click the program's dock icon and get the menu right there where the mouse already is. Dock icons do have a contextual menu, but it's just a menu of windows. Fitting all of the app's menus in there
Re: Python and IDEs [was Re: Python 3 is killing Python]
Windows and OS X users, sadly, miss out on the power of an integrated package manager. Thankfully, all actually user-friendly operating systems (MacOS, TOS, RiscOS, probably AmigaOS, MacOS X) spare(d) their users the bottomless cesspit of package management and/or installers. Because on such operating systems, each and every application is an entirely self-contained package that doesn't need any packages or installers to use it. Sincerely, Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
On Fri, Aug 1, 2014 at 9:10 PM, Wolfgang Keller felip...@gmx.net wrote: Thankfully, all actually user-friendly operating systems (MacOS, TOS, RiscOS, probably AmigaOS, MacOS X) spare(d) their users the bottomless cesspit of package management and/or installers. Because on such operating systems, each and every application is an entirely self-contained package that doesn't need any packages or installers to use it. You mean everyone has to reinvent the proverbial wheel AND worry about dependency collisions? Yeah, that's a heavenly thought. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
On Fri, Aug 1, 2014 at 12:22 PM, Chris Angelico ros...@gmail.com wrote: On Fri, Aug 1, 2014 at 9:10 PM, Wolfgang Keller felip...@gmx.net wrote: Thankfully, all actually user-friendly operating systems (MacOS, TOS, RiscOS, probably AmigaOS, MacOS X) spare(d) their users the bottomless cesspit of package management and/or installers. Because on such operating systems, each and every application is an entirely self-contained package that doesn't need any packages or installers to use it. You mean everyone has to reinvent the proverbial wheel AND worry about dependency collisions? Yeah, that's a heavenly thought. Actually, that's not right. RiscOS had and OS X has (I'm sure the others do as well) a concept that is similar to a shared library. But the joy of an application bundle is that installing an application does not scatter its own files all over the file-system, putting configuration files here, binary resources there, library files somewhere else, executable files somewhere else again. The result on one of these other systems is that uninstalling an application is a simple matter of deleting the relevant bundle, which contains all of the resources necessary for that application. All that remains are whatever files exist within user directories. I've worked with both. Quite honestly, I really wish that other operating systems had gone down this route. MS didn't possibly to make it harder to steal software, and Unix...well, *nix has the concept of the distribution that will manage all of this for you. We all know the problems that this causes. N. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
On Sat, Aug 2, 2014 at 12:28 AM, Nicholas Cole nicholas.c...@gmail.com wrote: Actually, that's not right. RiscOS had and OS X has (I'm sure the others do as well) a concept that is similar to a shared library. But the joy of an application bundle is that installing an application does not scatter its own files all over the file-system, putting configuration files here, binary resources there, library files somewhere else, executable files somewhere else again. Shared libraries are a code execution model. The question is, how do you locate them? Let's suppose I write a program that requires the Nettle cryptography library. I can't depend on you already having that on your system; you might, but I can't depend on it. What do I do? Do I include it in my application bundle, or do I have some small record that says and by the way, I need libnettle? Including it in the application bundle means there'll be duplicates everywhere, possibly of slightly different versions. Not including it means there needs to be some kind of system for resolving dependencies, which is exactly what apt-get, yum, pacman, and so on are for. The installer has basically three choices. 1) Install libnettle inside the application directory 2) Install libnettle to some system library directory 3) Don't install libnettle, and demand that someone else (perhaps the user, or the system package manager) install it. Option 1 results in duplications. (Unless one application is allowed to access a library in another application's directory, which is a HORRIBLE mess.) Option 2 is exactly what you're complaining about, scattering files all over the FS. And option 3 is what package managers are for. What are you advocating? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
Am 01.08.2014 13:10, schrieb Wolfgang Keller: Because on such operating systems, each and every application is an entirely self-contained package that doesn't need any packages or installers to use it. For people who have never used such a system it's probably difficult to see the advantages. Besides the easy installation, backup and replication of software the RISC OS way also had the advantage that you were able to organize your applications in folders just like other folders and files. There was no need for separate File and Program managers. MS never got this right. Instead, they tried to fix things later with the start menu and finally the box to type the software name to start it ... One effect was that under DOS/Windows people usually saved their documents in folders per application whereas under RISC OS they were usually grouped by content/project. When it came to usability, RISC OS had many advantages over the other systems, e.g. - real drag'n'drop for loading *and* saving of files/selections - drag'n'drop also for transfer between applications - a standard vector graphics format that all applications supported (and for which an application was provided by default with the OS) - good font display (still better than e.g. MS Windows today) - three mouse buttons for select/menu/adjust - no menu bars - the icon bar for running applications, drives, shares and other resources - consistent, orthogonal logical user interfaces instead of assistants and wizards for each and every task - complete programmers reference manual Regards, Dietmar -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
On 08/01/2014 08:39 AM, Chris Angelico wrote: The installer has basically three choices. 1) Install libnettle inside the application directory 2) Install libnettle to some system library directory 3) Don't install libnettle, and demand that someone else (perhaps the user, or the system package manager) install it. Option 1 results in duplications. (Unless one application is allowed to access a library in another application's directory, which is a HORRIBLE mess.) Option 2 is exactly what you're complaining about, scattering files all over the FS. And option 3 is what package managers are for. What are you advocating? Option 1 also is a huge security hole. A prime example of this was the so-called heartbleed bug. In such a model, each app that distributes openssl in the app bundle has to be updated or it is at risk. This turns out to be a huge vulnerability. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
On 2014-08-01 18:16, Dietmar Schwertberger wrote: Am 01.08.2014 13:10, schrieb Wolfgang Keller: Because on such operating systems, each and every application is an entirely self-contained package that doesn't need any packages or installers to use it. For people who have never used such a system it's probably difficult to see the advantages. Besides the easy installation, backup and replication of software the RISC OS way also had the advantage that you were able to organize your applications in folders just like other folders and files. There was no need for separate File and Program managers. MS never got this right. Instead, they tried to fix things later with the start menu and finally the box to type the software name to start it ... One effect was that under DOS/Windows people usually saved their documents in folders per application whereas under RISC OS they were usually grouped by content/project. When it came to usability, RISC OS had many advantages over the other systems, e.g. - real drag'n'drop for loading *and* saving of files/selections - drag'n'drop also for transfer between applications - a standard vector graphics format that all applications supported (and for which an application was provided by default with the OS) - good font display (still better than e.g. MS Windows today) - three mouse buttons for select/menu/adjust - no menu bars - the icon bar for running applications, drives, shares and other resources - consistent, orthogonal logical user interfaces instead of assistants and wizards for each and every task - complete programmers reference manual I'd heard people say how user-friendly Apple Macs were, but when I got to use one I was somewhat disappointed. When opening files, it used old-fashioned dialog boxes like RISC OS's precursor from several years earlier. In RISC OS, if I had a directory window open, I could save to it with a simple drag-and-drop, but in MacOS, even if I had a directory window open, I had to navigate to the directory in the Save dialog. (OK, not quite true, because of a 3rd-party extension called Click There It Is.) And don't mention the menu bar across the top, separated from the window to which it belonged. Or the way that clicking on any window of an application or the Finder brought not only it but also all of the its siblings to the front. On RISC OS, windows came to the front only when *I* wanted them to. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
Chris Angelico wrote: The installer has basically three choices. 1) Install libnettle inside the application directory 2) Install libnettle to some system library directory 3) Don't install libnettle, and demand that someone else (perhaps the user, or the system package manager) install it. Option 2 is exactly what you're complaining about, scattering files all over the FS. Not really. On MacOSX, if you installed a shared library called libnettle, *all* the files relating to it would be kept in one directory called Nettle.framework (either in /Library/Frameworks or ~/Library/Frameworks depending on whether it's system-wide or for a single user). MacOSX doesn't currently have an automatic dependency manager, but if it did, things would still be a lot neater and tidier than they are in Linux or Windows, where what is conceptually a single object (a package) gets split up and its parts scattered around several obscure locations. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
On Sat, Aug 2, 2014 at 6:22 AM, Michael Torrie torr...@gmail.com wrote: On 08/01/2014 08:39 AM, Chris Angelico wrote: The installer has basically three choices. 1) Install libnettle inside the application directory 2) Install libnettle to some system library directory 3) Don't install libnettle, and demand that someone else (perhaps the user, or the system package manager) install it. Option 1 results in duplications. (Unless one application is allowed to access a library in another application's directory, which is a HORRIBLE mess.) Option 2 is exactly what you're complaining about, scattering files all over the FS. And option 3 is what package managers are for. What are you advocating? Option 1 also is a huge security hole. A prime example of this was the so-called heartbleed bug. In such a model, each app that distributes openssl in the app bundle has to be updated or it is at risk. This turns out to be a huge vulnerability. More generally, that's exactly what Steven said about needing every package to update before you can confidently say it's updated. But that's also the greatest feature of the first option: you can't break this application by upgrading that library, because only upgrading the application (which hopefully will have been tested by the author) will upgrade the library it uses. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
On Sat, Aug 2, 2014 at 9:14 AM, Gregory Ewing greg.ew...@canterbury.ac.nz wrote: Chris Angelico wrote: The installer has basically three choices. 1) Install libnettle inside the application directory 2) Install libnettle to some system library directory 3) Don't install libnettle, and demand that someone else (perhaps the user, or the system package manager) install it. Option 2 is exactly what you're complaining about, scattering files all over the FS. Not really. On MacOSX, if you installed a shared library called libnettle, *all* the files relating to it would be kept in one directory called Nettle.framework (either in /Library/Frameworks or ~/Library/Frameworks depending on whether it's system-wide or for a single user). MacOSX doesn't currently have an automatic dependency manager, but if it did, things would still be a lot neater and tidier than they are in Linux or Windows, where what is conceptually a single object (a package) gets split up and its parts scattered around several obscure locations. That's fine if I explicitly install libnettle - that's the third option. What happens if I install Foo's Cool Chat App, and FCCA uses libnettle to encrypt conversations? Is FCCA allowed to install libnettle into /Library/Frameworks? If so, its files will be split between there and its own app directory. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
MRAB wrote: I'd heard people say how user-friendly Apple Macs were, but when I got to use one I was somewhat disappointed. Well, they were compared to MS-DOS and the like, which was all that was within reach of the general public when the first Mac appeared. RISCOS came along somewhat later. in MacOS, even if I had a directory window open, I had to navigate to the directory in the Save dialog. Yes, that was annoying. It wasn't a problem to begin with, because the original Mac was strictly single-tasking -- you couldn't *have* a directory window and an application open at the same time. And all your files were on floppies in a flat file system -- folders only existed in the Finder's imagination -- so the only real choice to be made when saving a file was which disk do I put it on. When multitasking, hard disks and hierarchical file systems came along, there was an opportunity for a rethink, but it never really happened. Things are somewhat better in MacOSX, where you can drag a folder from a Finder window onto a file dialog to take you there, but there is still more of a distinction between Finder windows and save dialogs than there needs to be. And don't mention the menu bar across the top, separated from the window to which it belonged. That seems to be a matter of taste. There are some advantages to the menu-bar-at-top model. It's an easier target to hit, because you can just flick the mouse up to the top. It only takes up space once, instead of once per window. It makes it possible for an app to be running without having any windows, and still be able to interact with it. Or the way that clicking on any window of an application or the Finder brought not only it but also all of the its siblings to the front. MacOSX has fixed that one, thankfully. Only the window you click comes to the front, now. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
On Sat, Aug 2, 2014 at 10:00 AM, Gregory Ewing greg.ew...@canterbury.ac.nz wrote: MRAB wrote: in MacOS, even if I had a directory window open, I had to navigate to the directory in the Save dialog. Yes, that was annoying. It wasn't a problem to begin with, because the original Mac was strictly single-tasking -- you couldn't *have* a directory window and an application open at the same time. And all your files were on floppies in a flat file system -- folders only existed in the Finder's imagination -- so the only real choice to be made when saving a file was which disk do I put it on. Okay, so it was like DOS 1.0... When multitasking, hard disks and hierarchical file systems came along, there was an opportunity for a rethink, but it never really happened. ... and it didn't get improved when it grew directories like DOS 2.0 did. It's like how the default DOS prompt is actually $N$G when $P$G is a lot more useful, except that changing the default prompt is pretty easy and applies globally (not to mention that you might well want to enhance the prompt beyond just $P$G). And don't mention the menu bar across the top, separated from the window to which it belonged. That seems to be a matter of taste. There are some advantages to the menu-bar-at-top model. It's an easier target to hit, because you can just flick the mouse up to the top. It only takes up space once, instead of once per window. It makes it possible for an app to be running without having any windows, and still be able to interact with it. Downside: It separates (graphically and logically) a window from its menu bar. The easier target for the mouse argument is valuable ONLY when you use the mouse to access the menu bar. If you use the keyboard (and take advantage of mnemonic letters), it's much more useful to have the menu bar attached to its window. In the rare case of an app that runs without any windows, incidentally, how do you tell the system that you want that app's menu bar instead of (say) Finder, which comes up when you click on the desktop? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
On Sunday, July 20, 2014 9:53:02 AM UTC+8, C.D. Reimer wrote: On 7/19/2014 6:23 PM, Steven D'Aprano wrote: I haven't used Python on Windows much, but when I did use it, I found the standard Python interactive interpreter running under cmd.exe to be bare- bones but usable for testing short snippets. If I recall correctly, it is missing any sort of command history or line editing other than backspace, which I guess it would have been painful to use for extensive interactive work, but when I started using Python on Linux the interactive interpreter had no readline support either so it was just like old times :-) Windows PowerShell supports very basic Linux commands and has a command history. I'm always typing ls for a directory listing when I'm on a Windows machine. The regular command line would throw a DOS fit. PowerShell lets me get away with it. http://en.wikipedia.org/wiki/Windows_PowerShell#Comparison_of_cmdlets_with_similar_commands I prefer working on my vintage 2006 Black MacBook. Alas, the CPU fan is dying and MacBook shuts down after 15 minutes. I'm surprised at how well I was able to set up a equivalent programming environment on Windows. Chris Reimer Well, Python could be used as a scripting language for routine jobs in various Oses. But Python has been designed to be a cross-platform high-level general purpose programming language from the birth. One can be sure that the investing in most of the programming concepts and skills in Python 2.XX is still valid in Python 3.XX. Forget those non-investing imitators' flase spamming claims. -- https://mail.python.org/mailman/listinfo/python-list
Python and IDEs [was Re: Python 3 is killing Python]
Earlier, I mentioned a considerable number of IDEs which are available for Python, including: PyDev, Eric, Komodo, PyCharm, WingIDE, SPE, Ninja-IDE, Geany, IEP, Spyder, Boa Constructor, PyScripter, NetBeans, Emacs, KDevelop, and BlackAdder. https://wiki.python.org/moin/IntegratedDevelopmentEnvironments There is also IDLE, which is part of the standard Python installation, as well as my preference: Unix/Linux as an IDE. http://blog.sanctum.geek.nz/series/unix-as-ide/ http://michaelochurch.wordpress.com/2013/01/09/ide-culture-vs-unix-philosophy/ Some people ask: How many of those quality IDEs ship with Python? Most don't, of course, since they are third-party tools. Not that it matters: it's 2014, not 1974, and anyone in the developed world interested in computer programming has easy access to the information superhighway sometimes know as the Internet. (Many people in developing nations also have access to the Internet, and those who don't probably have bigger problems to worry about.) With the Internet, most of these IDEs are normally just a few clicks away. People using Linux will generally find that they can install some of these IDEs using their package manager. For example, Red Hat Linux based systems such on Centos or Fedora can use the yum package manager, e.g.: yum install geany geany-plugins while Debian and Ubuntu based systems (such as Mint) can use apt-get or aptitude, e.g.: aptitude install eric apt-get install spe Of course, most Linux distros include a GUI front-end to their package manager, but frankly if you're programming on Linux and you're unwilling to use the command line, you're making life harder for yourself than it need be. Windows and OS X users, sadly, miss out on the power of an integrated package manager. OS X have a couple of third-party packaging systems, MacPorts and Homebrew: http://www.macports.org/ http://brew.sh/ Unfortunately, software development on Windows is something of a ghetto, compared to the wide range of free tools available for Linux. Outside of a few oases like Microsoft's own commercial development tools, it's hard to do development on Windows. Hard, but not impossible, of course, and there are quite a few resources available for the Windows user willing to download installers from the Internet. For Python users, the IDEs from Wingware and Activestate are notable: https://wingware.com/ http://komodoide.com/ Some people are under the impression that IDEs are mostly or even solely for the benefit of newbies or n00bs. That's a gross misunderstanding of the situation: the average newbie is likely to be happy writing code using Notepad, or whatever bare-bones text editor they're used to, and may not even know what an IDE is. It's those with some experience in programming (particularly in the Java and Visual Basic worlds) who are more likely to expect an IDE. Another patronising view is that those who are new to programming are automatically too incompetent or ignorant to download or install an IDE without hand-holding. Even if that were the case, there is no shortage of hand-holding available on the Internet, with dozens or hundreds of forums, mailing lists, tutorial, videos and blogs offering to help. (It is undeniable that the quality of these is *extremely* variable, but that's another story.) This is the Internet generation, if software has a downloadable installer, or can be installed using a package manager, most people can deal with it, and those who can't have many opportunities to learn. (It's probably a bit much to expect the average newbie to install software from source, especially on Windows which doesn't come with much in the way of compilers and other development tools, but still, it has to be said that if you're hoping to become a programmer, installing software from source is one of the skills you should learn.) So why does Python ship with IDLE? It's not because Python requires an IDE, or that newbies need one, or that there aren't alternatives. The biggest reason for Python shipping with an IDE is not that people are unable to install alternatives, but that a lot of people are *prohibited* from doing so. For those of us who have control over our computing environment, it's all too easy to forget that a lot of people (e.g. students using school computers, or people in corporate environments where the desktops are locked down to a standard operating environment) aren't able to install the IDE of their choice. It's relatively easy to get Python itself approved -- on many systems, Python comes pre-installed -- but trying to get approval to also install third-party software is difficult or impossible. It is for the sake of those people, people who prefer or require an IDE but don't have the choice to install third-party software, that Python ships with a minimal but usable IDE. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
On 7/19/2014 12:28 AM, Steven D'Aprano wrote: Earlier, I mentioned a considerable number of IDEs which are available for Python, including: I prefer to use Notepad++ (Windows) and TextWrangler (Mac). Text editors with code highlighting can get the job done as well, especially if the project is modest and doesn't require version control. Chris Reimer -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
On 7/19/2014 3:28 AM, Steven D'Aprano wrote: So why does Python ship with IDLE? On Windows the Idle shell is needed for sensible interactive use. For simply editing a Python file, running it, and fixing it, the Idle editor seems *about* as good as anything. It's not because Python requires an IDE, or that newbies need one, or that there aren't alternatives. The biggest reason for Python shipping with an IDE is not that people are unable to install alternatives, but that a lot of people are *prohibited* from doing so. This is true, but I think it understates the case. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
On 20 July 2014 04:08, C.D. Reimer ch...@cdreimer.com wrote: On 7/19/2014 12:28 AM, Steven D'Aprano wrote: Earlier, I mentioned a considerable number of IDEs which are available for Python, including: I prefer to use Notepad++ (Windows) and TextWrangler (Mac). Text editors with code highlighting can get the job done as well, especially if the project is modest and doesn't require version control. IMO there is no project so modest that it doesn't require version control. Especially since version control is as simple as: cd project hg init hg add hg commit FWIW I also don't find a need for an IDE for Python - I'm quite happy using EditPlus (which I preferred enough to other alternatives on Windows to pay for many years ago). Tim Delaney -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
On Sun, Jul 20, 2014 at 7:50 AM, Tim Delaney timothy.c.dela...@gmail.com wrote: IMO there is no project so modest that it doesn't require version control. Especially since version control is as simple as: cd project hg init hg add hg commit That said, though, there are some projects so modest they don't require dedicated repositories. I have a repo called shed - it's a collection of random tools that I've put together, no more logical grouping exists. Generally each one is a single file, although I have a couple of related ones in there. (Code at https://github.com/Rosuav/shed if anyone's curious.) If I have an idea for a program that doesn't really merit a full repo, I'll just save it into shed. Keeps the where did I put that, what did I call that to a minimum :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
On 20 July 2014 09:19, Chris Angelico ros...@gmail.com wrote: On Sun, Jul 20, 2014 at 7:50 AM, Tim Delaney timothy.c.dela...@gmail.com wrote: IMO there is no project so modest that it doesn't require version control. Especially since version control is as simple as: cd project hg init hg add hg commit That said, though, there are some projects so modest they don't require dedicated repositories. I have a repo called shed - it's a collection of random tools that I've put together, no more logical grouping exists. Agreed. I have a utils one - but I do like shed and think I'm going to rename :) The main thing is that versioning should be automatic now - it's almost free, and the benefits are huge because even trivial scripts end up evolving. Tim Delaney -- https://mail.python.org/mailman/listinfo/python-list
Repo/directory names (was Re: Python and IDEs [was Re: Python 3 is killing Python])
On Sun, Jul 20, 2014 at 10:41 AM, Tim Delaney timothy.c.dela...@gmail.com wrote: On 20 July 2014 09:19, Chris Angelico ros...@gmail.com wrote: That said, though, there are some projects so modest they don't require dedicated repositories. I have a repo called shed - it's a collection of random tools that I've put together, no more logical grouping exists. Agreed. I have a utils one - but I do like shed and think I'm going to rename :) I first met that name on our old DOS and OS/2 systems, set up by my Dad. It was a directory on whichever drive was appropriate (exactly one per installation - we wouldn't risk a network dependency here), and had programs that would probably go in /usr/bin or /usr/local/bin on a Unix system. Part of setting up a new OS/2 installation was always copying E:\SHED (the network drive) to D:\SHED, and putting D:\SHED\NPSWPS\NPSWPS.EXE into Startup. (NPS WPS Enhancer, awesome program. If you have OS/2, get it. What, you don't have OS/2 anywhere? What a surprise.) Other people had, for instance, a C:\BELFRY (best place to have BATs, you know), or other such names. What's your favorite directory/repository name for a concretion of ... random stuff? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
On 7/19/2014 5:41 PM, Tim Delaney wrote: The main thing is that versioning should be automatic now - it's almost free, and the benefits are huge because even trivial scripts end up evolving. I keep my modest Python scripts in a Dropbox directory and run a weekly Python script to zip up the Dropbox directory for safekeeping on the home file server and Microsoft OneDrive. If I really need a recent copy of a script, Time Machine on the Mac should have a copy from the Drop Box folder. The only time I use version control is when I have a big project with many moving parts and/or I'm publishing software for other people to use. Chris Reimer -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
On Sat, 19 Jul 2014 14:31:10 -0400, Terry Reedy wrote: On 7/19/2014 3:28 AM, Steven D'Aprano wrote: So why does Python ship with IDLE? On Windows the Idle shell is needed for sensible interactive use. One might say that *some* IDE is needed, but Idle itself isn't compulsory :-) It also depends on what you consider sensible. I haven't used Python on Windows much, but when I did use it, I found the standard Python interactive interpreter running under cmd.exe to be bare- bones but usable for testing short snippets. If I recall correctly, it is missing any sort of command history or line editing other than backspace, which I guess it would have been painful to use for extensive interactive work, but when I started using Python on Linux the interactive interpreter had no readline support either so it was just like old times :-) -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
On Sun, Jul 20, 2014 at 11:23 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: If I recall correctly, it [Python under cmd.exe] is missing any sort of command history or line editing other than backspace, Not quite, but it has some extreme oddities. I'd have to call them features because I can't imagine them to be bugs, but they're very surprising... like how you can recall something, but if you enter it without any editing, your current recall position is retained. This means you can re-enter a series of lines by recalling the first and then pressing Down, Enter for each subsequent line (it's a feature!), but it means that any usage where the lines are truly independent will start getting very awkward. In contrast, Idle recalls entire suites, rather than individual lines, which (IMO) makes it superior to a readline-based interface. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
On 7/19/2014 6:23 PM, Steven D'Aprano wrote: I haven't used Python on Windows much, but when I did use it, I found the standard Python interactive interpreter running under cmd.exe to be bare- bones but usable for testing short snippets. If I recall correctly, it is missing any sort of command history or line editing other than backspace, which I guess it would have been painful to use for extensive interactive work, but when I started using Python on Linux the interactive interpreter had no readline support either so it was just like old times :-) Windows PowerShell supports very basic Linux commands and has a command history. I'm always typing ls for a directory listing when I'm on a Windows machine. The regular command line would throw a DOS fit. PowerShell lets me get away with it. http://en.wikipedia.org/wiki/Windows_PowerShell#Comparison_of_cmdlets_with_similar_commands I prefer working on my vintage 2006 Black MacBook. Alas, the CPU fan is dying and MacBook shuts down after 15 minutes. I'm surprised at how well I was able to set up a equivalent programming environment on Windows. Chris Reimer -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
On Sat, Jul 19, 2014 at 12:28 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: For Python users, the IDEs from Wingware and Activestate are notable: https://wingware.com/ http://komodoide.com/ I would say that since PyCharm (https://www.jetbrains.com/pycharm/) now has a free Community Edition it is an even more notable IDE as the above two programs cost $. And as a Windows user, for version control I really like TortoiseHg ( http://tortoisehg.bitbucket.org/) for Mercurial. Likewise I tend to use TortoiseSVN and TortoiseGit rather than the command line. PyCharm even has support for those but I still like right-clicking on folders in Windows Explorer and activating various hg commands from the popup menu. Especially since not every program I write is written in Python :) -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
On 7/19/2014 7:03 PM, TP wrote: I would say that since PyCharm (https://www.jetbrains.com/pycharm/) now has a free Community Edition it is an even more notable IDE as the above two programs cost $. PyCharm look really nice as an IDE. Thanks for the heads up. Chris Reimer -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
On 20 July 2014 11:53, C.D. Reimer ch...@cdreimer.com wrote: On 7/19/2014 6:23 PM, Steven D'Aprano wrote: I haven't used Python on Windows much, but when I did use it, I found the standard Python interactive interpreter running under cmd.exe to be bare- bones but usable for testing short snippets. If I recall correctly, it is missing any sort of command history or line editing other than backspace, which I guess it would have been painful to use for extensive interactive work, but when I started using Python on Linux the interactive interpreter had no readline support either so it was just like old times :-) Windows PowerShell supports very basic Linux commands and has a command history. I'm always typing ls for a directory listing when I'm on a Windows machine. The regular command line would throw a DOS fit. PowerShell lets me get away with it. http://en.wikipedia.org/wiki/Windows_PowerShell#Comparison_ of_cmdlets_with_similar_commands I prefer working on my vintage 2006 Black MacBook. Alas, the CPU fan is dying and MacBook shuts down after 15 minutes. I'm surprised at how well I was able to set up a equivalent programming environment on Windows. I advise anyone who works cross-platform to install MSYS on their Windows boxes (for the simplest, most consistent behaviour ignore rxvt and just launch bash -l - i directly). Or use cygwin if you prefer. Tim Delaney -- https://mail.python.org/mailman/listinfo/python-list
Re: Repo/directory names (was Re: Python and IDEs [was Re: Python 3 is killing Python])
Chris Angelico wrote: Other people had, for instance, a C:\BELFRY (best place to have BATs, you know), or other such names. What's your favorite directory/repository name for a concretion of ... random stuff? My project directories typically contain a directory called Attic for putting stuff in that I probably won't use any more, but want to keep just in case. Fortunately, it doesn't have the same space restrictions as its physical namesake. :-) -- Greg -- https://mail.python.org/mailman/listinfo/python-list