mirror of
https://github.com/python/cpython.git
synced 2025-08-20 08:41:07 +00:00
Update version of What's New
This commit is contained in:
parent
bb6a0edce1
commit
e69747c630
1 changed files with 27 additions and 17 deletions
|
@ -5,7 +5,7 @@
|
|||
% Fix XXX comments
|
||||
|
||||
\title{What's New in Python 2.5}
|
||||
\release{1.0}
|
||||
\release{1.01}
|
||||
\author{A.M. Kuchling}
|
||||
\authoraddress{\email{amk@amk.ca}}
|
||||
|
||||
|
@ -409,7 +409,7 @@ is always executed, or one or more \keyword{except} blocks to catch
|
|||
specific exceptions. You couldn't combine both \keyword{except} blocks and a
|
||||
\keyword{finally} block, because generating the right bytecode for the
|
||||
combined version was complicated and it wasn't clear what the
|
||||
semantics of the combined should be.
|
||||
semantics of the combined statement should be.
|
||||
|
||||
Guido van~Rossum spent some time working with Java, which does support the
|
||||
equivalent of combining \keyword{except} blocks and a
|
||||
|
@ -556,13 +556,14 @@ generators:
|
|||
where the generator's execution is paused.
|
||||
|
||||
\item \method{close()} raises a new \exception{GeneratorExit}
|
||||
exception inside the generator to terminate the iteration.
|
||||
On receiving this
|
||||
exception, the generator's code must either raise
|
||||
\exception{GeneratorExit} or \exception{StopIteration}; catching the
|
||||
exception and doing anything else is illegal and will trigger
|
||||
a \exception{RuntimeError}. \method{close()} will also be called by
|
||||
Python's garbage collector when the generator is garbage-collected.
|
||||
exception inside the generator to terminate the iteration. On
|
||||
receiving this exception, the generator's code must either raise
|
||||
\exception{GeneratorExit} or \exception{StopIteration}. Catching
|
||||
the \exception{GeneratorExit} exception and returning a value is
|
||||
illegal and will trigger a \exception{RuntimeError}; if the function
|
||||
raises some other exception, that exception is propagated to the
|
||||
caller. \method{close()} will also be called by Python's garbage
|
||||
collector when the generator is garbage-collected.
|
||||
|
||||
If you need to run cleanup code when a \exception{GeneratorExit} occurs,
|
||||
I suggest using a \code{try: ... finally:} suite instead of
|
||||
|
@ -1663,6 +1664,13 @@ single number as \file{pystone.py} does.
|
|||
\item The \module{pyexpat} module now uses version 2.0 of the Expat parser.
|
||||
(Contributed by Trent Mick.)
|
||||
|
||||
\item The \class{Queue} class provided by the \module{Queue} module
|
||||
gained two new methods. \method{join()} blocks until all items in
|
||||
the queue have been retrieved and all processing work on the items
|
||||
have been completed. Worker threads call the other new method,
|
||||
\method{task_done()}, to signal that processing for an item has been
|
||||
completed. (Contributed by Raymond Hettinger.)
|
||||
|
||||
\item The old \module{regex} and \module{regsub} modules, which have been
|
||||
deprecated ever since Python 2.0, have finally been deleted.
|
||||
Other deleted modules: \module{statcache}, \module{tzparse},
|
||||
|
@ -2116,14 +2124,16 @@ The pysqlite module (\url{http://www.pysqlite.org}), a wrapper for the
|
|||
SQLite embedded database, has been added to the standard library under
|
||||
the package name \module{sqlite3}.
|
||||
|
||||
SQLite is a C library that provides a SQL-language database that
|
||||
stores data in disk files without requiring a separate server process.
|
||||
SQLite is a C library that provides a lightweight disk-based database
|
||||
that doesn't require a separate server process and allows accessing
|
||||
the database using a nonstandard variant of the SQL query language.
|
||||
Some applications can use SQLite for internal data storage. It's also
|
||||
possible to prototype an application using SQLite and then port the
|
||||
code to a larger database such as PostgreSQL or Oracle.
|
||||
|
||||
pysqlite was written by Gerhard H\"aring and provides a SQL interface
|
||||
compliant with the DB-API 2.0 specification described by
|
||||
\pep{249}. This means that it should be possible to write the first
|
||||
version of your applications using SQLite for data storage. If
|
||||
switching to a larger database such as PostgreSQL or Oracle is
|
||||
later necessary, the switch should be relatively easy.
|
||||
\pep{249}.
|
||||
|
||||
If you're compiling the Python source yourself, note that the source
|
||||
tree doesn't include the SQLite code, only the wrapper module.
|
||||
|
@ -2150,8 +2160,8 @@ c = conn.cursor()
|
|||
|
||||
# Create table
|
||||
c.execute('''create table stocks
|
||||
(date timestamp, trans varchar, symbol varchar,
|
||||
qty decimal, price decimal)''')
|
||||
(date text, trans text, symbol text,
|
||||
qty real, price real)''')
|
||||
|
||||
# Insert a row of data
|
||||
c.execute("""insert into stocks
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue