Mailman 3 July 2011 - Python-Dev

status of absolute_import w/ python 2.7
by Sylvain Thénault July 13, 2011

July 13, 2011

Hi there, the documentation state that absolute_import feature is the default behaviour with python 2.7, though it seems that it behave differently with the __future__ import : $ cat package/__init__.py import subpackage $ python2.7 Python 2.7.1+ (default, Apr 20 2011, 22:33:39) [GCC 4.5.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import package >>> $ cat package/__init__.py from __future__ import absolute_import import subpackage $ python2.7 Python 2.7.1+ (default, Apr 20 2011, 22:33:39) [GCC 4.5.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import package Traceback (most recent call last): File "<stdin>", line 1, in <module> File "package/__init__.py", line 23, in <module> import subpackage ImportError: No module named subpackage Maybe the doc should be fixed ? -- Sylvain Thénault LOGILAB, Paris (France) Formations Python, Debian, Méth. Agiles: http://www.logilab.fr/formations Développement logiciel sur mesure: http://www.logilab.fr/services CubicWeb, the semantic web framework: http://www.cubicweb.org

5 4

Re: [Python-Dev] [Python-checkins] cpython: no one passes NULL here (or should anyway)
by Nick Coghlan July 13, 2011

July 13, 2011

On Mon, Jul 4, 2011 at 8:02 AM, benjamin.peterson <python-checkins(a)python.org> wrote: > http://hg.python.org/cpython/rev/bbbeddafeec0 > changeset: 71160:bbbeddafeec0 > user: Benjamin Peterson <benjamin(a)python.org> > date: Sun Jul 03 17:06:32 2011 -0500 > summary: > no one passes NULL here (or should anyway) > > files: > Python/ceval.c | 3 --- > 1 files changed, 0 insertions(+), 3 deletions(-) > > > diff --git a/Python/ceval.c b/Python/ceval.c > --- a/Python/ceval.c > +++ b/Python/ceval.c > @@ -1115,9 +1115,6 @@ > > /* Start of code */ > > - if (f == NULL) > - return NULL; > - May need to replace that with an assert(f != NULL) to keep static analysers happy. Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

3 4

Re: [Python-Dev] [Python-checkins] cpython: Fix syntax in packaging docs and update suspicious ignore file.
by Éric Araujo July 12, 2011

July 12, 2011

> changeset: 71283:3a4b983dd70b > user: Georg Brandl <georg(a)python.org> > summary: > Fix syntax in packaging docs and update suspicious ignore file. > > files: > Doc/library/packaging.compiler.rst | 2 +- > Doc/packaging/builtdist.rst | 2 +- > Doc/packaging/commandref.rst | 2 +- Thanks for the fixes, Georg. I fix problems when I get warnings, but these fell through. Maybe you used a special command line to find those? > Doc/tools/sphinxext/susp-ignored.csv | 27 ++++++++++++++- I’ve always wondered about that file’s role, and I’ve finally found answers in Doc/tools/sphinxext/suspicious.py. Should we update this file when we get suspicious output? Does using “.. block-code:: none” prevent program output from appearing as suspicious? Regards

2 1

Fwd: Dead link to documentation on Python main page
by Michael Foord July 11, 2011

July 11, 2011

-------- Original Message -------- Subject: Dead link to documentation on Python main page Date: Mon, 11 Jul 2011 09:27:57 -0500 From: René van Oostrum <rene(a)59bits.nl> To: webmaster(a)python.org Hi, http://www.python.org -> Quick Links (3.2.1), Documentation points to http://http://docs.python.org/3.2.1/, which does not exist. Best regards, René van Oostrum

1 0

[RELEASED] Python 3.2.1
by Georg Brandl July 11, 2011

July 11, 2011

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On behalf of the Python development team, I am pleased to announce the final release of Python 3.2.1. Python 3.2.1 is the first bugfix release for Python 3.2, fixing over 120 bugs and regressions in Python 3.2. For an extensive list of changes and features in the 3.2 line, see http://docs.python.org/3.2/whatsnew/3.2.html To download Python 3.2.1 visit: http://www.python.org/download/releases/3.2.1/ This is a final release: Please report any bugs you may notice to: http://bugs.python.org/ Enjoy! - -- Georg Brandl, Release Manager georg at python.org (on behalf of the entire python-dev team and 3.2's contributors) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iEYEARECAAYFAk4aiNMACgkQN9GcIYhpnLDofwCglfgDQ1/B/TxxwfqtDxK13ksz micAn0CVWmNNaYE2a6z0N7+Dz+hCZSj1 =7Mia -----END PGP SIGNATURE-----

1 0

Support the /usr/bin/python2 symlink upstream
by Kerrick Staley July 10, 2011

July 10, 2011

Hello, There is a need for the default Python2 install to place a symlink at /usr/bin/python2 that points to /usr/bin/python, or for the documentation to recommend that packagers ensure that python2 is defined. Also, all documentation should be changed to recommend that "#!/usr/bin/env python2" be used as the shebang for Python 2 scripts. This is needed because some distributions (Arch Linux, in particular), point /usr/bin/python to /usr/bin/python3, while others (including Slackware, Debian, and the BSDs, probably more) do not even define the python2 command. This means that a script has no way of achieving cross-platform compatibility. The point at which many distributions begin to alias /usr/bin/python to /usr/bin/python3 is due soon, and for the next couple of years, it would be best to use a python2 or python3 shebang in all scripts, making no assumptions about plain python, which should only be invoked interactively. This email from about 3 years ago seems relevant: : http://mail.python.org/pipermail/python-3000/2008-March/012421.html Again, this issue needs to be addressed by the Python developers themselves so that different *nix distributions will handle it consistently, allowing Python scripts to continue to be cross-platform. Thanks, Kerrick Staley

40 184

Summary of Python tracker Issues
by Python tracker July 8, 2011

July 8, 2011

ACTIVITY SUMMARY (2011-07-01 - 2011-07-08) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 2857 ( +7) closed 21444 (+45) total 24301 (+52) Open issues with patches: 1243 Issues opened (33) ================== #10898: posixmodule.c redefines FSTAT http://bugs.python.org/issue10898 reopened by alanh #12472: Build failure on IRIX http://bugs.python.org/issue12472 opened by kais58 #12476: ctypes: need example how to pass raw data from Python http://bugs.python.org/issue12476 opened by techtonik #12478: Possible error in HTTPErrorProcessor documentation http://bugs.python.org/issue12478 opened by sandro.tosi #12479: Add HTTPErrorProcessor class definition http://bugs.python.org/issue12479 opened by sandro.tosi #12480: urllib2 doesn't use proxy (fieddler2), configed the proxy with http://bugs.python.org/issue12480 opened by Or.Wilder #12483: CThunkObject_dealloc should call PyObject_GC_UnTrack? http://bugs.python.org/issue12483 opened by rfk #12484: The Py_InitModule functions no longer exist, but remain in the http://bugs.python.org/issue12484 opened by alejolp #12485: textwrap.wrap: new argument for more pleasing output http://bugs.python.org/issue12485 opened by parent5446 #12486: tokenize module should have a unicode API http://bugs.python.org/issue12486 opened by Devin Jeanpierre #12488: multiprocessing.Connection does not communicate pipe closure b http://bugs.python.org/issue12488 opened by lcampagn #12489: email.errors.HeaderParseError if base64url is used http://bugs.python.org/issue12489 opened by guettli #12491: Update glossary documentation for the term 'attribute' http://bugs.python.org/issue12491 opened by orsenthil #12494: subprocess: check_output() doesn't close pipes on error http://bugs.python.org/issue12494 opened by haypo #12495: Rewrite InterProcessSignalTests http://bugs.python.org/issue12495 opened by haypo #12498: asyncore.dispatcher_with_send, disconnection problem + miss-co http://bugs.python.org/issue12498 opened by François-Xavier.Bourlet #12499: textwrap.wrap: add control for fonts with different character http://bugs.python.org/issue12499 opened by parent5446 #12500: Skip test_ssl.test_connect_ex() on connection error http://bugs.python.org/issue12500 opened by haypo #12502: 100% cpu usage when using asyncore with UNIX socket http://bugs.python.org/issue12502 opened by Alexey.Agapitov #12503: "with" statement error message is more confusing in Py2.7 http://bugs.python.org/issue12503 opened by Ismael.Garrido #12506: NIS module cant handle multiple NIS map entries for the same G http://bugs.python.org/issue12506 opened by bjorn.lofdahl #12507: tkSimpleDialog problem http://bugs.python.org/issue12507 opened by rzn8tr #12508: Codecs Anomaly http://bugs.python.org/issue12508 opened by spatz123 #12509: test_gdb fails on debug build when builddir != srcdir http://bugs.python.org/issue12509 opened by dmalcolm #12510: IDLE get_the_calltip mishandles raw strings http://bugs.python.org/issue12510 opened by Roy.Fox #12512: codecs: StreamWriter issues with stateful codecs after a seek http://bugs.python.org/issue12512 opened by haypo #12513: codec.StreamReaderWriter: issues with interlaced read-write http://bugs.python.org/issue12513 opened by haypo #12514: timeit disables garbage collection if timed code raises an exc http://bugs.python.org/issue12514 opened by Gareth.Rees #12515: email modifies the message structure when the parsed email is http://bugs.python.org/issue12515 opened by xavierd #12516: imghdr.what should take one argument http://bugs.python.org/issue12516 opened by jfinkels #12517: Large file support on Windows: sizeof(off_t) is 32 bits http://bugs.python.org/issue12517 opened by haypo #12518: In string.Template it's impossible to transform delimiter in t http://bugs.python.org/issue12518 opened by py.user #12519: Call next version 3.3.0 http://bugs.python.org/issue12519 opened by eric.araujo Most recent 15 issues with no replies (15) ========================================== #12519: Call next version 3.3.0 http://bugs.python.org/issue12519 #12518: In string.Template it's impossible to transform delimiter in t http://bugs.python.org/issue12518 #12516: imghdr.what should take one argument http://bugs.python.org/issue12516 #12515: email modifies the message structure when the parsed email is http://bugs.python.org/issue12515 #12513: codec.StreamReaderWriter: issues with interlaced read-write http://bugs.python.org/issue12513 #12510: IDLE get_the_calltip mishandles raw strings http://bugs.python.org/issue12510 #12509: test_gdb fails on debug build when builddir != srcdir http://bugs.python.org/issue12509 #12506: NIS module cant handle multiple NIS map entries for the same G http://bugs.python.org/issue12506 #12498: asyncore.dispatcher_with_send, disconnection problem + miss-co http://bugs.python.org/issue12498 #12495: Rewrite InterProcessSignalTests http://bugs.python.org/issue12495 #12491: Update glossary documentation for the term 'attribute' http://bugs.python.org/issue12491 #12486: tokenize module should have a unicode API http://bugs.python.org/issue12486 #12483: CThunkObject_dealloc should call PyObject_GC_UnTrack? http://bugs.python.org/issue12483 #12479: Add HTTPErrorProcessor class definition http://bugs.python.org/issue12479 #12478: Possible error in HTTPErrorProcessor documentation http://bugs.python.org/issue12478 Most recent 15 issues waiting for review (15) ============================================= #12517: Large file support on Windows: sizeof(off_t) is 32 bits http://bugs.python.org/issue12517 #12516: imghdr.what should take one argument http://bugs.python.org/issue12516 #12514: timeit disables garbage collection if timed code raises an exc http://bugs.python.org/issue12514 #12509: test_gdb fails on debug build when builddir != srcdir http://bugs.python.org/issue12509 #12502: 100% cpu usage when using asyncore with UNIX socket http://bugs.python.org/issue12502 #12500: Skip test_ssl.test_connect_ex() on connection error http://bugs.python.org/issue12500 #12499: textwrap.wrap: add control for fonts with different character http://bugs.python.org/issue12499 #12494: subprocess: check_output() doesn't close pipes on error http://bugs.python.org/issue12494 #12485: textwrap.wrap: new argument for more pleasing output http://bugs.python.org/issue12485 #12483: CThunkObject_dealloc should call PyObject_GC_UnTrack? http://bugs.python.org/issue12483 #12479: Add HTTPErrorProcessor class definition http://bugs.python.org/issue12479 #12454: mailbox: use ASCII to read/write .mh_sequences files http://bugs.python.org/issue12454 #12452: reuse plistlib in sysconfig; deprecation process in plistlib http://bugs.python.org/issue12452 #12451: open: avoid the locale encoding when possible http://bugs.python.org/issue12451 #12448: smtplib's __main__ doesn't flush when prompting http://bugs.python.org/issue12448 Top 10 most discussed issues (10) ================================= #10181: Problems with Py_buffer management in memoryobject.c (and else http://bugs.python.org/issue10181 35 msgs #6721: Locks in python standard library should be sanitized on fork http://bugs.python.org/issue6721 10 msgs #8716: test_tk/test_tkk_guionly fails on OS X if run from buildbot sl http://bugs.python.org/issue8716 9 msgs #10898: posixmodule.c redefines FSTAT http://bugs.python.org/issue10898 8 msgs #12167: test_packaging reference leak http://bugs.python.org/issue12167 7 msgs #12411: cgi.parse_multipart is broken on 3.x http://bugs.python.org/issue12411 6 msgs #12488: multiprocessing.Connection does not communicate pipe closure b http://bugs.python.org/issue12488 6 msgs #10117: Tools/scripts/reindent.py fails on non-UTF-8 encodings http://bugs.python.org/issue10117 5 msgs #10883: urllib: socket is not closed explicitly http://bugs.python.org/issue10883 5 msgs #11732: Skip decorator for tests requiring manual intervention on Wind http://bugs.python.org/issue11732 5 msgs Issues closed (45) ================== #4673: Distutils should provide an uninstall command http://bugs.python.org/issue4673 closed by eric.araujo #6234: cgi.FieldStorage is broken when given POST data http://bugs.python.org/issue6234 closed by eric.araujo #7123: Multiprocess Process does not always exit when run from a thre http://bugs.python.org/issue7123 closed by neologix #9015: f.write(s) for s > 2GB hangs in win64 (and win32?) http://bugs.python.org/issue9015 closed by haypo #9611: FileIO not 64-bit safe under Windows http://bugs.python.org/issue9611 closed by haypo #9642: #ifdef and mbcs: don't check for defined(HAVE_USABLE_WCHAR_T) http://bugs.python.org/issue9642 closed by haypo #10403: Use "member" consistently http://bugs.python.org/issue10403 closed by python-dev #11512: adding test suite for cgitb http://bugs.python.org/issue11512 closed by brian.curtin #11859: test_interrupted_write_text() of test_io failed of Python 3.3 http://bugs.python.org/issue11859 closed by haypo #12016: Wrong behavior for '\xff\n'.decode('gb2312', 'ignore') http://bugs.python.org/issue12016 closed by haypo #12147: smtplib.send_message does not implement corectly rfc 2822 http://bugs.python.org/issue12147 closed by r.david.murray #12169: Factor out common code for d2 commands register, upload and up http://bugs.python.org/issue12169 closed by eric.araujo #12198: zipfile.py:1047: DeprecationWarning: 'H' format requires 0 <= http://bugs.python.org/issue12198 closed by petri.lehtinen #12291: file written using marshal in 3.2 can be read by 2.7, but not http://bugs.python.org/issue12291 closed by python-dev #12352: multiprocessing.Value() hangs http://bugs.python.org/issue12352 closed by neologix #12391: packaging install fails to clean up temp files http://bugs.python.org/issue12391 closed by python-dev #12412: non defined representation for pwd.struct_passwd http://bugs.python.org/issue12412 closed by eric.araujo #12423: signal handler doesn't handle SIGABRT from os.abort http://bugs.python.org/issue12423 closed by haypo #12426: packaging.tests.test_command_install_dist.InstallTestCase fail http://bugs.python.org/issue12426 closed by haypo #12429: test_io.check_interrupted_write() sporadic failures on FreeBSD http://bugs.python.org/issue12429 closed by haypo #12438: IDLE problem displaying warning message http://bugs.python.org/issue12438 closed by python-dev #12456: Hangs in concurrent.futures http://bugs.python.org/issue12456 closed by pitrou #12459: time.sleep(-1.0) behaviour http://bugs.python.org/issue12459 closed by haypo #12465: gc.get_referents can be used to crash Python http://bugs.python.org/issue12465 closed by georg.brandl #12467: test_threading.test_6_daemon_threads(): Assertion failed: PyUn http://bugs.python.org/issue12467 closed by haypo #12468: longjmp causes uninitialized stack frame http://bugs.python.org/issue12468 closed by neologix #12469: test_faulthandler failures on FreeBSD 6 http://bugs.python.org/issue12469 closed by haypo #12470: Fix cut&paste typo in test_shutil http://bugs.python.org/issue12470 closed by orsenthil #12471: wrong TypeError message on '%i' formatting http://bugs.python.org/issue12471 closed by python-dev #12473: factory func of collections.defaultdict should receive the "mi http://bugs.python.org/issue12473 closed by amaury.forgeotdarc #12474: Invalid read in symtable.c http://bugs.python.org/issue12474 closed by python-dev #12475: Generator bug allows you to chain arbitrary tracebacks to the http://bugs.python.org/issue12475 closed by python-dev #12477: input() does'nt strip CR http://bugs.python.org/issue12477 closed by georg.brandl #12481: test_faulthandler: popups on Windows/Debug/x64 http://bugs.python.org/issue12481 closed by haypo #12482: input() not working correctly on Mac OS X http://bugs.python.org/issue12482 closed by ned.deily #12487: urllib2.urlopen() returns object missing context manager http://bugs.python.org/issue12487 closed by orsenthil #12490: Documentation for itertools.chain.from_iterable is incorrect http://bugs.python.org/issue12490 closed by RodolphoEckhardt #12492: Inconsistent Python find() behavior http://bugs.python.org/issue12492 closed by georg.brandl #12493: subprocess: Popen.communicate() doesn't handle EINTR in some c http://bugs.python.org/issue12493 closed by haypo #12496: test_ssl test_connect_capath fails with "certificate verify fa http://bugs.python.org/issue12496 closed by ned.deily #12497: test_codecmaps_* skipped - Could not retrieve * http://bugs.python.org/issue12497 closed by ned.deily #12501: callable(): remove/amend the deprecation warning in Python 2.7 http://bugs.python.org/issue12501 closed by python-dev #12504: packaging: fix database to stop skipping uninstall tests on wi http://bugs.python.org/issue12504 closed by eric.araujo #12505: python interpreter not handle wildards properly http://bugs.python.org/issue12505 closed by brian.curtin #12511: class/instance xyz has no attribute '_abc' http://bugs.python.org/issue12511 closed by Andreas.Hasenkopf

1 0

Draft PEP: Deprecate codecs.StreamReader and codecs.StreamWriter
by Victor Stinner July 8, 2011

July 8, 2011

Hi, Last may, I proposed to deprecate open() function, StreamWriter and StreamReader classes of the codecs module. I accepted to keep open() after the discussion on python-dev. Here is a more complete proposition as a PEP. It is a draft and I expect a lot of comments :) Victor ----------------------- PEP: xxx Title: Deprecate codecs.StreamReader and codecs.StreamWriter Version: $Revision$ Last-Modified: $Date$ Author: Victor Stinner Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 28-May-2011 Python-Version: 3.3 Abstract ======== io.TextIOWrapper and codecs.StreamReaderWriter offer the same API [#f1]_. TextIOWrapper has more features and is faster than StreamReaderWriter. Duplicate code means that bugs should be fixed twice and that we may have subtle differences between the two implementations. The codecs modules was introduced in Python 2.0, see the PEP 100. The io module was introduced in Python 2.6 and 3.0 (see the PEP 3116), and reimplemented in C in Python 2.7 and 3.1. Motivation ========== When the Python I/O model was updated for 3.0, the concept of a "stream-with-known-encoding" was introduced in the form of io.TextIOWrapper. As this class is critical to the performance of text-based I/O in Python 3, this module has an optimised C version which is used by CPython by default. Many corner cases in handling buffering, stateful codecs and universal newlines have been dealt with since the release of Python 3.0. This new interface overlaps heavily with the legacy codecs.StreamReader, codecs.StreamWriter and codecs.StreamReaderWriter interfaces that were part of the original codec interface design in PEP 100. These interfaces are organised around the principle of an encoding with an associated stream (i.e. the reverse of arrangement in the io module), so the original PEP 100 design required that codec writers provide appropriate StreamReader and StreamWriter implementations in addition to the core codec encode() and decode() methods. This places a heavy burden on codec authors providing these specialised implementations to correctly handle many of the corner cases that have now been dealt with by io.TextIOWrapper. While deeper integration between the codec and the stream allows for additional optimisations in theory, these optimisations have in practice either not been carried out and else the associated code duplication means that the corner cases that have been fixed in io.TextIOWrapper are still not handled correctly in the various StreamReader and StreamWriter implementations. Accordingly, this PEP proposes that: * codecs.open() be updated to delegate to the builtin open() in Python 3.3; * the legacy codecs.Stream* interfaces, including the streamreader and streamwriter attributes of codecs.CodecInfo be deprecated in Python 3.3 and removed in Python 3.4. Rationale ========= StreamReader and StreamWriter issues '''''''''''''''''''''''''''''''''''' * StreamReader is unable to translate newlines. * StreamReaderWriter handles reads using StreamReader and writes using StreamWriter. These two classes may be inconsistent. To stay consistent, flush() must be called after each write which slows down interlaced read-write. * StreamWriter doesn't support "line buffering" (flush if the input text contains a newline). * StreamReader classes of the CJK encodings (e.g. GB18030) don't support universal newlines, only UNIX newlines ('\\n'). * StreamReader and StreamWriter are stateful codecs but don't expose functions to control their state (getstate() or setstate()). Each codec has to implement corner cases, see "Issue with stateful codecs". * StreamReader and StreamWriter are very similar to IncrementalReader and IncrementalEncoder, some code is duplicated for stateful codecs (e.g. UTF-16). * Each codec has to reimplement its own StreamReader and StreamWriter class, even if it's trivial (just call the encoder/decoder). * codecs.open(filename, "r") creates a io.TextIOWrapper object. * No codec implements an optimized method in StreamReader or StreamWriter based on the specificities of the codec. TextIOWrapper features '''''''''''''''''''''' * TextIOWrapper supports any kind of newline, including translating newlines (to UNIX newlines), to read and write. * TextIOWrapper reuses incremental encoders and decoders (no duplication of code). * The io module (TextIOWrapper) is faster than the codecs module (StreamReader). It is implemented in C, whereas codecs is implemented in Python. * TextIOWrapper has a readahead algorithm which speeds up small reads: read character by character or line by line (io is 10x through 25x faster than codecs on these operations). * TextIOWrapper has a write buffer. * TextIOWrapper.tell() is optimized. * TextIOWrapper supports random access (read+write) using a single class which permit to optimize interlaced read-write (but no such optimization is implemented). Possible improvements of StreamReader and StreamWriter '''''''''''''''''''''''''''''''''''''''''''''''''''''' It would be possible to add functions to StreamReader and StreamWriter to give access to the state of codec. And so it would be possible fix issues with stateful codecs in a base class instead of having to fix them is each stateful StreamReader and StreamWriter classes. It would be possible to change StreamReader and StreamWriter to make them use IncrementalDecoder and IncrementalEncoder. A codec can implement variants which are optimized for the specific encoding or intercept certain stream methods to add functionality or improve the encoding/decoding performance. TextIOWrapper cannot implement such optimization, but TextIOWrapper uses incremental encoders and decoders and uses read and write buffers, so the overhead of incomplete inputs is low or nul. A lot more could be done for other variable length encoding codecs, e.g. UTF-8, since these often have problems near the end of a read due to missing bytes. The UTF-32-BE/LE codecs could simply multiply the character position by 4 to get the byte position. Usage of StreamReader and StreamWriter '''''''''''''''''''''''''''''''''''''' These classes are rarely used directly, but indirectly using codecs.open(). They are not used in Python 3 standard library (except in the codecs module). Some projects implement their own codec with StreamReader and StreamWriter, but don't use these classes. Backwards Compatibility ======================= Keep the public API, codecs.open '''''''''''''''''''''''''''''''' codecs.open() can be replaced by the builtin open() function. open() has a similar API but has also more options. codecs.open() was the only way to open a text file in Unicode mode until Python 2.6. Many Python 2 programs uses this function. Removing codecs.open() implies more work to port programs from Python 2 to Python 3, especially projets using the same code base for the two Python versions (without using 2to3 program). codecs.open() is kept for backward compatibility with Python 2. Deprecate StreamReader and StreamWriter ''''''''''''''''''''''''''''''''''''''' Instanciate StreamReader or StreamWriter must raise a DeprecationWarning in Python 3.3. Implement a subclass don't raise a DeprecationWarning. codecs.open() will be changed to reuse the builtin open() function (TextIOWrapper). EncodedFile(), StreamRandom, StreamReader, StreamReaderWriter and StreamWriter will be removed in Python 3.4. Issue with stateful codecs ========================== It is difficult to use correctly a stateful codec with a stream. Some cases are supported by the codecs module, while io has no more known bug related to stateful codecs. The main difference between the codecs and the io module is that bugs have to be fixed in StreamReader and/or StreamWriter classes of each codec for the codecs module, whereas bugs can be fixed only once in io.TextIOWrapper. Here are some examples of issues with stateful codecs. Stateful codecs ''''''''''''''' Python supports the following stateful codecs: * cp932 * cp949 * cp950 * euc_jis_2004 * euc_jisx2003 * euc_jp * euc_kr * gb18030 * gbk * hz * iso2022_jp * iso2022_jp_1 * iso2022_jp_2 * iso2022_jp_2004 * iso2022_jp_3 * iso2022_jp_ext * iso2022_kr * shift_jis * shift_jis_2004 * shift_jisx0213 * utf_8_sig * utf_16 * utf_32 Read and seek(0) '''''''''''''''' :: with open(filename, 'w', encoding='utf_16') as f: f.write('abc') f.write('def') f.seek(0) assert f.read() == 'abcdef' f.seek(0) assert f.read() == 'abcdef' The io and codecs modules support this usecase correctly. Write, seek(0) and seek(n) '''''''''''''''''''''''''' :: with open(filename, 'w', encoding='utf_16') as f: f.write('abc') pos = f.tell() with open(filename, 'r+', encoding='utf_16') as f: f.seek(pos) f.write('def') f.seek(0) f.write('###') with open(filename, 'r', encoding='utf_16') as f: assert f.read() == '###def' The io module supports this usecase, whereas codecs fails because it writes a new BOM on the second write. Append mode ''''''''''' :: with open(filename, 'w', encoding='utf_16') as f: f.write('abc') with open(filename, 'a', encoding='utf_16') as f: f.write('def') with open(filename, 'r', encoding='utf_16') as f: assert f.read() == 'abcdef' The io module supports this usecase, whereas codecs fails because it writes a new BOM on the second write. Links ===== * `PEP 100: Python Unicode Integration <http://www.python.org/dev/peps/pep-0100/>`_ * `PEP 3116 <http://www.python.org/dev/peps/pep-3116/>`_ * `Issue #8796: Deprecate codecs.open() <http://bugs.python.org/issue8796>`_ * `[python-dev] Deprecate codecs.open() and StreamWriter/StreamReader <http://mail.python.org/pipermail/python-dev/2011-May/111591.html>`_ Copyright ========= This document has been placed in the public domain. Footnotes ========= .. [#f1] StreamReaderWriter has two more attributes than TextIOWrapper, reader and writer.

9 25

Re: [Python-Dev] Python Launcher for Windows (PEP 397) needs testing!
by Paul Moore July 7, 2011

July 7, 2011

On 7 July 2011 15:24, Vinay Sajip <vinay_sajip(a)yahoo.co.uk> wrote: > Hi Paul, > > Thanks for trying it out. If it installs successfully, nothing will appear to > happen, Unix-style :-) > > There should be files installed in c:\Program Files\Python Launcher: > > py.exe, pyw.exe, py.ini > > and there should be registry entries in HKEY_CLASSES_ROOT\Python.File, > Python.NoConFile and Python.CompiledFile which point to those installed files. > > Can you confirm if this is the case? Ah, yes. This is what has happened. In that case, some points: 1. A "silent by default" installer like this is not very usual in the Windows world, I'd have expected a confirmation dialog at least. For silent installs, msiexec /silent is available. 2. I thought the idea from the PEP was to put py.exe/pyw.exe into a "system" location which is already on the PATH (likely windows\system32, or whatever the 64-bit equivalent is). That way, py or py -3 and similar can be used to launch the interactive interpreter. 3. Given that you're not installing in system32, you should add the install dir to PATH (and remove it on uninstall :-)) That's definitely a second-best option, though, so I'd rather you didn't, but installed in system32 instead :-) 4. If you embed both of the py.ico and pyc.ico files into the launcher exes, you wouldn't need to have them as separate files (I see py.ico is embedded already) and so the footprint becomes 2 exes and an ini file. That might be a bit more palatable for people who are uncomfortable with installing into somewhere like system32. Otherwise it looks great. > P.S. I didn't copy the list, as if there is some problem which requires going > back and forth a bit, it would be OT for the list. Agreed. I've added the list back in as the above is really design feedback, and so would benefit from comments from the list. Paul.

