O que há de novo no Python 2.0¶
A.M. Kuchling e Moshe Zadka
Uma nova versão do Python, versão 2.0, foi lançada em 16 de outubro de 2000. Este artigo aborda os novos recursos interessantes da versão, destaca algumas outras mudanças úteis e aponta algumas alterações incompatíveis que podem exigir a reescrita do código.
Python’s development never completely stops between releases, and a steady flow of bug fixes and improvements are always being submitted. A host of minor fixes, a few optimizations, additional docstrings, and better error messages went into 2.0; to list them all would be impossible, but they’re certainly significant. Consult the publicly available CVS logs if you want to see the full list. This progress is due to the five developers working for PythonLabs are now getting paid to spend their days fixing bugs, and also due to the improved communication resulting from moving to SourceForge.
E quanto ao Python 1.6?¶
Python 1.6 pode ser considerado a versão de obrigações contratuais do Python. Depois que a equipe de desenvolvimento principal deixou o CNRI em maio de 2000, o CNRI solicitou que uma versão 1.6 fosse criada, contendo todo o trabalho em Python que havia sido executado no CNRI. Python 1.6, portanto, representa o estado da árvore CVS em maio de 2000, com o novo recurso mais significativo sendo o suporte a Unicode. O desenvolvimento continuou depois de maio, é claro, então a árvore 1.6 recebeu algumas correções para garantir que seja compatível com o Python 2.0. 1.6 é, portanto, parte da evolução do Python, e não um ramo secundário.
Então, você deve se interessar muito pelo Python 1.6? Provavelmente não. Os lançamentos 1.6final e 2.0beta1 foram feitos no mesmo dia (5 de setembro de 2000), e o plano era finalizar o Python 2.0 em cerca de um mês. Se você tem aplicativos para manter, parece que não faz muito sentido interromper as coisas mudando para 1.6, consertá-las e, em seguida, ter outra rodada de interrupções em um mês mudando para 2.0; é melhor ir direto para 2.0. A maioria dos recursos realmente interessantes descritos neste documento estão apenas na versão 2.0, porque muito trabalho foi feito entre maio e setembro.
Novo processo de desenvolvimento¶
A mudança mais importante no Python 2.0 pode não ser no código, mas em como o Python é desenvolvido: em maio de 2000, os desenvolvedores do Python começaram a usar as ferramentas disponibilizadas pelo SourceForge para armazenar o código-fonte, rastrear relatórios de bug e gerenciar a fila de envios de patch. Para relatar bugs ou enviar patches para Python 2.0, use o rastreamento de bugs e ferramentas de gerenciamento de patch disponíveis na página do projeto Python, localizada em https://sourceforge.net/projects/python/.
O mais importante dos serviços agora hospedados no SourceForge é a árvore CVS do Python, o repositório controlado por versão que contém o código-fonte do Python. Anteriormente, havia aproximadamente 7 ou mais pessoas que tinham acesso de escrita à árvore CVS, e todos os patches tinham que ser inspecionados e verificados por uma das pessoas nesta pequena lista. Obviamente, isso não era muito escalonável. Ao mover a árvore CVS para o SourceForge, tornou-se possível conceder acesso de escrita a mais pessoas; em setembro de 2000, havia 27 pessoas capazes de verificar as mudanças, um aumento de quatro vezes. Isso possibilita mudanças em grande escala que não seriam tentadas se tivessem que ser filtradas pelo pequeno grupo de desenvolvedores centrais. Por exemplo, um dia Peter Schneider-Kamp pensou em abandonar a compatibilidade K&R C e converter o código-fonte C para Python em ANSI C. Depois de obter aprovação na lista de e-mails python-dev, ele começou uma enxurrada de verificações que duraram cerca de uma semana, outros desenvolvedores juntaram-se para ajudar e o trabalho estava feito. Se houvesse apenas 5 pessoas com acesso de escrita, provavelmente essa tarefa teria sido vista como “legal, mas não vale o tempo e esforço necessários” e nunca teria sido realizada.
A mudança para o uso dos serviços do SourceForge resultou em um aumento notável na velocidade de desenvolvimento. Os patches agora são enviados, comentados, revisados por outras pessoas que não o remetente original e devolvidos para frente e para trás entre as pessoas até que o patch valha a pena ser verificado. Os bugs são rastreados em um local central e podem ser atribuídos a uma pessoa específica para correção, e podemos contar o número de bugs abertos para medir o progresso. Isso não veio sem custo: os desenvolvedores agora têm mais e-mail para lidar, mais listas de e-mail a seguir e ferramentas especiais tiveram que ser escritas para o novo ambiente. Por exemplo, SourceForge envia mensagens de e-mail de notificação de patch e bug padrão que são completamente inúteis, então Ka-Ping Yee escreveu um raspador de tela HTML que envia mensagens mais úteis.
A facilidade de adicionar código causou alguns problemas iniciais de crescimento, como a entrada de código antes de estar pronto ou sem um acordo claro do grupo de desenvolvedores. O processo de aprovação que surgiu é um pouco semelhante ao usado pelo grupo Apache. Os desenvolvedores podem votar +1, +0, -0 ou -1 em um patch; +1 e -1 denotam aceitação ou rejeição, enquanto +0 e -0 significam que o desenvolvedor é indiferente à mudança, embora com uma ligeira inclinação positiva ou negativa. A mudança mais significativa do modelo Apache é que a votação é essencialmente consultiva, permitindo que Guido van Rossum, que tem o status de Ditador Benevolente pela Vida, saiba qual é a opinião geral. Ele ainda pode ignorar o resultado de uma votação e aprovar ou rejeitar uma alteração, mesmo se a comunidade discordar dele.
Producing an actual patch is the last step in adding a new feature, and is usually easy compared to the earlier task of coming up with a good design. Discussions of new features can often explode into lengthy mailing list threads, making the discussion hard to follow, and no one can read every posting to python-dev. Therefore, a relatively formal process has been set up to write Python Enhancement Proposals (PEPs), modelled on the internet RFC process. PEPs are draft documents that describe a proposed new feature, and are continually revised until the community reaches a consensus, either accepting or rejecting the proposal. Quoting from the introduction to PEP 1, “PEP Purpose and Guidelines”:
PEP significa Python Enhancement Proposal. Uma PEP é um documento de design que fornece informações para a comunidade Python ou descreve um novo recurso para Python. A PEP deve fornecer uma especificação técnica concisa do recurso e uma justificativa para o recurso.
Pretendemos que as PEPs sejam os principais mecanismos para propor novos recursos, para coletar a opinião da comunidade sobre um problema e para documentar as decisões de design que foram para o Python. O autor da PEP é responsável por construir consenso dentro da comunidade e documentar opiniões divergentes.
Read the rest of PEP 1 for the details of the PEP editorial process, style, and format. PEPs are kept in the Python CVS tree on SourceForge, though they’re not part of the Python 2.0 distribution, and are also available in HTML form from https://peps.python.org/. As of September 2000, there are 25 PEPS, ranging from PEP 201, “Lockstep Iteration”, to PEP 225, “Elementwise/Objectwise Operators”.
O maior novo recurso no Python 2.0 é um novo tipo de dados fundamental: strings Unicode. O Unicode usa números de 16 bits para representar os caracteres em vez do número de 8 bits usado pelo ASCII, o que significa que 65.536 caracteres distintos podem ser suportados.
A interface final para suporte Unicode foi alcançada por meio de inúmeras discussões frequentemente tempestuosas na lista de discussão python-dev, e implementada principalmente por Marc-André Lemburg, com base na implementação de um tipo de string Unicode por Fredrik Lundh. Uma explicação detalhada da interface foi escrita como PEP 100, “Python Unicode Integration”. Este artigo irá simplesmente cobrir os pontos mais significativos sobre as interfaces Unicode.
No código-fonte do Python, strings Unicode são escritas como
u"string". Caracteres Unicode arbitrários podem ser escritos usando uma nova sequência de escape,
\uHHHH, onde HHHH é um número hexadecimal de 4 dígitos de 0000 a FFFF. A sequência de escape existente
\xHHHH também pode ser usada e escapes octais podem ser usados para caracteres até U+01FF, que é representado por
Strings Unicode, assim como strings regulares, são um tipo de sequência imutável. Elas podem ser indexadas e fatiadas, mas não modificadas no local. Strings Unicode têm um método
encode( [encoding] ) que retorna uma string de 8 bits na codificação desejada. Codificações são nomeadas por strings, como
'iso-8859-1' ou qualquer outra coisa. Uma API de codec é definida para implementar e registrar novas codificações que estarão disponíveis em um programa Python. Se uma codificação não for especificada, a codificação padrão é geralmente ASCII de 7 bits, embora possa ser alterada para sua instalação Python chamando a função
sys.setdefaultencoding(encoding) em uma versão personalizada de
Combinar strings de 8 bits e Unicode sempre força o uso de Unicode, usando a codificação ASCII padrão; o resultado de
'a' + u'bc' é
Novas funções embutidas foram adicionadas e embutidas existentes modificadas para oferecer suporte a Unicode:
unichr(ch)retorna uma string Unicode com 1 caractere, contendo o caractere ch.
ord(u), onde u é uma string regular ou Unicode de 1 caractere, retorna o número do caractere como um inteiro.
unicode(string [, encoding] [, errors] )cria uma string Unicode a partir de uma string de 8 bits.
encodingé uma string que nomeia a codificação a ser usada. O parâmetro
errorsespecifica o tratamento de caracteres que são inválidos para a codificação atual; passar
'strict'como o valor faz com que uma exceção seja levantada em qualquer erro de codificação, enquanto
'ignore'faz com que os erros sejam ignorados silenciosamente e
'replace'usa U+FFFD, o caráter oficial de substituição, em caso de quaisquer problemas.
exec, e vários embutidos como
setattr()também aceitarão strings Unicode assim como strings regulares. (É possível que o processo de consertar isso tenha perdido algumas funções embutidas; se você encontrar uma função embutida que aceita strings, mas não aceita strings Unicode, informe-o como um bug.)
Um novo módulo,
unicodedata, fornece uma interface para as propriedades de caracteres Unicode. Por exemplo,
unicodedata.category(u'A') retorna a string de 2 caracteres ‘Lu’, o ‘L’ denotando sua letra e ‘u’ significando que é em maiúsculo.
unicodedata.bidirectional(u'\u0660') retorna ‘AN’, significando que U+0660 é um número árabe.
codecs contém funções para pesquisar codificações existentes e registrar novas. A menos que você queira implementar uma nova codificação, você usará mais frequentemente a função
codecs.lookup(encoding), a qual retorna uma tupla de 4 elementos:
(encode_func, decode_func, stream_reader, stream_writer).
encode_func é uma função que recebe uma string Unicode e retorna uma tupla de 2 elementos
(string, length). string é uma string de 8 bits que contém uma parte (talvez toda) da string Unicode convertida na codificação fornecida e length informa quanto da string Unicode foi convertida.
decode_func é o oposto de encode_func, pegando uma string de 8 bits e retornando uma tupla de 2 elementos
(ustring, length), consistindo na string Unicode resultante ustring e o inteiro length informando quanto do String de 8 bits foi consumida.
stream_reader is a class that supports decoding input from a stream. stream_reader(file_obj) returns an object that supports the
readlines()methods. These methods will all translate from the given encoding and return Unicode strings.
stream_writer, similarly, is a class that supports encoding output to a stream. stream_writer(file_obj) returns an object that supports the
writelines()methods. These methods expect Unicode strings, translating them to the given encoding on output.
For example, the following code writes a Unicode string into a file, encoding it as UTF-8:
import codecs unistr = u'\u0660\u2000ab ...' (UTF8_encode, UTF8_decode, UTF8_streamreader, UTF8_streamwriter) = codecs.lookup('UTF-8') output = UTF8_streamwriter( open( '/tmp/output', 'wb') ) output.write( unistr ) output.close()
The following code would then read UTF-8 input from the file:
input = UTF8_streamreader( open( '/tmp/output', 'rb') ) print repr(input.read()) input.close()
Unicode-aware regular expressions are available through the
which has a new underlying implementation called SRE written by Fredrik Lundh of
Secret Labs AB.
-U command line option was added which causes the Python compiler to
interpret all string literals as Unicode string literals. This is intended to be
used in testing and future-proofing your Python code, since some future version
of Python may drop support for 8-bit strings and provide only Unicode strings.
Compreensões de lista¶
Lists are a workhorse data type in Python, and many programs manipulate a list at some point. Two common operations on lists are to loop over them, and either pick out the elements that meet a certain criterion, or apply some function to each element. For example, given a list of strings, you might want to pull out all the strings containing a given substring, or strip off trailing whitespace from each line.
filter() functions can be used for this
purpose, but they require a function as one of their arguments. This is fine if
there’s an existing built-in function that can be passed directly, but if there
isn’t, you have to create a little function to do the required work, and
Python’s scoping rules make the result ugly if the little function needs
additional information. Take the first example in the previous paragraph,
finding all the strings in the list containing a given substring. You could
write the following to do it:
# Given the list L, make a list of all strings # containing the substring S. sublist = filter( lambda s, substring=S: string.find(s, substring) != -1, L)
Because of Python’s scoping rules, a default argument is used so that the
anonymous function created by the
lambda expression knows what
substring is being searched for. List comprehensions make this cleaner:
sublist = [ s for s in L if string.find(s, S) != -1 ]
List comprehensions have the form:
[ expression for expr in sequence1 for expr2 in sequence2 ... for exprN in sequenceN if condition ]
in clauses contain the sequences to be
iterated over. The sequences do not have to be the same length, because they
are not iterated over in parallel, but from left to right; this is explained
more clearly in the following paragraphs. The elements of the generated list
will be the successive values of expression. The final
is optional; if present, expression is only evaluated and added to the result
if condition is true.
To make the semantics very clear, a list comprehension is equivalent to the following Python code:
for expr1 in sequence1: for expr2 in sequence2: ... for exprN in sequenceN: if (condition): # Append the value of # the expression to the # resulting list.
This means that when there are multiple
clauses, the resulting list will be equal to the product of the lengths of all
the sequences. If you have two lists of length 3, the output list is 9 elements
seq1 = 'abc' seq2 = (1,2,3) >>> [ (x,y) for x in seq1 for y in seq2] [('a', 1), ('a', 2), ('a', 3), ('b', 1), ('b', 2), ('b', 3), ('c', 1), ('c', 2), ('c', 3)]
To avoid introducing an ambiguity into Python’s grammar, if expression is creating a tuple, it must be surrounded with parentheses. The first list comprehension below is a syntax error, while the second one is correct:
# Syntax error [ x,y for x in seq1 for y in seq2] # Correct [ (x,y) for x in seq1 for y in seq2]
The idea of list comprehensions originally comes from the functional programming language Haskell (https://www.haskell.org). Greg Ewing argued most effectively for adding them to Python and wrote the initial list comprehension patch, which was then discussed for a seemingly endless time on the python-dev mailing list and kept up-to-date by Skip Montanaro.
Augmented assignment operators, another long-requested feature, have been added
to Python 2.0. Augmented assignment operators include
and so forth. For example, the statement
a += 2 increments the value of the
a by 2, equivalent to the slightly lengthier
a = a + 2.
The full list of supported assignment operators is
classes can override the augmented assignment operators by defining methods
__isub__(), etc. For example, the following
Number class stores a number and supports using += to create a new
instance with an incremented value.
class Number: def __init__(self, value): self.value = value def __iadd__(self, increment): return Number( self.value + increment) n = Number(5) n += 3 print n.value
__iadd__() special method is called with the value of the increment,
and should return a new instance with an appropriately modified value; this
return value is bound as the new value of the variable on the left-hand side.
Augmented assignment operators were first introduced in the C programming language, and most C-derived languages, such as awk, C++, Java, Perl, and PHP also support them. The augmented assignment patch was implemented by Thomas Wouters.
Métodos de string¶
Until now string-manipulation functionality was in the
which was usually a front-end for the
strop module written in C. The
addition of Unicode posed a difficulty for the
strop module, because the
functions would all need to be rewritten in order to accept either 8-bit or
Unicode strings. For functions such as
string.replace(), which takes 3
string arguments, that means eight possible permutations, and correspondingly
Instead, Python 2.0 pushes the problem onto the string type, making string manipulation functionality available through methods on both 8-bit strings and Unicode strings.
>>> 'andrew'.capitalize() 'Andrew' >>> 'hostname'.replace('os', 'linux') 'hlinuxtname' >>> 'moshe'.find('sh') 2
One thing that hasn’t changed, a noteworthy April Fools’ joke notwithstanding, is that Python strings are immutable. Thus, the string methods return new strings, and do not modify the string on which they operate.
string module is still around for backwards compatibility, but it
mostly acts as a front-end to the new string methods.
Two methods which have no parallel in pre-2.0 versions, although they did exist
in JPython for quite some time, are
s.startswith(t) is equivalent to
s[:len(t)] == t, while
s.endswith(t) is equivalent to
s[-len(t):] == t.
One other method which deserves special mention is
join() method of a string receives one parameter, a sequence of strings,
and is equivalent to the
string.join() function from the old
module, with the arguments reversed. In other words,
equivalent to the old
Garbage Collection of Cycles¶
The C implementation of Python uses reference counting to implement garbage collection. Every Python object maintains a count of the number of references pointing to itself, and adjusts the count as references are created or destroyed. Once the reference count reaches zero, the object is no longer accessible, since you need to have a reference to an object to access it, and if the count is zero, no references exist any longer.
Reference counting has some pleasant properties: it’s easy to understand and implement, and the resulting implementation is portable, fairly fast, and reacts well with other libraries that implement their own memory handling schemes. The major problem with reference counting is that it sometimes doesn’t realise that objects are no longer accessible, resulting in a memory leak. This happens when there are cycles of references.
Consider the simplest possible cycle, a class instance which has a reference to itself:
instance = SomeClass() instance.myself = instance
After the above two lines of code have been executed, the reference count of
instance is 2; one reference is from the variable named
the other is from the
myself attribute of the instance.
If the next line of code is
del instance, what happens? The reference count
instance is decreased by 1, so it has a reference count of 1; the
reference in the
myself attribute still exists. Yet the instance is no
longer accessible through Python code, and it could be deleted. Several objects
can participate in a cycle if they have references to each other, causing all of
the objects to be leaked.
Python 2.0 fixes this problem by periodically executing a cycle detection
algorithm which looks for inaccessible cycles and deletes the objects involved.
gc module provides functions to perform a garbage collection,
obtain debugging statistics, and tuning the collector’s parameters.
Running the cycle detection algorithm takes some time, and therefore will result
in some additional overhead. It is hoped that after we’ve gotten experience
with the cycle collection from using 2.0, Python 2.1 will be able to minimize
the overhead with careful tuning. It’s not yet obvious how much performance is
lost, because benchmarking this is tricky and depends crucially on how often the
program creates and destroys objects. The detection of cycles can be disabled
when Python is compiled, if you can’t afford even a tiny speed penalty or
suspect that the cycle collection is buggy, by specifying the
--without-cycle-gc switch when running the configure
Several people tackled this problem and contributed to a solution. An early implementation of the cycle detection approach was written by Toby Kelsey. The current algorithm was suggested by Eric Tiedemann during a visit to CNRI, and Guido van Rossum and Neil Schemenauer wrote two different implementations, which were later integrated by Neil. Lots of other people offered suggestions along the way; the March 2000 archives of the python-dev mailing list contain most of the relevant discussion, especially in the threads titled “Reference cycle collection for Python” and “Finalization again”.
Other Core Changes¶
Various minor changes have been made to Python’s syntax and built-in functions. None of the changes are very far-reaching, but they’re handy conveniences.
Alterações Menores na Linguagem¶
A new syntax makes it more convenient to call a given function with a tuple of
arguments and/or a dictionary of keyword arguments. In Python 1.5 and earlier,
you’d use the
apply() built-in function:
apply(f, args, kw) calls the
f() with the argument tuple args and the keyword arguments in
the dictionary kw.
apply() is the same in 2.0, but thanks to a patch
from Greg Ewing,
f(*args, **kw) is a shorter and clearer way to achieve the
same effect. This syntax is symmetrical with the syntax for defining
def f(*args, **kw): # args is a tuple of positional args, # kw is a dictionary of keyword args ...
>> file, similar to the
redirection operator in Unix shells. Previously you’d either have to use the
write() method of the file-like object, which lacks the convenience and
sys.stdout and then restore the old value. For sending output to standard
error, it’s much easier to write this:
print >> sys.stderr, "Warning: action field not supplied"
Modules can now be renamed on importing them, using the syntax
as name or
from module import name as othername. The patch was submitted
by Thomas Wouters.
A new format style is available when using the
% operator; ‘%r’ will insert
repr() of its argument. This was also added from symmetry
considerations, this time for symmetry with the existing ‘%s’ format style,
which inserts the
str() of its argument. For example,
'%r %s' % ('abc',
'abc') returns a string containing
Previously there was no way to implement a class that overrode Python’s built-in
in operator and implemented a custom version.
obj in seq returns
true if obj is present in the sequence seq; Python computes this by simply
trying every index of the sequence until either obj is found or an
IndexError is encountered. Moshe Zadka contributed a patch which adds a
__contains__() magic method for providing a custom implementation for
in. Additionally, new built-in objects written in C can define what
in means for them via a new slot in the sequence protocol.
Earlier versions of Python used a recursive algorithm for deleting objects. Deeply nested data structures could cause the interpreter to fill up the C stack and crash; Christian Tismer rewrote the deletion logic to fix this problem. On a related note, comparing recursive objects recursed infinitely and crashed; Jeremy Hylton rewrote the code to no longer crash, producing a useful result instead. For example, after this code:
a =  b =  a.append(a) b.append(b)
a==b returns true, because the two recursive data structures
are isomorphic. See the thread “trashcan and PR#7” in the April 2000 archives of
the python-dev mailing list for the discussion leading up to this
implementation, and some useful relevant links. Note that comparisons can now
also raise exceptions. In earlier versions of Python, a comparison operation
cmp(a,b) would always produce an answer, even if a user-defined
__cmp__() method encountered an error, since the resulting exception would
simply be silently swallowed.
Work has been done on porting Python to 64-bit Windows on the Itanium processor,
mostly by Trent Mick of ActiveState. (Confusingly,
sys.platform is still
'win32' on Win64 because it seems that for ease of porting, MS Visual C++
treats code as 32 bit on Itanium.) PythonWin also supports Windows CE; see the
Python CE page at https://pythonce.sourceforge.net/ for more information.
Another new platform is Darwin/MacOS X; initial support for it is in Python 2.0. Dynamic loading works, if you specify “configure –with-dyld –with-suffix=.x”. Consult the README in the Python source distribution for more instructions.
An attempt has been made to alleviate one of Python’s warts, the often-confusing
NameError exception when code refers to a local variable before the
variable has been assigned a value. For example, the following code raises an
exception on the
NameError exception is raised, while 2.0 raises a new
UnboundLocalError is a subclass of
NameError, so any existing code that expects
NameError to be
raised should still work.
def f(): print "i=",i i = i + 1 f()
Two new exceptions,
IndentationError, have been
introduced. They’re both subclasses of
SyntaxError, and are raised when
Python code is found to be improperly indented.
Changes to Built-in Functions¶
A new built-in,
zip(seq1, seq2, ...), has been added.
returns a list of tuples where each tuple contains the i-th element from each of
the argument sequences. The difference between
seq1, seq2) is that
map() pads the sequences with
None if the
sequences aren’t all of the same length, while
zip() truncates the
returned list to the length of the shortest argument sequence.
long() functions now accept an optional “base”
parameter when the first argument is a string.
int('123', 10) returns 123,
int('123', 16) returns 291.
int(123, 16) raises a
TypeError exception with the message “can’t convert non-string with
A new variable holding more detailed version information has been added to the
sys.version_info is a tuple
(major, minor, micro,
level, serial) For example, in a hypothetical 2.0.1beta1,
(2, 0, 1, 'beta', 1). level is a string such as
"final" for a final release.
Dictionaries have an odd new method,
setdefault(key, default), which
behaves similarly to the existing
get() method. However, if the key is
setdefault() both returns the value of default as
would do, and also inserts it into the dictionary as the value for key. Thus,
the following lines of code:
if dict.has_key( key ): return dict[key] else: dict[key] =  return dict[key]
can be reduced to a single
return dict.setdefault(key, ) statement.
The interpreter sets a maximum recursion depth in order to catch runaway
recursion before filling the C stack and causing a core dump or GPF..
Previously this limit was fixed when you compiled Python, but in 2.0 the maximum
recursion depth can be read and modified using
sys.setrecursionlimit(). The default value is 1000, and a rough maximum
value for a given platform can be found by running a new script,
Porting to 2.0¶
New Python releases try hard to be compatible with previous releases, and the record has been pretty good. However, some changes are considered useful enough, usually because they fix initial design decisions that turned out to be actively mistaken, that breaking backward compatibility can’t always be avoided. This section lists the changes in Python 2.0 that may cause old Python code to break.
The change which will probably break the most code is tightening up the
arguments accepted by some methods. Some methods would take multiple arguments
and treat them as a tuple, particularly various list methods such as
insert(). In earlier versions of Python, if
L.append( 1,2 ) appends the tuple
(1,2) to the list. In Python
2.0 this causes a
TypeError exception to be raised, with the message:
‘append requires exactly 1 argument; 2 given’. The fix is to simply add an
extra set of parentheses to pass both values as a tuple:
L.append( (1,2) ).
The earlier versions of these methods were more forgiving because they used an
old function in Python’s C interface to parse their arguments; 2.0 modernizes
them to use
PyArg_ParseTuple(), the current argument parsing function,
which provides more helpful error messages and treats multi-argument calls as
errors. If you absolutely must use 2.0 but can’t fix your code, you can edit
Objects/listobject.c and define the preprocessor symbol
NO_STRICT_LIST_APPEND to preserve the old behaviour; this isn’t recommended.
Some of the functions in the
socket module are still forgiving in this
way. For example,
socket.connect( ('hostname', 25) )() is the correct
form, passing a tuple representing an IP address, but
'hostname', 25 )() also works.
are similarly easy-going. 2.0alpha1 tightened these functions up, but because
the documentation actually used the erroneous multiple argument form, many
people wrote code which would break with the stricter checking. GvR backed out
the changes in the face of public reaction, so for the
socket module, the
documentation was fixed and the multiple argument form is simply marked as
deprecated; it will be tightened up again in a future Python version.
\x escape in string literals now takes exactly 2 hex digits. Previously
it would consume all the hex digits following the ‘x’ and take the lowest 8 bits
of the result, so
\x123456 was equivalent to
NameError exceptions have a more friendly
error message, whose text will be something like
'Spam' instance has no
attribute 'eggs' or
name 'eggs' is not defined. Previously the error
message was just the missing attribute name
eggs, and code written to take
advantage of this fact will break in 2.0.
Some work has been done to make integers and long integers a bit more
interchangeable. In 1.5.2, large-file support was added for Solaris, to allow
reading files larger than 2 GiB; this made the
tell() method of file
objects return a long integer instead of a regular integer. Some code would
subtract two file offsets and attempt to use the result to multiply a sequence
or slice a string, but this raised a
TypeError. In 2.0, long integers
can be used to multiply or slice a sequence, and it’ll behave as you’d
intuitively expect it to;
3L * 'abc' produces ‘abcabcabc’, and
(0,1,2,3)[2L:4L] produces (2,3). Long integers can also be used in various
contexts where previously only integers were accepted, such as in the
seek() method of file objects, and in the formats supported by the
%x, etc.). For example,
"%d" % 2L**64 will
produce the string
The subtlest long integer change of all is that the
str() of a long
integer no longer has a trailing ‘L’ character, though
includes it. The ‘L’ annoyed many people who wanted to print long integers that
looked just like regular integers, since they had to go out of their way to chop
off the character. This is no longer a problem in 2.0, but code which does
str(longval)[:-1] and assumes the ‘L’ is there, will now lose the final
repr() of a float now uses a different formatting precision
%.17g format string for C’s
%.12g as before. The effect is that
repr() may occasionally show more decimal places than
certain numbers. For example, the number 8.1 can’t be represented exactly in
'8.0999999999999996', while str(8.1) is
-X command-line option, which turned all standard exceptions into
strings instead of classes, has been removed; the standard exceptions will now
always be classes. The
exceptions module containing the standard
exceptions was translated from Python to a built-in C module, written by Barry
Warsaw and Fredrik Lundh.
Some of the changes are under the covers, and will only be apparent to people writing C extension modules or embedding a Python interpreter in a larger application. If you aren’t dealing with Python’s C API, you can safely skip this section.
The version number of the Python C API was incremented, so C extensions compiled for 1.5.2 must be recompiled in order to work with 2.0. On Windows, it’s not possible for Python 2.0 to import a third party extension built for Python 1.5.x due to how Windows DLLs work, so Python will raise an exception and the import will fail.
Users of Jim Fulton’s ExtensionClass module will be pleased to find out that
hooks have been added so that ExtensionClasses are now supported by
issubclass(). This means you no longer have to
remember to write code such as
if type(obj) == myExtensionClass, but can use
the more natural
if isinstance(obj, myExtensionClass).
Python/importdl.c file, which was a mass of #ifdefs to support
dynamic loading on many different platforms, was cleaned up and reorganised by
importdl.c is now quite small, and platform-specific code
has been moved into a bunch of
Python/dynload_*.c files. Another
cleanup: there were also a number of
my*.h files in the Include/
directory that held various portability hacks; they’ve been merged into a single
Vladimir Marangozov’s long-awaited malloc restructuring was completed, to make
it easy to have the Python interpreter use a custom allocator instead of C’s
malloc(). For documentation, read the comments in
Include/objimpl.h. For the lengthy
discussions during which the interface was hammered out, see the web archives of
the ‘patches’ and ‘python-dev’ lists at python.org.
Recent versions of the GUSI development environment for MacOS support POSIX
threads. Therefore, Python’s POSIX threading support now works on the
Macintosh. Threading support using the user-space GNU
pth library was also
Threading support on Windows was enhanced, too. Windows supports thread locks that use kernel objects only in case of contention; in the common case when there’s no contention, they use simpler functions which are an order of magnitude faster. A threaded version of Python 1.5.2 on NT is twice as slow as an unthreaded version; with the 2.0 changes, the difference is only 10%. These improvements were contributed by Yakov Markovitch.
Python 2.0’s source now uses only ANSI C prototypes, so compiling Python now requires an ANSI C compiler, and can no longer be done using a compiler that only supports K&R C.
Previously the Python virtual machine used 16-bit numbers in its bytecode,
limiting the size of source files. In particular, this affected the maximum
size of literal lists and dictionaries in Python source; occasionally people who
are generating Python code would run into this limit. A patch by Charles G.
Waldman raises the limit from
Three new convenience functions intended for adding constants to a module’s
dictionary at module initialization time were added:
of these functions takes a module object, a null-terminated C string containing
the name to be added, and a third argument for the value to be assigned to the
name. This third argument is, respectively, a Python object, a C long, or a C
A wrapper API was added for Unix-style signal handlers.
a signal handler and
PyOS_setsig() will set a new handler.
Distutils: Making Modules Easy to Install¶
Before Python 2.0, installing modules was a tedious affair – there was no way to figure out automatically where Python is installed, or what compiler options to use for extension modules. Software authors had to go through an arduous ritual of editing Makefiles and configuration files, which only really work on Unix and leave Windows and MacOS unsupported. Python users faced wildly differing installation instructions which varied between different extension packages, which made administering a Python installation something of a chore.
The SIG for distribution utilities, shepherded by Greg Ward, has created the
Distutils, a system to make package installation much easier. They form the
distutils package, a new part of Python’s standard library. In the best
case, installing a Python module from source will require the same steps: first
you simply mean unpack the tarball or zip archive, and the run “
setup.py install”. The platform will be automatically detected, the compiler
will be recognized, C extension modules will be compiled, and the distribution
installed into the proper directory. Optional command-line arguments provide
more control over the installation process, the distutils package offers many
places to override defaults – separating the build from the install, building
or installing in non-default directories, and more.
In order to use the Distutils, you need to write a
setup.py script. For
the simple case, when the software contains only .py files, a minimal
setup.py can be just a few lines long:
from distutils.core import setup setup (name = "foo", version = "1.0", py_modules = ["module1", "module2"])
setup.py file isn’t much more complicated if the software consists
of a few packages:
from distutils.core import setup setup (name = "foo", version = "1.0", packages = ["package", "package.subpackage"])
A C extension can be the most complicated case; here’s an example taken from the PyXML package:
from distutils.core import setup, Extension expat_extension = Extension('xml.parsers.pyexpat', define_macros = [('XML_NS', None)], include_dirs = [ 'extensions/expat/xmltok', 'extensions/expat/xmlparse' ], sources = [ 'extensions/pyexpat.c', 'extensions/expat/xmltok/xmltok.c', 'extensions/expat/xmltok/xmlrole.c', ] ) setup (name = "PyXML", version = "0.5.4", ext_modules =[ expat_extension ] )
The Distutils can also take care of creating source and binary distributions.
The “sdist” command, run by “
python setup.py sdist’, builds a source
distribution such as
foo-1.0.tar.gz. Adding new commands isn’t
difficult, “bdist_rpm” and “bdist_wininst” commands have already been
contributed to create an RPM distribution and a Windows installer for the
software, respectively. Commands to create other distribution formats such as
Debian packages and Solaris
.pkg files are in various stages of
All this is documented in a new manual, Distributing Python Modules, that joins the basic set of Python documentation.
Python 1.5.2 included a simple XML parser in the form of the
module, contributed by Sjoerd Mullender. Since 1.5.2’s release, two different
interfaces for processing XML have become common: SAX2 (version 2 of the Simple
API for XML) provides an event-driven interface with some similarities to
xmllib, and the DOM (Document Object Model) provides a tree-based
interface, transforming an XML document into a tree of nodes that can be
traversed and modified. Python 2.0 includes a SAX2 interface and a stripped-down
DOM interface as part of the
xml package. Here we will give a brief
overview of these new interfaces; consult the Python documentation or the source
code for complete details. The Python XML SIG is also working on improved
SAX defines an event-driven interface for parsing XML. To use SAX, you must
write a SAX handler class. Handler classes inherit from various classes
provided by SAX, and override various methods that will then be called by the
XML parser. For example, the
methods are called for every starting and end tag encountered by the parser, the
characters() method is called for every chunk of character data, and so
The advantage of the event-driven approach is that the whole document doesn’t have to be resident in memory at any one time, which matters if you are processing really huge documents. However, writing the SAX handler class can get very complicated if you’re trying to modify the document structure in some elaborate way.
For example, this little example program defines a handler that prints a message
for every starting and ending tag, and then parses the file
from xml import sax class SimpleHandler(sax.ContentHandler): def startElement(self, name, attrs): print 'Start of element:', name, attrs.keys() def endElement(self, name): print 'End of element:', name # Create a parser object parser = sax.make_parser() # Tell it what handler to use handler = SimpleHandler() parser.setContentHandler( handler ) # Parse a file! parser.parse( 'hamlet.xml' )
For more information, consult the Python documentation, or the XML HOWTO at https://pyxml.sourceforge.net/topics/howto/xml-howto.html.
The Document Object Model is a tree-based representation for an XML document. A
Document instance is the root of the tree, and has a single
child which is the top-level
Element instance. This
has children nodes representing character data and any sub-elements, which may
have further children of their own, and so forth. Using the DOM you can
traverse the resulting tree any way you like, access element and attribute
values, insert and delete nodes, and convert the tree back into XML.
The DOM is useful for modifying XML documents, because you can create a DOM
tree, modify it by adding new nodes or rearranging subtrees, and then produce a
new XML document as output. You can also construct a DOM tree manually and
convert it to XML, which can be a more flexible way of producing XML output than
</tag1> to a file.
The DOM implementation included with Python lives in the
module. It’s a lightweight implementation of the Level 1 DOM with support for
XML namespaces. The
functions are provided for generating a DOM tree:
from xml.dom import minidom doc = minidom.parse('hamlet.xml')
doc is a
Document, like all the other
DOM classes such as
Text, is a subclass of the
Node base class. All the nodes in a DOM tree therefore support certain
common methods, such as
toxml() which returns a string containing the XML
representation of the node and its children. Each class also has special
methods of its own; for example,
instances have a method to find all child elements with a given tag name.
Continuing from the previous 2-line example:
perslist = doc.getElementsByTagName( 'PERSONA' ) print perslist.toxml() print perslist.toxml()
For the Hamlet XML file, the above few lines output:
<PERSONA>CLAUDIUS, king of Denmark. </PERSONA> <PERSONA>HAMLET, son to the late, and nephew to the present king.</PERSONA>
The root element of the document is available as
its children can be easily modified by deleting, adding, or removing nodes:
root = doc.documentElement # Remove the first child root.removeChild( root.childNodes ) # Move the new first child to the end root.appendChild( root.childNodes ) # Insert the new first child (originally, # the third child) before the 20th child. root.insertBefore( root.childNodes, root.childNodes )
Again, I will refer you to the Python documentation for a complete listing of
Node classes and their various methods.
Relationship to PyXML¶
The XML Special Interest Group has been working on XML-related Python code for a
while. Its code distribution, called PyXML, is available from the SIG’s web
pages at https://www.python.org/community/sigs/current/xml-sig. The PyXML distribution also used
the package name
xml. If you’ve written programs that used PyXML, you’re
probably wondering about its compatibility with the 2.0
The answer is that Python 2.0’s
xml package isn’t compatible with PyXML,
but can be made compatible by installing a recent version PyXML. Many
applications can get by with the XML support that is included with Python 2.0,
but more complicated applications will require that the full PyXML package will
be installed. When installed, PyXML versions 0.6.0 or greater will replace the
xml package shipped with Python, and will be a strict superset of the
standard package, adding a bunch of additional features. Some of the additional
features in PyXML include:
4DOM, a full DOM implementation from FourThought, Inc.
The xmlproc validating parser, written by Lars Marius Garshol.
sgmlopparser accelerator module, written by Fredrik Lundh.
Lots of improvements and bugfixes were made to Python’s extensive standard
library; some of the affected modules include
nntplib. Consult the CVS logs for the exact patch-by-patch details.
Brian Gallew contributed OpenSSL support for the
socket module. OpenSSL
is an implementation of the Secure Socket Layer, which encrypts the data being
sent over a socket. When compiling Python, you can edit
to include SSL support, which adds an additional function to the
socket.ssl(socket, keyfile, certfile), which takes a socket
object and returns an SSL socket. The
were also changed to support
https:// URLs, though no one has implemented
FTP or SMTP over SSL.
httplib module has been rewritten by Greg Stein to support HTTP/1.1.
Backward compatibility with the 1.5 version of
httplib is provided,
though using HTTP/1.1 features such as pipelining will require rewriting code to
use a different set of interfaces.
Tkinter module now supports Tcl/Tk version 8.1, 8.2, or 8.3, and
support for the older 7.x versions has been dropped. The Tkinter module now
supports displaying Unicode strings in Tk widgets. Also, Fredrik Lundh
contributed an optimization which makes operations like
create_polygon much faster, especially when using lots of coordinates.
curses module has been greatly extended, starting from Oliver
Andrich’s enhanced version, to provide many additional functions from ncurses
and SYSV curses, such as colour, alternative character set support, pads, and
mouse support. This means the module is no longer compatible with operating
systems that only have BSD curses, but there don’t seem to be any currently
maintained OSes that fall into this category.
As mentioned in the earlier discussion of 2.0’s Unicode support, the underlying
implementation of the regular expressions provided by the
re module has
been changed. SRE, a new regular expression engine written by Fredrik Lundh and
partially funded by Hewlett Packard, supports matching against both 8-bit
strings and Unicode strings.
A number of new modules were added. We’ll simply list them with brief descriptions; consult the 2.0 documentation for the details of a particular module.
atexit: For registering functions to be called before the Python interpreter exits. Code that currently sets
sys.exitfuncdirectly should be changed to use the
atexitmodule instead, importing
atexit.register()with the function to be called on exit. (Contributed by Skip Montanaro.)
unicodedata: Added as part of the new Unicode support.
filecmp: Supersedes the old
dircmpmodules, which have now become deprecated. (Contributed by Gordon MacMillan and Moshe Zadka.)
gettext: This module provides internationalization (I18N) and localization (L10N) support for Python programs by providing an interface to the GNU gettext message catalog library. (Integrated by Barry Warsaw, from separate contributions by Martin von Löwis, Peter Funk, and James Henstridge.)
linuxaudiodev: Support for the
/dev/audiodevice on Linux, a twin to the existing
sunaudiodevmodule. (Contributed by Peter Bosch, with fixes by Jeremy Hylton.)
mmap: An interface to memory-mapped files on both Windows and Unix. A file’s contents can be mapped directly into memory, at which point it behaves like a mutable string, so its contents can be read and modified. They can even be passed to functions that expect ordinary strings, such as the
remodule. (Contributed by Sam Rushing, with some extensions by A.M. Kuchling.)
pyexpat: An interface to the Expat XML parser. (Contributed by Paul Prescod.)
robotparser: Parse a
robots.txtfile, which is used for writing web spiders that politely avoid certain areas of a web site. The parser accepts the contents of a
robots.txtfile, builds a set of rules from it, and can then answer questions about the fetchability of a given URL. (Contributed by Skip Montanaro.)
tabnanny: A module/script to check Python source code for ambiguous indentation. (Contributed by Tim Peters.)
UserString: A base class useful for deriving objects that behave like strings.
webbrowser: A module that provides a platform independent way to launch a web browser on a specific URL. For each platform, various browsers are tried in a specific order. The user can alter which browser is launched by setting the BROWSER environment variable. (Originally inspired by Eric S. Raymond’s patch to
urllibwhich added similar functionality, but the final module comes from code originally implemented by Fred Drake as
Tools/idle/BrowserControl.py, and adapted for the standard library by Fred.)
_winreg: An interface to the Windows registry.
_winregis an adaptation of functions that have been part of PythonWin since 1995, but has now been added to the core distribution, and enhanced to support Unicode.
_winregwas written by Bill Tutt and Mark Hammond.
zipfile: A module for reading and writing ZIP-format archives. These are archives produced by PKZIP on DOS/Windows or zip on Unix, not to be confused with gzip-format files (which are supported by the
gzipmodule) (Contributed by James C. Ahlstrom.)
imputil: A module that provides a simpler way for writing customized import hooks, in comparison to the existing
ihooksmodule. (Implemented by Greg Stein, with much discussion on python-dev along the way.)
IDLE is the official Python cross-platform IDE, written using Tkinter. Python 2.0 includes IDLE 0.6, which adds a number of new features and improvements. A partial list:
UI improvements and optimizations, especially in the area of syntax highlighting and auto-indentation.
The class browser now shows more information, such as the top level functions in a module.
Tab width is now a user settable option. When opening an existing Python file, IDLE automatically detects the indentation conventions, and adapts.
There is now support for calling browsers on various platforms, used to open the Python documentation in a browser.
IDLE now has a command line, which is largely similar to the vanilla Python interpreter.
Call tips were added in many places.
IDLE can now be installed as a package.
In the editor window, there is now a line/column bar at the bottom.
Three new keystroke commands: Check module (Alt-F5), Import module (F5) and Run script (Ctrl-F5).
Módulos apagados e desativados¶
A few modules have been dropped because they’re obsolete, or because there are
now better ways to do the same thing. The
stdwin module is gone; it was
for a platform-independent windowing toolkit that’s no longer developed.
A number of modules have been moved to the
zmod. If you have code which relies on a module that’s been moved to
lib-old, you can simply add that directory to
sys.path to get them
back, but you’re encouraged to update any code that uses these modules.
Os autores agradecem as seguintes pessoas por oferecer sugestões sobre vários rascunhos deste artigo: David Bolen, Mark Hammond, Gregg Hauser, Jeremy Hylton, Fredrik Lundh, Detlef Lannert, Aahz Maruch, Skip Montanaro, Vladimir Marangozov, Tobias Polzin, Guido Van Rossum, Neil Schemenauer e Russ Schmidt.