Mailman 3 August 2000 - Python-Dev

[Announce] ActivePython 1.6 beta release (fwd)
by David Ascher Aug. 24, 2000

Aug. 24, 2000

It is my pleasure to announce the availability of the beta release of ActivePython 1.6, build 100. This binary distribution, based on Python 1.6b1, is available from ActiveState's website at: http://www.ActiveState.com/Products/ActivePython/ ActiveState is committed to making Python easy to install and use on all major platforms. ActivePython contains the convenience of swift installation, coupled with commonly used modules, providing you with a total package to meets your Python needs. Additionally, for Windows users, ActivePython provides a suite of Windows tools, developed by Mark Hammond. ActivePython is provided in convenient binary form for Windows, Linux and Solaris under a variety of installation packages, available at: http://www.ActiveState.com/Products/ActivePython/Download.html For support information, mailing list subscriptions and archives, a bug reporting system, and fee-based technical support, please go to http://www.ActiveState.com/Products/ActivePython/ Please send us feedback regarding this release, either through the mailing list or through direct email to ActivePython-feedback(a)ActiveState.com. ActivePython is free, and redistribution of ActivePython within your organization is allowed. The ActivePython license is available at http://www.activestate.com/Products/ActivePython/License_Agreement.html and in the software packages. We look forward to your comments and to making ActivePython suit your Python needs in future releases. Thank you, -- David Ascher & the ActivePython team ActiveState Tool Corporation

1 0

Re: anyone tried Python 2.0 with Tk 8.3.2?
by Fredrik Lundh Aug. 23, 2000

Aug. 23, 2000

I wrote: > doesn't work too well for me -- Tkinter._test() tends to hang > when I press quit (not every time, though). the only way to > shut down the process is to reboot. hmm. it looks like it's more likely to hang if the program uses unicode strings. Tkinter._test() hangs about 2 times out of three same goes for a simple test program that passes a unicode string constant (containing Latin-1 chars) to a Label the same test program using a Latin-1 string (which, I suppose, is converted to Unicode inside Tk) hangs in about 1/3 of the runs. the same test program with a pure ASCII string never hangs... confusing. </F>

2 1

Re: anyone tried Python 2.0 with Tk 8.3.2?
by Martin v. Loewis Aug. 23, 2000

Aug. 23, 2000

> hmm. it looks like it's more likely to hang if the program > uses unicode strings. Are you sure it hangs? It may just take a lot of time to determine which font is best to display the strings. Of course, if it is not done after an hour or so, it probably hangs... Alternatively, a debugger could tell what it is actually doing. Regards, Martin

1 0

The Python 1.6 License Explained
by Guido van Rossum Aug. 23, 2000

Aug. 23, 2000

[Also posted to c.l.py] With BeOpen's help, CNRI has prepared a FAQ about the new license which should answer those questions. The official URL for the Python 1.6 license FAQ is http://www.python.org/1.6/license_faq.html (soon on a mirror site near you), but I'm also appending it here. We expect that we will be able to issue the final 1.6 release very soon. We're also working hard on the first beta release of Python 2.0, slated for September 4; the final 2.0 release should be ready in October. See http://www.pythonlabs.com/tech/python2.html for up-to-date 2.0 information. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) Python 1.6 License FAQ This FAQ addresses questions concerning the CNRI Open Source License and its impact on past and future Python releases. The text below has been approved for posting on the Python website and newsgroup by CNRI's president, Dr. Robert E. Kahn. 1.The old Python license from CWI worked well for almost 10 years. Why a new license for Python 1.6? CNRI claims copyright in Python code and documentation from releases 1.3 through 1.6 inclusive. However, for a number of technical reasons, CNRI never formally licensed this work for Internet download, although it did permit Guido to share the results with the Python community. As none of this work was published either, there were no CNRI copyright notices placed on these Python releases prior to 1.6. A CNRI copyright notice will appear on the official release of Python 1.6. The CNRI license was created to clarify for all users that CNRI's intent is to enable Python extensions to be developed in an extremely open form, in the best interests of the Python community. 2.Why isn't the new CNRI license as short and simple as the CWI license? Are there any issues with it? A license is a legally binding document, and the CNRI Open Source License is-- according to CNRI --as simple as they were able to make it at this time while still maintaining a balance between the need for access and other use of Python with CNRI's rights. 3.Are you saying that the CWI license did not protect our rights? CNRI has held copyright and other rights to the code but never codified them into a CNRI-blessed license prior to 1.6. The CNRI Open Source License is a binding contract between CNRI and Python 1.6's users and, unlike the CWI statement, cannot be revoked except for a material breach of its terms. So this provides a licensing certainty to Python users that never really existed before. 4.What is CNRI's position on prior Python releases, e.g. Python 1.5.2? Releases of Python prior to 1.6 were shared with the community without a formal license from CNRI. The CWI Copyright Notice and Permissions statement (which was included with Python releases prior to 1.6b1), as well as the combined CWI-CNRI disclaimer, were required to be included as a condition for using the prior Python software. CNRI does not intend to require users of prior versions of Python to upgrade to 1.6 unless they voluntarily choose to do so. 5.OK, on to the new license. Is it an Open Source license? Yes. The board of the Open Source Initiative certified the CNRI Open Source License as being fully Open Source compliant. 6.Has it been approved by the Python Consortium? Yes, the Python Consortium members approved the new CNRI Open Source License at a meeting of the Python Consortium on Friday, July 21, 2000 in Monterey, California. 7.Is it compatible with the GNU Public License (GPL)? Legal counsel for both CNRI and BeOpen.com believe that it is fully compatible with the GPL. However, the Free Software Foundation attorney and Richard Stallman believe there may be one incompatibility, i.e., the CNRI License specifies a legal venue to interpret its License while the GPL is silent on the issue of jurisdiction. Resolution of this issue is being pursued. 8.So that means it has a GPL-like "copyleft" provision? No. "GPL-compatible" means that code licensed under the terms of the CNRI Open Source License may be combined with GPLed code. The CNRI license imposes fewer restrictions than does the GPL. There is no "copyleft" provision in the CNRI Open Source License. 9.So it supports proprietary ("closed source") use of Python too? Yes, provided you abide by the terms of the CNRI license and also include the CWI Copyright Notice and Permissions Statement. 10.I have some questions about those! First, about the "click to accept" business. What if I have a derivative work that has no GUI? As the text says, "COPYING, INSTALLING OR OTHERWISE USING THE SOFTWARE" also constitutes agreement to the terms of the license, so there is no requirement to use the click to accept button if that is not appropriate. CNRI prefers to offer the software via the Internet by first presenting the License and having a prospective user click an Accept button. Others may offer it in different forms (e.g. CD-ROM) and thus clicking the Accept button is one means but not the only one. 11.Virginia is one of the few states to have adopted the Uniform Computer Information Transactions Act, and paragraph 7 requires that the license be interpreted under Virginia law. Is the "click clause" a way to invoke UCITA? CNRI needs a body of law to define what its License means, and, since its headquarters are in Virginia, Virginia law is a logical choice. The adoption of UCITA in Virginia was not a motivating factor. If CNRI didn't require that its License be interpreted under Virginia law, then anyone could interpret the license under very different laws than the ones under which it is intended to be interpreted. In particular in a jurisdiction that does not recognize general disclaimers of liability (such as in CNRI license's paragraphs 4 and 5). 12.Suppose I embed Python in an application such that the user neither knows nor cares about the existence of Python. Does the install process have to inform my app's users about the CNRI license anyway? No, the license does not specify this. For example, in addition to including the License text in the License file of a program (or in the installer as well), you could just include a reference to it in the Readme file. There is also no need to include the full License text in the program (the License provides for an alternative reference using the specified handle citation). Usage of the software amounts to license acceptance. 13.In paragraph 2, does "provided, however, that CNRI's License Agreement is retained in Python 1.6 beta 1, alone or in any derivative version prepared by Licensee" mean that I can make and retain a derivative version of the license instead? The above statement applies to derivative versions of Python 1.6 beta 1. You cannot revise the CNRI License. You must retain the CNRI License (or their defined reference to it) verbatim. However, you can make derivative works and license them as a whole under a different but compatible license. 14.Since I have to retain the CNRI license in my derivative work, doesn't that mean my work must be released under exactly the same terms as Python? No. Paragraph 1 explicitly names Python 1.6 beta 1 as the only software covered by the CNRI license. Since it doesn't name your derivative work, your derivative work is not bound by the license (except to the extent that it binds you to meet the requirements with respect to your use of Python 1.6). You are, of course, free to add your own license distributing your derivative work under terms similar to the CNRI Open Source License, but you are not required to do so. In other words, you cannot change the terms under which CNRI licenses Python 1.6, and must retain the CNRI License Agreement to make that clear, but you can (via adding your own license) set your own terms for your derivative works. Note that there is no requirement to distribute the Python source code either, if this does not make sense for your application. 15.Does that include, for example, releasing my derivative work under the GPL? Yes, but you must retain the CNRI License Agreement in your work, and it will continue to apply to the Python 1.6 beta 1 portion of your work (as is made explicit in paragraph 1 of the CNRI License). 16.With regard to paragraph 3, what does "make available to the public" mean? If I embed Python in an application and make it available for download on the Internet, does that fit the meaning of this clause? Making the application generally available for download on the Internet would be making it available to the public. 17.In paragraph 3, what does "indicate in any such work the nature of the modifications made to Python 1.6 beta 1" mean? Do you mean I must publish a patch? A textual description? If a description, how detailed must it be? For example, is "Assorted speedups" sufficient? Or "Ported to new architecture"? What if I merely add a new Python module, or C extension module? Does that constitute "a modification" too? What if I just use the freeze tool to change the way the distribution is packaged? Or change the layout of files and directories from the way CNRI ships them? Or change some file names to match my operating system's restrictions? What if I merely use the documentation, as a basis for a brand new implementation of Python? This license clause is in discussion right now. CNRI has stated that the intent is just to have people provide a very high level summary of changes, e.g. includes new features X, Y and Z. There is no requirement for a specific level of detail. Work is in progress to clarify the intent of this clause so as to be clearer as to what the standard is. CNRI has already indicated that whatever has been done in the past to indicate changes in python releases would be sufficient. 18.In paragraph 6, is automatic termination of the license upon material breach immediate? Yes. CNRI preferred to give the users a 60 day period to cure any deficiencies, but this was deemed incompatible with the GPL and CNRI reluctantly agreed to use the automatic termination language instead. 19.Many licenses allow a 30 to 60 day period during which breaches can be corrected. Immediate termination is actually required for GPL compatibility, as the GPL terminates immediately upon a material breach. However, there is little you can do to breach the license based on usage of the code, since almost any usage is allowed by the license. You can breach it by not including the appropriate License information or by misusing CNRI's name and logo - to give two examples. As indicated above, CNRI actually preferred a 60 day cure period but GPL-compatibility required otherwise. In practice, the immediate termination clause is likely to have no substantive effect. Since breaches are simple to cure, most will have no substantive liability associated with them. CNRI can take legal steps to prevent eggregious and persistent offenders from relicensing the code, but this is a step they will not take cavalierly. 20.What if people already downloaded a million copies of my derivative work before CNRI informs me my license has been terminated? What am I supposed to do then? Contact every one of them and tell them to download a new copy? I won't even know who they are! This is really up to the party that chooses to enforce such licensing. With the cure period removed for compliance with the GPL, CNRI is under no obligation to inform you of a termination. If you repair any such breach than you are in conformance with the License. Enforcement of the CNRI License is up to CNRI. Again, there are very few ways to violate the license. 21.Well, I'm not even sure what "material breach" means. What's an example? This is a well-defined legal term. Very few examples of breaches can be given, because the CNRI license imposes very few requirements on you. A clear example is if you violate the requirement in paragraph 2 to retain CNRI's License Agreement (or their defined reference to it) in derivative works. So simply retain the agreement, and you'll have no problem with that. Also, if you don't misuse CNRI's name and logo you'll be fine. 22.OK, I'll retain the License Agreement in my derivative works, Does that mean my users and I then enter into this license agreement too? Yes, with CNRI but not with each other. As explained in paragraph 1, the license is between CNRI and whoever is using Python 1.6 beta 1. 23.So you mean that everyone who uses my derivative work is entering into a contract with CNRI? With respect to the Python 1.6 beta 1 portion of your work, yes. This is what assures their right to use the Python 1.6 beta 1 portion of your work-- which is licensed by CNRI, not by you --regardless of whatever other restrictions you may impose in your license. 24.In paragraph 7, is the name "Python" a "CNRI trademark or trade name"? CNRI has certain trademark rights based on its use of the name Python. CNRI has begun discussing an orderly transition of the www.python.org site with Guido and the trademark matters will be addressed in that context. 25.Will the license change for Python 2.0? BeOpen.com, who is leading future Python development, will make that determination at the appropriate time. Throughout the licensing process, BeOpen.com will be working to keep things as simple and as compatible with existing licenses as possible. BeOpen.com will add its copyright notice to Python but understands the complexities of licensing and so will work to avoid adding any further confusion on any of these issues. This is why BeOpen.com and CNRI are working together now to finalize a license. 26.What about the copyrights? Will CNRI assign its copyright on Python to BeOpen.com or to Guido? If you say you want to clarify the legal status of the code, establishing a single copyright holder would go a long way toward achieving that! There is no need for a single copyright holder. Most composite works involve licensing of rights from parties that hold the rights to others that wish to make use of them. CNRI will retain copyright to its work on Python. CNRI has also worked to get wet signatures for major contributions to Python which assign rights to it, and email agreements to use minor contributions, so that it can license the bulk of the Python system for the public good. CNRI also worked with Guido van Rossum and CWI to clarify the legal status with respect to permissions for Python 1.2 and earlier versions. August 23, 2000

1 0

anyone tried Python 2.0 with Tk 8.3.2?
by Fredrik Lundh Aug. 23, 2000

Aug. 23, 2000

doesn't work too well for me -- Tkinter._test() tends to hang when I press quit (not every time, though). the only way to shut down the process is to reboot. any ideas? (msvc 5, win95). </F>

1 0

Re: [Python-checkins] CVS: python/dist/src README,1.89,1.90
by Thomas Wouters Aug. 23, 2000

Aug. 23, 2000

On Wed, Aug 23, 2000 at 12:01:47PM -0700, Guido van Rossum wrote: > Update of /cvsroot/python/python/dist/src > In directory slayer.i.sourceforge.net:/tmp/cvs-serv31228 > > Modified Files: > README > Log Message: > Updated some URLs; removed mention of copyright (we'll have to add > something in later after that discussion is over); remove explanation > of 2.0 version number. I submit that this file needs some more editing for 2.0. For instance, it mentions that 'some modules' will not compile on old SunOS compilers because they are written in ANSI C. It also has a section on threads which needs to be rewritten to reflect that threads are *on* by default, and explain how to turn them off. I also think it should put some more emphasis on editing Modules/Setup, which is commonly forgotten by newbies. Either that or make some more things 'standard', like '*shared*'. (It mentions '... editing a file, typing make, ...' in the overview, but doesn't actually mention which file to edit until much later, in a sideways kind of way in the machine-specific section, and even later in a separate section.) It also has some teensy small bugs: it says "uncomment" when it should say "comment out" in the Cray T3E section, and it's "glibc2" or "libc6", not "glibc6", in the Linux section. (it's glibc version 2, but the interface number is 6.) I would personally suggest removing that entire section, it's a bit outdated. But the same might go for other sections! -- Thomas Wouters <thomas(a)xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