2 1

Python Launcher for Windows (PEP 397) needs testing!
by Vinay Sajip July 7, 2011

July 7, 2011

The C implementation of the PEP 397-compatible Python Launcher for Windows has come along nicely in the last few days, and now reached a point where it would benefit from some testing by interested python-dev members. Points of note: 1. As well as source available on https://bitbucket.org/vinay.sajip/pylauncher there are built 32- and 64-bit msi files at https://bitbucket.org/vinay.sajip/pylauncher/downloads Please remember that this is beta software. While it appears stable, I've tested in virtual machines (WinXP 32-bit, Win7 32-bit and 64-bit) which I can readily restore from backup. There are also msm files which could be used to e.g. integrate with the Python msi files, if approved, at some later date. 2. On installation, any existing associations are saved, and restored when the launcher is uninstalled (this is done automatically by Windows Installer). 3. On uninstallation, if there are Pythons installed and no associations, a dialog pops up listing all the installed Pythons and offering the user the chance to associate one of the Pythons with the Python extensions. The user can choose to associate or not, but once they choose an association, then that association will always be there unless the launcher is reinstalled (in which case it takes over the association while it's still installed, and restores the previous one when it's uninstalled). 4. I've tried to cover all of the points in the PEP. There is a test suite - while this appears to be small (7 tests) the individual shebangs are all tested, as are the customisable commands etc. However, I'm sure some of you will break it ;-) 5. I used WiX to build the msm/msi files, but that's only because of increased familiarity over msilib. The build procedure could switch over to msilib at some later date. All the other code is just plain C and Win32 APIs (gosh - takes me back! Window procedures, anyone?). The code builds with Visual Studio and also Visual Studio Express (C++ edition). Regards, Vinay Sajip

3 3