# SOME DESCRIPTIVE TITLE.

# Copyright (C) 2001-2017, Python Software Foundation

# This file is distributed under the same license as the Python package.

# FIRST AUTHOR <EMAIL@ADDRESS>, 2017.

#

#, fuzzy

msgid ""

msgstr ""

"Project-Id-Version: Python 3.6\n"

"Report-Msgid-Bugs-To: \n"

"POT-Creation-Date: 2018-12-25 10:27+0900\n"

"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"

"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"

"Language-Team: LANGUAGE <LL@li.org>\n"

"MIME-Version: 1.0\n"

"Content-Type: text/plain; charset=utf-8\n"

"Content-Transfer-Encoding: 8bit\n"

"Generated-By: Babel 2.6.0\n"

#: ../Doc/whatsnew/2.2.rst:3

msgid "What's New in Python 2.2"

msgstr ""

#: ../Doc/whatsnew/2.2.rst

msgid "Author"

msgstr ""

#: ../Doc/whatsnew/2.2.rst:5

msgid "A.M. Kuchling"

msgstr ""

#: ../Doc/whatsnew/2.2.rst:13

msgid "Introduction"

msgstr ""

#: ../Doc/whatsnew/2.2.rst:15

msgid ""

"This article explains the new features in Python 2.2.2, released on "

"October 14, 2002. Python 2.2.2 is a bugfix release of Python 2.2, "

"originally released on December 21, 2001."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:19

msgid ""

"Python 2.2 can be thought of as the \"cleanup release\". There are some "

"features such as generators and iterators that are completely new, but "

"most of the changes, significant and far-reaching though they may be, are"

" aimed at cleaning up irregularities and dark corners of the language "

"design."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:24

msgid ""

"This article doesn't attempt to provide a complete specification of the "

"new features, but instead provides a convenient overview. For full "

"details, you should refer to the documentation for Python 2.2, such as "

"the `Python Library Reference "

"<https://docs.python.org/2.2/lib/lib.html>`_ and the `Python Reference "

"Manual <https://docs.python.org/2.2/ref/ref.html>`_. If you want to "

"understand the complete implementation and design rationale for a change,"

" refer to the PEP for a particular new feature."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:43

msgid "PEPs 252 and 253: Type and Class Changes"

msgstr ""

#: ../Doc/whatsnew/2.2.rst:45

msgid ""

"The largest and most far-reaching changes in Python 2.2 are to Python's "

"model of objects and classes. The changes should be backward compatible,"

" so it's likely that your code will continue to run unchanged, but the "

"changes provide some amazing new capabilities. Before beginning this, the"

" longest and most complicated section of this article, I'll provide an "

"overview of the changes and offer some comments."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:52

msgid ""

"A long time ago I wrote a Web page listing flaws in Python's design. One"

" of the most significant flaws was that it's impossible to subclass "

"Python types implemented in C. In particular, it's not possible to "

"subclass built-in types, so you can't just subclass, say, lists in order "

"to add a single useful method to them. The :mod:`UserList` module "

"provides a class that supports all of the methods of lists and that can "

"be subclassed further, but there's lots of C code that expects a regular "

"Python list and won't accept a :class:`UserList` instance."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:61

msgid ""

"Python 2.2 fixes this, and in the process adds some exciting new "

"capabilities. A brief summary:"

msgstr ""

#: ../Doc/whatsnew/2.2.rst:64

msgid ""

"You can subclass built-in types such as lists and even integers, and your"

" subclasses should work in every place that requires the original type."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:67

msgid ""

"It's now possible to define static and class methods, in addition to the "

"instance methods available in previous versions of Python."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:70

msgid ""

"It's also possible to automatically call methods on accessing or setting "

"an instance attribute by using a new mechanism called :dfn:`properties`."

" Many uses of :meth:`__getattr__` can be rewritten to use properties "

"instead, making the resulting code simpler and faster. As a small side "

"benefit, attributes can now have docstrings, too."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:76

msgid ""

"The list of legal attributes for an instance can be limited to a "

"particular set using :dfn:`slots`, making it possible to safeguard "

"against typos and perhaps make more optimizations possible in future "

"versions of Python."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:80

msgid ""

"Some users have voiced concern about all these changes. Sure, they say, "

"the new features are neat and lend themselves to all sorts of tricks that"

" weren't possible in previous versions of Python, but they also make the "

"language more complicated. Some people have said that they've always "

"recommended Python for its simplicity, and feel that its simplicity is "

"being lost."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:86

msgid ""

"Personally, I think there's no need to worry. Many of the new features "

"are quite esoteric, and you can write a lot of Python code without ever "

"needed to be aware of them. Writing a simple class is no more difficult "

"than it ever was, so you don't need to bother learning or teaching them "

"unless they're actually needed. Some very complicated tasks that were "

"previously only possible from C will now be possible in pure Python, and "

"to my mind that's all for the better."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:93

msgid ""

"I'm not going to attempt to cover every single corner case and small "

"change that were required to make the new features work. Instead this "

"section will paint only the broad strokes. See section :ref:`sect-"

"rellinks`, \"Related Links\", for further sources of information about "

"Python 2.2's new object model."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:100

msgid "Old and New Classes"

msgstr ""

#: ../Doc/whatsnew/2.2.rst:102

msgid ""

"First, you should know that Python 2.2 really has two kinds of classes: "

"classic or old-style classes, and new-style classes. The old-style class"

" model is exactly the same as the class model in earlier versions of "

"Python. All the new features described in this section apply only to "

"new-style classes. This divergence isn't intended to last forever; "

"eventually old-style classes will be dropped, possibly in Python 3.0."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:109

msgid ""

"So how do you define a new-style class? You do it by subclassing an "

"existing new-style class. Most of Python's built-in types, such as "

"integers, lists, dictionaries, and even files, are new-style classes now."

" A new-style class named :class:`object`, the base class for all built-"

"in types, has also been added so if no built-in type is suitable, you can"

" just subclass :class:`object`::"

msgstr ""

#: ../Doc/whatsnew/2.2.rst:121

msgid ""

"This means that :keyword:`class` statements that don't have any base "

"classes are always classic classes in Python 2.2. (Actually you can also"

" change this by setting a module-level variable named "

":attr:`__metaclass__` --- see :pep:`253` for the details --- but it's "

"easier to just subclass :class:`object`.)"

msgstr ""

#: ../Doc/whatsnew/2.2.rst:126

msgid ""

"The type objects for the built-in types are available as built-ins, named"

" using a clever trick. Python has always had built-in functions named "

":func:`int`, :func:`float`, and :func:`str`. In 2.2, they aren't "

"functions any more, but type objects that behave as factories when "

"called. ::"

msgstr ""

#: ../Doc/whatsnew/2.2.rst:136

msgid ""

"To make the set of types complete, new type objects such as :func:`dict` "

"and :func:`file` have been added. Here's a more interesting example, "

"adding a :meth:`lock` method to file objects::"

msgstr ""

#: ../Doc/whatsnew/2.2.rst:146

msgid ""

"The now-obsolete :mod:`posixfile` module contained a class that emulated "

"all of a file object's methods and also added a :meth:`lock` method, but "

"this class couldn't be passed to internal functions that expected a "

"built-in file, something which is possible with our new "

":class:`LockableFile`."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:153

msgid "Descriptors"

msgstr ""

#: ../Doc/whatsnew/2.2.rst:155

msgid ""

"In previous versions of Python, there was no consistent way to discover "

"what attributes and methods were supported by an object. There were some "

"informal conventions, such as defining :attr:`__members__` and "

":attr:`__methods__` attributes that were lists of names, but often the "

"author of an extension type or a class wouldn't bother to define them. "

"You could fall back on inspecting the :attr:`~object.__dict__` of an "

"object, but when class inheritance or an arbitrary :meth:`__getattr__` "

"hook were in use this could still be inaccurate."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:163

msgid ""

"The one big idea underlying the new class model is that an API for "

"describing the attributes of an object using :dfn:`descriptors` has been "

"formalized. Descriptors specify the value of an attribute, stating "

"whether it's a method or a field. With the descriptor API, static "

"methods and class methods become possible, as well as more exotic "

"constructs."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:169

msgid ""

"Attribute descriptors are objects that live inside class objects, and "

"have a few attributes of their own:"

msgstr ""

#: ../Doc/whatsnew/2.2.rst:172

msgid ":attr:`~definition.__name__` is the attribute's name."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:174

msgid ":attr:`__doc__` is the attribute's docstring."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:176

msgid ""

"``__get__(object)`` is a method that retrieves the attribute value from "

"*object*."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:179

msgid "``__set__(object, value)`` sets the attribute on *object* to *value*."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:181

msgid "``__delete__(object, value)`` deletes the *value* attribute of *object*."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:183

msgid ""

"For example, when you write ``obj.x``, the steps that Python actually "

"performs are::"

msgstr ""

#: ../Doc/whatsnew/2.2.rst:189

msgid ""

"For methods, :meth:`descriptor.__get__` returns a temporary object that's"

" callable, and wraps up the instance and the method to be called on it. "

"This is also why static methods and class methods are now possible; they "

"have descriptors that wrap up just the method, or the method and the "

"class. As a brief explanation of these new kinds of methods, static "

"methods aren't passed the instance, and therefore resemble regular "

"functions. Class methods are passed the class of the object, but not the"

" object itself. Static and class methods are defined like this::"

msgstr ""

#: ../Doc/whatsnew/2.2.rst:207

msgid ""

"The :func:`staticmethod` function takes the function :func:`f`, and "

"returns it wrapped up in a descriptor so it can be stored in the class "

"object. You might expect there to be special syntax for creating such "

"methods (``def static f``, ``defstatic f()``, or something like that) but"

" no such syntax has been defined yet; that's been left for future "

"versions of Python."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:213

msgid ""

"More new features, such as slots and properties, are also implemented as "

"new kinds of descriptors, and it's not difficult to write a descriptor "

"class that does something novel. For example, it would be possible to "

"write a descriptor class that made it possible to write Eiffel-style "

"preconditions and postconditions for a method. A class that used this "

"feature might be defined like this::"

msgstr ""

#: ../Doc/whatsnew/2.2.rst:235

msgid ""

"Note that a person using the new :func:`eiffelmethod` doesn't have to "

"understand anything about descriptors. This is why I think the new "

"features don't increase the basic complexity of the language. There will "

"be a few wizards who need to know about it in order to write "

":func:`eiffelmethod` or the ZODB or whatever, but most users will just "

"write code on top of the resulting libraries and ignore the "

"implementation details."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:244

msgid "Multiple Inheritance: The Diamond Rule"

msgstr ""

#: ../Doc/whatsnew/2.2.rst:246

msgid ""

"Multiple inheritance has also been made more useful through changing the "

"rules under which names are resolved. Consider this set of classes "

"(diagram taken from :pep:`253` by Guido van Rossum)::"

msgstr ""

#: ../Doc/whatsnew/2.2.rst:264

msgid ""

"The lookup rule for classic classes is simple but not very smart; the "

"base classes are searched depth-first, going from left to right. A "

"reference to :meth:`D.save` will search the classes :class:`D`, "

":class:`B`, and then :class:`A`, where :meth:`save` would be found and "

"returned. :meth:`C.save` would never be found at all. This is bad, "

"because if :class:`C`'s :meth:`save` method is saving some internal state"

" specific to :class:`C`, not calling it will result in that state never "

"getting saved."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:272

msgid ""

"New-style classes follow a different algorithm that's a bit more "

"complicated to explain, but does the right thing in this situation. (Note"

" that Python 2.3 changes this algorithm to one that produces the same "

"results in most cases, but produces more useful results for really "

"complicated inheritance graphs.)"

msgstr ""

#: ../Doc/whatsnew/2.2.rst:277

msgid ""

"List all the base classes, following the classic lookup rule and include "

"a class multiple times if it's visited repeatedly. In the above example,"

" the list of visited classes is [:class:`D`, :class:`B`, :class:`A`, "

":class:`C`, :class:`A`]."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:282

msgid ""

"Scan the list for duplicated classes. If any are found, remove all but "

"one occurrence, leaving the *last* one in the list. In the above "

"example, the list becomes [:class:`D`, :class:`B`, :class:`C`, "

":class:`A`] after dropping duplicates."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:287

msgid ""

"Following this rule, referring to :meth:`D.save` will return "

":meth:`C.save`, which is the behaviour we're after. This lookup rule is "

"the same as the one followed by Common Lisp. A new built-in function, "

":func:`super`, provides a way to get at a class's superclasses without "

"having to reimplement Python's algorithm. The most commonly used form "

"will be ``super(class, obj)``, which returns a bound superclass object "

"(not the actual class object). This form will be used in methods to call"

" a method in the superclass; for example, :class:`D`'s :meth:`save` "

"method would look like this::"

msgstr ""

#: ../Doc/whatsnew/2.2.rst:303

msgid ""

":func:`super` can also return unbound superclass objects when called as "

"``super(class)`` or ``super(class1, class2)``, but this probably won't "

"often be useful."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:309

msgid "Attribute Access"

msgstr ""

#: ../Doc/whatsnew/2.2.rst:311

msgid ""

"A fair number of sophisticated Python classes define hooks for attribute "

"access using :meth:`__getattr__`; most commonly this is done for "

"convenience, to make code more readable by automatically mapping an "

"attribute access such as ``obj.parent`` into a method call such as "

"``obj.get_parent``. Python 2.2 adds some new ways of controlling "

"attribute access."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:317

msgid ""

"First, ``__getattr__(attr_name)`` is still supported by new-style "

"classes, and nothing about it has changed. As before, it will be called "

"when an attempt is made to access ``obj.foo`` and no attribute named "

"``foo`` is found in the instance's dictionary."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:322

msgid ""

"New-style classes also support a new method, "

"``__getattribute__(attr_name)``. The difference between the two methods "

"is that :meth:`__getattribute__` is *always* called whenever any "

"attribute is accessed, while the old :meth:`__getattr__` is only called "

"if ``foo`` isn't found in the instance's dictionary."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:328

msgid ""

"However, Python 2.2's support for :dfn:`properties` will often be a "

"simpler way to trap attribute references. Writing a :meth:`__getattr__` "

"method is complicated because to avoid recursion you can't use regular "

"attribute accesses inside them, and instead have to mess around with the "

"contents of :attr:`~object.__dict__`. :meth:`__getattr__` methods also "

"end up being called by Python when it checks for other methods such as "

":meth:`__repr__` or :meth:`__coerce__`, and so have to be written with "

"this in mind. Finally, calling a function on every attribute access "

"results in a sizable performance loss."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:337

msgid ""

":class:`property` is a new built-in type that packages up three functions"

" that get, set, or delete an attribute, and a docstring. For example, if"

" you want to define a :attr:`size` attribute that's computed, but also "

"settable, you could write::"

msgstr ""

#: ../Doc/whatsnew/2.2.rst:357

msgid ""

"That is certainly clearer and easier to write than a pair of "

":meth:`__getattr__`/:meth:`__setattr__` methods that check for the "

":attr:`size` attribute and handle it specially while retrieving all other"

" attributes from the instance's :attr:`~object.__dict__`. Accesses to "

":attr:`size` are also the only ones which have to perform the work of "

"calling a function, so references to other attributes run at their usual "

"speed."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:364

msgid ""

"Finally, it's possible to constrain the list of attributes that can be "

"referenced on an object using the new :attr:`~object.__slots__` class "

"attribute. Python objects are usually very dynamic; at any time it's "

"possible to define a new attribute on an instance by just doing "

"``obj.new_attr=1``. A new-style class can define a class attribute "

"named :attr:`~object.__slots__` to limit the legal attributes to a "

"particular set of names. An example will make this clear::"

msgstr ""

#: ../Doc/whatsnew/2.2.rst:385

msgid ""

"Note how you get an :exc:`AttributeError` on the attempt to assign to an "

"attribute not listed in :attr:`~object.__slots__`."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:392

msgid "Related Links"

msgstr ""

#: ../Doc/whatsnew/2.2.rst:394

msgid ""

"This section has just been a quick overview of the new features, giving "

"enough of an explanation to start you programming, but many details have "

"been simplified or ignored. Where should you go to get a more complete "

"picture?"

msgstr ""

#: ../Doc/whatsnew/2.2.rst:398

msgid ""

"https://docs.python.org/dev/howto/descriptor.html is a lengthy tutorial "

"introduction to the descriptor features, written by Guido van Rossum. If "

"my description has whetted your appetite, go read this tutorial next, "

"because it goes into much more detail about the new features while still "

"remaining quite easy to read."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:403

msgid ""

"Next, there are two relevant PEPs, :pep:`252` and :pep:`253`. :pep:`252`"

" is titled \"Making Types Look More Like Classes\", and covers the "

"descriptor API. :pep:`253` is titled \"Subtyping Built-in Types\", and "

"describes the changes to type objects that make it possible to subtype "

"built-in objects. :pep:`253` is the more complicated PEP of the two, and"

" at a few points the necessary explanations of types and meta-types may "

"cause your head to explode. Both PEPs were written and implemented by "

"Guido van Rossum, with substantial assistance from the rest of the Zope "

"Corp. team."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:412

msgid ""

"Finally, there's the ultimate authority: the source code. Most of the "

"machinery for the type handling is in :file:`Objects/typeobject.c`, but "

"you should only resort to it after all other avenues have been exhausted,"

" including posting a question to python-list or python-dev."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:421

msgid "PEP 234: Iterators"

msgstr ""

#: ../Doc/whatsnew/2.2.rst:423

msgid ""

"Another significant addition to 2.2 is an iteration interface at both the"

" C and Python levels. Objects can define how they can be looped over by "

"callers."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:426

msgid ""

"In Python versions up to 2.1, the usual way to make ``for item in obj`` "

"work is to define a :meth:`__getitem__` method that looks something like "

"this::"

msgstr ""

#: ../Doc/whatsnew/2.2.rst:432

msgid ""

":meth:`__getitem__` is more properly used to define an indexing operation"

" on an object so that you can write ``obj[5]`` to retrieve the sixth "

"element. It's a bit misleading when you're using this only to support "

":keyword:`for` loops. Consider some file-like object that wants to be "

"looped over; the *index* parameter is essentially meaningless, as the "

"class probably assumes that a series of :meth:`__getitem__` calls will be"

" made with *index* incrementing by one each time. In other words, the "

"presence of the :meth:`__getitem__` method doesn't mean that using "

"``file[5]`` to randomly access the sixth element will work, though it "

"really should."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:442

msgid ""

"In Python 2.2, iteration can be implemented separately, and "

":meth:`__getitem__` methods can be limited to classes that really do "

"support random access. The basic idea of iterators is simple. A new "

"built-in function, ``iter(obj)`` or ``iter(C, sentinel)``, is used to get"

" an iterator. ``iter(obj)`` returns an iterator for the object *obj*, "

"while ``iter(C, sentinel)`` returns an iterator that will invoke the "

"callable object *C* until it returns *sentinel* to signal that the "

"iterator is done."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:450

msgid ""

"Python classes can define an :meth:`__iter__` method, which should create"

" and return a new iterator for the object; if the object is its own "

"iterator, this method can just return ``self``. In particular, iterators"

" will usually be their own iterators. Extension types implemented in C "

"can implement a :c:member:`~PyTypeObject.tp_iter` function in order to "

"return an iterator, and extension types that want to behave as iterators "

"can define a :c:member:`~PyTypeObject.tp_iternext` function."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:457

msgid ""

"So, after all this, what do iterators actually do? They have one "

"required method, :meth:`next`, which takes no arguments and returns the "

"next value. When there are no more values to be returned, calling "

":meth:`next` should raise the :exc:`StopIteration` exception. ::"

msgstr ""

#: ../Doc/whatsnew/2.2.rst:478

msgid ""

"In 2.2, Python's :keyword:`for` statement no longer expects a sequence; "

"it expects something for which :func:`iter` will return an iterator. For "

"backward compatibility and convenience, an iterator is automatically "

"constructed for sequences that don't implement :meth:`__iter__` or a "

":c:member:`~PyTypeObject.tp_iter` slot, so ``for i in [1,2,3]`` will "

"still work. Wherever the Python interpreter loops over a sequence, it's "

"been changed to use the iterator protocol. This means you can do things "

"like this::"

msgstr ""

#: ../Doc/whatsnew/2.2.rst:492

msgid ""

"Iterator support has been added to some of Python's basic types. "

"Calling :func:`iter` on a dictionary will return an iterator which loops "

"over its keys::"

msgstr ""

#: ../Doc/whatsnew/2.2.rst:512

msgid ""

"That's just the default behaviour. If you want to iterate over keys, "

"values, or key/value pairs, you can explicitly call the :meth:`iterkeys`,"

" :meth:`itervalues`, or :meth:`iteritems` methods to get an appropriate "

"iterator. In a minor related change, the :keyword:`in` operator now works"

" on dictionaries, so ``key in dict`` is now equivalent to "

"``dict.has_key(key)``."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:518

msgid ""

"Files also provide an iterator, which calls the :meth:`readline` method "

"until there are no more lines in the file. This means you can now read "

"each line of a file using code like this::"

msgstr ""

#: ../Doc/whatsnew/2.2.rst:526

msgid ""

"Note that you can only go forward in an iterator; there's no way to get "

"the previous element, reset the iterator, or make a copy of it. An "

"iterator object could provide such additional capabilities, but the "

"iterator protocol only requires a :meth:`next` method."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:535

msgid ":pep:`234` - Iterators"

msgstr ""

#: ../Doc/whatsnew/2.2.rst:535

msgid ""

"Written by Ka-Ping Yee and GvR; implemented by the Python Labs crew, "

"mostly by GvR and Tim Peters."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:542

msgid "PEP 255: Simple Generators"

msgstr ""

#: ../Doc/whatsnew/2.2.rst:544

msgid ""

"Generators are another new feature, one that interacts with the "

"introduction of iterators."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:547

msgid ""

"You're doubtless familiar with how function calls work in Python or C. "

"When you call a function, it gets a private namespace where its local "

"variables are created. When the function reaches a :keyword:`return` "

"statement, the local variables are destroyed and the resulting value is "

"returned to the caller. A later call to the same function will get a "

"fresh new set of local variables. But, what if the local variables "

"weren't thrown away on exiting a function? What if you could later resume"

" the function where it left off? This is what generators provide; they "

"can be thought of as resumable functions."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:556

msgid "Here's the simplest example of a generator function::"

msgstr ""

#: ../Doc/whatsnew/2.2.rst:562

msgid ""

"A new keyword, :keyword:`yield`, was introduced for generators. Any "

"function containing a :keyword:`!yield` statement is a generator "

"function; this is detected by Python's bytecode compiler which compiles "

"the function specially as a result. Because a new keyword was "

"introduced, generators must be explicitly enabled in a module by "

"including a ``from __future__ import generators`` statement near the top "

"of the module's source code. In Python 2.3 this statement will become "

"unnecessary."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:570

msgid ""

"When you call a generator function, it doesn't return a single value; "

"instead it returns a generator object that supports the iterator "

"protocol. On executing the :keyword:`yield` statement, the generator "

"outputs the value of ``i``, similar to a :keyword:`return` statement. "

"The big difference between :keyword:`!yield` and a :keyword:`!return` "

"statement is that on reaching a :keyword:`!yield` the generator's state "

"of execution is suspended and local variables are preserved. On the next"

" call to the generator's ``next()`` method, the function will resume "

"executing immediately after the :keyword:`!yield` statement. (For "

"complicated reasons, the :keyword:`!yield` statement isn't allowed inside"

" the :keyword:`!try` block of a :keyword:`try`...\\ :keyword:`finally` "

"statement; read :pep:`255` for a full explanation of the interaction "

"between :keyword:`!yield` and exceptions.)"

msgstr ""

#: ../Doc/whatsnew/2.2.rst:583

msgid "Here's a sample usage of the :func:`generate_ints` generator::"

msgstr ""

#: ../Doc/whatsnew/2.2.rst:600

msgid ""

"You could equally write ``for i in generate_ints(5)``, or ``a,b,c = "

"generate_ints(3)``."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:603

msgid ""

"Inside a generator function, the :keyword:`return` statement can only be "

"used without a value, and signals the end of the procession of values; "

"afterwards the generator cannot return any further values. "

":keyword:`!return` with a value, such as ``return 5``, is a syntax error "

"inside a generator function. The end of the generator's results can also"

" be indicated by raising :exc:`StopIteration` manually, or by just "

"letting the flow of execution fall off the bottom of the function."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:611

msgid ""

"You could achieve the effect of generators manually by writing your own "

"class and storing all the local variables of the generator as instance "

"variables. For example, returning a list of integers could be done by "

"setting ``self.count`` to 0, and having the :meth:`next` method increment"

" ``self.count`` and return it. However, for a moderately complicated "

"generator, writing a corresponding class would be much messier. "

":file:`Lib/test/test_generators.py` contains a number of more interesting"

" examples. The simplest one implements an in-order traversal of a tree "

"using generators recursively. ::"

msgstr ""

#: ../Doc/whatsnew/2.2.rst:629

msgid ""

"Two other examples in :file:`Lib/test/test_generators.py` produce "

"solutions for the N-Queens problem (placing $N$ queens on an $NxN$ chess "

"board so that no queen threatens another) and the Knight's Tour (a route "

"that takes a knight to every square of an $NxN$ chessboard without "

"visiting any square twice)."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:634

msgid ""

"The idea of generators comes from other programming languages, especially"

" Icon (https://www.cs.arizona.edu/icon/), where the idea of generators is"

" central. In Icon, every expression and function call behaves like a "

"generator. One example from \"An Overview of the Icon Programming "

"Language\" at https://www.cs.arizona.edu/icon/docs/ipd266.htm gives an "

"idea of what this looks like::"

msgstr ""

#: ../Doc/whatsnew/2.2.rst:644

msgid ""

"In Icon the :func:`find` function returns the indexes at which the "

"substring \"or\" is found: 3, 23, 33. In the :keyword:`if` statement, "

"``i`` is first assigned a value of 3, but 3 is less than 5, so the "

"comparison fails, and Icon retries it with the second value of 23. 23 is"

" greater than 5, so the comparison now succeeds, and the code prints the "

"value 23 to the screen."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:650

msgid ""

"Python doesn't go nearly as far as Icon in adopting generators as a "

"central concept. Generators are considered a new part of the core Python"

" language, but learning or using them isn't compulsory; if they don't "

"solve any problems that you have, feel free to ignore them. One novel "

"feature of Python's interface as compared to Icon's is that a generator's"

" state is represented as a concrete object (the iterator) that can be "

"passed around to other functions or stored in a data structure."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:662

msgid ":pep:`255` - Simple Generators"

