Mailman 3 October 2000 - Python-Dev

Re: [XML-SIG] PyXML home page on SF
by Greg Stein 17 Oct '00

17 Oct '00

[ moving from xml-sig to python-dev ] Reality check time... On Tue, Oct 17, 2000 at 12:18:41PM +0200, Nicolas Chauvat wrote: > [maintaining a pythonforge.org would take time and ressources] > > Yes. But I understand a commercial company (BeOpen) has taken over python > development. I think it is the kind of free services they could give > back to the python community. If VA Linux is already offering the service, then how does the community benefit from BeOpen offering the same thing? More importantly: how is BeOpen going to benefit from it? How do they get a business return on that investment? That *will* come into play, you know. Somebody has to pay for those sysadmins and hardware and connectivity. > > > That would be pyxml.pythonforge.org, distutils.pythonforge.org, etc. :-) > > > > I'd personally hope that python.org becomes accessible in that > > way. You could probably have all of the current content there, and > > then also have python.org/projects/pyxml; python.org/users/someone; > > xml.python.org (and whatever other gimmicks they offer). The last I heard, the intent was to move python.org from CNRI to a machine at VA Linux. The content would then become available for the community to work on; possibly through SourceForge facilities. > > One advantage of taking things off SF is that responsiveness of that > > system was really bad. That seems to have improved recently; > > My concern is not about responsiveness as much as distribution (as in > Internet is a distributed system). SourceForge is a great service. Good. > Now are we to host every single open source project on SourceForge ? If we > do so, the day SourceForge closes or changes its policy, or whatever, > every single open source project will be halted or maybe discontinued. There is no way that SF is ever going to close and take all of those projects with it. VA Linux would be see their business instantly vaporized. As ESR is fond to point out: VA Linux has built their business on trust from the community. *ANY* failure to meet that trust will kill their biz. > The people at SourceForge know their job: they provide a good service and > the tools (code+doc) to implement that same service at other places. > > Why wouldn't a community as big an active as python's put up ressources in > common to offer such a useful service, but dedicated to python > development ? There use to be a python.starship.net, maintained by > volunteers, that is now hosted by BeOpen. Why not take the next step ? python.starship.net has historically been a disaster area. Poorly maintained or (even worse) maintained by a whole bunch of people. Have you ever seen what happens when you give 20 people root access? Then there was the time that a drive crashed. The machine was *gone* for months. Oh, and the network connectivity loss. A month offline, maybe? The community is way to busy to run a service. Sorry. That is why I like SF so much. They are ready and willing to run a service and to fund that operation. And to all appearances, they are running it very well (and continually upgrading it!). > > if anybody is to host a similar server, they need to be aware that it > > is probably hard to compete with SF in terms of provided services. For > > example, I trust that SF has a reasonable backup strategy - they They do. It is somewhere on their site. They have a complete backup strategy. In fact, a while back, they lost a drive and restored most of it from backup. I forget if there was any actual material lost. > > simply can't risk a desaster. Anybody hosting a server for just a few > > projects would not get the same sort of trust from me. > > That's why I think we shouldn't look for someone able to host a server for > a few projects but for some company(ies) able to put up the ressources for > "python projects" and volunteers that help them. Idealistic, but it won't happen. starship.net is my case in point. > That would also make it easier for people to look for python ressources: > code in development would be at something.python.org and 3rd party > software at www.vex.net/parnassus. But I would agree that's a weak > argument as long as www.python.org continues to be well-maintained with > no broken links and stays the central hub for python information. When python.org moves, then it will be maintained much better. I don't recall the status of that, but I presume that Guido is still pushing to see it happen. Cheers, -g -- Greg Stein, http://www.lyra.org/

1 0

Wierd buffer "add" behaviour.
by Mark Hammond 17 Oct '00

17 Oct '00

I just struck this, and wonder if it is intentional: * Adding 2 buffer objects together yields a string. Fair enough. * Adding a buffer and a string yields a type error! Eeek. This yields the following strange behaviour: >>> a=buffer('a') >>> a+a 'aa' >>> a+a+a Traceback (innermost last): File "<interactive input>", line 1, in ? TypeError: cannot add type "buffer" to string >>> That doesnt seem correct to me? Mark.

11 18

CVS repository open for business
by Fred L. Drake, Jr. 16 Oct '00

16 Oct '00

The Python CVS repository is now open for further development. If critical patches are needed to the 2.0 release, they should be developed against the branch tagged "release20-maint", and should be posted at SourceForge and discussed here on python-dev before checking them into the branch. Thanks to all the Python developers for your hard work and contributions! -Fred -- Fred L. Drake, Jr. <fdrake at beopen.com> BeOpen PythonLabs Team Member

1 0

Python 2.0 final release is out!
by Guido van Rossum 16 Oct '00

16 Oct '00

I am happy to announce that Python 2.0 is released. I thank my colleagues at BeOpen PythonLabs and the many volunteers in the Python developer community for their incredible work on this release over the past months. Please pick up the new release at http://www.pythonlabs.com/products/python2.0/ There you will find a Windows installer, a source tarball, RedHat RPMs, downloadable and online documentation, and a long list of new features and fixed bugs. Among the new features in Python 2.0 are: - Augmented assignment, e.g. x += 1 - List comprehensions, e.g. [x**2 for x in range(10)] - Extended import statement, e.g. import Module as Name - Extended print statement, e.g. print >> file, "Hello" - Collection of cyclical garbage For a fuller discussion of the changes in Python 2.0 since Python 1.5.2, please see the article "What's New in Python 2.0" by A.M. Kuchling and Moshe Zadka: http://starship.python.net/crew/amk/python/writing/new-python/ All major reported bugs have been fixed in this final release. We've gone through an extremely thorough set of beta releases followed by a release candidate, and therefore we expect that this release will be stable and virtually problem-free. If you nevertheless run into a bug, use the SourceForge bug tracker to report it: http://sourceforge.net/bugs/?group_id=5470 --Guido van Rossum (home page: http://www.python.org/~guido/)

1 0

Python 2.0 final release is out!
by Guido van Rossum 16 Oct '00

16 Oct '00

I am happy to announce that Python 2.0 is released. I thank my colleagues at BeOpen PythonLabs and the many volunteers in the Python developer community for their incredible work on this release over the past months. Please pick up the new release at http://www.pythonlabs.com/products/python2.0/ There you will find a Windows installer, a source tarball, RedHat RPMs, downloadable and online documentation, and a long list of new features and fixed bugs. Among the new features in Python 2.0 are: - Augmented assignment, e.g. x += 1 - List comprehensions, e.g. [x**2 for x in range(10)] - Extended import statement, e.g. import Module as Name - Extended print statement, e.g. print >> file, "Hello" - Collection of cyclical garbage For a fuller discussion of the changes in Python 2.0 since Python 1.5.2, please see the article "What's New in Python 2.0" by A.M. Kuchling and Moshe Zadka: http://starship.python.net/crew/amk/python/writing/new-python/ All major reported bugs have been fixed in this final release. We've gone through an extremely thorough set of beta releases followed by a release candidate, and therefore we expect that this release will be stable and virtually problem-free. If you nevertheless run into a bug, use the SourceForge bug tracker to report it: http://sourceforge.net/bugs/?group_id=5470 --Guido van Rossum (home page: http://www.python.org/~guido/)

1 0

Python 2.1 Release Schedule (tentative)
by Jeremy Hylton 16 Oct '00

16 Oct '00

FYI: In anticpation of the Python 2.0 final release this evening, we just created a new PEP describing the release schedule for Python 2.1. Jeremy PEP: 226 Title: Python 2.1 Release Schedule Version: $Revision: 1.1 $ Author: Jeremy Hylton <jeremy(a)beopen.com> Status: Incomplete Type: Informational Created: 16-Oct-2000 Python-Version: 2.1 Post-History: Abstract This document describes the post Python 2.0 development and release schedule. According to this schedule, Python 2.1 will be released in mid-March of 2001. The schedule primarily concerns itself with PEP-size items. Small bug fixes and changes will occur up until the first beta release. Tentative Release Schedule 16-Oct-2000: Python 2.0 final release These dates represent goals, not commitments. 16-Dec-2000: 2.1 PEPs ready for review 01-Feb-2001: First 2.1 beta release 16-Mar-2001: 2.1 final release Guidelines for making changes for Python 2.1 The guidelines and schedule will be revised based on discussion in the python-dev(a)python.org mailing list. The PEP system was instituted late in the Python 2.0 development cycle and many changes did not follow the process described in PEP 1. The development process for 2.1, however, will follow the PEP process as documented. The first eight weeks following 2.0 final will be the design and review phase. By the end of this period, any PEP that is proposed for 2.1 should be ready for review. This means that the PEP is written and discussion has occurred on the python-dev(a)python.org and python-list(a)python.org mailing lists. The next six weeks will be spent reviewing the PEPs and implementing and testing the accepted PEPs. When this period stops, we will end consideration of any incomplete PEPs. Near the end of this period, there will be a feature freeze where any small features not worthy of a PEP will not be accepted. Before the final release, we will have six weeks of beta testing and a release candidate or two. Bug fix releases before 2.1 We may have to issue Python 2.0.1 for critical bug fixes. If we need to issue a bug fix release, we will use a CVS branch. General guidelines for submitting patches and making changes Use good sense when committing changes. You should know what we mean by good sense or we wouldn't have given you commit privileges <0.5 wink>. Some specific examples of good sense include: - Do whatever the dictator tells you. - Discuss any controversial changes on python-dev first. If you get a lot of +1 votes and no -1 votes, make the change. If you get a some -1 votes, think twice; consider asking Guido what he thinks. - If the change is to code you contributed, it probably makes sense for you to fix it. - If the change affects code someone else wrote, it probably makes sense to ask him or her first. - You can use the SourceForge (SF) Patch Manager to submit a patch and assign it to someone for review. Any significant new feature must be described in a PEP and approved before it is checked in. Any significant code addition, such as a new module or large patch, must include test cases for the regression test and documentation. A patch should not be checked in until the tests and documentation are ready. If you fix a bug, you should write a test case that would have caught the bug. If you commit a patch from the SF Patch Manager or fix a bug from the Jitterbug database, be sure to reference the patch/bug number in the CVS log message. Also be sure to change the status in the patch manager or bug database (if you have access to the bug database). It is not acceptable for any checked in code to cause the regression test to fail. If a checkin causes a failure, it must be fixed within 24 hours or it will be backed out. All contributed C code must be ANSI C. If possible check it with two different compilers, e.g. gcc and MSVC. All contributed Python code must follow Guido's Python style guide. http://www.python.org/doc/essays/styleguide.html It is understood that any code contributed will be released under an Open Source license. Do not contribute code if it can't be released this way.

