dcsimg
Linux Today: Linux News On Internet Time.





More on LinuxToday


Python 2.1 alpha 2 released

Feb 05, 2001, 22:23 (0 Talkback[s])
(Other stories by Jeremy Hylton)

WEBINAR:
On-Demand

How to Help Your Business Become an AI Early Adopter


From: Jeremy Hylton jeremy@alum.mit.edu
Newsgroups: comp.lang.python.announce
Subject: Python 2.1 alpha 2 released
To: python-announce-list@python.org
Fri, 2 Feb 2001 18:40:08 -0500 (EST) 
While Guido is working the press circuit at the LinuxWorld Expo in New York City, the Python developers, including the many volunteers and the folks from PythonLabs, were busy finishing the second alpha release of Python 2.1.

The release is currently available from SourceForge and will also be available from python.org later today. You can find the source release at:

http://sourceforge.net/project/showfiles.php?group_id=5470

The Windows installer will be ready shortly.

Fred Drake announced the documentation release earlier today. You can browse the new docs online at

http://python.sourceforge.net/devel-docs/

or download them from

ftp://ftp.python.org/pub/python/doc/2.1a2/

Please give it a good try! The only way Python 2.1 can become a rock-solid product is if people test the alpha releases. If you are using Python for demanding applications or on extreme platforms, we are particularly interested in hearing your feedback. Are you embedding Python or using threads? Please test your application using Python 2.1a2! Please submit all bug reports through SourceForge:

http://sourceforge.net/bugs/?group_id=5470

Here's the NEWS file:

What's New in Python 2.1 alpha 2?


Core language, builtins, and interpreter

- Scopes nest. If a name is used in a function or class, but is not local, the definition in the nearest enclosing function scope will be used. One consequence of this change is that lambda statements could reference variables in the namespaces where the lambda is defined. In some unusual cases, this change will break code.

In all previous version of Python, names were resolved in exactly three namespaces -- the local namespace, the global namespace, and the builtin namespace. According to this old definition, if a function A is defined within a function B, the names bound in B are not visible in A. The new rules make names bound in B visible in A, unless A contains a name binding that hides the binding in B.

Section 4.1 of the reference manual describes the new scoping rules in detail. The test script in Lib/test/test_scope.py demonstrates some of the effects of the change.

The new rules will cause existing code to break if it defines nested functions where an outer function has local variables with the same name as globals or builtins used by the inner function. Example:

    def munge(str):
        def helper(x):
            return str(x)
        if type(str) != type(''):
            str = helper(str)
        return str.strip()
Under the old rules, the name str in helper() is bound to the builtin function str(). Under the new rules, it will be bound to the argument named str and an error will occur when helper() is called.

- The compiler will report a SyntaxError if "from ... import *" occurs in a function or class scope. The language reference has documented that this case is illegal, but the compiler never checked for it. The recent introduction of nested scope makes the meaning of this form of name binding ambiguous. In a future release, the compiler may allow this form when there is no possibility of ambiguity.

- repr(string) is easier to read, now using hex escapes instead of octal, and using \t, \n and \r instead of \011, \012 and \015 (respectively):

  >>> "\texample \r\n" + chr(0) + chr(255)
  '\texample \r\n\x00\xff'         # in 2.1
  '\011example \015\012\000\377'   # in 2.0
- Functions are now compared and hashed by identity, not by value, since the func_code attribute is writable.

- Weak references (PEP 205) have been added. This involves a few changes in the core, an extension module (_weakref), and a Python module (weakref). The weakref module is the public interface. It includes support for "explicit" weak references, proxy objects, and mappings with weakly held values.

- A 'continue' statement can now appear in a try block within the body of a loop. It is still not possible to use continue in a finally clause.

Standard library

- mailbox.py now has a new class, PortableUnixMailbox which is identical to UnixMailbox but uses a more portable scheme for determining From_ separators. Also, the constructors for all the classes in this module have a new optional `factory' argument, which is a callable used when new message classes must be instantiated by the next() method.

- random.py is now self-contained, and offers all the functionality of the now-deprecated whrandom.py. See the docs for details. random.py also supports new functions getstate() and setstate(), for saving and restoring the internal state of the generator; and jumpahead(n), for quickly forcing the internal state to be the same as if n calls to random() had been made. The latter is particularly useful for multi- threaded programs, creating one instance of the random.Random() class for each thread, then using .jumpahead() to force each instance to use a non-overlapping segment of the full period.

- random.py's seed() function is new. For bit-for-bit compatibility with prior releases, use the whseed function instead. The new seed function addresses two problems: (1) The old function couldn't produce more than about 2**24 distinct internal states; the new one about 2**45 (the best that can be done in the Wichmann-Hill generator). (2) The old function sometimes produced identical internal states when passed distinct integers, and there was no simple way to predict when that would happen; the new one guarantees to produce distinct internal states for all arguments in [0, 27814431486576L).

- The socket module now supports raw packets on Linux. The socket family is AF_PACKET.

- test_capi.py is a start at running tests of the Python C API. The tests are implemented by the new Modules/_testmodule.c.

- A new extension module, _symtable, provides provisional access to the internal symbol table used by the Python compiler. A higher-level interface will be added on top of _symtable in a future release.

Windows changes

- Build procedure: the zlib project is built in a different way that ensures the zlib header files used can no longer get out of synch with the zlib binary used. See PCbuild\readme.txt for details. Your old zlib-related directories can be deleted; you'll need to download fresh source for zlib and unpack it into a new directory.

- Build: New subproject _test for the benefit of test_capi.py (see above).

- Build: subproject ucnhash is gone, since the code was folded into the unicodedata subproject.