msgstr ""

#: ../Doc/whatsnew/2.2.rst:662

msgid ""

"Written by Neil Schemenauer, Tim Peters, Magnus Lie Hetland. Implemented"

" mostly by Neil Schemenauer and Tim Peters, with other fixes from the "

"Python Labs crew."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:669

msgid "PEP 237: Unifying Long Integers and Integers"

msgstr ""

#: ../Doc/whatsnew/2.2.rst:671

msgid ""

"In recent versions, the distinction between regular integers, which are "

"32-bit values on most machines, and long integers, which can be of "

"arbitrary size, was becoming an annoyance. For example, on platforms "

"that support files larger than ``2**32`` bytes, the :meth:`tell` method "

"of file objects has to return a long integer. However, there were various"

" bits of Python that expected plain integers and would raise an error if "

"a long integer was provided instead. For example, in Python 1.5, only "

"regular integers could be used as a slice index, and ``'abc'[1L:]`` would"

" raise a :exc:`TypeError` exception with the message 'slice index must be"

" int'."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:681

msgid ""

"Python 2.2 will shift values from short to long integers as required. The"

" 'L' suffix is no longer needed to indicate a long integer literal, as "

"now the compiler will choose the appropriate type. (Using the 'L' suffix"

" will be discouraged in future 2.x versions of Python, triggering a "

"warning in Python 2.4, and probably dropped in Python 3.0.) Many "

"operations that used to raise an :exc:`OverflowError` will now return a "

"long integer as their result. For example::"

msgstr ""

#: ../Doc/whatsnew/2.2.rst:694

msgid ""

"In most cases, integers and long integers will now be treated "

"identically. You can still distinguish them with the :func:`type` built-"

"in function, but that's rarely needed."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:702

msgid ":pep:`237` - Unifying Long Integers and Integers"

msgstr ""

#: ../Doc/whatsnew/2.2.rst:702

msgid ""

"Written by Moshe Zadka and Guido van Rossum. Implemented mostly by Guido"

" van Rossum."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:709

msgid "PEP 238: Changing the Division Operator"

msgstr ""

#: ../Doc/whatsnew/2.2.rst:711

msgid ""

"The most controversial change in Python 2.2 heralds the start of an "

"effort to fix an old design flaw that's been in Python from the "

"beginning. Currently Python's division operator, ``/``, behaves like C's "

"division operator when presented with two integer arguments: it returns "

"an integer result that's truncated down when there would be a fractional "

"part. For example, ``3/2`` is 1, not 1.5, and ``(-1)/2`` is -1, not "

"-0.5. This means that the results of division can vary unexpectedly "

"depending on the type of the two operands and because Python is "

"dynamically typed, it can be difficult to determine the possible types of"

" the operands."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:721

msgid ""

"(The controversy is over whether this is *really* a design flaw, and "

"whether it's worth breaking existing code to fix this. It's caused "

"endless discussions on python-dev, and in July 2001 erupted into a storm "

"of acidly sarcastic postings on :newsgroup:`comp.lang.python`. I won't "

"argue for either side here and will stick to describing what's "

"implemented in 2.2. Read :pep:`238` for a summary of arguments and "

"counter-arguments.)"

msgstr ""

#: ../Doc/whatsnew/2.2.rst:728

msgid ""

"Because this change might break code, it's being introduced very "

"gradually. Python 2.2 begins the transition, but the switch won't be "

"complete until Python 3.0."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:732

msgid ""

"First, I'll borrow some terminology from :pep:`238`. \"True division\" "

"is the division that most non-programmers are familiar with: 3/2 is 1.5, "

"1/4 is 0.25, and so forth. \"Floor division\" is what Python's ``/`` "

"operator currently does when given integer operands; the result is the "

"floor of the value returned by true division. \"Classic division\" is "

"the current mixed behaviour of ``/``; it returns the result of floor "

"division when the operands are integers, and returns the result of true "

"division when one of the operands is a floating-point number."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:740

msgid "Here are the changes 2.2 introduces:"

msgstr ""

#: ../Doc/whatsnew/2.2.rst:742

msgid ""

"A new operator, ``//``, is the floor division operator. (Yes, we know it "

"looks like C++'s comment symbol.) ``//`` *always* performs floor "

"division no matter what the types of its operands are, so ``1 // 2`` is 0"

" and ``1.0 // 2.0`` is also 0.0."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:747

msgid ""

"``//`` is always available in Python 2.2; you don't need to enable it "

"using a ``__future__`` statement."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:750

msgid ""

"By including a ``from __future__ import division`` in a module, the ``/``"