1 0

Re: [Python-checkins] CVS: python/nondist/peps pep-0204.txt,1.3,1.4
by Thomas Wouters Aug. 23, 2000

Aug. 23, 2000

On Tue, Aug 22, 2000 at 10:42:00PM -0700, Barry Warsaw wrote: > Update of /cvsroot/python/python/nondist/peps > In directory slayer.i.sourceforge.net:/tmp/cvs-serv2158 > > Modified Files: > pep-0204.txt > Log Message: > Editorial review, including: > > - Rearrange and standardize headers > - Removed ^L's > - Spellchecked > - Indentation and formatting > - Added reference to PEP 202 Damn, I'm glad I didn't rewrite it on my laptop yesterday. This looks much better, Barry, thanx ! Want to co-author it ? :) (I really need to get myself some proper (X)Emacs education so I can do cool things like two-spaces-after-finished-sentences too) > Thomas, if the open issues have been decided, they can be `closed' in > this PEP, and then it should probably be marked as Accepted. Well, that would require me to force the open issues, because they haven't been decided. They have hardly been discussed ;) I'm not sure how to properly close them, however. For instance: I would say "not now" to ranges of something other than PyInt objects, and the same to the idea of generators. But the issues remain open for debate in future versions. Should there be a 'closed issues' section, or should I just not mention them and have people start a new PEP and gather the ideas anew when the time comes ? (And a Decisions (either a consensus one or a BDFL one) would be nice on whether the two new PyList_ functions should be part of the API or not. The rest of the issues I can handle.) Don't forget, I'm a newbie in standards texts. Be gentle ;) -- Thomas Wouters <thomas(a)xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

