On Tue, Nov 10, 2009 at 12:10 AM, "Martin v. Löwis" <martin@v.loewis.de> wrote:
Anatoly's question is actually a fair one for python-dev - we're the ones that *ship* Idle, so it is legitimate to ask our reasons for continuing to do so.
OTOH, the second (or, rather, third) question (does anybody think it should be replaced) is indeed on-topic for python-dev.
That is the exact question I have in my mind. Sorry for not being able to state it clearly. I'll be more straightforward next time.
I didn't really answer that question before, so I do now: I have not personally plans to replace it, and I'm skeptical wrt. anybody else's plans unless there is specific code in existence that IDLE could be replaced *with*.
There are a lot of Python editors. It is unlikely that they implement all IDLE features, but I believe that 20% of IDLE features that is used by 80% of users are guaranteed by any editor out of the box. Assuming that they are more extensible than IDLE anyway. (I would say "perfection is achieved when there is nothing more to add...", but I promised to be straightforward). If we filter list of http://wiki.python.org/moin/PythonEditors by language/license/framework, we will be able to see if there is any suitable open source Python code to replace IDLE's. Then there will be another issue - all editors are based upon some frameworks - I didn't see any popular cross-platform GUI toolkits in Python, so we will inevitably face the need to replace Tkinter with other default GUI toolkit. Should we place an editor first and combine the list a of unique features of IDLE that we (as developers) will surely miss OR should we think what GUI framework will be more beneficial for Python users if shipped by default (keeping in mind that we might have to add missing features to whatever editor we choose later)? -- anatoly t.
On 10 Nov, 2009, at 17:20, anatoly techtonik wrote:
On Tue, Nov 10, 2009 at 12:10 AM, "Martin v. Löwis" <martin@v.loewis.de> wrote:
Anatoly's question is actually a fair one for python-dev - we're the ones that *ship* Idle, so it is legitimate to ask our reasons for continuing to do so.
OTOH, the second (or, rather, third) question (does anybody think it should be replaced) is indeed on-topic for python-dev.
That is the exact question I have in my mind. Sorry for not being able to state it clearly. I'll be more straightforward next time.
What's so bad about IDLE that you'd like to replace it? The obvious alternative to replacing IDLE is to fix whatever is wrong with it. I sometimes use IDLE and it's not too bad as a simple Python editor. A major reason for not using it more often is that the keystrokes for my prefered text-editor are in my muscle memory and IDLE is not that much of an improvement over my current habits that I'm willing the re-educate myself. Ronald
On Tue, Nov 10, 2009 at 6:44 PM, Ronald Oussoren <ronaldoussoren@mac.com> wrote:
What's so bad about IDLE that you'd like to replace it?
That was exactly my previous question. You don't use IDLE either, so why not to replace it with something that you can actually use, with something that is at least extensible? So people will be interested to learn and contribute.
The obvious alternative to replacing IDLE is to fix whatever is wrong with it.
It is also obvious that developer would better download a decent editor than bog their mind with once perspective, but now dead technology IDLE was build upon. -- anatoly t.
anatoly techtonik wrote:
why not to replace it with something that you can actually use, with something that is at least extensible? So people will be interested to learn and contribute.
IDLE is written in Python, so it's about as extensible as you can get. Seems to me the only kind of IDE that it makes sense to ship with Python is one that is written in Python and maintained by the core developers. Anything else is best left as a third party package for download by those who want to use it. Tkinter is arguably not a very good basis for it from a technical point of view, but so far all the alternatives are too bloated and/or nonportable to consider bundling with the standard distribution. So the only realistic alternatives at the moment seem to be either IDLE+Tkinter or nothing. Quite likely most experienced developers use something else, and wouldn't care if IDLE were removed and not replaced with anything. But there are benefits to having a standard, lightweight IDE present in most Python installations. Books and tutorials can be designed around it, for example, with fairly high assurance that it will be available to beginners who aren't comfortable finding their way around text editors and command shells. So, I'd say that, like democracy, it's not very good, but it's better than any of the alternatives. :-) -- Greg
On 2009-11-10, at 22:07, Greg Ewing wrote:
So, I'd say that, like democracy, [IDLE is] not very good, but it's better than any of the alternatives. :-)
Speaking purely as a Python user, I am very happy that IDLE is part of the Python distribution. Personally, I use and like emacs too much, and have no use for IDLE for my own programming at all. But I have taught a lot of Python classes, and being able to tell the IT staff `please install Python x.y on the machines in the lab', and then knowing that students have everything they need to do their lab work, is a major plus. (I found that many of the students stayed with IDLE even after their course was over, too.) As a side observation, I think the main reasons why Tk is so resistant to removal from Python (and several other dynamic languages) is that its developers took very seriously the idea of being lightweight and portable, while many other toolkits grew more and more complex. Not all GUI toolkits are like that; I have nice things to say about FLTK, for example. Perhaps one day somebody will do a revision of Tk (sans Tcl) for the 21st century, but until then, Greg's Winston Churchill quote applies not just to IDLE but also to Tk. [`This horse is dead, please stop flogging it.' `No it's not, it's just observing the moratorium'] -- v
On Tue, Nov 10, 2009 at 10:07 PM, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
Seems to me the only kind of IDE that it makes sense to ship with Python is one that is written in Python and maintained by the core developers. Anything else is best left as a third party package for download by those who want to use it.
Tkinter is arguably not a very good basis for it from a technical point of view, but so far all the alternatives are too bloated and/or nonportable to consider bundling with the standard distribution.
So the only realistic alternatives at the moment seem to be either IDLE+Tkinter or nothing.
My immediate reaction? What about stdwin? Then I found this: http://mail.python.org/pipermail/python-dev/2000-October/010113.html
On 11 Nov, 2009, at 2:48, anatoly techtonik wrote:
On Tue, Nov 10, 2009 at 6:44 PM, Ronald Oussoren <ronaldoussoren@mac.com> wrote:
What's so bad about IDLE that you'd like to replace it?
That was exactly my previous question. You don't use IDLE either, so why not to replace it with something that you can actually use, with something that is at least extensible? So people will be interested to learn and contribute.
I don't use IDLE because I'm too used to my current editor, which btw. is the cmd-line version of vim. That offers everything I need from a Python editor. That said, I have used IDLE occasionaly and it works fine for a basic Python environment. IDLE is extensible, I've seen a number of IDLE extensions on the IDLE-dev mailinglist (<http://mail.python.org/mailman/listinfo/idle-dev>). That list would be a better location to discus this. BTW. You still haven't mentioned why you think IDLE should be replaced.
The obvious alternative to replacing IDLE is to fix whatever is wrong with it.
It is also obvious that developer would better download a decent editor than bog their mind with once perspective, but now dead technology IDLE was build upon.
Tk is actively developed, it is not dead technology. Replacing IDLE by an editor which uses another toolkit would either mean that the default editor uses libraries not in the stdlib, or the inclusion of that toolkit in the stdlib. Ronald
anatoly techtonik wrote:
On Tue, Nov 10, 2009 at 12:10 AM, "Martin v. Löwis" <martin@v.loewis.de> wrote:
Anatoly's question is actually a fair one for python-dev - we're the ones that *ship* Idle, so it is legitimate to ask our reasons for continuing to do so.
OTOH, the second (or, rather, third) question (does anybody think it should be replaced) is indeed on-topic for python-dev.
That is the exact question I have in my mind. Sorry for not being able to state it clearly. I'll be more straightforward next time.
I didn't really answer that question before, so I do now: I have not personally plans to replace it, and I'm skeptical wrt. anybody else's plans unless there is specific code in existence that IDLE could be replaced *with*.
There are a lot of Python editors. It is unlikely that they implement all IDLE features, but I believe that 20% of IDLE features that is used by 80% of users are guaranteed by any editor out of the box. Assuming that they are more extensible than IDLE anyway. (I would say "perfection is achieved when there is nothing more to add...", but I promised to be straightforward).
If we filter list of http://wiki.python.org/moin/PythonEditors by language/license/framework, we will be able to see if there is any suitable open source Python code to replace IDLE's.
Why replace IDLE?
Then there will be another issue - all editors are based upon some frameworks - I didn't see any popular cross-platform GUI toolkits in Python, so we will inevitably face the need to replace Tkinter with other default GUI toolkit.
This just *won't* happen. (At least not in the forseeable future.) Better filter your list to only those IDEs that use Tkinter or have a GUI not dependent on packages that aren't already in the standard library. Michael -- http://www.ironpythoninaction.com/
On Tue, Nov 10, 2009 at 9:26 PM, Michael Foord <fuzzyman@voidspace.org.uk> wrote:
Then there will be another issue - all editors are based upon some frameworks - I didn't see any popular cross-platform GUI toolkits in Python, so we will inevitably face the need to replace Tkinter with other default GUI toolkit.
This just *won't* happen. (At least not in the forseeable future.) Better filter your list to only those IDEs that use Tkinter or have a GUI not dependent on packages that aren't already in the standard library.
That is a real stumbling block. There aren't any GUI toolkits in pure Python to be included alongside the editor, and those Tkinter bindings that compiled for every platform are just useless. If there is a reason that we just *won't* let any GUI framework (except Tkinter) slip into Python distribution then of course, any talk about editor is just a waste of time. But I'd like to see is that reason is real to know when to expect the changes. I've done a small research about Tkinter editors to investigate the solution you proposed. http://wiki.python.org/moin/PythonEditors shows that these were made with Tk: Pye - not true, either switched or wrong project, but PyQT4 - http://code.google.com/p/pye-editor/ xRope - GPL and probably worse than IDLE - http://sourceforge.net/projects/xrope/ IDEStudio - enhanced IDLE, dead - http://wiki.python.org/moin/IDEStudio SourceNavigator - GPL, C and not really an editor - http://sourcenav.sourceforge.net/ There is only one perspective project called Leo (with MIT license) that was historically written in Tkinter with the goal (I believe) to construct pure Python editor. It is editor with outlines unique in the way that it is able to rewrite itself literally at runtime. I believe only using such advanced tool one can cope with Tkinter inconsistencies and limitations. Since the beginning Leo has also developed PyQT4 interface. -- anatoly t.
If we filter list of http://wiki.python.org/moin/PythonEditors by language/license/framework, we will be able to see if there is any suitable open source Python code to replace IDLE's.
This is not how it works. We cannot incorporate something into Python without explicit consent and support from the author(s). So for any editor to be incorporated as a replacement (along with all libraries it depends on) we would need a commitment from the author(s) that they support the fork that we create (and eventually abandon their stand-alone release in favor of the fork).
Should we place an editor first and combine the list a of unique features of IDLE that we (as developers) will surely miss OR should we think what GUI framework will be more beneficial for Python users if shipped by default (keeping in mind that we might have to add missing features to whatever editor we choose later)?
I think neither approach can possibly work. It's always the authors of contribution who need to act first. Regards, Martin
On Tue, Nov 10, 2009 at 10:49 PM, "Martin v. Löwis" <martin@v.loewis.de> wrote:
This is not how it works. We cannot incorporate something into Python without explicit consent and support from the author(s). So for any editor to be incorporated as a replacement (along with all libraries it depends on) we would need a commitment from the author(s) that they support the fork that we create (and eventually abandon their stand-alone release in favor of the fork).
Does that mean even if authors of some imaginary editor agree to incorporate their code into Python, the framework that it is built upon will have to be incorporated into Python also (and eventually abandoned at original location)? In this situation I see no way we can provide any decent tools for GUI like for default editor. Thanks for support. -- anatoly t.
anatoly techtonik writes:
Does that mean even if authors of some imaginary editor agree to incorporate their code into Python, the framework that it is built upon will have to be incorporated into Python also (and eventually abandoned at original location)?
I would assume so. How else can Python guarantee its maintenance?
In this situation I see no way we can provide any decent tools for GUI like for default editor.
IDLE *is* a "decent tool". You don't have to like it, but it's good enough to get started. By the time you realize its limitations, you should have a handle on easy_install. The promise is "batteries included." Nobody promised you a nickel metal hydride battery that you can use as a replacement in your Prius.
Does that mean even if authors of some imaginary editor agree to incorporate their code into Python, the framework that it is built upon will have to be incorporated into Python also (and eventually abandoned at original location)?
It depends. It should work the same way as IDLE: it's ok that Tcl/Tk itself is not included in Python, however, Tkinter is. If that imaginary editor has lots of build dependencies that make it really difficult to use it, I would be opposed to including it. If it requires one library that is typically already available on a Linux system, it would be fine with me. Regards, Martin
On 2009-11-10, at 22:17, Martin v. Löwis wrote:
If that imaginary editor has lots of build dependencies that make it really difficult to use it, I would be opposed to including it. If it requires one library that is typically already available on a Linux system, it would be fine with me. s/Linux/Linux, Mac (Aqua, not X11), and Windows/
-- v
Martin v. Löwis wrote:
If that imaginary editor has lots of build dependencies that make it really difficult to use it, I would be opposed to including it. If it requires one library that is typically already available on a Linux system, it would be fine with me.
If I manage to get PyGUI into a practically usable state and it ever gets included in the core distribution, then it might be a viable basis for a modernised version of IDLE. That's probably a fairly long way off, though. -- Greg
participants (8)
-
"Martin v. Löwis" -
anatoly techtonik -
David Robinow -
Greg Ewing -
Michael Foord -
Ronald Oussoren -
Stephen J. Turnbull -
Vincent Manis