[Python-Dev] how about updating PEP 290?
the "Code Migration and Modernization" PEP hasn't been updated for 2.5 and 2.6. http://www.python.org/dev/peps/pep-0290/ surely there's something new in 2.5 and 2.6 that might be worth mentioning? ___ Python-Dev mailing list [email protected] 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 documentation
Barry Warsaw schrieb: > Martin points out that in the past, as part of the release process, > we've built separate downloadable documentation. > > Do we still want to do that for Python 2.6 and 3.0, and if so, how do > we go about doing that? I have this feeling that building the > documentation is much different now than in the past, and I don't > really have a good feel for how it's done now. > > If you think we should release separate downloadable documentation and > can help integrate that into the release project, you just might be a > Documentation Expert . Please let me know if you can help. There is almost everything ready for doing this. There is a "download" page in the HTML docs (that at the moment contains nothing). If you tell me where the downloadable files will be on python.org, I can add them to the "download" page and you only need to build the docs and put them in that location. I've just added a "dist" target to the Doc/ Makefile, so a "make dist" should place all needed files in the Doc/dist directory, from where you can copy them to the desired location. 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 [email protected] 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 documentation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sep 21, 2008, at 6:03 AM, Georg Brandl wrote: Barry Warsaw schrieb: Martin points out that in the past, as part of the release process, we've built separate downloadable documentation. Do we still want to do that for Python 2.6 and 3.0, and if so, how do we go about doing that? I have this feeling that building the documentation is much different now than in the past, and I don't really have a good feel for how it's done now. If you think we should release separate downloadable documentation and can help integrate that into the release project, you just might be a Documentation Expert . Please let me know if you can help. There is almost everything ready for doing this. There is a "download" page in the HTML docs (that at the moment contains nothing). If you tell me where the downloadable files will be on python.org, I can add them to the "download" page and you only need to build the docs and put them in that location. I've just added a "dist" target to the Doc/ Makefile, so a "make dist" should place all needed files in the Doc/ dist directory, from where you can copy them to the desired location. Benjamin has hacked on the release.py script to build and sign the documentation. I haven't tried it yet but it looks like it does a 'make html' and exports that. Given the above, we should change that to 'make dist' and update the PEP to describe scp'ing them to dinsdale:/ftp/python/doc/X.Y using the templates on this page: http://docs.python.org/download.html I notice that for 2.5, we zip'd and tar-bz2'd them. Do we want to also support tgz? We'll have to hack the release script to build the doc zips. I'll try to test drive this whole process soon. Thanks! - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSNYvAXEjvBPtnXfVAQKj/QQApu2YzQLZfpazIb6jPxtWDMnpW99+TrRP miMEwURQmncYWIK1kt9RuBpjszjKKw5x/pP9DEy7Slx+AQq13q1U2Ddi8yQmvWGk Sf3rRxBbgG8QM5H67toB/T6kDtti8C0F0OZZFZpG83nAVZuwtomw7ZYZS2P5Qzq+ eZnW5aANX4g= =HF5j -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Deploying a Python Service on Apache Axis2
Hi guys, Apache Axis2/Java, is a popular open source Web service engine. It currently supports exposing services written in Java, Javascript as Web services. This article [1] discusses the Python data Binding that enable exposing Web services written in Python. [1] - http://wso2.org/library/articles/deploying-python-service-axis2 [2] - http://heshans.blogspot.com/2008/09/wso2-wsfjython-10-alpha.html [3] - http://wso2.org/library/invoking-enterprise-web-services-using-jython -- Regards, Heshan Suriyaarachchi http://heshans.blogspot.com/ ___ Python-Dev mailing list [email protected] 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 documentation
On Sep 21, 2008, at 7:24 AM, Barry Warsaw wrote: I notice that for 2.5, we zip'd and tar-bz2'd them. Do we want to also support tgz? We'll have to hack the release script to build the doc zips. I'll try to test drive this whole process soon. We specifically decided to drop .tgz since it didn't really make sense to have both .tgz and .tar.bz2, and the software to handle .tar.bz2 is widely deployed. -Fred -- Fred Drake ___ Python-Dev mailing list [email protected] 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 documentation
> I notice that for 2.5, we zip'd and tar-bz2'd them. Do we want to also > support tgz? We'll have to hack the release script to build the doc > zips. I'll try to test drive this whole process soon. In addition to the creation of downloadable scripts, there should also be a copy of the documentation online, at http://www.python.org/doc/2.6/ http://www.python.org/doc/3.0/ In addition, some documentation set should show up at http://docs.python.org/ Not sure whether this should be 2.6 or 3.0. Regards, Martin ___ Python-Dev mailing list [email protected] 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 documentation
On Sun, Sep 21, 2008 at 2:12 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: >> I notice that for 2.5, we zip'd and tar-bz2'd them. Do we want to also >> support tgz? We'll have to hack the release script to build the doc >> zips. I'll try to test drive this whole process soon. > > In addition to the creation of downloadable scripts, there should also > be a copy of the documentation online, at > > http://www.python.org/doc/2.6/ > http://www.python.org/doc/3.0/ > > In addition, some documentation set should show up at > > http://docs.python.org/ > > Not sure whether this should be 2.6 or 3.0. Almost certainly 2.6. -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1." ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deploying a Python Service on Apache Axis2
On Sun, Sep 21, 2008 at 7:24 AM, Heshan Suriyaarachchi <[EMAIL PROTECTED]> wrote: > Hi guys, > Apache Axis2/Java, is a popular open source Web service engine. It > currently supports exposing services written in Java, Javascript as Web > services. This article [1] discusses the Python data Binding that enable > exposing Web services written in Python. > > [1] - http://wso2.org/library/articles/deploying-python-service-axis2 > [2] - http://heshans.blogspot.com/2008/09/wso2-wsfjython-10-alpha.html > [3] - http://wso2.org/library/invoking-enterprise-web-services-using-jython > Thanks for the links, Heshan, but python-dev is for discussing the design of Python. For general announcements like this, they should go to comp.lang.python or comp.lang.python.announce (both of which you can get to at Google Groups). -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Possible issue in warnings.py
Does someone who knows the design of warnings.py a bit better than I know whether it would be an improvement to switch from: > try: > file.write(formatwarning(message, category, filename, > lineno, line)) > except IOError: > pass # the file (probably stderr) is invalid > # - this warning gets lost. to: > complaint = formatwarning(message, category, filename, > lineno, line) > try: > file.write(complaint) > except IOError: > pass # the file (probably stderr) is invalid > # - this warning gets lost. on the grounds that you might not want failures in the linecache code to behave the same as failures in writing the complaint to the target area? I'm working on a patch where the Idle warnings code seems to accidentally escalating warnings into errors, and it looked to me like this would accidentally swallow errors getting warning context and make them fail silently. The Idle issue that I'm fiddling with is that it doesn't take the new showwarning call format, and it looked like this should possibly be fixed at the same time. --Scott David Daniels [EMAIL PROTECTED] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Possible issue in warnings.py
On Sun, Sep 21, 2008 at 4:26 PM, Scott David Daniels <[EMAIL PROTECTED]> wrote: > Does someone who knows the design of warnings.py a bit better than I > know whether it would be an improvement to switch from: >> try: >> file.write(formatwarning(message, category, filename, >> lineno, line)) >> except IOError: >> pass # the file (probably stderr) is invalid >> # - this warning gets lost. > > to: >> complaint = formatwarning(message, category, filename, >> lineno, line) >> try: >> file.write(complaint) >> except IOError: >> pass # the file (probably stderr) is invalid >> # - this warning gets lost. > > on the grounds that you might not want failures in the > linecache code to behave the same as failures in writing > the complaint to the target area? > > I'm working on a patch where the Idle warnings code seems to > accidentally escalating warnings into errors, and it looked > to me like this would accidentally swallow errors getting > warning context and make them fail silently. The Idle issue > that I'm fiddling with is that it doesn't take the new > showwarning call format, and it looked like this should > possibly be fixed at the same time. Sounds reasonable. Please file a ticket on the tracker. -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1." ___ Python-Dev mailing list [email protected] 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 documentation
Benjamin Peterson wrote: > On Sun, Sep 21, 2008 at 2:12 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: >>> I notice that for 2.5, we zip'd and tar-bz2'd them. Do we want to also >>> support tgz? We'll have to hack the release script to build the doc >>> zips. I'll try to test drive this whole process soon. >> In addition to the creation of downloadable scripts, there should also >> be a copy of the documentation online, at >> >> http://www.python.org/doc/2.6/ >> http://www.python.org/doc/3.0/ >> >> In addition, some documentation set should show up at >> >> http://docs.python.org/ >> >> Not sure whether this should be 2.6 or 3.0. > > Almost certainly 2.6. Definitely 2.6 - 2.x is still going to be the "mainstream" Python version for a good while yet. Although it may be worth tweaking the main index page for the 2.6 docs to include a cross-link to the 3.0 docs. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] turtle.Screen.__init__ issue
Hello there, its high time to resolve an issue, which I have already addressed twice some weeks ago. (You can find a more elaborate description in my former posting cited below) There is a tiny difference (also in behaviour!) in turtle.Screen.__init__() between the versions for 2.6 and 3.0. The difference results from the fact, that I submitted the 3.0 version approx. a week later, after having it ported to 3.0. In this process I had found what I now consider to be a bug in 2.6 and changed it accordingly. Shortly: If you have already a Screen object containing some turtles and some graphics, in 2.6: s = Screen() returns an object with identical state and behaviour, but clears (re-initializes) the screen and thus destroys the content in 3.0 s = Screen() returns an object with identical state and behaviour, but leaves the content untouched The difference in code consist only in indenting the call of the __init__ method of the parent class, so it will be executed only conditionally. Anyway, as this difference between the two versions is highly undesirable there are (imho) three options to proceed: (1) correct 2.6 in order that it will work like 3.0 (2) undo the change in 3.0 in order that it will work like 2.6 (3) find a different solution for both I would (like Vern, see below) decisevely prefer option (1), and I suppose that there is not enough time left to chose option (3) as this would probably need some discussions. What is your opinion, and who should decide? For your convenience I've attached a diff-file which also contains the description of three other small bugs, which I've found in the meantime and which shouldn't cause any controversies. Regards, Gregor %% Here follows the answer of Vern Ceder - a long term turtle graphics user and author of several patches for the old turtle module - to my former posting: >> Gregor, >> >> I don't feel authoritative on the correctness/appropriateness of the implementation, >> but I do agree completely that behavior b, or what you have in the 3.0 version, >> is vastly preferable. >> >> Cheers, >> Vern Original-Nachricht Betreff:[Python-Dev] turtle.Screen- how to implement best a Singleton Datum: Mon, 18 Aug 2008 10:15:45 +0200 Von:Gregor Lingl <[EMAIL PROTECTED]> An: [email protected] CC: Toby Donaldson <[EMAIL PROTECTED]>, [EMAIL PROTECTED], [EMAIL PROTECTED], Brad Miller <[EMAIL PROTECTED]>, Vern Ceder <[EMAIL PROTECTED]> Hi, this posting - concerning the new turtle module - goes to the Python-Dev and Python-3000 lists and to a couple of 'power users' of turtle graphics, hoping to recieve feedback from the developer's point of view as well as from the user's point of view. Currently the implementations of the turtle.Screen class for Python 2.6 and Python 3.0 differ by a 'tiny' detail with an important difference in behaviour. So clearly this has to be resolved before the final release.(The origin of this difference is, that when I ported turtle.py to Python 3.0 I discovered (and 'fixed') what I now consider to be a bug in the 2.6 version.) I'd like to ask you kindly for your advice to achieve an optimal solution. The posting consists of three parts: 1. Exposition of design goals 2. Problem with the implementation 3. How to solve it? Preliminary remark: I've had some discussions on this topic before but I still do not see a clear solution. Moreover I'm well aware of the fact that using the Singleton pattern is controversial. So ... 1. Exposition of design goals ... why use the Singleton design pattern? The turtle module contains a TurtleScreen class, which implements methods to control the drawing area the turtle is (turtles are) drawing on. It's constructor needs a Tkinter Canvas as argument. In order to avoid the need for users to tinker around with Tkinter stuff there is the Screen(TurtleScreen) class, designed to be used by beginners(students, kids,...), particularly in interactive sessions. A (THE (!)) Screen object is essentially a window containing a scrolled canvas, the TurtleScreen. So it's a ressource which should exist only once. It can be constructed in several ways: - implicitely by calling an arbitrary function derived from a Turtle-method, such as forward(100) or by constructing a Turtle such as bob = Turtle() - implicitely by calling an arbitrary function derived from a Screen method, such as bgcolor("red") - explicitely by calling it's constructor such as s = Screen() Anyway this construction should only happen if a Screen object doesn't exist yet. Now for the pending question: What should happen, when s = Screen() is called explicitely and there exists already 'the' Screen object. (i) Clearly s should get a reference to the existing Screen object, but ... (ii) (a)... should s be reinitialized (this is the case now in Python 2.6), or (b)... should s be left untouched (this is the case now in Python
Re: [Python-Dev] Python documentation
Barry Warsaw schrieb: > On Sep 21, 2008, at 6:03 AM, Georg Brandl wrote: > >> Barry Warsaw schrieb: >>> Martin points out that in the past, as part of the release process, >>> we've built separate downloadable documentation. >>> >>> Do we still want to do that for Python 2.6 and 3.0, and if so, how do >>> we go about doing that? I have this feeling that building the >>> documentation is much different now than in the past, and I don't >>> really have a good feel for how it's done now. >>> >>> If you think we should release separate downloadable documentation >>> and >>> can help integrate that into the release project, you just might be a >>> Documentation Expert . Please let me know if you can help. > >> There is almost everything ready for doing this. There is a "download" >> page in the HTML docs (that at the moment contains nothing). > >> If you tell me where the downloadable files will be on python.org, I >> can >> add them to the "download" page and you only need to build the docs >> and >> put them in that location. I've just added a "dist" target to the Doc/ >> Makefile, so a "make dist" should place all needed files in the Doc/ >> dist >> directory, from where you can copy them to the desired location. > > Benjamin has hacked on the release.py script to build and sign the > documentation. I haven't tried it yet but it looks like it does a > 'make html' and exports that. > > Given the above, we should change that to 'make dist' and update the > PEP to describe scp'ing them to dinsdale:/ftp/python/doc/X.Y using the > templates on this page: http://docs.python.org/download.html I've now completed the download page for the new docs. The file names it expects are currently http://docs.python.org/ftp/python/doc/$version/python-docs-$format.$ext which is what "make dist" generates. If you want to have the version in the filename as well, use "make dist DISTVERSION=2.6" and I'll adapt the download page accordingly. > I notice that for 2.5, we zip'd and tar-bz2'd them. Do we want to > also support tgz? We'll have to hack the release script to build the > doc zips. I'll try to test drive this whole process soon. As Fred says, bz2 should suffice. gzip offers no compression advantage over zip either. I've also dropped the PostScript download versions; I see no compelling reason to use them instead of PDF. 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] turtle.Screen.__init__ issue
> What is your opinion, and who should decide? Please don't post patches to the mailing list. Post them exclusively to bugs.python.org instead. Also, don't post unrelated patches in a single message. Create separate issues in the bug tracker for them. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] turtle.Screen.__init__ issue
Martin v. Löwis schrieb: What is your opinion, and who should decide? Please don't post patches to the mailing list. Post them exclusively to bugs.python.org instead. Ok. But this was meant for illustrative purposes only and not as a patch-submission, which I'll do eventually separately. Sorry Gregor Also, don't post unrelated patches in a single message. Create separate issues in the bug tracker for them. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