2 1

...and the new name for our favourite little language is...
by Fredrik Lundh Aug. 23, 2000

Aug. 23, 2000

well, see for yourself: http://www.pythonlabs.com/logos.html

5 5

commonprefix - the beast just won't die...
by Skip Montanaro Aug. 23, 2000

Aug. 23, 2000

I reverted the changes to {posix,nt,dos}path.commonprefix this morning, updated the tests (still to be checked in) and was starting to work on documentation changes, when I realized that something Guido said about using dirname to trim to the common directory prefix is probably not correct. Here's an example. The common prefix of ["/usr/local", "/usr/local/bin"] is "/usr/local". If you blindly apply dirname to that (which is what I think Guido suggested as the way to make commonprefix do what I wanted, you wind up with "/usr", which isn't going to be correct on most Unix flavors. Instead, you need to check that the prefix doesn't exist or isn't a directory before applying dirname. (And of course, that only works on the machine containing the paths in question. You should be able to import posixpath on a Mac and feed it Unix-style paths, which you won't be able to check for existence.) Based on this problem, I'm against documenting using dirname to trim the commonprefix output to a directory prefix. I'm going to submit a patch with the test case and minimal documentation changes and leave it at that for now. Skip

3 2

Re: [Python-Dev] ...and the new name for our favourite little language is...
by Jack Jansen Aug. 22, 2000

Aug. 22, 2000

Ah, forget about the snake. It was an invention of those-who-watch-blue-screens, and I guess Guido only jumped on the bandwagon because those-who-gave-us-bluescreens offered him lots of money or something. On Real Machines Python still uses the One And Only True Python Icon, and will continue to do so by popular demand (although those-who-used-to-watch-bluescreens-but-saw-the-light occasionally complain:-). -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

1 0