" operator will be changed to return the result of true division, so "

"``1/2`` is 0.5. Without the ``__future__`` statement, ``/`` still means "

"classic division. The default meaning of ``/`` will not change until "

"Python 3.0."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:755

msgid ""

"Classes can define methods called :meth:`__truediv__` and "

":meth:`__floordiv__` to overload the two division operators. At the C "

"level, there are also slots in the :c:type:`PyNumberMethods` structure so"

" extension types can define the two operators."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:760

msgid ""

"Python 2.2 supports some command-line arguments for testing whether code "

"will work with the changed division semantics. Running python with "

":option:`!-Q warn` will cause a warning to be issued whenever division is"

" applied to two integers. You can use this to find code that's affected "

"by the change and fix it. By default, Python 2.2 will simply perform "

"classic division without a warning; the warning will be turned on by "

"default in Python 2.3."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:770

msgid ":pep:`238` - Changing the Division Operator"

msgstr ""

#: ../Doc/whatsnew/2.2.rst:771

msgid ""

"Written by Moshe Zadka and Guido van Rossum. Implemented by Guido van "

"Rossum.."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:777

msgid "Unicode Changes"

msgstr ""

#: ../Doc/whatsnew/2.2.rst:779

msgid ""

"Python's Unicode support has been enhanced a bit in 2.2. Unicode strings"

" are usually stored as UCS-2, as 16-bit unsigned integers. Python 2.2 can"

" also be compiled to use UCS-4, 32-bit unsigned integers, as its internal"

" encoding by supplying :option:`!--enable-unicode=ucs4` to the configure "

"script. (It's also possible to specify :option:`!--disable-unicode` to "

"completely disable Unicode support.)"

msgstr ""

#: ../Doc/whatsnew/2.2.rst:786

msgid ""

"When built to use UCS-4 (a \"wide Python\"), the interpreter can natively"

" handle Unicode characters from U+000000 to U+110000, so the range of "

"legal values for the :func:`unichr` function is expanded accordingly. "

"Using an interpreter compiled to use UCS-2 (a \"narrow Python\"), values "

"greater than 65535 will still cause :func:`unichr` to raise a "

":exc:`ValueError` exception. This is all described in :pep:`261`, "

"\"Support for 'wide' Unicode characters\"; consult it for further "

"details."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:794

msgid ""

"Another change is simpler to explain. Since their introduction, Unicode "

"strings have supported an :meth:`encode` method to convert the string to "

"a selected encoding such as UTF-8 or Latin-1. A symmetric "

"``decode([*encoding*])`` method has been added to 8-bit strings (though "

"not to Unicode strings) in 2.2. :meth:`decode` assumes that the string is"

" in the specified encoding and decodes it, returning whatever is returned"

" by the codec."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:801

msgid ""

"Using this new feature, codecs have been added for tasks not directly "

"related to Unicode. For example, codecs have been added for uu-encoding,"

" MIME's base64 encoding, and compression with the :mod:`zlib` module::"

msgstr ""

#: ../Doc/whatsnew/2.2.rst:822

msgid ""

"To convert a class instance to Unicode, a :meth:`__unicode__` method can "

"be defined by a class, analogous to :meth:`__str__`."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:825

msgid ""

":meth:`encode`, :meth:`decode`, and :meth:`__unicode__` were implemented "

"by Marc-André Lemburg. The changes to support using UCS-4 internally "

"were implemented by Fredrik Lundh and Martin von Löwis."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:832

msgid ":pep:`261` - Support for 'wide' Unicode characters"

msgstr ""

#: ../Doc/whatsnew/2.2.rst:833

msgid "Written by Paul Prescod."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:839

msgid "PEP 227: Nested Scopes"

msgstr ""

#: ../Doc/whatsnew/2.2.rst:841

msgid ""

"In Python 2.1, statically nested scopes were added as an optional "

"feature, to be enabled by a ``from __future__ import nested_scopes`` "

"directive. In 2.2 nested scopes no longer need to be specially enabled, "

"and are now always present. The rest of this section is a copy of the "

"description of nested scopes from my \"What's New in Python 2.1\" "

"document; if you read it when 2.1 came out, you can skip the rest of this"

" section."

msgstr ""

#: ../Doc/whatsnew/2.2.rst:848

msgid ""

"The largest change introduced in Python 2.1, and made complete in 2.2, is"

" to Python's scoping rules. In Python 2.0, at any given time there are "

"at most three namespaces used to look up variable names: local, module-"

"level, and the built-in namespace. This often surprised people because "

"it didn't match their intuitive expectations. For example, a nested "