Re: [Python-Dev] Deprecate codecs.open() and StreamWriter/StreamReader
Victor Stinner wrote: > Le mercredi 25 mai 2011 à 15:43 +0200, M.-A. Lemburg a écrit : >> For UTF-16 it would e.g. make sense to always read data in blocks >> with even sizes, removing the trial-and-error decoding and extra >> buffering currently done by the base classes. For UTF-32, the >> blocks should have size % 4 == 0. >> >> For UTF-8 (and other variable length encodings) it would make >> sense looking at the end of the (bytes) data read from the >> stream to see whether a complete code point was read or not, >> rather than simply running the decoder on the complete data >> set, only to find that a few bytes at the end are missing. > > I think that the readahead algorithm is much more faster than trying to > avoid partial input, and it's not a problem to have partial input if you > use an incremental decoder. Depends on where you're coming from. For non-seekable streams such as sockets or pipes, readahead is not going to work. For seekable streams, I agree that readahead is better strategy. And of course, it also makes sense to use incremental decoders for these encodings. >> For single character encodings, it would make sense to prefetch >> data in big chunks and skip all the trial and error decoding >> implemented by the base classes to address the above problem >> with variable length encodings. > > TextIOWrapper implements this optimization using its readahead > algorithm. It does yes, but the above was an optimization specific to single character encodings, not all encodings and TextIOWrapper doesn't know anything about specific characteristics of the underlying encodings (except perhaps a few special cases). >> That's somewhat unfair: TextIOWrapper is implemented in C, >> whereas the StreamReader/Writer subclasses used by the >> codecs are written in Python. >> >> A fair comparison would use the Python implementation of >> TextIOWrapper. > > Do you mean that you would like to reimplement codecs in C? As use of Unicode codecs increases in Python applications, this would certainly be an approach to consider, yes. Looking at the current situation, it is better to use TextIOWrapper as it provides better performance, but since TextIOWrapper cannot (per desing) provide per-codec optimizations, this is likely to change with a codec rewrite in C of codecs that benefit a lot from such specific optimizations. > It is not > revelant to compare codecs and _pyio, because codecs reuses > BufferedReader (of the io module, not of the _pyio module), and io is > the main I/O module of Python 3. They both use whatever stream you pass in as parameter, so your TextIOWrapper benchmark will also use the BufferedReader of the io module. The point here is to compare Python to Python, not Python to C. > But well, as you want, here is a benchmark comparing: >_pyio.TextIOWrapper(io.open(filename, 'rb'), encoding) > and > codecs.open(filename, encoding) > > The only change with my previous bench.py script is the test_io() > function : > > def test_io(test_func, chunk_size): > with open(FILENAME, 'rb') as buffered: > f = _pyio.TextIOWrapper(buffered, ENCODING) > test_file(f, test_func, chunk_size) > f.close() Thanks for running those tests. > (1) Decode Objects/unicodeobject.c (317336 characters) from utf-8 > > test_io.readline(): 1193.4 ms > test_codecs.readline(): 1267.9 ms > -> codecs 6% slower than io > > test_io.read(1): 21696.4 ms > test_codecs.read(1): 36027.2 ms > -> codecs 66% slower than io > > test_io.read(100): 3080.7 ms > test_codecs.read(100): 3901.7 ms > -> codecs 27% slower than io This shows that StreamReader/Writer could benefit quite a bit from using incremental encoders/decoders. > test_io.read(): 3991.0 ms > test_codecs.read(): 1736.9 ms > -> codecs 130% FASTER than io No surprise here. It's also a very common use case to read the whole file in one go and the bigger the file, the more impact this has. > (2) Decode README (6613 characters) from ascii > > test_io.readline(): 678.1 ms > test_codecs.readline(): 760.5 ms > -> codecs 12% slower than io > > test_io.read(1): 13533.2 ms > test_codecs.read(1): 21900.0 ms > -> codecs 62% slower than io > > test_io.read(100): 2663.1 ms > test_codecs.read(100): 3270.1 ms > -> codecs 23% slower than io > > test_io.read(): 6769.1 ms > test_codecs.read(): 3919.6 ms > -> codecs 73% FASTER than io See above. > (3) Decode Lib/test/cjkencodings/gb18030.txt (501 characters) from > gb18030 > > test_io.readline(): 38.9 ms > test_codecs.readline(): 15.1 ms > -> codecs 157% FASTER than io > > test_io.read(1): 369.8 ms > test_codecs.read(1): 302.2 ms > -> codecs 22% FASTER than io > > test_io.read(100): 258.2 ms > test_codecs.read(100): 155.1 ms > -> codecs 67% FASTER than io > > test_io.read(): 1803.2 ms > test_codecs.read(): 1002.9 ms > -> codecs 80% FASTER than io These results are interesting since gb18030 is a shift encoding which keeps state in the encoded data stream, so the strategy chosen by TextI
Re: [Python-Dev] [Python-checkins] cpython: Avoid useless "++" at the end of functions
So, given the discussions about this change, can you please revert it,
Victor?
Eric.
On 05/26/2011 08:07 AM, victor.stinner wrote:
> http://hg.python.org/cpython/rev/7ba176c2f558
> changeset: 70397:7ba176c2f558
> user:Victor Stinner
> date:Thu May 26 13:53:47 2011 +0200
> summary:
> Avoid useless "++" at the end of functions
>
> Warnings found by the Clang Static Analyzer.
>
> files:
> Objects/setobject.c | 4 ++--
> Objects/unicodeobject.c | 2 +-
> Python/compile.c| 6 +++---
> 3 files changed, 6 insertions(+), 6 deletions(-)
>
>
> diff --git a/Objects/setobject.c b/Objects/setobject.c
> --- a/Objects/setobject.c
> +++ b/Objects/setobject.c
> @@ -612,9 +612,9 @@
> *u++ = '{';
> /* Omit the brackets from the listrepr */
> Py_UNICODE_COPY(u, PyUnicode_AS_UNICODE(listrepr)+1,
> - PyUnicode_GET_SIZE(listrepr)-2);
> + newsize-2);
> u += newsize-2;
> -*u++ = '}';
> +*u = '}';
> }
> Py_DECREF(listrepr);
> if (Py_TYPE(so) != &PySet_Type) {
> diff --git a/Objects/unicodeobject.c b/Objects/unicodeobject.c
> --- a/Objects/unicodeobject.c
> +++ b/Objects/unicodeobject.c
> @@ -6474,7 +6474,7 @@
> }
> }
> /* 0-terminate the output string */
> -*output++ = '\0';
> +*output = '\0';
> Py_XDECREF(exc);
> Py_XDECREF(errorHandler);
> return 0;
> diff --git a/Python/compile.c b/Python/compile.c
> --- a/Python/compile.c
> +++ b/Python/compile.c
> @@ -3747,11 +3747,11 @@
> a->a_lnotab_off += 2;
> if (d_bytecode) {
> *lnotab++ = d_bytecode;
> -*lnotab++ = d_lineno;
> +*lnotab = d_lineno;
> }
> else { /* First line of a block; def stmt, etc. */
> *lnotab++ = 0;
> -*lnotab++ = d_lineno;
> +*lnotab = d_lineno;
> }
> a->a_lineno = i->i_lineno;
> a->a_lineno_off = a->a_offset;
> @@ -3796,7 +3796,7 @@
> if (i->i_hasarg) {
> assert(size == 3 || size == 6);
> *code++ = arg & 0xff;
> -*code++ = arg >> 8;
> +*code = arg >> 8;
> }
> return 1;
> }
>
>
>
>
> ___
> Python-checkins mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-checkins
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecate codecs.open() and StreamWriter/StreamReader
Le vendredi 27 mai 2011 10:17:29, M.-A. Lemburg a écrit : > > I think that the readahead algorithm is much more faster than trying to > > avoid partial input, and it's not a problem to have partial input if you > > use an incremental decoder. > > Depends on where you're coming from. For non-seekable streams > such as sockets or pipes, readahead is not going to work. I don't see how StreamReader/StreamWriter can do a better job than TextIOWrapper for non-seekable streams. > > TextIOWrapper implements this optimization using its readahead > > algorithm. > > It does yes, but the above was an optimization specific > to single character encodings, not all encodings and > TextIOWrapper doesn't know anything about specific characteristics > of the underlying encodings (except perhaps a few special > cases). Please give me numbers: how fast are your suggested optimizations? Are they faster than readahead? All of your argumentation is based on theorical facts. > > Do you mean that you would like to reimplement codecs in C? > > As use of Unicode codecs increases in Python applications, > this would certainly be an approach to consider, yes. I am not sure that StreamReader is/can be faster than TextIOWrapper if it is reimplemented in C (see the updated benchmark below, codecs vs _pyio). > > test_io.read(): 3991.0 ms > > test_codecs.read(): 1736.9 ms > > -> codecs 130% FASTER than io > > No surprise here. It's also a very common use case > to read the whole file in one go and the bigger > the file, the more impact this has. Oh, I understood why codecs is always faster than _pyio (or even io): it's because of IncrementalNewlineDecoder. To be fair, the read(-1) should be tested without IncrementalNewlineDecoder: e.g. with newline='\n'. newline='' cannot be used for the read(-1) test, because even if newline='' indicates that we don't want to translate newlines, read(-1) uses the IncrementalNewlineDecoder (which is slower than not calling it at all). We may optimize this specific case in TextIOWrapper. > > (3) Decode Lib/test/cjkencodings/gb18030.txt (501 characters) from > > gb18030 > > > > test_io.readline(): 38.9 ms > > test_codecs.readline(): 15.1 ms > > -> codecs 157% FASTER than io > > > > test_io.read(1): 369.8 ms > > test_codecs.read(1): 302.2 ms > > -> codecs 22% FASTER than io > > > > test_io.read(100): 258.2 ms > > test_codecs.read(100): 155.1 ms > > -> codecs 67% FASTER than io > > > > test_io.read(): 1803.2 ms > > test_codecs.read(): 1002.9 ms > > -> codecs 80% FASTER than io > > These results are interesting since gb18030 is a shift > encoding which keeps state in the encoded data stream, so > the strategy chosen by TextIOWrapper doesn't work out that > well. In the 4 tests, TextIOWrapper only calls the decoder *once*, on the whole content of the file. The file size if 864 bytes, which is smaller than the TextIOWrapper chunk size (2048 bytes). StreamReader of the gb18030 codec is implemented in C, not in Python (using multibytecodec.c). So to be fair, the test on this encoding should be done using io, not _pyio for this encoding. Moreover, the multibytecodec module doesn't support universal newline! It does only support '\n' newlines. So to be more fair, the test should use '\n' newline. It's one more reason to TextIOWrapper instead of StreamReader: it has the same behaviour (universal newlines) for all encodings. Or is it yet another bug in StreamReader? > I am still -1 on deprecating the StreamReader/Writer parts of > the codec APIs. I've given numerous reasons on why these are > useful, what their intention is, why they were added to Python 1.6. codecs.open() now uses TextIOWrapper, so there is no good reason to keep StreamReader or StreamWriter. You did not give me any use case where StreamReader or StreamWriter should be used instead of TextIOWrapper. You only listed theorical optimizations. You have until the release of Python 3.3 to prove that StreamReader and/or StreamWriter can be faster than TextIOWrapper. If you can prove it using a patch and a benchmark, I will be ok to revert my commit. > Since such a deprecation would change an important documented API, > please write a PEP outlining your reasoning, including my comments, > use cases and possibilities for optimizations. Ok, I will write on a PEP explaining why StreamReader and StreamWriter are deprecated. --- I wrote a new benchmarking script which tries to compare more closely codecs to io/_pyio (change the newline value and use io for gb18030). It should be a little bit more reliable because each test now runs 5 times (taking the smallest time), but it's not really reliable... The script is attached to this mail. (1) Decode Objects/unicodeobject.c (317334 characters) from utf-8 _pyio.readline(): 1078.4 ms (8 loops, newline: '') codecs.readline(): 983.0 ms (8 loops, newline: '') -> codecs 10% FASTER than _pyio _pyio.read(1): 3503.5 ms (2 loops, newline: '') codecs.read(1): 66
Re: [Python-Dev] Deprecate codecs.open() and StreamWriter/StreamReader
2011/5/27 Victor Stinner : > You have until the release of Python 3.3 to prove that StreamReader and/or > StreamWriter can be faster than TextIOWrapper. If you can prove it using a > patch and a benchmark, I will be ok to revert my commit. Please don't hold commits over someone's head. -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecate codecs.open() and StreamWriter/StreamReader
Victor Stinner wrote: > Le vendredi 27 mai 2011 10:17:29, M.-A. Lemburg a écrit : >> I am still -1 on deprecating the StreamReader/Writer parts of >> the codec APIs. I've given numerous reasons on why these are >> useful, what their intention is, why they were added to Python 1.6. > > codecs.open() now uses TextIOWrapper, so there is no good reason to keep > StreamReader or StreamWriter. You did not give me any use case where > StreamReader or StreamWriter should be used instead of TextIOWrapper. You > only > listed theorical optimizations. > > You have until the release of Python 3.3 to prove that StreamReader and/or > StreamWriter can be faster than TextIOWrapper. If you can prove it using a > patch and a benchmark, I will be ok to revert my commit. Victor, please revert the change. It has *not* been approved ! If we'd go by your reasoning for deprecating and eventually removing parts of the stdlib or Python's subsystems, we'll end up with a barebone version of Python. That's not what we want and it's not what our users want. I have tried to explain the design decisions and reasons for those codec APIs at great length. You've pretty much used up my patience. If you are not going to revert the patch, I will. >> Since such a deprecation would change an important documented API, >> please write a PEP outlining your reasoning, including my comments, >> use cases and possibilities for optimizations. > > Ok, I will write on a PEP explaining why StreamReader and StreamWriter are > deprecated. Wrong order: first write a PEP, then discuss, then get approval, then patch. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 27 2011) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2011-05-23: Released eGenix mx Base 3.2.0 http://python.egenix.com/ 2011-05-25: Released mxODBC 3.1.1 http://python.egenix.com/ 2011-06-20: EuroPython 2011, Florence, Italy 24 days to go ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecate codecs.open() and StreamWriter/StreamReader
On Fri, May 27, 2011 at 11:42 PM, M.-A. Lemburg wrote: > > Wrong order: first write a PEP, then discuss, then get approval, > then patch. Indeed. If another committer says "please revert and better justify this change" then we revert it. We don't get into commit wars. Something does need to be done to resolve the duplication of functionality between the io and codecs modules, but it is *far* from clear that deprecating chunks of the longer standing API is the right way to go about it. This is especially true given Guido's explicit direction following the issues with the PyCObject removal in 3.2 that we be *very* conservative about introducing additional incompatibilities between Python 2 and Python 3. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecate codecs.open() and StreamWriter/StreamReader
Le vendredi 27 mai 2011 15:33:07, Benjamin Peterson a écrit : > 2011/5/27 Victor Stinner : > > You have until the release of Python 3.3 to prove that StreamReader > > and/or StreamWriter can be faster than TextIOWrapper. If you can prove > > it using a patch and a benchmark, I will be ok to revert my commit. > > Please don't hold commits over someone's head. Tell me if I am wrong, but only Marc-Andre is against deprecating StreamReader and StreamWriter. Walter and Antoine are in favor of using TextIOWrapper instead of StreamReader/StreamWriter. Different people would like to be able to call codecs.open() in Python 2 and 3, so I kept the function with its API unchanged, and I documented that open() should be preferred (but I did not deprecated codecs.open). Victor ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecate codecs.open() and StreamWriter/StreamReader
2011/5/27 Victor Stinner : > Le vendredi 27 mai 2011 15:33:07, Benjamin Peterson a écrit : >> 2011/5/27 Victor Stinner : >> > You have until the release of Python 3.3 to prove that StreamReader >> > and/or StreamWriter can be faster than TextIOWrapper. If you can prove >> > it using a patch and a benchmark, I will be ok to revert my commit. >> >> Please don't hold commits over someone's head. > > Tell me if I am wrong, but only Marc-Andre is against deprecating StreamReader > and StreamWriter. Walter and Antoine are in favor of using TextIOWrapper > instead of StreamReader/StreamWriter. I'm am too. There does, however, seem to be significant disagreement, and it shouldn't be a race to see who can commit first. > > Different people would like to be able to call codecs.open() in Python 2 and > 3, > so I kept the function with its API unchanged, and I documented that open() > should be preferred (but I did not deprecated codecs.open). -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecate codecs.open() and StreamWriter/StreamReader
Le vendredi 27 mai 2011 16:01:14, Nick Coghlan a écrit : > On Fri, May 27, 2011 at 11:42 PM, M.-A. Lemburg wrote: > > Wrong order: first write a PEP, then discuss, then get approval, > > then patch. > > Indeed. > > If another committer says "please revert and better justify this > change" then we revert it. We don't get into commit wars. I reverted my controversal commit. > Something does need to be done to resolve the duplication of > functionality between the io and codecs modules, but it is *far* from > clear that deprecating chunks of the longer standing API is the right > way to go about it. Yes, StreamReader & friends are present in Python since Python 2.0. > This is especially true given Guido's explicit > direction following the issues with the PyCObject removal in 3.2 that > we be *very* conservative about introducing additional > incompatibilities between Python 2 and Python 3. I did search for usage of these classes on the Internet, and except projects implementing their own codecs (and so implement their StreamReader/StreamWriter classes, even if they don't use it), I only found one project using directly StreamReader: pygment (*). I searched quickly, so don't trust these results :-) StreamReader & friends are used indirectly through codecs.open(). My patch changes codecs.open() to make it reuse open (io.TextIOWrapper), so the deprecation of StreamReader would not be noticed by most users. I think that there are much more users of PyCObject than users using directly the StreamReader API (not through codecs.open()). (*) I also found Sphinx, but I was wrong: it doesn't use StreamReader, it just has a full copy of the UTF-8-SIG codec which has a StreamReader class. I don't think that the class is used. Victor ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecate codecs.open() and StreamWriter/StreamReader
Le vendredi 27 mai 2011 15:42:10, M.-A. Lemburg a écrit : > If we'd go by your reasoning for deprecating and eventually > removing parts of the stdlib or Python's subsystems, we'll end > up with a barebone version of Python. That's not what we want > and it's not what our users want. I don't want to deprecate the whole stdlib, just duplicate old API, to follow "import this" mantra: "There should be one-- and preferably only one --obvious way to do it." It's difficult for an user to choose between between open() and codecs.open(). Victor ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2011-05-20 - 2011-05-27)
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:
open2813 (+19)
closed 21165 (+50)
total 23978 (+69)
Open issues with patches: 1216
Issues opened (47)
==
#12128: Allow an abc.abstractproperty to be overridden by an instance
http://bugs.python.org/issue12128 opened by cool-RR
#12129: Document Object Model API - validation
http://bugs.python.org/issue12129 opened by Kyle.Keating
#12133: ResourceWarning in urllib.request
http://bugs.python.org/issue12133 opened by ezio.melotti
#12134: json.dump much slower than dumps
http://bugs.python.org/issue12134 opened by poq
#12135: The spawn function should return stderr.
http://bugs.python.org/issue12135 opened by pitrou
#12137: EBADF in test_urllibnet
http://bugs.python.org/issue12137 opened by pitrou
#12139: Add CCC command support to ftplib
http://bugs.python.org/issue12139 opened by giampaolo.rodola
#12141: sysconfig.get_config_vars('srcdir') fails in specific cases
http://bugs.python.org/issue12141 opened by tarek
#12142: Reference cycle when importing ctypes
http://bugs.python.org/issue12142 opened by poq
#12144: cookielib.CookieJar.make_cookies fails for cookies with 'expir
http://bugs.python.org/issue12144 opened by Scott.Wimer
#12145: distutils2 should support README.rst
http://bugs.python.org/issue12145 opened by daniellindsley
#12147: smtplib.send_message does not implement corectly rfc 2822
http://bugs.python.org/issue12147 opened by Nicolas.Estibals
#12148: Clarify "or-ing together" doctest option flags
http://bugs.python.org/issue12148 opened by ekorn
#12149: Segfault in _PyObject_GenericGetAttrWithDict
http://bugs.python.org/issue12149 opened by ezio.melotti
#12151: test_logging fails sometimes
http://bugs.python.org/issue12151 opened by haypo
#12154: PyDoc Partial Functions
http://bugs.python.org/issue12154 opened by JJeffries
#12155: queue example doesn't stop worker threads
http://bugs.python.org/issue12155 opened by haypo
#12156: test_multiprocessing.test_notify_all() timeout (1 hour) on Fre
http://bugs.python.org/issue12156 opened by haypo
#12157: join method of multiprocessing Pool object hangs if iterable a
http://bugs.python.org/issue12157 opened by Gökçen.Eraslan
#12160: codecs doc: what is StreamCodec?
http://bugs.python.org/issue12160 opened by haypo
#12162: Documentation about re \number
http://bugs.python.org/issue12162 opened by Seth.Troisi
#12163: str.count
http://bugs.python.org/issue12163 opened by py.user
#12164: str.translate docstring doesn't mention that 'table' can be No
http://bugs.python.org/issue12164 opened by mark.dickinson
#12165: Nonlocal does not include global; clarify doc
http://bugs.python.org/issue12165 opened by Lukas.Petru
#12167: test_packaging reference leak
http://bugs.python.org/issue12167 opened by pitrou
#12168: SysLogHandler incorrectly appends \000 to messages
http://bugs.python.org/issue12168 opened by Carl.Crowder
#12169: Factor out common code for d2 commands register, upload and up
http://bugs.python.org/issue12169 opened by eric.araujo
#12170: Bytes.index() and bytes.count() should accept byte ints
http://bugs.python.org/issue12170 opened by max-alleged
#12171: Reset method of the incremental encoders of CJK codecs calls t
http://bugs.python.org/issue12171 opened by haypo
#12172: IDLE crashes when I use F5 to run
http://bugs.python.org/issue12172 opened by Kevin Ness
#12174: Multiprocessing logging levels unclear
http://bugs.python.org/issue12174 opened by JJeffries
#12175: FileIO.readall() read the file position and size at each read
http://bugs.python.org/issue12175 opened by haypo
#12177: re.match raises MemoryError
http://bugs.python.org/issue12177 opened by EungJun.Yi
#12178: csv writer doesn't escape escapechar
http://bugs.python.org/issue12178 opened by ebreck
#12179: Race condition using PyGILState_Ensure on a new thread
http://bugs.python.org/issue12179 opened by syeberman
#12181: SIGBUS error on OpenBSD (sparc64)
http://bugs.python.org/issue12181 opened by rpointel
#12183: Document behaviour of shutil.copy2 and copystat with symlinks
http://bugs.python.org/issue12183 opened by mmarkk
#12184: socketserver.ForkingMixin collect_children routine needs to co
http://bugs.python.org/issue12184 opened by orsenthil
#12186: readline.replace_history_item still leaks memory
http://bugs.python.org/issue12186 opened by stefanholek
#12187: subprocess.wait() with a timeout uses polling on POSIX
http://bugs.python.org/issue12187 opened by haypo
#12188: PEP 7, C style: add ++ policy and explanation
http://bugs.python.org/issue12188 opened by terry.reedy
#12190: intern filenames in bytecode
http://bugs.python.org/issue12190 opened by Mike.Solomon
#12191: Shutil - add chown() in order to allow to use user and group n
http://bugs.
Re: [Python-Dev] Deprecate codecs.open() and StreamWriter/StreamReader
Victor Stinner wrote: > Le vendredi 27 mai 2011 15:42:10, M.-A. Lemburg a écrit : >> If we'd go by your reasoning for deprecating and eventually >> removing parts of the stdlib or Python's subsystems, we'll end >> up with a barebone version of Python. That's not what we want >> and it's not what our users want. > > I don't want to deprecate the whole stdlib, just duplicate old API, to follow > "import this" mantra: > > "There should be one-- and preferably only one --obvious way to do it." What people tend to miss in this mantra is the last part: "obvious". It doesn't say: there should only be one way to do it. There can be many ways, but there should preferably be only one *obvious* way. Using codec.open() is not obvious in Python3, since the standard open() already provides a way to access an encoded stream. Using a builtin is the obvious way to go. It is obvious in Python2 where the standard open() doesn't provide a way to define an encoding, so the user has to explicitly look for this kind of API and then find it in the "obvious" (to some extent) codecs module, since that's where encodings happen in Python2. Having multiple ways to do things, is the most natural thing on earth and it's good that way. Python does not and should not force people into doing things in one dictated "right" way. It should, however, provide natural choices and obvious hints to find a good solution. And that's what the Zen mantra is all about. > It's difficult for an user to choose between between open() and codecs.open(). As I mentioned on the ticket and in my replies: I'm not against changing codecs.open() to use a variant that is based on TextIOWrapper, provided there are no user noticeable compatibility issues. Thanks for reverting the patch. Have a nice weekend, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 27 2011) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2011-05-23: Released eGenix mx Base 3.2.0 http://python.egenix.com/ 2011-05-25: Released mxODBC 3.1.1 http://python.egenix.com/ 2011-06-20: EuroPython 2011, Florence, Italy 24 days to go ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] [ANN] Python 2.5.6 released
On behalf of the Python development team and the Python community, I'm happy to announce the release of Python 2.5.6. There were no changes since the release candidate. This is a source-only release that only includes security fixes. The last full bug-fix release of Python 2.5 was Python 2.5.4. Users are encouraged to upgrade to the latest release of Python 2.7 (which is 2.7.1 at this point). This release is most likely the final release of Python 2.5; under the current release policy, no security issues in Python 2.5 will be fixed after October, 2011. This releases fixes issues with the urllib, urllib2, SimpleHTTPServer, and audiop modules. See the release notes at the website (also available as Misc/NEWS in the source distribution) for details of bugs fixed. For more information on Python 2.5.6, including download links for various platforms, release notes, and known issues, please see: http://www.python.org/2.5.6 Highlights of the previous major Python releases are available from the Python 2.5 page, at http://www.python.org/2.5/highlights.html Enjoy this release, Martin Martin v. Loewis [email protected] Python Release Manager (on behalf of the entire python-dev team) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecate codecs.open() and StreamWriter/StreamReader
On 5/27/2011 11:08 AM, Victor Stinner wrote: Tell me if I am wrong, but only Marc-Andre is against deprecating StreamReader While I am, in general, in favor of removing some duplication, I was and am against doing this change precipitously. So I was for the reversion (noted), at least temporarily. Given the disagreement, I think there should be a PEP with pro and con arguments. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecate codecs.open() and StreamWriter/StreamReader
On Sat, May 28, 2011 at 6:30 AM, Terry Reedy wrote: > On 5/27/2011 11:08 AM, Victor Stinner wrote: > >> Tell me if I am wrong, but only Marc-Andre is against deprecating >> StreamReader > > While I am, in general, in favor of removing some duplication, I was and am > against doing this change precipitously. So I was for the reversion (noted), > at least temporarily. Given the disagreement, I think there should be a PEP > with pro and con arguments. Indeed. I'm also against any deprecation in this area, since that just means needless work for anyone that *do* use these APIs (even if those people are few and far between). If we can refactor to remove the duplication of functionality, that's a *much* better solution. If we can carry optparse style argument parsing and 2.x style string formatting, we can carry a couple of legacy codec interface definitions. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
