Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library
On 11 Jul, 2010, at 19:35, Bill Janssen wrote: Tal Einat talei...@gmail.com wrote: Although several people say that they think having IDLE in the stdlib is important, the fact is that IDLE is considered quite unimportant by most of the Python community. Having IDLE in the stdlib may be convenient for a few people, but most never use it and don't care about it. I think that in its current state, IDLE may still be helpful for learning Python, but it is more likely to drive away users who run into its various quirks and problems. And for experienced Python developers, very few actually use IDLE, and those who do could easily install it if it weren't part of the stdlib. I agree with you on this, Tal. On OS X, this is particularly aggravating, as the Apple-supplied Python doesn't seem to include a working version, and installing MacPython leads to other problems (see, for instance, the thread at http://groups.google.com/group/nltk-users/browse_thread/thread/e14b647243ca5b66). Apple doesn't ship IDLE.app, but does ship the rest of the code. It should be fairly easy to create a small IDLE.app using the python.org source tree that uses /usr/bin/python. Ronald smime.p7s Description: S/MIME cryptographic signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing IDLE from the standard library
What I specifically want right now is Commit Authorization Privilege, especially for IDLE, Not sure who could grant that, but as far as I can: you have it. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing IDLE from the standard library
On Sun, Jul 11, 2010 at 4:53 PM, Steve Holden st...@holdenweb.com wrote:
Stephen Hansen wrote:
On Sat, Jul 10, 2010 at 9:23 PM, Guilherme Polo ggp...@gmail.com
mailto:ggp...@gmail.com wrote:
By never had a problem do you mean using some of the latest
versions
? Here, running idle from a mac terminal and trying to type: print
hi crashes when entering the quotation mark.
Huh? Works fine for me. Python 2.6.1, OSX 10.6.3, intel.
One of the good things about the python-dev community is its commitment
to test-driven development. If you are prepared to define fine as
'successfully runs \'print hello\'' then I guess we should be
perfectly happy about IDLE.
Er, how hostile.
My point is, the poster made an assertion-- that you couldn't do the simple
act as launching idle from a command line, and printing Hi. Maybe they
can't, I have no idea.
I know I can. I know that I have also opened random python files, saved
them, and ran them with IDLE. I don't use IDLE beyond that though: I live in
TextMate on my mac.
My point was not, IDLE is perfect. My point was, You've claimed you can't
even print out a word in IDLE, so its utterly and completely non-functional
-- and that assertion surprises me and I challenge.
I don't define IDLE as fine, because I'm not qualified to speak to its
larger aspects-- as I only rarely use it. But the level of utter brokenness
that the poster I was replying to spoke of, I've never seen. Across multiple
versions of Python, IDLE, and OSX.
From the lurking crowd-- Please don't consider removing IDLE until there
is a compelling replacement ready. It's better to have a limited IDE
that works everywhere (even if in a limited fashion-- people are free to
try out one of the many excellent full-featured Python IDE's out there
after they advance to that point) then not.
1: I refuse to see why we need a compelling replacement for a piece of
software whose performance might be actively deterring people from
taking up the language. [Have you thought about Python? Yeah, but I
tried it {meaning I downloaded some random Python release and tried
IDLE, which by modern standards appears completely lame} and it
sucked. If this is our standard for compelling then it appears the
command-line interpreter is the competition.
The claim that IDLE is actively deterring people from taking up Python is
in my opinion unsupported. I know a lot of people who have and do use it,
and I am personally (in my own experience) unaware of anyone who is actively
deterred from using Python because of it. Therefore, I see no negative, and
only a positive of IDLE's presence-- and so I'd want a compelling
replacement available before that positive was wiped out.
Perhaps your experience is different.
So be it: but -- uh, really, Hostile. I was just sharing my own experience
with using and talking to people who use IDLE. I've found it -- on the mac,
but on other platforms as well -- an adequate but limited sort of IDE. I've
found more issues with it with the people I know who use windows then mac
(in particular, details of when the subprocess runs). But my comment was
simply: it has constantly worked for me in the limited use I make of it, and
I have a positive experience with the people I know that have used it.
If your experience is different, that's fine. Perhaps your experience is
more broad, more compelling, and representative of more people.
But I, personally, would consider it a significant loss if IDLE went the way
of the dodo or a third-party module.
-- Stephen
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing IDLE from the standard library
-On [20100712 08:26], Stephen Hansen (apt.shan...@gmail.com) wrote: But I, personally, would consider it a significant loss if IDLE went the way of the dodo or a third-party module. Why would it be a significant loss if it went the way of a third party module? Clearly right now it's not being maintained as well as the rest of Python. Maybe that's a clear indicator that it's better maintained externally instead of in the main tree. And for what it is worth, I personally never used it beyond one time looking at it in disgust and neither do I know Pythonistas around me that use it. Bpython and ipython do get installed a lot though, even on Windows. And all these people, no matter their proficiency in programming, use an editor or IDE of some sort, but not IDLE. So I would not mourn to see IDLE get moved out of the main repository as I do not see the added value or benefit, not even for training (and since you're going to set up a training environment anyway, it can only be described as lazy if you are adamant on having it included in the base distribution). Just my EUR 0,02. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Born from the Dark, in the black Cloak of Night... ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing IDLE from the standard library
Am 12.07.2010 10:06, schrieb Jeroen Ruigrok van der Werven: -On [20100712 08:26], Stephen Hansen (apt.shan...@gmail.com) wrote: But I, personally, would consider it a significant loss if IDLE went the way of the dodo or a third-party module. Why would it be a significant loss if it went the way of a third party module? Clearly right now it's not being maintained as well as the rest of Python. I start disagreeing here already. It *is* as well maintained as the rest of Python - at least, there are many other parts of Python that get the same attention (or less). IDLE has been working for years, in a certain feature set. It just doesn't need much maintenance, except for updates when the world around it is changing. Maybe that's a clear indicator that it's better maintained externally instead of in the main tree. That's an unfounded theory, at best. Two experiments to pro So I would not mourn to see IDLE get moved out of the main repository as I do not see the added value or benefit Now that's a different issue. You are not using it, fine. Does that mean it should be removed? If we removed all modules that somebody is not using, the standard library would be empty. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library
On Sun, Jul 11 2010, Bruce Sherwood wrote: On the notion that IDLE is fatally flawed and is driving away potential users of Python (to put the statements in their most extreme form): It seems that there are (at least) two very different communities people have in mind. I can appreciate that highly expert programmers may find IDLE insufficient for their needs, and it might even be the case that these people should be advised not to even try IDLE. But I want to stress as strongly as possible that for a very large community of nonexpert users of Python, IDLE has been extremely important and works very well for their purposes. Editing is pretty much like what they're already used to in word processors, which is certainly not the case with professional tools such as vim or Emacs. Particularly on Windows, there is an expectation that a contemporary programming language comes with a GUI. Using the Windows Python shell isn't very satisfactory, largely because of the poor file handling capability in that environment. IDLE provides a simple solution, suitable for beginners as well as experts. It provides one-keystroke save/run in a fresh environment not associated with the GUI. I have run IDLE inside IDLE (though I'm not positive that will work right now). How many IDEs can do that? I've tried to channel Guido, and my general approach has been to provide as much functionality as needed, but to hide the more advanced features to avoid clutter. When the 'experts' need them, they will find them. I'm mystified about the comments that the GUI is ugly. It is minimal. On XP, it looks exactly like an XP window with a simple menubar. Those who haven't looked at it for awhile may not be aware of the recent advances made by Tk in native look and feel. What is ugly? And IDLE is cross-platform. There are perhaps deficiencies on the Mac, but Ron has made good progress. I haven't been able to come up with a Mac yet, so I can't really comment. IDLE works on 2.7 and 3.x. Running IDLE on the trunk is a decent test of Python and tkinter during development. It seems that people who do Scheme write Scheme implementations, while people who do Python write IDEs :-) Usually, they keep adding features and buttons until it looks like Eclipse. That's fine. But why turn IDLE into another example of that style and diminish diversity in doing so? On a netbook, screen space is at a premium, and a simple interface has advantages. There are many IDEs listed on the wiki if people are looking for the more complex style, but I'd suggest that they aren't appropriate for beginners. And by beginners, I include elementary school students. IDLE works with extensions. Plug-ins, if you will. The Option dialog needs enhancement to support extension selection, and I believe there is a patch to do that. More extensions would be a good thing. The .idlerc directory determines IDLE's configuration, including the help source urls available on the Help menu. By downloading .idlerc or via indirection, a student environment can be set up including the day's lesson and which extensions are activated. Call tips and method name completion can be hidden by increasing the time delay before they pop up. That said, yes, there are some significant deficiencies with the current IDLE (which is why there's a VIDLE, for instance). I'm very glad to hear from Martin that Guilherme is free to commit his important bug fixes and improvements. I'm afraid that neither Guilherme nor I understood the procedures and thought that we had to wait for others to act. Tal has made a couple of comments about not being able to run multiple IDLEs at the same time, and he mentions http://bugs.python.org/issue1529142 This bug has been closed for over a year, and you can run as many IDLEs as you like. You can run 2.7 and 3.x at the same time. I would have expected Tal to know that. Also, the current right click edit action on Windows is to only open an edit window; no shell. And it uses the subprocess! So, some of the comments on this thread are not up to date. The reason that bug languished for two years was because first, it was a bit of a hack, and second, Windows was problematic in that it reused sockets and often left zombie subprocesses behind which couldn't be killed except with the task manager. This causes real problems with students - they lose confidence in the tool. Scherer and Weeble put together a patch using ephemeral ports which nailed the problem, and I checked it in right away and forward/backported it. As I recollect, much of what Scherer did in VIDLE related to running multiple IDLE copies. For that reason, the VIDLE changes have to be evaluated carefully to determine what has already been incorporated. I believe I added a couple of his smaller changes, also. Bruce, speaking of Dave Scherer, we've been trying to get a Python Contributor Agreement from him. Is that something you can help us with? -- KBK
Re: [Python-Dev] Removing IDLE from the standard library
Jesse Noller jnol...@gmail.com wrote: On Sun, Jul 11, 2010 at 8:22 PM, geremy condra debat...@gmail.com wrote: (This seems to me like an area where a judicious application of PSF funds might help; if every single bug were actively triaged and responded to, even if it weren't reviewed, and patch contributors were directed to take specific steps to elicit a response or a review, the fact that patch reviews take a while might not be so bad.) The operative word being judicious. It is not obvious who should get funded, and for what tasks. Some specific issues (like email in 3.x) are large enough that they can be the sole focus of a fund grant. But I'm not sure triaging can apply. I'm mulling over starting a monthly triage sprint under the auspices of Jesse Noeller's PSF sponsored sprints in the hopes of making this a little more fun. I'd appreciate comments on the idea. [responding to Geremy] I'm with Georg on this. If triaging needs a monetary incentive because it is tedious work, so does committing. A lot of the abandoned issues aren't very glamorous either. Also, from the work that Mark Lawrence has been doing on the tracker in the past few weeks, it's apparent that a dedicated person can achieve a lot without pay. Due to his tracker reshuffling, many issues got closed, several bug reporters responded after years, etc. Thanks, Mark! Stefan Krah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing IDLE from the standard library
On Mon, Jul 12 2010, Jeroen Ruigrok van der Werven wrote: -On [20100712 08:26], Stephen Hansen (apt.shan...@gmail.com) wrote: But I, personally, would consider it a significant loss if IDLE went the way of the dodo or a third-party module. Why would it be a significant loss if it went the way of a third party module? Clearly right now it's not being maintained as well as the rest of Python. Maybe that's a clear indicator that it's better maintained externally instead of in the main tree. And for what it is worth, I personally never used it beyond one time looking at it in disgust Apparently you haven't looked recently. If you'd describe specifically what is disgusting on the current version, perhaps we can do something about it. and neither do I know Pythonistas around me that use it. Bpython and ipython do get installed a lot though, even on Windows. And all these people, no matter their proficiency in programming, use an editor or IDE of some sort, but not IDLE. Well, I use it :-) I used to use emacs to develop IDLE, but as IDLE became more capable, I stopped using emacs (except to fix IDLE when I break it completely :) When I find something I really miss, I add it. But I don't just add features to check off a list. Search on the status bar and jump to definition are next. So I would not mourn to see IDLE get moved out of the main repository as I do not see the added value or benefit, not even for training (and since you're going to set up a training environment anyway, it can only be described as lazy if you are adamant on having it included in the base distribution). On Windows, IDLE opens when you right click / edit a .py. Very useful. On linux, the packagers generally split IDLE off into a separate package so Python can be installed without Tcl/Tk. That doesn't mean it should be removed from the tarball; their package build tools build several packages from the single tarball at the same time. Second guessing them by having two tarballs just increases the work for everyone. This could be done on Windows, but then you wouldn't have a GUI to use right after running the Python installer. Minimal installations are not so important on Windows. -- KBK ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing IDLE from the standard library
On Mon, 12 Jul 2010 05:20:49 -0400 Kurt B. Kaiser k...@shore.net wrote: I'm mystified about the comments that the GUI is ugly. It is minimal. On XP, it looks exactly like an XP window with a simple menubar. Those who haven't looked at it for awhile may not be aware of the recent advances made by Tk in native look and feel. What is ugly? Ok, I've just tried IDLE (on py3k) for the first time in years. Under Linux, the look is ugly and outdated; it uses some kind of Motif-like widgets. Usability is inconsistent with the rest of the desktop, and looks generally subpar (for example, you have to click on a menu to open it; the file open dialog is antiquated and doesn't allow me to use keyboard shortcuts). The editor looks decent, though there doesn't seem to be a simple (e.g. Shift+Tab) way of unindenting a block of code. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing IDLE from the standard library
After a few keystrokes in the interactive interpreter, I got the following traceback: Traceback (most recent call last): File Lib/idlelib/idle.py, line 11, in module idlelib.PyShell.main() File /home/antoine/py3k/__svn__/Lib/idlelib/PyShell.py, line 1420, in main root.mainloop() File /home/antoine/py3k/__svn__/Lib/tkinter/__init__.py, line 1009, in mainloop self.tk.mainloop(n) UnicodeDecodeError: 'utf8' codec can't decode byte 0xc0 in position 0: invalid start byte The keystrokes were ['d', 'i', Ctrl+Space], which briefly displayed the completion popup before crashing. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing IDLE from the standard library
On Mon, Jul 12, 2010 at 5:31 AM, Stefan Krah ste...@bytereef.org wrote: Jesse Noller jnol...@gmail.com wrote: On Sun, Jul 11, 2010 at 8:22 PM, geremy condra debat...@gmail.com wrote: (This seems to me like an area where a judicious application of PSF funds might help; if every single bug were actively triaged and responded to, even if it weren't reviewed, and patch contributors were directed to take specific steps to elicit a response or a review, the fact that patch reviews take a while might not be so bad.) The operative word being judicious. It is not obvious who should get funded, and for what tasks. Some specific issues (like email in 3.x) are large enough that they can be the sole focus of a fund grant. But I'm not sure triaging can apply. I'm mulling over starting a monthly triage sprint under the auspices of Jesse Noeller's PSF sponsored sprints in the hopes of making this a little more fun. I'd appreciate comments on the idea. [responding to Geremy] I'm with Georg on this. If triaging needs a monetary incentive because it is tedious work, so does committing. A lot of the abandoned issues aren't very glamorous either. I'm not sure what you mean by monetary incentive. I was considering handing a t-shirt or beer token to the most productive sprinters, but that's about the limit of it, and I suspect that would come out of my pocket. I'd also emphasize that I am exactly as far as I stated on this: I'm mulling it over and asking for feedback. If it turns out that there are other things that python-dev feels are more necessary but similarly unglamorous, then I'll think about doing that instead. Also, from the work that Mark Lawrence has been doing on the tracker in the past few weeks, it's apparent that a dedicated person can achieve a lot without pay. Indeed, although I'm again unsure what pay has to do with this. Due to his tracker reshuffling, many issues got closed, several bug reporters responded after years, etc. Thanks, Mark! +1 Geremy Condra ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing IDLE from the standard library
On 12/07/2010 2.56, Martin v. Löwis wrote: As for assigning bugs, I've been told to use the maintainer.rst list, so either the list is wrong, or I've had finger problems. If it's the latter I again say sorry. I see. What copy have you been using specifically? I think I need to remove myself from these lists. Regards, Martin Indeed it's not clear if the names that appear in the maintainers.rst list are supposed to be added only to the nosy list or if it's possible to add them to the assigned to field too. A way to avoid confusion is to mark the names that should be added to the Assigned to field with a '*', and add the others to the nosy list only. E.g.: unicodedata loewis, lemburg, ezio.melotti* would mean You can add loewis and lemburg to the nosy list and assign the issue to ezio.melotti. Otherwise we can just decide that those names should just be added to the nosy list and let them assign the issue to themselves if they want to fix it. Best Regards, Ezio Melotti ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library
Hi Kurt, I'm glad you've joined this discussion. My point is that whatever the reason, for the past five years (at least) nearly every issue related to IDLE has taken years to be resolved, and many have still not been resolved. As a result the current state of IDLE is quite poor. To be perfectly clear, I'm am not blaming anyone for this. I just think this is something the development community should be more aware of and decide how to deal with. On Mon, Jul 12, 2010 at 12:20 PM, Kurt B. Kaiser wrote: Particularly on Windows, there is an expectation that a contemporary programming language comes with a GUI. Using the Windows Python shell isn't very satisfactory, largely because of the poor file handling capability in that environment. IDLE provides a simple solution, suitable for beginners as well as experts. It provides one-keystroke save/run in a fresh environment not associated with the GUI. I have run IDLE inside IDLE (though I'm not positive that will work right now). How many IDEs can do that? [snip] On a netbook, screen space is at a premium, and a simple interface has advantages. There are many IDEs listed on the wiki if people are looking for the more complex style, but I'd suggest that they aren't appropriate for beginners. And by beginners, I include elementary school students. I agree that IDLE is great specifically thanks to its simplicity, and should be kept simple. I think something like IDLE can be great for teaching and learning Python (and other uses as well) and has a place in the stdlib. I'm simply not sure if IDLE in its current state is fit for this purpose. I'm mystified about the comments that the GUI is ugly. It is minimal. On XP, it looks exactly like an XP window with a simple menubar. Those who haven't looked at it for awhile may not be aware of the recent advances made by Tk in native look and feel. What is ugly? IDLE may be somewhat close to looking like a native application, but it is not quite there. Some examples: * Users expect to be able to copy/paste using the mouse via the right-click context menu, which is impossible in IDLE (in both shell and editor windows). * The selection jumping to the end of the line unexpectedly doesn't happen in any other GUI text editor. * The config dialog looks archaic. As for the native lookfeel, this has still not been integrated into IDLE, though it seems now it will happen soon. This has already been discussed here. IDLE works with extensions. Plug-ins, if you will. The Option dialog needs enhancement to support extension selection, and I believe there is a patch to do that. More extensions would be a good thing. IDLE extensions are a pain to work with and badly supported. Installing an extension requires manually placing it in the idlelib directory and manually adding its config options to a certain text file in that directory. In practice nobody ever takes the effort to try installing an IDLE extension, such as my SearchBar extension. There has been discussion on improving this situation, but again this never actually happened. I tried to move this along with a patch which adds an extension config dialog, which has been sitting in the issue tracker ignored for two years. Tal has made a couple of comments about not being able to run multiple IDLEs at the same time, and he mentions http://bugs.python.org/issue1529142 This bug has been closed for over a year, and you can run as many IDLEs as you like. You can run 2.7 and 3.x at the same time. I would have expected Tal to know that. I clearly mentioned that as an example of a fix for a major usability issue which took three years to resolve after a workaround was first posted. It is worth noting that most people still don't use the versions of Python (and IDLE) where this fix has been integrated. The reason that bug languished for two years was because first, it was a bit of a hack, and second, Windows was problematic in that it reused sockets and often left zombie subprocesses behind which couldn't be killed except with the task manager. This causes real problems with students - they lose confidence in the tool. Scherer and Weeble put together a patch using ephemeral ports which nailed the problem, and I checked it in right away and forward/backported it. True, but it took three whole years for this to happen. And this is for a glaring, annoying and limiting issue that nearly every user of IDLE has encountered. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library
On Mon, Jul 12, 2010 at 1:41 AM, Martin v. Löwis mar...@v.loewis.de wrote: My point is that I don't think I am exaggerating IDLE's flaws. I'm not saying that it is no longer usable or useful, but I am saying that its current state is not okay. So can you produce a list of patches that you think can be accepted as-is? That's not a fair question! There have been several such patches, but most will likely need revision since they have been sitting around untouched for so long. And there would have been many more patches if the existing ones would have been addressed. Getting a few current patches accepted is not the reason I posted here. - Tal Einat ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library
On Mon, Jul 12, 2010 at 1:44 AM, Martin v. Löwis mar...@v.loewis.de wrote: FWIW this is why I started IDLE-Spoon (well, continued Noam Raphael's project of the same name, in a sense). The idea was to have a fork of IDLE with new features which need to be tried out by beta testers to iron out all of the glitches before making it into the main version, like IDLE-fork back in the beginning of the decade. However I have utterly failed in promoting this project and getting beta testers on board, at least partially due to the lack of interest from the community (and admittedly my lack of PR skills). I think such a thing must inherently fail - precisely for these reasons. It's much better to release proposed new features along with Python, and wait for feedback. Users won't start trying things out until after the release. This is a general problem, and lead Barry Warsaw to believe that release candidates are an utter waste of time. That's debatable, and I disagree. IDLE-fork was a great success, for example. If IDLE actually had many users today, certainly some of them would be interested in trying out a version with usability fixes and improvements. Waiting for a new release of Python can take over a year. Furthermore, backwards compatibility issues and support by third party libraries can delay migration to a newer version of Python even further. - Tal Einat ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library
Kurt B. Kaiser: I'm mystified about the comments that the GUI is ugly. It is minimal. On XP, it looks exactly like an XP window with a simple menubar. Those who haven't looked at it for awhile may not be aware of the recent advances made by Tk in native look and feel. What is ugly? While Tk has improved at emulating native appearance, there are still many differences. On the main editing screen of IDLE, the most noticeable issue is that there is no horizontal scroll bar even though the text will move left when you move the caret beyond the rightmost visible character. The scrollbar and status bar have an appearance that looks to be from Windows 2000, not Windows XP and there is no resizing gripper on the right side of the status bar. The tear off menus are ugly as well as being non-standard on all three major platforms. Use the Configure IDLE... and an idle dialog appears that also looks to be from Windows 2000. I know Tk can do better than this as Git Gui (the Tk (8.5.8) program I use most often) at least shows XP themed buttons, scrollbars and other controls. However, the idle dialog (as well as Git Gui) shows the largest remaining problem for Tk user interfaces: keyboard navigation. When the idle dialog opens, try doing anything with the keyboard. Chances are nothing will happen. If you press Tab 16 times (yes, 16!) a focus rectangle will finally show on the Bold check box. Another Tab takes you to the Indentation Width slider. After that you don't see the focus until it wraps around to Bold again. The Enter key doesn't trigger OK and the Escape key doesn't let you escape. The Find and Replace dialogs are better as focus works as do Enter and Escape but none of the buttons have mnemonics. This may all sound like picking nits but details and consistency are important in user interfaces and this is just looking at the most easily discovered problems. Neil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing IDLE from the standard library
geremy condra debat...@gmail.com wrote: On Mon, Jul 12, 2010 at 5:31 AM, Stefan Krah ste...@bytereef.org wrote: Jesse Noller jnol...@gmail.com wrote: On Sun, Jul 11, 2010 at 8:22 PM, geremy condra debat...@gmail.com wrote: (This seems to me like an area where a judicious application of PSF funds might help; if every single bug were actively triaged and responded to, even if it weren't reviewed, and patch contributors were directed to take specific steps to elicit a response or a review, the fact that patch reviews take a while might not be so bad.) The operative word being judicious. It is not obvious who should get funded, and for what tasks. Some specific issues (like email in 3.x) are large enough that they can be the sole focus of a fund grant. But I'm not sure triaging can apply. I'm mulling over starting a monthly triage sprint under the auspices of Jesse Noeller's PSF sponsored sprints in the hopes of making this a little more fun. I'd appreciate comments on the idea. [responding to Geremy] I'm with Georg on this. If triaging needs a monetary incentive because it is tedious work, so does committing. A lot of the abandoned issues aren't very glamorous either. I'm not sure what you mean by monetary incentive. I was considering handing a t-shirt or beer token to the most productive sprinters, but that's about the limit of it, and I suspect that would come out of my pocket. Sorry for misinterpreting your intentions. I was reading this in the context of judicious application of PSF funds. What you are describing is of course quite judicious. To me, PSF sponsored sounded like there would be a lot more money involved. Stefan Krah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing IDLE from the standard library
On Mon, Jul 12, 2010 at 7:17 AM, Stefan Krah ste...@bytereef.org wrote: geremy condra debat...@gmail.com wrote: On Mon, Jul 12, 2010 at 5:31 AM, Stefan Krah ste...@bytereef.org wrote: Jesse Noller jnol...@gmail.com wrote: On Sun, Jul 11, 2010 at 8:22 PM, geremy condra debat...@gmail.com wrote: (This seems to me like an area where a judicious application of PSF funds might help; if every single bug were actively triaged and responded to, even if it weren't reviewed, and patch contributors were directed to take specific steps to elicit a response or a review, the fact that patch reviews take a while might not be so bad.) The operative word being judicious. It is not obvious who should get funded, and for what tasks. Some specific issues (like email in 3.x) are large enough that they can be the sole focus of a fund grant. But I'm not sure triaging can apply. I'm mulling over starting a monthly triage sprint under the auspices of Jesse Noeller's PSF sponsored sprints in the hopes of making this a little more fun. I'd appreciate comments on the idea. [responding to Geremy] I'm with Georg on this. If triaging needs a monetary incentive because it is tedious work, so does committing. A lot of the abandoned issues aren't very glamorous either. I'm not sure what you mean by monetary incentive. I was considering handing a t-shirt or beer token to the most productive sprinters, but that's about the limit of it, and I suspect that would come out of my pocket. Sorry for misinterpreting your intentions. I was reading this in the context of judicious application of PSF funds. What you are describing is of course quite judicious. To me, PSF sponsored sounded like there would be a lot more money involved. Nope, as long as I can keep the costs under $100 or so (I'm the worlds biggest cheapskate, shouldn't be a problem) I doubt I'll ask for anything except that people promote and attend. Geremy Condra ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] maintainers.rst enhancement (was: Removing IDLE from the standard library)
On Mon, 12 Jul 2010 13:39:15 +0300, Ezio Melotti ezio.melo...@gmail.com wrote: On 12/07/2010 2.56, Martin v. L=F6wis wrote: As for assigning bugs, I've been told to use the maintainer.rst list, so either the list is wrong, or I've had finger problems. If it's the latter I again say sorry. I see. What copy have you been using specifically? I think I need to remove myself from these lists. Regards, Martin Indeed it's not clear if the names that appear in the maintainers.rst list are supposed to be added only to the nosy list or if it's possible to add them to the assigned to field too. A way to avoid confusion is to mark the names that should be added to the Assigned to field with a '*', and add the others to the nosy list only. Actually it is clear. The text at the top of the file says the names are there to be added to the nosy list. It does not mention assigning bugs. This was actually discussed at least briefly when the file was created. We probably should have included *don't* assign tickets, nosy the maintainer and let them pick it up if they want to in the intro text. E.g.: unicodedata loewis, lemburg, ezio.melotti* would mean You can add loewis and lemburg to the nosy list and assign the issue to ezio.melotti. Otherwise we can just decide that those I like this suggestion, but obviously we need to let those developers who wish to do this star themselves. If there are no objections to this change to maintainers.rst, I'll start the ball rolling by marking myself for email, and adjusting the introductory text accordingly. -- R. David Murray www.bitdance.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] maintainers.rst enhancement
On 12/07/2010 12:42, R. David Murray wrote: [snip...] E.g.: unicodedata loewis, lemburg, ezio.melotti* would mean You can add loewis and lemburg to the nosy list and assign the issue to ezio.melotti. Otherwise we can just decide that those I like this suggestion, but obviously we need to let those developers who wish to do this star themselves. If there are no objections to this change to maintainers.rst, I'll start the ball rolling by marking myself for email, and adjusting the introductory text accordingly. Sounds good to me. You can leave me starred for unittest. Michael -- R. David Murray www.bitdance.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] maintainers.rst enhancement (was: Removing IDLE from the standard library)
On Mon, 12 Jul 2010 01:07:54 +0100, Mark Lawrence breamore...@yahoo.co.uk wrote: I've been working from this:- http://svn.python.org/view/*checkout*/python/branches/py3k/Misc/maintainers.rst It strikes me as being so sadly outdated that it's getting less than useless, or I assume that it's the same old case of not enough volunteers? Why did I bother. :) As someone else mentioned, it is relatively new. It was created partially in the hopes that the huge gaps in coverage would encourage people to step forward and volunteer to be maintainers, and this has indeed been happening slowly. For example, Alexander Belopolsky recently became a committer and picked up datetime, time, and pickle. Another issue with the file that may make it look a tad outdated is that I think it hasn't been clear to everyone that it is designed to hold *tracker ids* rather than *committer ids*. I noticed the other day that I had to translate from committer id to tracker id for someone (I forget who, and I didn't have time to update the file at the time). -- R. David Murray www.bitdance.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing IDLE from the standard library
On Mon, 12 Jul 2010 00:13:21 +0100, Mark Lawrence breamore...@yahoo.co.uk wrote: On 11/07/2010 19:40, Martin v. L=F6wis wrote: There clearly are *some* folks who care enough about IDLE to submit bug reports and fixes. How about we empower these people by giving at least one of them commit privileges? IDLE development has often been done by people who aren't otherwise contributing to the core, and we surely should trust those folks with commit privileges. Can I take a really big liberty and volunteer Terry Reedy for the job. It doesn't work that way. You can't volunteer somebody else (*). If Terry would volunteer himself, he'd get commit access in no time. Regards, Martin (*) so when you assign bugs to me, it probably means that they get less attention, not more. Martin, Thanks for your response. IIRC Terry Reedy has already volunteered to do this, if I'm incorrect I'll apologise right now to both of you. As for assigning bugs, I've been told to use the maintainer.rst list, so either the list is wrong, or I've had finger problems. If it's the latter I again say sorry. I suggested you use maintainers.rst to find people to add to the nosy list, not to assign bugs to. But I can understand your confusion about that, given the name of the file, and the lack of complete process documentation. -- R. David Murray www.bitdance.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing IDLE from the standard library
On Mon, Jul 12 2010, Antoine Pitrou wrote: On Mon, 12 Jul 2010 05:20:49 -0400 Kurt B. Kaiser k...@shore.net wrote: I'm mystified about the comments that the GUI is ugly. It is minimal. On XP, it looks exactly like an XP window with a simple menubar. Those who haven't looked at it for awhile may not be aware of the recent advances made by Tk in native look and feel. What is ugly? Ok, I've just tried IDLE (on py3k) for the first time in years. Under Linux, the look is ugly and outdated; it uses some kind of Motif-like widgets. That's because Linux isn't using Tk 8.5 yet. Debian defaults to Tk 8.5 in experimental since March. Most Linux is Tk 8.4. On Windows, our installer is using 8.5. Here's a screenshot from my eeePC, 1024 x 600: http://images.rant.ml1.net/idle.gif Quoting Tal: Perhaps, but the point is that these bugs remain. Certainly this isn't because just you, out of the entire Python development community, know little about Tk and Tkinter. Using Tkinter is a major reason that maintaining and further developing IDLE is difficult. For example, it took me many hours just to get a working Tkinter scrolled frame widget, having had to write it from scratch and struggle with the under-documented Canvas widget. Another example is that integration of the new ttk (a.k.a. Tile) widget set, which supports native lookfeel on various platforms and adds modern widgets, has still not been integrated despite being available in Tk for years and despite considerable effort being invested into it. = Tal, you've got some catching up to do, yourself. Tile went into Tk in 8.5, two years ago. Linux is behind, we don't control that, but our Windows installer and tkinter is cutting edge! Thanks, Martin! I don't know what version is running on the Mac: http://blog.markroseman.com/2007/12/tcltk-85-first.html I've got an ancient Python 2.5.1 running in Gnome/gNewSense using Tk 8.4. I think you guys are exaggerating. It's not /all/ that ugly, not by a long shot. It's just not native look and feel (yet). Usability is inconsistent with the rest of the desktop, and looks generally subpar (for example, you have to click on a menu to open it; On Linux and Windows, alt f will drop the file menu. the file open dialog is antiquated and doesn't allow me to use keyboard shortcuts). Looks much better in 8.5 and the shortcuts work. http://images.rant.ml1.net/idle2.gif The editor looks decent, though there doesn't seem to be a simple (e.g. Shift+Tab) way of unindenting a block of code. Pull down the format menu. The dedent hotkey is Ctrl+[ This possibly could be changed to Shift+Tab by the user, but there may be conflicts with completion. -- KBK ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing IDLE from the standard library
On Mon, 12 Jul 2010 08:12:10 -0400 Kurt B. Kaiser k...@shore.net wrote: Ok, I've just tried IDLE (on py3k) for the first time in years. Under Linux, the look is ugly and outdated; it uses some kind of Motif-like widgets. That's because Linux isn't using Tk 8.5 yet. Debian defaults to Tk 8.5 in experimental since March. Most Linux is Tk 8.4. No, that's wrong. Tk here is 8.6: $ ldd build/lib.linux-x86_64-3.2/_tkinter.so [...] libtk8.6.so.0 = /usr/lib64/libtk8.6.so.0 (0x7f4eb9259000) libtcl8.6.so.0 = /usr/lib64/libtcl8.6.so.0 (0x7f4eb8f07000) [...] $ ./python -c import tkinter; print(tkinter.TkVersion) 8.6 the file open dialog is antiquated and doesn't allow me to use keyboard shortcuts). Looks much better in 8.5 and the shortcuts work. http://images.rant.ml1.net/idle2.gif Well, this is a Windows screenshot. I'm under Linux. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing IDLE from the standard library
On Mon, Jul 12, 2010 at 8:12 AM, Kurt B. Kaiser k...@shore.net wrote: On Mon, Jul 12 2010, Antoine Pitrou wrote: On Mon, 12 Jul 2010 05:20:49 -0400 Kurt B. Kaiser k...@shore.net wrote: I'm mystified about the comments that the GUI is ugly. It is minimal. On XP, it looks exactly like an XP window with a simple menubar. Those who haven't looked at it for awhile may not be aware of the recent advances made by Tk in native look and feel. What is ugly? Ok, I've just tried IDLE (on py3k) for the first time in years. Under Linux, the look is ugly and outdated; it uses some kind of Motif-like widgets. That's because Linux isn't using Tk 8.5 yet. Debian defaults to Tk 8.5 in experimental since March. Most Linux is Tk 8.4. FYI, I'm at 8.5 here, running Ubuntu 9.10, haven't knowingly updated tk. On Windows, our installer is using 8.5. Here's a screenshot from my eeePC, 1024 x 600: http://images.rant.ml1.net/idle.gif You may have meant to put a different image up, this one is windows. Quoting Tal: Perhaps, but the point is that these bugs remain. Certainly this isn't because just you, out of the entire Python development community, know little about Tk and Tkinter. Using Tkinter is a major reason that maintaining and further developing IDLE is difficult. For example, it took me many hours just to get a working Tkinter scrolled frame widget, having had to write it from scratch and struggle with the under-documented Canvas widget. Another example is that integration of the new ttk (a.k.a. Tile) widget set, which supports native lookfeel on various platforms and adds modern widgets, has still not been integrated despite being available in Tk for years and despite considerable effort being invested into it. = Tal, you've got some catching up to do, yourself. Tile went into Tk in 8.5, two years ago. Linux is behind, we don't control that, but our Windows installer and tkinter is cutting edge! Thanks, Martin! I don't know what version is running on the Mac: http://blog.markroseman.com/2007/12/tcltk-85-first.html I've got an ancient Python 2.5.1 running in Gnome/gNewSense using Tk 8.4. I think you guys are exaggerating. It's not /all/ that ugly, not by a long shot. It's just not native look and feel (yet). No offense, but I've been specifically asked not to do demos with IDLE because it looked 'unprofessional'. Given the constraint of working within tkinter that may not be something you can work around, but I'm sure you can see that from a certain perspective that's beside the point. Usability is inconsistent with the rest of the desktop, and looks generally subpar (for example, you have to click on a menu to open it; On Linux and Windows, alt f will drop the file menu. the file open dialog is antiquated and doesn't allow me to use keyboard shortcuts). Looks much better in 8.5 and the shortcuts work. http://images.rant.ml1.net/idle2.gif The editor looks decent, though there doesn't seem to be a simple (e.g. Shift+Tab) way of unindenting a block of code. Pull down the format menu. The dedent hotkey is Ctrl+[ This possibly could be changed to Shift+Tab by the user, but there may be conflicts with completion. -- KBK ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/debatem1%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Getting an optional parameter instead of creating a socket internally
On Sun, Jul 11, 2010 at 9:06 PM, exar...@twistedmatrix.com wrote: On 03:11 pm, j...@jcea.es wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 13/04/10 04:03, exar...@twistedmatrix.com wrote: On 12 Apr, 11:19 pm, j...@jcea.es wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/13/2010 12:47 AM, Antoine Pitrou wrote: Jesus Cea jcea at jcea.es writes: PS: socket.setdefaulttimeout() is not enough, because it could shutdown a perfectly functional connection, just because it was idle for too long. The socket timeout doesn't shutdown anything. It just puts a limit on how much time recv() and send() can block. Then it's up to you to detect whether the server is still alive (for example by pinging it through whatever means the application protocol gives you). A regular standard library (let say, poplib) would abort, after getting the timeout exception. 4. Modify client libraries to accept a new optional socket-like object as an optional parameter. This would allow things like transparent compression or encryption, or to replace the socket connection by anything else (read/write to shared memory or database, for example). This could be useful too. I have been thinking about this for years. Do you actually think this could be formally proposed?. Every once in a while I make a little bit more progress on the PEP I'm working on for this. If you want to talk more about this, you can find me in #python-dev or #twisted on freenode. Jean-Paul Jean-Paul, I would like to have this for 3.2. How is the PEP going?. It's still little more than an outline. You can see it here: http://twistedmatrix.com/trac/wiki/ProtocolPEP And if you're interested in helping, we can figure out a way to do that (you can have edit permission on the wiki or we can move the document elsewhere, whatever). Jean-Paul This seems like an interesting idea to me. I would like to figure out some way I could help with the PEP. If you move the document, could you please keep me updated on the new location? :.:: mattias ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/thebrasse%40brasse.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] IRC culture (was: Removing IDLE from the standard library)
On Sun, 11 Jul 2010 23:51:35 +0100, Mark Lawrence breamore...@yahoo.co.uk wrote: I have been attempting to fill this hole and have been faced with animosity from people who hang out on the python-dev IRC channel. I thought it was a complete and utter waste of space, so I don't intend going back. I would like things fixed, not a cosy little who's round is it next mentality from the triage team. IMHO if they spent more It was clear from a message you sent to me, that I didn't see until after your visit to the channel, that you don't have any experience on IRC. IRC is its own unique medium, with its own mores, conventions, and culture. That you perceived hostility was probably due to the nature of the medium and its communication via short sentences and intertwined conversations. And yes, the IRC channel is our office water cooler where we come to chat with each other about things unrelated to our coding work, as well as serious talk about the coding and bug triage work (some of which takes place *while* we're chatting about things like the World Cup Final). It's a community, and we hang out there because we find it fun to do so. We often tease each other mercilessly, and an outsider would probably wonder what the heck was going on if they didn't stick around long enough to get the flavor of the community. But we also do a lot of good communicating about bugs and code, helping each other to improve the quality of Python. I thought the conversation when you arrived was mostly positive, and we were trying to share our (somewhat disjointed, as we admitted) wisdom about what works best when doing triage. Antoine did lead off with a specific criticism, which was unfortunate and doubtless set a bad tone for you, and his mini-rant could have been more politely phrased given that you were a newcomer. But I use the term mini-rant descriptively...that is part of the IRC style of communication, for better or worse. As several people have pointed out, currently there is a dearth of good documentation about the Python workflow. I think Jesse's sprint effort is going to help improve this, and I know Brett Cannon really wants to have time to work the docs over thoroughly. But in the meantime, what we have is institutional knowledge locked up in people's heads. The python-dev mailing list is one way to get access to that knowledge, as is the tracker-discuss list for triage in particular...and the IRC channel is a great way to get access to that knowledge (like, for example, the fact that maintainers.rst is not out of date :), if you are comfortable with IRC style communication. If you don't find the IRC channel a useful place, there's no reason for you to hang out there. We were offering you the opportunity to experience the camaraderie and mutual help that we find there, and I'm very sorry that you instead found the experience offputting. It is not an exclusive club (far from it) and you would be welcome to return. As I also said to you in a private message, the non-exclusivity goes both ways...there is no *formal* triage team, and only some of us who do triage work hang out on IRC, and only some of us who hang out on #python-dev do triage work. Further, many of the people who chat regularly on the IRC channel are committers, which is one of the reasons why it can be a rich resource while doing triage. Often enough, bugs get closed that way.[*] -- R. David Murray www.bitdance.com But, to be honest, I remember that Arfrever asked about committing the patch for a particular bug on at least three different days before someone finally had the time to do it. It was very appropriate for that bugfix to go in before the release, and he was very patient, and it did get done. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library
If I read the patch correctly it replaces the existing 8.4 support by support for 8.5. That would not be acceptable because it would result in a non-functional version of IDLE for anyone that hasn't installed a custom copy of Tk. Not quite. It doesn't specify a version of Tk to run; it checks instead for whether Tk is built on Cocoa or Carbon. (It needs 8.5 to run on Cocoa.) The checkForAppKit function doesn't work with the system version of Tk that Python currently links to. The checkForAppKit function queries the Tk windowing server for some information about its implementation. If it find 'AppKit,' then Cocoa's running: if no, then Carbon's running. If Carbon, then the code falls back to the current implementation. Does the patch work with the system version of Tk 8.4 on OSX? I just tested it against Python 2.5/Tk 8.4.7 (the system install on Leopard), which runs on Carobn, and it works fine. I've also tested it against 2.6 with Tk-Cocoa, and again it runs fine. I don't have access to other combinations of Python and Tk, such as Python 3.1, but I think these results indicate it's safe to apply. --Kevin -- Kevin Walzer Code by Kevin http://www.codebykevin.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing IDLE from the standard library
On 12/07/2010 11:37, geremy condra wrote: On Mon, Jul 12, 2010 at 5:31 AM, Stefan Krahste...@bytereef.org wrote: Jesse Nollerjnol...@gmail.com wrote: On Sun, Jul 11, 2010 at 8:22 PM, geremy condradebat...@gmail.com wrote: (This seems to me like an area where a judicious application of PSF funds might help; if every single bug were actively triaged and responded to, even if it weren't reviewed, and patch contributors were directed to take specific steps to elicit a response or a review, the fact that patch reviews take a while might not be so bad.) The operative word being judicious. It is not obvious who should get funded, and for what tasks. Some specific issues (like email in 3.x) are large enough that they can be the sole focus of a fund grant. But I'm not sure triaging can apply. I'm mulling over starting a monthly triage sprint under the auspices of Jesse Noeller's PSF sponsored sprints in the hopes of making this a little more fun. I'd appreciate comments on the idea. [responding to Geremy] I'm with Georg on this. If triaging needs a monetary incentive because it is tedious work, so does committing. A lot of the abandoned issues aren't very glamorous either. I'm not sure what you mean by monetary incentive. I was considering handing a t-shirt or beer token to the most productive sprinters, but that's about the limit of it, and I suspect that would come out of my pocket. Any chance of getting me a t-shirt autographed by the one and only BDFL? :) I'd also emphasize that I am exactly as far as I stated on this: I'm mulling it over and asking for feedback. If it turns out that there are other things that python-dev feels are more necessary but similarly unglamorous, then I'll think about doing that instead. Also, from the work that Mark Lawrence has been doing on the tracker in the past few weeks, it's apparent that a dedicated person can achieve a lot without pay. Indeed, although I'm again unsure what pay has to do with this. Due to his tracker reshuffling, many issues got closed, several bug reporters responded after years, etc. Thanks, Mark! +1 Geremy Condra Geremy, Stefan, Jesse and anyone that I might have missed, thanks for your kind responses, its given me quite a lift. For the record note that I only got going because of a post on c.l.py from Terry Reedy, and that he too has been doing similar work on the issue tracker, my round Terry. :) Kindest regards. Mark Lawrence ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Getting an optional parameter instead of creating a socket internally
On 12:30 pm, thebra...@brasse.org wrote: On Sun, Jul 11, 2010 at 9:06 PM, exar...@twistedmatrix.com wrote: It's still little more than an outline. You can see it here: http://twistedmatrix.com/trac/wiki/ProtocolPEP And if you're interested in helping, we can figure out a way to do that (you can have edit permission on the wiki or we can move the document elsewhere, whatever). Jean-Paul This seems like an interesting idea to me. I would like to figure out some way I could help with the PEP. If you move the document, could you please keep me updated on the new location? Sure. If it moves, there'll be a pointer from its existing location to the new one. Jean-Paul ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library
On Mon, 12 Jul 2010 00:36:33 +0200 Martin v. Löwis mar...@v.loewis.de wrote: I think Martin has always supported me in some way and I really appreciate that. But, maybe because I won commit privileges solely based on GSoC work, I felt other developers wouldn't approve my commits without previous discussion and that is the major reason for not committing most of my patches. [...] So: go ahead. I won't have the time to review your changes in detail, and nobody else will, so just put them in, and we wait for people to complain (in which case I'd hope that you would be around to respond quickly - as you did in the past). +1. Don't be afraid. We are quite good at pointing out mistakes after the fact :) Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New regex module for 3.2?
On Mon, Jul 12, 2010 at 9:42 AM, Steven D'Aprano st...@pearwood.info wrote: On Sun, 11 Jul 2010 09:37:22 pm Eric Smith wrote: re2 comparison is interesting from the point of if it should be included in stdlib. Is it re2 or regex? I don't see having 2 regular expression engines in the stdlib. There's precedence though... the old regex engine and the new re engine were side-by-side for many years before regex was deprecated and finally removed in 2.5. Hypothetically, re2 could similarly be added to the standard library while re is deprecated. re2 deliberately omits some features for efficiency reasons, hence is not even on the table as a possible replacement for the standard library version. If someone is in a position where re2 can solve their problems with the re module, they should also be in a position where they can track it down for themselves. MRAB's module offers a superset of re's features rather than a subset though, so once it has had more of a chance to bake on PyPI it may be worth another look. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 3148 ready for pronouncement [ACCEPTED]
Hi I learned about the futures PEP only today. I saw the example on
http://code.google.com/p/pythonfutures/
One thing that worries me is that this approach seems to bypass the
usual exception handling mechanism of Python. In particular I'm
wondering why you have to do things like:
if future.exception() is not None:
...
This reminds me a lot of how things are done in C but it's not very
pythonic. Wouldn't it be possible and nicer to raise the exception --
if there was one inside the asynchronous job -- when the result of the
future is accessed?
try:
print('%r page is %d bytes' % (url, len(future.result(
except FutureError:
print('%r generated an exception: %s' % (url, future.exception()))
Best,
Titus
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library
Tal Einat wrote: I would like to propose removing IDLE from the standard library. I use IDLE every day. It does everything I want an IDE to do, it looks simple and doesn't waste screen real estate like some other IDEs do, it supports proportionally spaced fonts correctly, its syntax coloring is easy configurable (not a nightmare like some scintilla-based IDEs), and it's instantly available on any PC on which I install Python. I'd like to keep it in the stdlib. Greetings, ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing IDLE from the standard library
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tal Einat wrote: I would like to propose removing IDLE from the standard library. I have been using IDLE since 2002 and have been doing my best to help maintain and further develop IDLE since 2005. I'm surprised by the amount of interest this has raised already. To answer a few questions that were raised: In recent years I have worked up many patches, both bugfixes and new features and improvements. Getting any attention to these was non-trivial, and getting patches accepted (or an explanation why they are rejected in some cases) almost always took many months, sometimes years, and some are still unresolved. It has been very frustrating. When I ran into bugs I fixed them and submitted a patch. I have also done so for quite a few bugs reported by others. However, there are currently several bugs in the tracker which nobody is taking any notice of. IIRC most of the recent bugs are related to OSX or 64-bit Windows. To those who mention that IDLE is okay or not going uphill, my grandfather would say if you aren't running forwards, you are falling behind. You should know how IDLE looks to programmers seeing it for the first time -- IDLE's quirky and old-fashioned looks and interface are a major turnoff for new users. As a result I have stopped recommending it to coworkers, despite personally liking IDLE, instead recommending the basic command-line or IPython for interactive work, and any other IDE or text editor for development. I too prefer IDLE to the basic command line, and think that something like IDLE is well-suited for learning/teaching Python. I also think an interpreter with a nice GUI can be far superior to a text-only interpreter. However, I've mostly lost hope for IDLE, and am currently hoping that something else takes its place. The fact is that for many years little effort has gone into developing and maintaining IDLE, and I believe being tucked in a corner of the Python codebase is a major reason for this. I really don't see why IDLE has to be part of the standard library, what's wrong with IDLE being an externally maintained application? Yes, IDLE still works (mostly), but us few who continue to use it could do so even if it weren't part of the standard library. I wonder if moving it out of stdlib might actually help improve its development velocity: maybe if it were managed via bitbucket, with user-visible forks to known fixes, etc., it would get caught up to people's expectations. Perhaps I'm really suggesting that there be an 'idle2' project nn bitbucket, as a friendly fork of the mostly freeze-dried version in stdlib. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkw7JcAACgkQ+gerLs4ltQ73RACfTcPaDXPFlg8EWnBxYj3qfWwg qswAn3Ws/FvYqLLiYGvgzEpd1sIpWuWJ =ZlSp -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library
On 7/12/10 10:16 AM, Michiel Overtoom wrote: Tal Einat wrote: I would like to propose removing IDLE from the standard library. I use IDLE every day. It does everything I want an IDE to do, it looks simple and doesn't waste screen real estate like some other IDEs do, it supports proportionally spaced fonts correctly, its syntax coloring is easy configurable (not a nightmare like some scintilla-based IDEs), and it's instantly available on any PC on which I install Python. I'd like to keep it in the stdlib. +1 to keeping it in the stdlib, in case my earlier comments didn't make that clear. My own reasons for submitting patches to help with Tkinter on the Mac are pretty typical: the Cocoa-based implementation of Tk broke some things in IDLE because of different methods for menu placement, etc. I wanted this fixed, and since I might be the only Python person with the knowledge about Carbon vs. Cocoa internals in Tk to do it, I dug in, attempted to grok IDLE's rather baroque code, and eventually came up with some patches. Scratching my own itch, IOW. I'm currently using Aquamacs/Emacs for my Python development because of some other issues with Tk-Cocoa (external to IDLE) on Leopard, but once I upgrade my OS, I plan to return to using IDLE for everyday Python development. Since Tkinter is my GUI toolkit of choice, I like to work in that environment. Also, I strongly urge Guilherme (or someone) to commit his changes to IDLE. While I like IDLE and feel it is a very useful IDE for Python work even for someone who is past the beginner stage, I also agree that its current UI is dated. Adding the themed Tk widgets would likely make it more pleasant to use, as well as showing what can be done with the new widgets. (The existence and widespread use of archaic Tk extensions like Tix within Tkinter isn't a recommendation for the toolkit beyond backwards compatibility.) --Kevin -- Kevin Walzer Code by Kevin http://www.codebykevin.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library
On Mon, Jul 12, 2010 at 11:19 PM, Antoine Pitrou solip...@pitrou.net wrote: +1. Don't be afraid. We are quite good at pointing out mistakes after the fact :) Just make sure to subscribe to python-checkins and keep an eye out for replies to your commits. Most post hoc review comments come in as replies to the commit notifications :) Hmm, do we mention that part of the process in the dev docs anywhere?... and it turns out we do, as Brett included it in the Intro to Development article. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3148 ready for pronouncement [ACCEPTED]
On Tue, Jul 13, 2010 at 12:19 AM, Titus von der Malsburg malsb...@gmail.com wrote: This reminds me a lot of how things are done in C but it's not very pythonic. Wouldn't it be possible and nicer to raise the exception -- if there was one inside the asynchronous job -- when the result of the future is accessed? That's what actually happens, so you can code it either way (either just calling result() and dealing with any exception that was raised, or else checking for a non-None exception value directly). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3148 ready for pronouncement [ACCEPTED]
On Tue, Jul 13, 2010 at 12:48:35AM +1000, Nick Coghlan wrote: On Tue, Jul 13, 2010 at 12:19 AM, Titus von der Malsburg That's what actually happens, so you can code it either way That's great! None of the examples I found used the pythonic exception style, that's why I assumed that checking the return value is the only possibility. Reading the PEP carefully would have helped. :-) Titus ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library
On 12/07/2010 15:42, Nick Coghlan wrote: On Mon, Jul 12, 2010 at 11:19 PM, Antoine Pitrousolip...@pitrou.net wrote: +1. Don't be afraid. We are quite good at pointing out mistakes after the fact :) Just make sure to subscribe to python-checkins and keep an eye out for replies to your commits. Most post hoc review comments come in as replies to the commit notifications :) That mailing list (python-checkins) is way too high traffic for many committers to monitor. I hope people making comments on checkins also email the committer directly. All the best, Michael Hmm, do we mention that part of the process in the dev docs anywhere?... and it turns out we do, as Brett included it in the Intro to Development article. Cheers, Nick. -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library
On Mon, Jul 12 2010, Tal Einat wrote: On Mon, Jul 12, 2010 at 1:44 AM, Martin v. Löwis mar...@v.loewis.de wrote: FWIW this is why I started IDLE-Spoon (well, continued Noam Raphael's project of the same name, in a sense). The idea was to have a fork of IDLE with new features which need to be tried out by beta testers to iron out all of the glitches before making it into the main version, like IDLE-fork back in the beginning of the decade. However I have utterly failed in promoting this project and getting beta testers on board, at least partially due to the lack of interest from the community (and admittedly my lack of PR skills). I think such a thing must inherently fail - precisely for these reasons. It's much better to release proposed new features along with Python, and wait for feedback. Users won't start trying things out until after the release. This is a general problem, and lead Barry Warsaw to believe that release candidates are an utter waste of time. That's debatable, and I disagree. IDLE-fork was a great success, for example. We had major contributions from David Scherer, Guido, and Stephen Gava. But a key factor in its success was that I took it upon myself to keep IDLEfork sync'd with core IDLE using a cvs vendor branch and frequent merges. Once the project was completed, I arranged with SF to move the IDLEfork repository, including history, back into Python. This was not done with Noam's branch. As a result, it gradually drifted to the point where it became essentially unmergable. Once we switch to Hg, we should be able to use distributed vc and topic branches to facilitate community participation without the need for a separate project. None of this is automatic, of course, it requires diligence, planning, and clean topic patches. If IDLE actually had many users today, certainly some of them would be interested in trying out a version with usability fixes and improvements. Waiting for a new release of Python can take over a year. Furthermore, backwards compatibility issues and support by third party libraries can delay migration to a newer version of Python even further. There's no reason why we couldn't release interim IDLE testing packages from somewhere other than python.org (for those that don't want to track IDLE's Hg repo). To do this successfully, we would need to avoid using new Python features being introduced during that development cycle, i.e. IDLE would be compatible with the previous Python release. -- KBK ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library
Kurt B. Kaiser wrote: Using Tkinter is a major reason that maintaining and further developing IDLE is difficult. For example, it took me many hours just to get a working Tkinter scrolled frame widget, having had to write it from scratch and struggle with the under-documented Canvas widget. Another example is that integration of the new ttk (a.k.a. Tile) widget set, which supports native lookfeel on various platforms and adds modern widgets, has still not been integrated despite being available in Tk for years and despite considerable effort being invested into it. Tal, you've got some catching up to do, yourself. Tile went into Tk in 8.5, two years ago. I was referring to the integration of the new ttk widgets into IDLE, which still hasn't happened despite two years having gone by. Sorry for not being clear on that point. - Tal Einat ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library
On Mon, Jul 12, 2010 at 3:20 AM, Kurt B. Kaiser k...@shore.net wrote: As I recollect, much of what Scherer did in VIDLE related to running multiple IDLE copies. For that reason, the VIDLE changes have to be evaluated carefully to determine what has already been incorporated. I believe I added a couple of his smaller changes, also. Bruce, speaking of Dave Scherer, we've been trying to get a Python Contributor Agreement from him. Is that something you can help us with? -- KBK I don't recall that VIDLE has anything to do with running multiple IDLE copies. What's in VIDLE is a lot of bug fixes and some improvements. For example, you can configure it to not require having to save a file, which makes it as easy to use for quick testing as the shell. Another improvement, of high importance for our physics students and other novice programmers, is to bring an error display forward. Many students fill the screen with the edit window and the error message could be hidden, leaving them puzzled as to why their program wasn't running. Stuff like that, all aimed at issues we had seen with a large population of science and engineering students. I'll say again that IDLE/VIDLE is an excellent environment for novices. Issues identified here about look and feel etc. have just not been of any importance in that context. If you'll send me what you want from Scherer, I can contact him. Bruce Sherwood ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing IDLE from the standard library
On Jul 12, 2010, at 4:34 AM, Éric Araujo wrote: Plus, http://twistedmatrix.com/trac/report/15 is a useful resource for core developers with only a little bit of free time to do a review. Title: “Review Tickets, By Order You Should Review Them In” I haven’t found a description of this order, can you explain? Thanks. Part of the reason that the report is worded that way is that we may decide that the order should be different, but it will still be the order that you should review them in :). Right now the order is amount of time since last change, sorted from highest to lowest. In other words, first come, first serve, by last activity. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New regex module for 3.2?
On 12/07/2010 15:07, Nick Coghlan wrote: On Mon, Jul 12, 2010 at 9:42 AM, Steven D'Apranost...@pearwood.info wrote: On Sun, 11 Jul 2010 09:37:22 pm Eric Smith wrote: re2 comparison is interesting from the point of if it should be included in stdlib. Is it re2 or regex? I don't see having 2 regular expression engines in the stdlib. There's precedence though... the old regex engine and the new re engine were side-by-side for many years before regex was deprecated and finally removed in 2.5. Hypothetically, re2 could similarly be added to the standard library while re is deprecated. re2 deliberately omits some features for efficiency reasons, hence is not even on the table as a possible replacement for the standard library version. If someone is in a position where re2 can solve their problems with the re module, they should also be in a position where they can track it down for themselves. If it has *partial* compatibility, and big enough performance improvements for common cases, it could perhaps be used where the regex doesn't use unsupported features. This would have some extra cost in the compile phase, but would mean Python could ship with two regex engines but only one interface exposed to the programmer... Michael MRAB's module offers a superset of re's features rather than a subset though, so once it has had more of a chance to bake on PyPI it may be worth another look. Cheers, Nick. -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing IDLE from the standard library
On Mon, Jul 12 2010, Antoine Pitrou wrote: On Mon, 12 Jul 2010 08:12:10 -0400 Kurt B. Kaiser k...@shore.net wrote: Ok, I've just tried IDLE (on py3k) for the first time in years. Under Linux, the look is ugly and outdated; it uses some kind of Motif-like widgets. That's because Linux isn't using Tk 8.5 yet. Debian defaults to Tk 8.5 in experimental since March. Most Linux is Tk 8.4. No, that's wrong. Tk here is 8.6: $ ldd build/lib.linux-x86_64-3.2/_tkinter.so [...] libtk8.6.so.0 = /usr/lib64/libtk8.6.so.0 (0x7f4eb9259000) libtcl8.6.so.0 = /usr/lib64/libtcl8.6.so.0 (0x7f4eb8f07000) [...] $ ./python -c import tkinter; print(tkinter.TkVersion) 8.6 What distro are you using? Tk8.6 is still in beta. Still looks crummy? Bummer. the file open dialog is antiquated and doesn't allow me to use keyboard shortcuts). Looks much better in 8.5 and the shortcuts work. http://images.rant.ml1.net/idle2.gif Well, this is a Windows screenshot. I'm under Linux. Fine, I showed it as an example of the improvement in 8.5. Most people, I think, are using Windows or Macs. Looks decent, don't you think? I don't have Tk8.5 running under Linux yet, much less 8.6. But the Tk release docs claim improvement under X11. It's possible we may have to use Tk theming to get full benefit of the Tile improvements in X11. -- KBK ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing IDLE from the standard library
On Mon, Jul 12 2010, geremy condra wrote: No offense, but I've been specifically asked not to do demos with IDLE because it looked 'unprofessional'. Given the constraint of working within tkinter that may not be something you can work around, but I'm sure you can see that from a certain perspective that's beside the point. Right, I stay away from working on Tk. It's not even a tkinter issue. I hope it will continue to get better, but I imagine it's a moving target for the Tk developers. In your case, just bring up Wing. That'll impress them. As long as it's not on netbook :-) -- KBK ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library
On Mon, Jul 12, 2010 at 9:20 AM, Kurt B. Kaiser k...@shore.net wrote: Also, the current right click edit action on Windows is to only open an edit window; no shell. And it uses the subprocess! So, some of the comments on this thread are not up to date. The reason that bug languished for two years was because first, it was a bit of a hack, and second, Windows was problematic in that it reused sockets and often left zombie subprocesses behind which couldn't be killed except with the task manager. This causes real problems with students - they lose confidence in the tool. Scherer and Weeble put together a patch using ephemeral ports which nailed the problem, and I checked it in right away and forward/backported it. That's great news! I TAed a freshman Python class this January, and Windows users ran into this problem a lot. Mostly when hitting 'x' in the upper right. Fortunately, some quick searching led me to the Python tracker where I found the workaround. :) (Somwhat off-topic): Another pain point students had was accidentally shadowing stdlib modules, like random. Renaming the file didn't solve the problem either, because it left behind .pycs, which I had to help them delete. Overall, I would say that IDLE worked very well in that situation, so while it does have its quirks, it worked very well for us. Imagine trying to get students started with Eclipse or NetBeans. Yuck! Reid ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New regex module for 3.2?
On Mon, 12 Jul 2010 16:18:38 +0100 Michael Foord fuzzy...@voidspace.org.uk wrote: On 12/07/2010 15:07, Nick Coghlan wrote: On Mon, Jul 12, 2010 at 9:42 AM, Steven D'Apranost...@pearwood.info wrote: On Sun, 11 Jul 2010 09:37:22 pm Eric Smith wrote: re2 comparison is interesting from the point of if it should be included in stdlib. Is it re2 or regex? I don't see having 2 regular expression engines in the stdlib. There's precedence though... the old regex engine and the new re engine were side-by-side for many years before regex was deprecated and finally removed in 2.5. Hypothetically, re2 could similarly be added to the standard library while re is deprecated. re2 deliberately omits some features for efficiency reasons, hence is not even on the table as a possible replacement for the standard library version. If someone is in a position where re2 can solve their problems with the re module, they should also be in a position where they can track it down for themselves. If it has *partial* compatibility, and big enough performance improvements for common cases, it could perhaps be used where the regex doesn't use unsupported features. This would have some extra cost in the compile phase, but would mean Python could ship with two regex engines but only one interface exposed to the programmer... You're forgetting the maintenance cost. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing IDLE from the standard library
Stephen Hansen apt.shan...@gmail.com wrote: On Sun, Jul 11, 2010 at 4:53 PM, Steve Holden st...@holdenweb.com wrote: Stephen Hansen wrote: On Sat, Jul 10, 2010 at 9:23 PM, Guilherme Polo ggp...@gmail.com mailto:ggp...@gmail.com wrote: By never had a problem do you mean using some of the latest versions ? Here, running idle from a mac terminal and trying to type: print hi crashes when entering the quotation mark. Huh? Works fine for me. Python 2.6.1, OSX 10.6.3, intel. One of the good things about the python-dev community is its commitment to test-driven development. If you are prepared to define fine as 'successfully runs \'print hello\'' then I guess we should be perfectly happy about IDLE. Er, how hostile. My point is, the poster made an assertion-- that you couldn't do the simple act as launching idle from a command line, and printing Hi. Maybe they can't, I have no idea. I know I can. I know that I have also opened random python files, saved them, and ran them with IDLE. I don't use IDLE beyond that though: I live in TextMate on my mac. My point was not, IDLE is perfect. My point was, You've claimed you can't even print out a word in IDLE, so its utterly and completely non-functional -- and that assertion surprises me and I challenge. Steve, you encouraged me to try it again. From an xterm on OS X 10.5.8, it launches fine (long as you know where it is -- /System/Library/Frameworks/Python.framework/Versions/Current/bin/idle). Seems to work OK for what it is, too. Same for Terminal. When I start it from the *shell* buffer in Cocoa GNU Emacs, though, the idle window pops up under the Emacs window, which is why I didn't see it over the weekend. Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing IDLE from the standard library
On Mon, 12 Jul 2010 11:23:04 -0400 Kurt B. Kaiser k...@shore.net wrote: What distro are you using? Tk8.6 is still in beta. It's Mandriva 2010.1 Still looks crummy? Bummer. Yes. Fine, I showed it as an example of the improvement in 8.5. Most people, I think, are using Windows or Macs. Looks decent, don't you think? Yes, it does. If indeed the main target population for IDLE is Windows and Mac users (since Linux users have a lot of alternatives almost by default), then I suppose the situation is not that bad. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New regex module for 3.2?
On Mon, 2010-07-12 at 16:18 +0100, Michael Foord wrote: On 12/07/2010 15:07, Nick Coghlan wrote: On Mon, Jul 12, 2010 at 9:42 AM, Steven D'Apranost...@pearwood.info wrote: re2 deliberately omits some features for efficiency reasons, hence is not even on the table as a possible replacement for the standard library version. If someone is in a position where re2 can solve their problems with the re module, they should also be in a position where they can track it down for themselves. If it has *partial* compatibility, and big enough performance improvements for common cases, it could perhaps be used where the regex doesn't use unsupported features. This would have some extra cost in the compile phase, but would mean Python could ship with two regex engines but only one interface exposed to the programmer... I'm not sure how common those cases are - I played around with RE2 a few months ago and found that the majority of regular expressions in my own code were noticeably slower running under RE2 than python's re module - RE2 just puts much nicer theoretical bounds on cases that were (in my code at least) unusual. The really good use case for RE2 is for applications where users can write regular expressions as input (exactly what RE2 was designed for) - but I'm not sure how common those applications are. Tim Wintle ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library
On Tue, Jul 13, 2010 at 1:07 AM, Michael Foord fuzzy...@voidspace.org.uk wrote: That mailing list (python-checkins) is way too high traffic for many committers to monitor. I hope people making comments on checkins also email the committer directly. Not normally, no - there's no easy way to connect a checkin message to a committer's email address, so it's usually just a matter of hitting Reply and sending the review comment to the list. With a new committer I'll make the effort to cc them directly in case they aren't subscribed yet, but I expect everyone else to be monitor the checkins list. If the list is too high volume, filter it down to just those issues with your checkin name in the From or To fields (your own checkin messages will have the former, while replies should have the latter, even though the email address in both cases will actually be python-check...@python.org. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] commit privs
On Sun, Jul 11, 2010 at 9:28 AM, Antoine Pitrou solip...@pitrou.net wrote: On Sun, 11 Jul 2010 13:23:13 + Reid Kleckner reid.kleck...@gmail.com wrote: I'm also expecting to be doing more work merging unladen-swallow into the py3k-jit branch, so I was wondering if I could get commit privileges for that. It sounds good to me. Also, thanks for your threading patches! +1 from me. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing IDLE from the standard library
On Tue, Jul 13, 2010 at 1:44 AM, Bill Janssen jans...@parc.com wrote: Steve, you encouraged me to try it again. From an xterm on OS X 10.5.8, it launches fine (long as you know where it is -- /System/Library/Frameworks/Python.framework/Versions/Current/bin/idle). Seems to work OK for what it is, too. Same for Terminal. When I start it from the *shell* buffer in Cocoa GNU Emacs, though, the idle window pops up under the Emacs window, which is why I didn't see it over the weekend. FWIW, ./python -m idlelib,idle launched the shell window for me on two development installs. python -m idlelib.idle didn't work intially on the system Python (since Kubuntu leaves idle out by default), but it worked fine once I installed the idle package. (Oh, and I can confirm it still looks like a Tcl/Tk app on Kubuntu rather than a KDE app even with Tk 8.5) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library
On Mon, Jul 12, 2010 at 6:11 PM, Kurt B. Kaiser wrote: On Mon, Jul 12 2010, Tal Einat wrote: On Mon, Jul 12, 2010 at 1:44 AM, Martin v. Löwis mar...@v.loewis.de wrote: FWIW this is why I started IDLE-Spoon (well, continued Noam Raphael's project of the same name, in a sense). The idea was to have a fork of IDLE with new features which need to be tried out by beta testers to iron out all of the glitches before making it into the main version, like IDLE-fork back in the beginning of the decade. However I have utterly failed in promoting this project and getting beta testers on board, at least partially due to the lack of interest from the community (and admittedly my lack of PR skills). I think such a thing must inherently fail - precisely for these reasons. It's much better to release proposed new features along with Python, and wait for feedback. Users won't start trying things out until after the release. This is a general problem, and lead Barry Warsaw to believe that release candidates are an utter waste of time. That's debatable, and I disagree. IDLE-fork was a great success, for example. We had major contributions from David Scherer, Guido, and Stephen Gava. But a key factor in its success was that I took it upon myself to keep IDLEfork sync'd with core IDLE using a cvs vendor branch and frequent merges. Once the project was completed, I arranged with SF to move the IDLEfork repository, including history, back into Python. This was not done with Noam's branch. As a result, it gradually drifted to the point where it became essentially unmergable. Actually, Noam's branch was pretty much merged back as is -- that's where IDLE's auto-completion functionality came from. The later changes he made on that branch were never merged, as you mentioned, because Noam never bothered. I have been maintaining my own fork of IDLE for several years and manually keeping it in sync with IDLE (this was simple). The difference is that there was no single major new feature I was working on, such as the addition of a sub-process in IDLE-fork or Noam's addition of auto-completion. I was mostly making relatively minor fixes and changes which were not interrelated. I saw no reason to have them all merged back at once, so I posted patches as soon as I felt they were ready, and did the best I could to get them accepted. I eventually gave up on this process because every patch took far too long to be addressed and finally accepted or rejected, and I realized that most of the work I had done would never be merged back into the mainstream version of IDLE. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library
On 12/07/2010 16:52, Nick Coghlan wrote: On Tue, Jul 13, 2010 at 1:07 AM, Michael Foord fuzzy...@voidspace.org.uk wrote: That mailing list (python-checkins) is way too high traffic for many committers to monitor. I hope people making comments on checkins also email the committer directly. Not normally, no - there's no easy way to connect a checkin message to a committer's email address, There's a one-to-one mapping somewhere. so it's usually just a matter of hitting Reply and sending the review comment to the list. With a new committer I'll make the effort to cc them directly in case they aren't subscribed yet, but I expect everyone else to be monitor the checkins list. Without contacting committers, rather than firing into the black depths of a high traffic list, I strongly suspect that much of the feedback is lost. All the best, Michael If the list is too high volume, filter it down to just those issues with your checkin name in the From or To fields (your own checkin messages will have the former, while replies should have the latter, even though the email address in both cases will actually be python-check...@python.org. Cheers, Nick. -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] More C API abstraction for user defined types
Hello,
Defining a user type which implements number protocol should be treated as a
number (long) in PyArg_ParseTuple using l format.
In getargs.c:
case 'l': {/* long int */
long *p = va_arg(*p_va, long *);
long ival;
if (float_argument_error(arg))
return converterr(integerl, arg, msgbuf, bufsize);
ival = PyLong_AsLong(arg);
if (ival == -1 PyErr_Occurred())
return converterr(integerl, arg, msgbuf, bufsize);
else
*p = ival;
break;
}
ival should not be resolved through PyLong_AsLong, but through
functionality/interface like PyNumber_Long, thus allowing more diversity in
accessing the PyArg_Parse interfaces.
Petre
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing IDLE from the standard library
On Sun, Jul 11, 2010 at 3:38 PM, Ron Adam r...@ronadam.com wrote: There might be another alternative. Both idle and pydoc are applications (are there others?) that are in the standard library. As such, they or parts of them, are possibly importable to other projects. That restricts changes because a committer needs to consider the chances that a change may break something else. I suggest they be moved out of the lib directory, but still be included with python. (Possibly in the tools directory.) That removes some of the backward compatibility restrictions or at least makes it clear there isn't a need for backward compatibility. I also like this idea. This means Python comes with an IDE out of he box but without the overhead of a management and release process that is built for something very different than a GUI program (the standard library). This would mean that IDLE would be in site-packages, could easily be upgraded using normal tools, and maybe most importantly it could have its own community tools and development process that is more casual (and can more easily integrate new contributors) and higher velocity of changes and releases. Python releases would then ship the most recent stable release of IDLE. -- Ian Bicking | http://blog.ianbicking.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing IDLE from the standard library
On 12/07/2010 19:21, Ian Bicking wrote: On Sun, Jul 11, 2010 at 3:38 PM, Ron Adam r...@ronadam.com mailto:r...@ronadam.com wrote: There might be another alternative. Both idle and pydoc are applications (are there others?) that are in the standard library. As such, they or parts of them, are possibly importable to other projects. That restricts changes because a committer needs to consider the chances that a change may break something else. I suggest they be moved out of the lib directory, but still be included with python. (Possibly in the tools directory.) That removes some of the backward compatibility restrictions or at least makes it clear there isn't a need for backward compatibility. I also like this idea. This means Python comes with an IDE out of he box but without the overhead of a management and release process that is built for something very different than a GUI program (the standard library). This would mean that IDLE would be in site-packages, could easily be upgraded using normal tools, and maybe most importantly it could have its own community tools and development process that is more casual (and can more easily integrate new contributors) and higher velocity of changes and releases. Python releases would then ship the most recent stable release of IDLE. IDLE itself is probably stable enough that being able to upgrade in place is not a high priority. That could change based on this thread of course. I would *really* support this approach with pip once distutils2 is complete and integrated into the standard library. I would really like Python to come with a capable package manager out of the box but understand your reluctance to tie pip to the Python release schedule. Having pip installed into site-packages by default, so that it *can* be upgraded in place, would be win-win as far as I can tell. Slight thread hijacking I realise... :-) All the best, Michael -- Ian Bicking | http://blog.ianbicking.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A grammatical oddity: trailing commas in argument lists.
On Sat, Jul 10, 2010 at 1:22 AM, Nick Coghlan ncogh...@gmail.com wrote: +1 for fixing it from me, unless any of the other implementations object. @Mark: my comment on the tracker issue had an implied ...unless you really want to on the end :) Thanks! Patch at http://bugs.python.org/issue9232 Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library
On Jul 12, 2010, at 11:36 AM, Reid Kleckner wrote: (Somwhat off-topic): Another pain point students had was accidentally shadowing stdlib modules, like random. Renaming the file didn't solve the problem either, because it left behind .pycs, which I had to help them delete. I feel your pain. It seems like every third person who starts playing with Twisted starts off by making a file called 'twisted.py' and then getting really confused by the behavior. I would love it if this could be fixed, but I haven't yet thought of a solution that would be less confusing than the problem itself.___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library
On Mon, Jul 12, 2010 at 03:48:12PM -0400, Glyph Lefkowitz wrote: I feel your pain. It seems like every third person who starts playing with Twisted starts off by making a file called 'twisted.py' and then getting really confused by the behavior. I would love it if this could be fixed, but I haven't yet thought of a solution that would be less confusing than the problem itself. Doesn't absolute import help? Oleg. -- Oleg Broytmanhttp://phd.pp.ru/p...@phd.pp.ru Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] maintainers.rst enhancement
On 7/12/2010 7:42 AM, R. David Murray wrote: Another 'enhancement' might be to have a program occasionally email people with the items they are currently signed up for, to encourage editing. -- R. David Murray www.bitdance.com -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing IDLE from the standard library
On Mon, Jul 12, 2010 at 11:32 AM, Kurt B. Kaiser k...@shore.net wrote: On Mon, Jul 12 2010, geremy condra wrote: No offense, but I've been specifically asked not to do demos with IDLE because it looked 'unprofessional'. Given the constraint of working within tkinter that may not be something you can work around, but I'm sure you can see that from a certain perspective that's beside the point. Right, I stay away from working on Tk. It's not even a tkinter issue. I hope it will continue to get better, but I imagine it's a moving target for the Tk developers. In your case, just bring up Wing. That'll impress them. As long as it's not on netbook :-) The point isn't to impress them. The point is to not embarrass us. I just do it in gedit and ipython now, and I use an eee 901 for all my presentations and a good bit of my work and it seems to be fine, which is not paying much of a complement to IDLE. Geremy Condra ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] More C API abstraction for user defined types
On Tue, Jul 13, 2010 at 3:35 AM, Petre Galan petre.ga...@gmail.com wrote: ival should not be resolved through PyLong_AsLong, but through functionality/interface like PyNumber_Long, thus allowing more diversity in accessing the PyArg_Parse interfaces. Sounds like a reasonable idea to me, but it needs to be a posted as a feature request on the tracker. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library
Am 12.07.2010 13:01, schrieb Tal Einat: On Mon, Jul 12, 2010 at 1:41 AM, Martin v. Löwis mar...@v.loewis.de wrote: My point is that I don't think I am exaggerating IDLE's flaws. I'm not saying that it is no longer usable or useful, but I am saying that its current state is not okay. So can you produce a list of patches that you think can be accepted as-is? That's not a fair question! There have been several such patches, but most will likely need revision since they have been sitting around untouched for so long. And there would have been many more patches if the existing ones would have been addressed. Getting a few current patches accepted is not the reason I posted here. Ok. Then I guess I cannot help further - I certainly don't support removal of IDLE from the standard library. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing IDLE from the standard library
On 7/12/2010 5:46 AM, Kurt B. Kaiser wrote: On Windows, IDLE opens when you right click / edit a .py. Very useful. On my xp machine with 3.1.2, it edit .py opens with notepad. Perhaps the installer just copies forward the association from long ago, before IDLE was available, or at least so usable. I have thought of changing that, but I do not know what the replacement incantation would be. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library
On Mon, Jul 12, 2010 at 4:12 PM, Oleg Broytman p...@phd.pp.ru wrote: Doesn't absolute import help? Not when both modules are at the top level; both acceptably provide the same name. The let's-play-with-it script just wasn't *intended* to be a module. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com A storm broke loose in my mind. --Albert Einstein ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library
On 12/07/2010 22:33, Fred Drake wrote: On Mon, Jul 12, 2010 at 4:12 PM, Oleg Broytmanp...@phd.pp.ru wrote: Doesn't absolute import help? Not when both modules are at the top level; both acceptably provide the same name. The let's-play-with-it script just wasn't *intended* to be a module. I'm sure Brett will love this idea, but if it was impossible to reimport the script being executed as __main__ with a different name it would solve these problems. Michael Foord -Fred -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3148 ready for pronouncement [ACCEPTED]
On 13 Jul 2010, at 00:59, Titus von der Malsburg wrote:
On Tue, Jul 13, 2010 at 12:48:35AM +1000, Nick Coghlan wrote:
On Tue, Jul 13, 2010 at 12:19 AM, Titus von der Malsburg
That's what actually happens, so you can code it either way
That's great! None of the examples I found used the pythonic
exception style, that's why I assumed that checking the return value
is the only possibility. Reading the PEP carefully would have helped.
:-)
I'd add that it would feel more natural to me to write:
try:
print('%r page is %d bytes' % (url, len(future.result(
- except FutureError:
- print('%r generated an exception: %s' % (url, future.exception()))
+ except FutureError as e:
+ print('%r generated an exception: %s' % (url, e))
Cheers,
Brian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing IDLE from the standard library
Am 12.07.2010 23:21, schrieb Terry Reedy: On 7/12/2010 5:46 AM, Kurt B. Kaiser wrote: On Windows, IDLE opens when you right click / edit a .py. Very useful. On my xp machine with 3.1.2, it edit .py opens with notepad. Perhaps the installer just copies forward the association from long ago, before IDLE was available, or at least so usable. I have thought of changing that, but I do not know what the replacement incantation would be. There should be an Edit with IDLE (sic) context menu item. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library
On Mon, Jul 12, 2010 at 5:42 PM, Michael Foord fuzzy...@voidspace.org.uk wrote: I'm sure Brett will love this idea, but if it was impossible to reimport the script being executed as __main__ with a different name it would solve these problems. Indeed! And I'd be quite content with such a solution, since I consider scripts and modules to be distinct. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com A storm broke loose in my mind. --Albert Einstein ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library
Not normally, no - there's no easy way to connect a checkin message to a committer's email address, There's a one-to-one mapping somewhere. Unfortunately, no: we don't have email addresses of all committers. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library
On 12/07/2010 22:47, Fred Drake wrote: On Mon, Jul 12, 2010 at 5:42 PM, Michael Foord fuzzy...@voidspace.org.uk wrote: I'm sure Brett will love this idea, but if it was impossible to reimport the script being executed as __main__ with a different name it would solve these problems. Indeed! And I'd be quite content with such a solution, since I consider scripts and modules to be distinct. It seems to bite every newbie at some point. The change would have to go through the usual deprecation cycle I guess. All the best, Michael Forod -Fred -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library
On Tue, Jul 13, 2010 at 3:39 AM, Michael Foord fuzzy...@voidspace.org.uk wrote: Not normally, no - there's no easy way to connect a checkin message to a committer's email address, There's a one-to-one mapping somewhere. That somewhere isn't readily available when I hit reply to the checkin email though (for me, somewhere is generally my python-dev archive - I think the actual mapping file is a private one on the SVN server somewhere). so it's usually just a matter of hitting Reply and sending the review comment to the list. With a new committer I'll make the effort to cc them directly in case they aren't subscribed yet, but I expect everyone else to be monitor the checkins list. Without contacting committers, rather than firing into the black depths of a high traffic list, I strongly suspect that much of the feedback is lost. Not that I've noticed. If someone doesn't respond to a comment I've made on python-checkins I'll follow up with them directly and point out that monitoring python-checkins for responses after making a commit is an obligation of making use of commit privileges, just as much as of one as running (at least relevant parts of) the test suite before committing and then checking the buildbots to see you haven't broken anything on other platforms. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library
2010/7/12 Martin v. Löwis mar...@v.loewis.de: Not normally, no - there's no easy way to connect a checkin message to a committer's email address, There's a one-to-one mapping somewhere. Unfortunately, no: we don't have email addresses of all committers. What about the python-committers mailing list? That has at least all the active ones, correct? -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library
On Mon, 12 Jul 2010 17:47:31 -0400 Fred Drake fdr...@acm.org wrote: On Mon, Jul 12, 2010 at 5:42 PM, Michael Foord fuzzy...@voidspace.org.uk wrote: I'm sure Brett will love this idea, but if it was impossible to reimport the script being executed as __main__ with a different name it would solve these problems. Indeed! And I'd be quite content with such a solution, since I consider scripts and modules to be distinct. Except that modules can often be executed as scripts... Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing IDLE from the standard library
On 7/12/2010 5:43 PM, Martin v. Löwis wrote: Am 12.07.2010 23:21, schrieb Terry Reedy: On 7/12/2010 5:46 AM, Kurt B. Kaiser wrote: On Windows, IDLE opens when you right click / edit a .py. Very useful. On my xp machine with 3.1.2, it edit .py opens with notepad. Perhaps the installer just copies forward the association from long ago, before IDLE was available, or at least so usable. I have thought of changing that, but I do not know what the replacement incantation would be. There should be an Edit with IDLE (sic) context menu item. I agree, and thought about requesting such, but there is not and never has been for me that I know of. Actually, I would like Edit with IDLE x.y and Run with x.y so it is easy to test a file with different versions. XP with updates, install for everyone, make install the default Python. Should I open a tracker issue? -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library
On 12/07/2010 22:52, Nick Coghlan wrote: [snip...] so it's usually just a matter of hitting Reply and sending the review comment to the list. With a new committer I'll make the effort to cc them directly in case they aren't subscribed yet, but I expect everyone else to be monitor the checkins list. Without contacting committers, rather than firing into the black depths of a high traffic list, I strongly suspect that much of the feedback is lost. Not that I've noticed. If someone doesn't respond to a comment I've made on python-checkins I'll follow up with them directly and point out that monitoring python-checkins for responses after making a commit is an obligation of making use of commit privileges, just as much as of one as running (at least relevant parts of) the test suite before committing and then checking the buildbots to see you haven't broken anything on other platforms. Given how high traffic python-checkins is I don't consider that a reasonable place to send follow-up and nor do I consider it the responsibility of committers to monitor it. As you said earlier this *isn't* in our standard dev procedures and nor do I think it should be. If you can't find an email address then either python-comitters or python-dev would be a better place to send feedback. Michael Cheers, Nick. -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] avoiding accidental shadowing of top-level libraries by the main module
On Tue, Jul 13, 2010 at 7:47 AM, Fred Drake fdr...@acm.org wrote: On Mon, Jul 12, 2010 at 5:42 PM, Michael Foord fuzzy...@voidspace.org.uk wrote: I'm sure Brett will love this idea, but if it was impossible to reimport the script being executed as __main__ with a different name it would solve these problems. Indeed! And I'd be quite content with such a solution, since I consider scripts and modules to be distinct. And here I've been busily blurring that distinction for years ;) (actually, the whole name == '__main__' idiom meant the distinction was already pretty blurry long before I got involved) I take it the concrete proposal here is if the filename of a new module matches either __main__.__file__ or __main__.__cached__, then that module should be ignored completely for import purposes allowing a module with the same name later on sys.path to be found? I'm not sure I like that, I'd be more inclined to just return the __main__ module in that case rather than letting the search continue further down sys.path (although I agree the current semantics of getting two copies of the same module under different names in this case are less than ideal). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] avoiding accidental shadowing of top-level libraries by the main module
On 12/07/2010 23:05, Nick Coghlan wrote: On Tue, Jul 13, 2010 at 7:47 AM, Fred Drakefdr...@acm.org wrote: On Mon, Jul 12, 2010 at 5:42 PM, Michael Foord fuzzy...@voidspace.org.uk wrote: I'm sure Brett will love this idea, but if it was impossible to reimport the script being executed as __main__ with a different name it would solve these problems. Indeed! And I'd be quite content with such a solution, since I consider scripts and modules to be distinct. And here I've been busily blurring that distinction for years ;) (actually, the whole name == '__main__' idiom meant the distinction was already pretty blurry long before I got involved) I take it the concrete proposal here is if the filename of a new module matches either __main__.__file__ or __main__.__cached__, then that module should be ignored completely for import purposes allowing a module with the same name later on sys.path to be found? An explicit error being raised instead would be just as good. Michael I'm not sure I like that, I'd be more inclined to just return the __main__ module in that case rather than letting the search continue further down sys.path (although I agree the current semantics of getting two copies of the same module under different names in this case are less than ideal). Cheers, Nick. -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library
On Tue, Jul 13, 2010 at 8:04 AM, Michael Foord fuzzy...@voidspace.org.uk wrote: Given how high traffic python-checkins is I don't consider that a reasonable place to send follow-up and nor do I consider it the responsibility of committers to monitor it. As you said earlier this *isn't* in our standard dev procedures and nor do I think it should be. If you can't find an email address then either python-comitters or python-dev would be a better place to send feedback. Umm, yeah it is - Brett's Intro to Development *is* the documentation of the workflow procedures, and it says that committers are expected to subscribe to both python-checkins and python-committers. And, as I said, I've been working this way for years, and haven't seen any of my comments or anyone else's made on python-checkins go unaddressed (although we've occasionally had to follow up by finding the committer's email address and adding it directly, that's fairly rare). It *really* isn't very hard to ignore most of the traffic on that list and just look at your own commits (and any responses). (I don't do that myself unless I'm busy, as I quite like doing after the fact reviews of commits) Bringing the whole of python-dev into a python-checkins discussion is only necessary if there are any actual disagreements regarding a commit (99% of what we spot in post review is just typos in documentation, comments and text strings, as well as minor things like poor choices of internal variable names). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] avoiding accidental shadowing of top-level libraries by the main module
On Tue, Jul 13, 2010 at 8:06 AM, Michael Foord fuzzy...@voidspace.org.uk wrote: An explicit error being raised instead would be just as good. Ah, refusing the temptation to guess. So the idea would be, when attempting to import __main__ under it's original name: 3.2 issue a DeprecationWarning 3.3 raise ImportError It still strikes me as wrong for the base import implementation, but PEP 302 may provide a mechanism for an interpreter shell to add its own newbie protection hooks (and that would have the virtue of being available much earlier and with a much lower chance of breaking anything). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library
On 7/12/2010 5:57 PM, Benjamin Peterson wrote: 2010/7/12 Martin v. Löwismar...@v.loewis.de: Not normally, no - there's no easy way to connect a checkin message to a committer's email address, There's a one-to-one mapping somewhere. Unfortunately, no: we don't have email addresses of all committers. What about the python-committers mailing list? That has at least all the active ones, correct? I put some effort into this a while ago and failed. Not all committers are subscribed, and for those that are we don't have a way of mapping them to names. Ideally I'd like to see a table with tracker id, username, email addresses, real name. But without a way of automatically keeping it up-to-date, I don't think it will happen. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Intended behavior of backlash in raw strings
I'm trying to determine if this is intended behavior: r\ '\\' r'\'' \\' Normally, the quote would end the string, but it gets escaped by the preceding '\'. However, the preceding slash is interpreted as 'not a backslash' because of the raw indicator, so it gets left in verbatim. Note that it works anywhere: rtesting \ backslash and quote 'testing \\ backslash and quote' It happens that this is the behavior I want, but it seemed just as likely to be an error. I tested it with python2.5 and 2.6 and got the same results. Is this something I can count on? Or is it undefined behavior and I should really not be doing it? John =:- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] avoiding accidental shadowing of top-level libraries by the main module
On 12/07/2010 22:59, Antoine Pitrou wrote: On Mon, 12 Jul 2010 17:47:31 -0400 Fred Drakefdr...@acm.org wrote: On Mon, Jul 12, 2010 at 5:42 PM, Michael Foord fuzzy...@voidspace.org.uk wrote: I'm sure Brett will love this idea, but if it was impossible to reimport the script being executed as __main__ with a different name it would solve these problems. Indeed! And I'd be quite content with such a solution, since I consider scripts and modules to be distinct. Except that modules can often be executed as scripts... Allowing a module-executed-as-script to be in sys.modules twice with different names and classes is still a recipe for problems. For example see this blog entry from Phil Hassey, an experienced Python developer, caused by this issue: http://www.philhassey.com/blog/2009/07/16/oddball-python-252-import-issue/ For scripts that need to be in sys.modules with their real name (e.g. modules executed with python -m) the following trivial workaround is possible: if __name__ == '__main__': sys.modules[real_name] = sys.modules['__main__'] That avoids the problem of error messages like: TypeError: unbound method foo() must be called with A instance as first argument (got A instance instead) (Two different classes with the same name created - one from __main__ and one from real_name.) Use cases for *genuinely* reimporting the same module with different names (as different module objects rather than aliases) are relatively rare, and the problem of modules *accidentally* reimporting themselves not that rare. All the best, Michael Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] avoiding accidental shadowing of top-level libraries by the main module
On 12/07/2010 23:23, Nick Coghlan wrote: On Tue, Jul 13, 2010 at 8:06 AM, Michael Foord fuzzy...@voidspace.org.uk wrote: An explicit error being raised instead would be just as good. Ah, refusing the temptation to guess. So the idea would be, when attempting to import __main__ under it's original name: 3.2 issue a DeprecationWarning 3.3 raise ImportError That's what I was suggesting. It still strikes me as wrong for the base import implementation, but PEP 302 may provide a mechanism for an interpreter shell to add its own newbie protection hooks (and that would have the virtue of being available much earlier and with a much lower chance of breaking anything). That would be a nice thing to have for earlier versions of Python. Personally I think the confusion the problem it causes would be nicer fixed. All the best, Michael Cheers, Nick. -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing IDLE from the standard library
On 12/07/2010 23:00, Terry Reedy wrote: On 7/12/2010 5:43 PM, Martin v. Löwis wrote: Am 12.07.2010 23:21, schrieb Terry Reedy: On 7/12/2010 5:46 AM, Kurt B. Kaiser wrote: On Windows, IDLE opens when you right click / edit a .py. Very useful. On my xp machine with 3.1.2, it edit .py opens with notepad. Perhaps the installer just copies forward the association from long ago, before IDLE was available, or at least so usable. I have thought of changing that, but I do not know what the replacement incantation would be. There should be an Edit with IDLE (sic) context menu item. I agree, and thought about requesting such, but there is not and never has been for me that I know of. Actually, I would like Edit with IDLE x.y and Run with x.y so it is easy to test a file with different versions. I have Edit with IDLE as a context menu option for Windows 7 - so it does exist *sometimes*. Either an XP issue or a your system issue I guess. Michael XP with updates, install for everyone, make install the default Python. Should I open a tracker issue? -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing IDLE from the standard library
On 12 July 2010 23:00, Terry Reedy tjre...@udel.edu wrote: On 7/12/2010 5:43 PM, Martin v. Löwis wrote: There should be an Edit with IDLE (sic) context menu item. I agree, and thought about requesting such, but there is not and never has been for me that I know of. There is for me. I think what Martin meant was that the standard install puts one there, and if you don't have one it looks like your install is broken somehow. Actually, I would like Edit with IDLE x.y and Run with x.y so it is easy to test a file with different versions. I'm not sure I would, too much menu clutter. But as an install-time option I'd be OK with it. XP with updates, install for everyone, make install the default Python. Should I open a tracker issue? If you can reproduce it, I guess so. But as I say, I have the entry (Win7, 2.6.3, install for everyone, default Python). So it's not a universal issue. Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library
On Mon, Jul 12 2010, Tal Einat wrote: I have been maintaining my own fork of IDLE for several years and manually keeping it in sync with IDLE (this was simple). The difference is that there was no single major new feature I was working on, such as the addition of a sub-process in IDLE-fork or Noam's addition of auto-completion. I was mostly making relatively minor fixes and changes which were not interrelated. I saw no reason to have them all merged back at once, so I posted patches as soon as I felt they were ready, and did the best I could to get them accepted. I eventually gave up on this process because every patch took far too long to be addressed and finally accepted or rejected, and I realized that most of the work I had done would never be merged back into the mainstream version of IDLE. There were several contributing factors. I decided to stop committing new features in 2.7 and focus on bugs for several reasons. First, IDLE3 needed work to get it running smoothly. Second, committing, forward porting and running the (manual) functional tests on a bunch of small features was a bit of a pain. Third, leaving the new features to IDLE3 was a draw to get people to use the new version. Then, about two years ago, I got buried with PSF/PyCon issues. If you'll look back in the IDLE NEWS, you'll see I was giving your patches quite a bit of attention. So never say never. -- KBK ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library
On Jul 12, 2010, at 5:47 PM, Fred Drake wrote: On Mon, Jul 12, 2010 at 5:42 PM, Michael Foord fuzzy...@voidspace.org.uk wrote: I'm sure Brett will love this idea, but if it was impossible to reimport the script being executed as __main__ with a different name it would solve these problems. Indeed! And I'd be quite content with such a solution, since I consider scripts and modules to be distinct. but ... isn't the whole point of 'python -m' to make scripts and modules _not_ be distinct?___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library
On 7/12/2010 6:04 PM, Michael Foord wrote: Given how high traffic python-checkins is I don't consider that a reasonable place to send follow-up and nor do I consider it the responsibility of committers to monitor it. As you said earlier this *isn't* in our standard dev procedures and nor do I think it should be. If you can't find an email address then either python-comitters or python-dev would be a better place to send feedback. Maybe reply-to on the checkin messages could be set to python-dev. Not sure if that's a mailman feature, though. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing IDLE from the standard library
On 07/12/2010 01:21 PM, Ian Bicking wrote: On Sun, Jul 11, 2010 at 3:38 PM, Ron Adam r...@ronadam.com mailto:r...@ronadam.com wrote: There might be another alternative. Both idle and pydoc are applications (are there others?) that are in the standard library. As such, they or parts of them, are possibly importable to other projects. That restricts changes because a committer needs to consider the chances that a change may break something else. I suggest they be moved out of the lib directory, but still be included with python. (Possibly in the tools directory.) That removes some of the backward compatibility restrictions or at least makes it clear there isn't a need for backward compatibility. I also like this idea. This means Python comes with an IDE out of he box but without the overhead of a management and release process that is built for something very different than a GUI program (the standard library). This would mean that IDLE would be in site-packages, could easily be upgraded using normal tools, and maybe most importantly it could have its own community tools and development process that is more casual (and can more easily integrate new contributors) and higher velocity of changes and releases. Python releases would then ship the most recent stable release of IDLE. Yes, if you follow the guide lines for the rest of the library, anything that is removed needs to be depreciated first and anything thats added needs to be carefully looked at to be sure it doesn't break anything that may depend on it. That is good for the rest of the standard library but really slows things down for an application like idle. Just removing those restrictions would make things a lot simpler and speed things up considerably I think. The site-packages directory is still in the lib path and so things there are still importable. That is why I suggested the tools directory. Another place would be in the same directory the python executable lives. But the exact location isn't really the important thing, having a clear policy on how the upgrade policy differs from the python library is what is needed. Ron Ron ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing IDLE from the standard library
On 7/12/2010 2:05 AM, Martin v. Löwis wrote: What I specifically want right now is Commit Authorization Privilege, especially for IDLE, Not sure who could grant that, but as far as I can: you have it. If I were approved to commit patches directly, then by implication I should be able to approve others doing the same. That is occasionally done now by others, but I wanted to be clear that for the present, the latter is all I could and would do. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] python-checkins
Le lundi 12 juillet 2010 à 23:04 +0100, Michael Foord a écrit : Given how high traffic python-checkins is I don't consider that a reasonable place to send follow-up and nor do I consider it the responsibility of committers to monitor it. You don't have to receive e-mail from it. Just take a look at the archives from time to time after you have done some commits. In a threaded view, it's easy to spot the few messages which aren't commit notifications, since they are the only one not at the top-level. Regatds Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New regex module for 3.2?
On Mon, Jul 12, 2010 at 8:18 AM, Michael Foord fuzzy...@voidspace.org.uk wrote: On 12/07/2010 15:07, Nick Coghlan wrote: On Mon, Jul 12, 2010 at 9:42 AM, Steven D'Apranost...@pearwood.info wrote: On Sun, 11 Jul 2010 09:37:22 pm Eric Smith wrote: re2 comparison is interesting from the point of if it should be included in stdlib. Is it re2 or regex? I don't see having 2 regular expression engines in the stdlib. There's precedence though... the old regex engine and the new re engine were side-by-side for many years before regex was deprecated and finally removed in 2.5. Hypothetically, re2 could similarly be added to the standard library while re is deprecated. re2 deliberately omits some features for efficiency reasons, hence is not even on the table as a possible replacement for the standard library version. If someone is in a position where re2 can solve their problems with the re module, they should also be in a position where they can track it down for themselves. If it has *partial* compatibility, and big enough performance improvements for common cases, it could perhaps be used where the regex doesn't use unsupported features. This would have some extra cost in the compile phase, but would mean Python could ship with two regex engines but only one interface exposed to the programmer... FWIW, this has all been discussed before: http://aspn.activestate.com/ASPN/Mail/Message/python-dev/3829265. In particular, I still believe that, it's not obvious that enough Python regexes would benefit from re2's performance/restrictions tradeoff to make such a hybrid system worthwhile in the long term. (There is no representative corpus of real-world Python regexes weighted for dynamic execution frequency to use in assessing such tradeoffs empirically like there is for JavaScript.) Collin MRAB's module offers a superset of re's features rather than a subset though, so once it has had more of a chance to bake on PyPI it may be worth another look. Cheers, Nick. -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/collinwinter%40google.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library
Kurt B. Kaiser: The tear off menus are ugly as well as being non-standard on all three major platforms. Well, would you discard them? They can (occasionally) be useful. Yes, I would replace the menus with ones missing the tear line. Most of the GUI toolkits experimented with tear-offs (Mac in late 80s, GTK+ up until 2002) and dropped them or hid them in a rarely visited API. The idea initially appeared reasonable (I can have the Run and Check commands available with a single click) but was found to be too confusing in use. IDLE, because it uses a separate top-level window for each file and shell suffers more than most applications. A menu is torn off from one window and always applies to that window but shows no visual affinity with that window: its window is not even activated when a menu command acts on it. Neil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python-checkins replies
On 12/07/2010 23:48, Eric Smith wrote: On 7/12/2010 6:04 PM, Michael Foord wrote: Given how high traffic python-checkins is I don't consider that a reasonable place to send follow-up and nor do I consider it the responsibility of committers to monitor it. As you said earlier this *isn't* in our standard dev procedures and nor do I think it should be. If you can't find an email address then either python-comitters or python-dev would be a better place to send feedback. Maybe reply-to on the checkin messages could be set to python-dev. Not sure if that's a mailman feature, though. I think this would be a good idea. It would be nice to have on-topic traffic here. :-) Michael Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3148 ready for pronouncement [ACCEPTED]
Titus von der Malsburg wrote: None of the examples I found used the pythonic exception style, that's why I assumed that checking the return value is the only possibility. Reading the PEP carefully would have helped. :-) I had to read the pep fairly carefully before I noticed this too, so perhaps it could be made more prominent. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