1 0

2.0 final is nearly ready
by Jeremy Hylton 16 Oct '00

16 Oct '00

There are provisional source tarballs available at ftp://python.beopen.com/pub/python/2.0 These are NOT the source tarballs that we intend to release. They are known to contain old README and Misc/NEWS files. But any reports of successful builds on your platform would be appreciated. I expect to put the final release in place in a few hours; any reports of success after the release will be expected <0.5 wink>. Jeremy

1 0

2.0 final is nearly ready
by Jeremy Hylton 16 Oct '00

16 Oct '00

There are provisional source tarballs available at ftp://python.beopen.com/pub/python/2.0 These are NOT the source tarballs that we intend to release. They are known to contain old README and Misc/NEWS files. But any reports of successful builds on your platform would be appreciated. I expect to put the final release in place in a few hours; any reports of success after the release will be expected <0.5 wink>. Jeremy

1 0

Re: [Python-checkins] CVS: python/dist/src/Lib calendar.py,1.17,1.18
by rob＠hooft.net 16 Oct '00

16 Oct '00

Just checking my E-mail coming back from holidays, I see: diff -C2 -r1.17 -r1.18 *** calendar.py 2000/08/30 14:01:28 1.17 --- calendar.py 2000/10/09 12:42:04 1.18 *************** *** 55,60 **** def leapdays(y1, y2): """Return number of leap years in range [y1, y2). ! Assume y1 <= y2 and no funny (non-leap century) years.""" ! return (y2+3)/4 - (y1+3)/4 def weekday(year, month, day): --- 55,62 ---- def leapdays(y1, y2): """Return number of leap years in range [y1, y2). ! Assume y1 <= y2.""" ! y1 -= 1 ! y2 -= 1 ! return (y2/4 - y1/4) - (y2/100 - y1/100) + (y2/400 - y1/400) def weekday(year, month, day): I am worried about the use of "-=" here. The code basically says: "if the arguments are mutable numeric types, I'd like to modify them in place". In c.l.py it has been stressed multiple times that "-=" is not the same as "= -". I think this is clearly a place where "= -" is preferable over "-=". Even though you might think people will always call this with python integers, you can never be sure enough. Rob -- ===== rob(a)hooft.net http://www.hooft.net/people/rob/ ===== ===== R&D, Nonius BV, Delft http://www.nonius.nl/ ===== ===== PGPid 0xFA19277D ========================== Use Linux! =========

2 1

gettext may fail to find .mo file (was Re: [PATCH] gettext)
by pf＠artcom-gmbh.de 16 Oct '00

16 Oct '00

Hi Ulf, Ulf Betlehem: [...] > ok, I compiled 2.0c1 and tried gettext. Now, there seems to be > a bug in the "normalize and expand" code that can prevent > gettext from finding an existing .mo file. The normalization > is done using a dictionary and therefore the languages get > reordered (as dict keys do). Later when selecting language the > function returns None if 'C' happens to come before the > required languages. I've included a patch to fix this. Your patch looks good to me. Thanks for taking the time to test and contributing the patch. I've submitted your bug report and your patch to sourceforge. See: https://sourceforge.net/bugs/?func=detailbug&bug_id=116964&group_id=5470 https://sourceforge.net/patch/?func=detailpatch&patch_id=101928&group_id=54… Regards, Peter P.S.: Cc to python-dev -- Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260 office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen)

1 0