[Python-Dev] Switching dev docs URL to Py3k?
With the trunk closed to new development, should we switch http://docs.python.org/dev/ to show the docs built from the Py3k branch? (The in-development Py3k docs are currently at dev/py3k/) 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] Switching dev docs URL to Py3k?
On Sat, 10 Jul 2010 18:04:32 +1000 Nick Coghlan wrote: > With the trunk closed to new development, should we switch > http://docs.python.org/dev/ to show the docs built from the Py3k > branch? Well, that page already says “Python v3.2a0 documentation” to me. cheers 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] Switching dev docs URL to Py3k?
On Sat, Jul 10, 2010 at 6:27 PM, Antoine Pitrou wrote: > On Sat, 10 Jul 2010 18:04:32 +1000 > Nick Coghlan wrote: > >> With the trunk closed to new development, should we switch >> http://docs.python.org/dev/ to show the docs built from the Py3k >> branch? > > Well, that page already says “Python v3.2a0 documentation” to me. Oops. I guess I should have *looked* before posting that question. Sorry for the noise. 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] Switching dev docs URL to Py3k?
Am 10.07.2010 10:32, schrieb Nick Coghlan: > On Sat, Jul 10, 2010 at 6:27 PM, Antoine Pitrou wrote: >> On Sat, 10 Jul 2010 18:04:32 +1000 >> Nick Coghlan wrote: >> >>> With the trunk closed to new development, should we switch >>> http://docs.python.org/dev/ to show the docs built from the Py3k >>> branch? >> >> Well, that page already says “Python v3.2a0 documentation” to me. > > Oops. I guess I should have *looked* before posting that question. > Sorry for the noise. Also, for "backwards compatibility", /dev/py3k still exists and is a symlink to /dev. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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] query: docstring formatting in python distutils code
On 07/07/2010 12:30 PM, Georg Brandl wrote: Am 07.07.2010 18:09, schrieb Michael Foord: I would say that the major use of docstrings is for interactive help - so interactive readability should be *the most important* (but perhaps not only) factor when considering how to format standard library docstrings. Agreed. However, reST doesn't need to be less readable if the specific inline markup is not used. For example, using `identifier` to refer to a function or *var* to refer to a variable (which is already done at quite a few places) is very readable IMO. Using ``code`` also isn't bad, considering that double quotes are not much different and potentially ambiguous. Overall, I think that we can make stdlib docstrings valid reST -- even if it's reST without much markup -- but valid, so that people pulling in stdlib doc- strings into Sphinx docs won't get ugly warnings. What I would *not* like to see is heavy markup and Sphinx specifics -- that would only make sense if we included the docstrings in the docs, and I don't see that coming. I also agree that interactive help should be the most important factor when writing doc strings for the standard library. Are there any plans to change how pydoc's GUI mode works? Could it use a minimal set of reST to improve it's display? The patch I submitted (*which is waiting to be reviewed) extends the GUI mode so it can show the same info that is available from the help() function. http://bugs.python.org/issue2001 I think the only issues with this patch are what new functions and classes should be part of the public api. * BTW... The bug trackers main links to items with patches, and needing review, doesn't pick up feature requests. 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
[Python-Dev] Removing IDLE from the standard library
Hello, 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. In recent years IDLE has received negligible interest and attention from the Python community. During this time IDLE has slowly gone downhill. The documentation and tutorials grow increasingly out of date. Cross-platform support has degraded with the increasing popularity of OSX and 64-bit platforms. Bugs take months, and sometimes more than a year, to be solved. Features that have since become common-place, such as having a non-intrusive search box instead of a dialog, are obviously and painfully lacking, making IDLE feel clumsy and out-dated. For these reasons, I think it would be fitting to remove IDLE from the standard library. IDLE is no longer recommended to beginners, IMO rightfully so, and this was the main reason for its inclusion in the standard library. Furthermore, if there is little or no interest in developing and maintaining IDLE, it should be removed to avoid having buggy and badly supported software in the standard library. - 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] Removing IDLE from the standard library
On 7/10/2010 7:05 PM, Tal Einat wrote: Hello, I would like to propose removing IDLE from the standard library. -1 I use it daily. On Windows, it works better in many ways than the awful interactive command window, which I almost never use. I would rather the latter be replaced. I have been using IDLE since 2002 and have been doing my best to help maintain and further develop IDLE since 2005. In recent years IDLE has received negligible interest and attention from the Python community. During this time IDLE has slowly gone downhill. I would say that it has not gone uphill. The documentation and tutorials grow increasingly out of date. Cross-platform support has degraded with the increasing popularity of OSX and 64-bit platforms. Does it not work with the 64bit Windows build? Bugs take months, and sometimes more than a year, to be solved. The problem here, it seems to me, is that all issues are autoassigned to an inactive person (KBK) who does not really accept them except once a year or so. I do not know whether all other commiter are unwilling to commit IDLE issues, no matter how obvious and trivial, or if they all think they 'belong' to KBK. If and when I get a development setup, learn how to apply patches, and get commit privileges, I would want to be able to work on IDLE issues. > Features that have since become common-place, such as having a non-intrusive search box instead of a dialog, are obviously and painfully lacking, making IDLE feel clumsy and out-dated. I do not know what you mean here, so the 'lack' is completely unobvious and non-painful to me. The IDLE search/replace box strikes as being as good as that I have seen with other Windows software. For these reasons, I think it would be fitting to remove IDLE from the standard library. IDLE is no longer recommended to beginners, IMO rightfully so, and this was the main reason for its inclusion in the standard library. Is there a superiour replacement that you would recommend to be packaged with the Windows distribution? It would have to have a shell replacement also. Furthermore, if there is little or no interest in developing and maintaining IDLE, it should be removed to avoid having buggy and badly supported software in the standard library. For my day to day use of the shell and editor, there are no serious bugs. -- 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
Hello Tal, > I would like to propose removing IDLE from the standard library. -1. One of the biggest "selling points" for me when switching to python was the "out of the box" working IDE with REPL, syntax highliting and a debugger. The only other candidate I think of to replace IDLE might be IPython. However for novice users who are not used to command line it might be too intimidating. There are my others IDEs out there, some better some worse. However IMO to have one bundled with Python is highly important. > Cross-platform support has degraded with the increasing popularity of OSX and > 64-bit > platforms. I use IDLE on Ubuntu 64bit and before that on OS X 64 bit, never had a problem. Can you give some examples on what do you mean by "cross-platform support"? All the best, -- Miki ___ 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] Can ftp url start with file:// ?
On Fri, Jul 09, 2010 at 02:32:04PM -0400, Fred Drake wrote: > FTP access also more often reflected the actual file hierarchy of the > machine, so trying that path as a system path is more likely to work > that I'd expect to see for HTTP. I see the reason. But I doubt if this is a reliable approach. Also when the scheme begins with file:// it should not be confused with ftp, so I think, that portion of code in urllib which work that way should be removed. The issue8801 was fixed in a different way so that no regression is introduced. For 3.2 release, shall we do way with relying on ftp for file:// scheme ? Currently for a url like file://somehost.domain//filesys/file.txt the flow control considers it a ftp url! The expected behaviour might be throw an exception saying that file:// url wont make any sense if it not localhost or absolute path. What if 'somehost.domain' is actually hostname of the machine? Should file:// be allowed in that case or is it the reason to rely on ftp? But it still does not make much sense to use ftp, because there is no guarantee that ftp service is running in that machine. -- Senthil The whole world is a scab. The point is to pick it constructively. -- Peter Beard ___ 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
2010/7/10 Miki Tebeka : > Hello Tal, > >> I would like to propose removing IDLE from the standard library. > -1. > One of the biggest "selling points" for me when switching to python was the > "out of the box" working IDE with REPL, syntax highliting and a debugger. > The only other candidate I think of to replace IDLE might be IPython. However > for novice users who are not used to command line it might be too > intimidating. > > There are my others IDEs out there, some better some worse. However IMO > to have one bundled with Python is highly important. > >> Cross-platform support has degraded with the increasing popularity of OSX >> and 64-bit >> platforms. > I use IDLE on Ubuntu 64bit and before that on OS X 64 bit, never had a > problem. Can you give > some examples on what do you mean by "cross-platform support"? > 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. I'm mostly sure this has been fixed on versions newer than 2.6.1 (but I hope you agree with me that shouldn't happen with a version distributed on macosx), so my another example is in the form of a question: how functional is the current IDLE debugger when running on a Mac ? -- -- Guilherme H. Polo Goncalves ___ 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 10, 2010, at 9:23 PM, Guilherme Polo wrote: > 2010/7/10 Miki Tebeka : >> Hello Tal, >> >>> I would like to propose removing IDLE from the standard library. >> -1. -1 from me too. IDLE is the tool I almost always used to introduce people to Python. FWIW, I've run in on a Mac and Windows without problems. Raymond ___ 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 Sat, Jul 10, 2010 at 9:23 PM, Guilherme Polo 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. >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. --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] [Idle-dev] Removing IDLE from the standard library
On 11 Jul, 2010, at 6:23, Guilherme Polo wrote: > 2010/7/10 Miki Tebeka : >> Hello Tal, >> >>> I would like to propose removing IDLE from the standard library. >> -1. >> One of the biggest "selling points" for me when switching to python was the >> "out of the box" working IDE with REPL, syntax highliting and a debugger. >> The only other candidate I think of to replace IDLE might be IPython. However >> for novice users who are not used to command line it might be too >> intimidating. >> >> There are my others IDEs out there, some better some worse. However IMO >> to have one bundled with Python is highly important. >> >>> Cross-platform support has degraded with the increasing popularity of OSX >>> and 64-bit >>> platforms. >> I use IDLE on Ubuntu 64bit and before that on OS X 64 bit, never had a >> problem. Can you give >> some examples on what do you mean by "cross-platform support"? >> > > 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. I'm mostly sure this > has been fixed on versions newer than 2.6.1 (but I hope you agree with > me that shouldn't happen with a version distributed on macosx), so my > another example is in the form of a question: how functional is the > current IDLE debugger when running on a Mac ? Apple basicly ships whatever is available at a cutoff point in their release cycle, without much if any involvment of the python-dev community. Have you tested this behaviour with a newer release of IDLE (the current 2.6.x release and the 2.7 release)? Does the IDLE application work for you (in "/Applications/Python X.Y" if you installed using a python.org binary installer)? And most importantly: have you filed bugs about things that don't work for you? If you don't file bugs there is little chance that issues get fixed unless some core developer happens to run into the same issue while having time to work on it. W.r.t. your last question: I don't know, I don't use IDLE or its debugger myself. 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] [Idle-dev] Removing IDLE from the standard library
On 11 Jul, 2010, at 1:05, Tal Einat wrote: > Hello, > > 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. > > In recent years IDLE has received negligible interest and attention from the > Python community. During this time IDLE has slowly gone downhill. The > documentation and tutorials grow increasingly out of date. Cross-platform > support has degraded with the increasing popularity of OSX and 64-bit > platforms. Bugs take months, and sometimes more than a year, to be solved. > Features that have since become common-place, such as having a non-intrusive > search box instead of a dialog, are obviously and painfully lacking, making > IDLE feel clumsy and out-dated. Are their patches that fixes these problems? If not, are their at least issues on python's tracker? > > For these reasons, I think it would be fitting to remove IDLE from the > standard library. IDLE is no longer recommended to beginners, IMO rightfully > so, and this was the main reason for its inclusion in the standard library. > Furthermore, if there is little or no interest in developing and maintaining > IDLE, it should be removed to avoid having buggy and badly supported software > in the standard library. I'm -1 on that. Several books, including fairly recent ones, use IDLE as the IDE for running examples. 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
