Login | Register   
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

A Developer's Guide to Python 3.0: Standard Library

The changes to the standard library in Python 3.0 truly "clean house." The results are both more usable and less cluttered.


advertisement
he previous articles in the series covered the most significant changes to the core language and type system and the basic data types in Python 3.0. This article covers the changes to the standard library.

PEP 3108 - Standard Library Reorganization

The Python standard library is one of the strongest libraries around and adequately supports Python's motto of "batteries included." But, over the years some cruft accumulated in the standard library. Python 3.0 takes full advantage of the fact that it's not backwardly compatible, using that lack of compatibility as a way to "clean house." PEP 3108 describes in detail the changes to the standard modules.

Removed modules

For Python 3.0, many older modules were simply removed. These were either already deprecated, or dropped because they weren't used often, or because better alternatives were already available in the standard library or in third-party packages. Many platform-specific modules were removed too, including:
  • The dl module, which has been superseded by ctypes
  • The dircache module, which was rarely used and easily implemented
  • The ihooks module, because it was undocumented and used only by rexec (turned off in Python 2.3 due to security issues), which has now been removed as well.
  • popen2 is gone (use subprocess) as well as sets (use the builtin set and frozenset types)
  • md5 and sha are gone (use hashlib)

Renamed Modules

Other modules were renamed to comply with PEP-8 style (short, all lowercase, and underscores may be used). I'm not particularly fond of this naming convention, which is sometimes referred to as "allwordssmashedtogether" for obvious reasons. For example, SocketServer has been renamed to socketserver. I would prefer a mandatory underscore between words (e.g. socket_server), because I feel that improves readability in a significant way.

Every successful naming scheme I know of has a way to emphasize word boundaries in multi-word names: Lisp uses hyphens (multi-word-name), other common methods are camel-casing (MultiWordName or multiWordName) and underscores, (multi_word_name). The Ada programming language went a little overboard and promotes both capitalization and underscores (Multi_Word_Name). Anyway, whether you like it or not, Python 3.0 adheres to this new official naming convention consistently across the standard library. Some modules are not intended for public consumption; they're used only by other modules from the standard library. These have a single underscore prefix in the name to make their use clearer. For example, markupbase has been renamed to _markupbase.



There were some larger changes where multiple modules have been renamed and moved into a package. For example, Python 3.0's html, http and tkinter packages contain a number of formerly top-level modules. The http.server module now contains the former BaseHTTPServer, CGIHTTPServer, and SimpleHTTPServer. The new urllib package contains functionality from the erstwhile urllib, urllib2, urlparse, and robotparser organized into slightly different modules: urllib.request, urllib.error, urllib.parse, and urllib.robotparser.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap