[issue20087] Mismatch between glibc and X11 locale.alias

Benjamin Peterson added the comment: I'm still confused about what getlocale() is supposed to do. Why do we attempt to return an encoding anyway if the underlying setlocale call doesn't return one? Is getlocale() not supposed to a simple wrapper over the C locale? If not, how is one supposed

[issue29770] Executable help output (--help) at commandline is wrong for option -B

Changes by Xiang Zhang : -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker ___

[issue29770] Executable help output (--help) at commandline is wrong for option -B

Changes by Xiang Zhang : -- pull_requests: +506 ___ Python tracker ___ ___ Python-bugs-list

[issue29770] Executable help output (--help) at commandline is wrong for option -B

Changes by Xiang Zhang : -- pull_requests: +505 ___ Python tracker ___ ___ Python-bugs-list

[issue21109] tarfile: Traversal attack vulnerability

Martin Panter added the comment: Issue 29788 proposes an option to disable the vulnerability in the CLI -- dependencies: +tarfile: Add absolute_path option to tarfile, disabled by default ___ Python tracker

[issue29788] tarfile: Add absolute_path option to tarfile, disabled by default

Martin Panter added the comment: The CLI was added in Issue 13477. I didn’t see any discussion of traversal attacks there, so maybe it was overlooked. Perhaps there should also be a warning, like with the Tarfile.extract and “extractall” methods. However I did see one of the goals was to keep

[issue29688] Document Path.absolute

Eryk Sun added the comment: resolve() can't replace absolute(). They serve different purposes. Sometimes one wants an absolute path, but without resolving symbolic links. absolute() processes a path as a string, which will continue to be true if it's updated to call nt._getfullpathname

[issue28685] Optimizing list.sort() by performing safety checks in advance

Elliot Gorokhovsky added the comment: Actually, I just ran this in the patched interpreter, and it worked! It printed: zebra gizmo zebra gizmo zebra gizmo zebra gizmo zebra gizmo zebra gizmo zebra gizmo Inspired by the above result, I ran your counterexample (below) to see if it would work as

[issue28685] Optimizing list.sort() by performing safety checks in advance

ppperry added the comment: And what about even wackier code like this? class A(int): def __lt__(self, other): print("zebra") A.__lt__ = A.__false_lt__ return int.__lt__(self, other) __true_lt__ = __lt__ def

[issue29784] Erroneous link in shutil.copy description

Mariatta Wijaya added the comment: Thanks all :) I fixed the two references to copy() in shutil docs, and backported to 3.5 and 3.6. Since this particular issue is fixed, I'm closing this. If people find other incorrect references, they can open another ticket. -- resolution: ->

[issue28685] Optimizing list.sort() by performing safety checks in advance

Elliot Gorokhovsky added the comment: Yup, I was completely wrong. If your classes were defined in pure-Python, this would raise an exception (since the pure-Python operators/functions check for bad types, correct me if I'm wrong). However, if you defined your compares at the C API level, you

[issue29746] Update marshal docs to Python 3

Martin Panter added the comment: One other difference between 2 and 3 is that Python 3 has two kinds of “binary” files. In most cases, a subset of the BufferedIOBase API is assumed, which does “exact” reads and writes. I understand this is how Python 2 files worked. But there is also

[issue29777] argparse arguments in main parser hide an argument in subparser

paul j3 added the comment: allow_abbrev as added with http://bugs.python.org/issue14910 I contributed to the patch, but my memory isn't fresh. The fact that this works across the subparser boundary is, in a sense, accidental. We didn't think about how abbreviations are handled across this

[issue29784] Erroneous link in shutil.copy description

Changes by Mariatta Wijaya : -- pull_requests: +504 ___ Python tracker ___ ___

[issue29784] Erroneous link in shutil.copy description

Changes by Mariatta Wijaya : -- pull_requests: +503 ___ Python tracker ___ ___

[issue29777] argparse arguments in main parser hide an argument in subparser

Changes by paul j3 : -- nosy: +paul.j3 ___ Python tracker ___ ___ Python-bugs-list

[issue28685] Optimizing list.sort() by performing safety checks in advance

ppperry added the comment: > > Elliot Gorokhovsky added the comment: > > Your code changes __class__, not type, which would remain equal to > "instance". (my understanding, could be wrong). The docs say the > following: > Nope: class A:pass class B:pass a = A() a.__class__ = B

[issue29785] Registration link sent via email by the tracker is http

Maxime Buquet added the comment: On 11 March 2017 00:30:48 GMT+00:00, Ezio Melotti wrote: > >Ezio Melotti added the comment: > >Could you report this to http://psf.upfronthosting.co.za/roundup/meta/ >? No problem! Sorry for the noise --

[issue29783] Modify codecs.open() to use the io module instead of codecs.StreamReaderWriter()

Martin Panter added the comment: I agree that it would be better to hold off deprecating codecs.open until Python 2 is no longer supported. This deprecation also discussed in Issue 8796. There is more to compatability than the missing attributes. The most obvious one to me is that the

[issue28685] Optimizing list.sort() by performing safety checks in advance

Elliot Gorokhovsky added the comment: Your code changes __class__, not type, which would remain equal to "instance". (my understanding, could be wrong). The docs say the following: https://docs.python.org/3.7/reference/datamodel.html > Like its identity, an object’s type is also unchangeable.

[issue29785] Registration link sent via email by the tracker is http

Ezio Melotti added the comment: Could you report this to http://psf.upfronthosting.co.za/roundup/meta/ ? -- assignee: -> ezio.melotti nosy: +ezio.melotti resolution: -> third party stage: -> resolved status: open -> closed ___ Python tracker

[issue29790] Optional use of /dev/random on linux

Ivan Anishchuk added the comment: Victor, I suppose you don't happen to have a good entropy source? :) I cannot really stress the word "optional" enough here. And I understand why most user wouldn't want this. That's why I'm proposing to make it optional. As per PEP, "The /dev/random device

[issue23894] lib2to3 doesn't recognize rb'...' and f'...' in Python 3.6

Łukasz Langa added the comment: Alright, we'll merge this for 3.6.2 then! -- ___ Python tracker ___ ___

[issue28685] Optimizing list.sort() by performing safety checks in advance

ppperry added the comment: Does this work with wacky code like this? @functools.total_ordering class ClassAssignmentCanBreakChecks(): def __init__(self, i): self._i = i def __lt__ (self, other):

[issue29478] email.policy.Compat32(max_line_length=None) not as documented

R. David Murray added the comment: OK. This looks good to me. I haven't figured out the new commit process, though (like how to do misc news and backports), so I'm not going to be the one to merge it, I'm afraid. At least not until I do find time to learn. --

[issue29790] Optional use of /dev/random on linux

STINNER Victor added the comment: I'm opposed to use blocking /dev/random instead of /dev/urandom: see PEP 524 for the rationale. -- ___ Python tracker

[issue28810] Document bytecode changes in 3.6

Brett Cannon added the comment: I have merged all the PRs that Ivan had open. I'll leave the issue open since Ivan said he had another PR he wanted to create. -- ___ Python tracker

[issue29741] BytesIO methods don't accept integer types, while StringIO counterparts do

Oren Milman added the comment: or maybe git is smart enough to realize what happened, and I don't have to update PR 560? -- ___ Python tracker ___

[issue29760] tarfile chokes on reading .tar file with no entries (but does fine if the same file is bzip2'ed)

Matt Bogosian added the comment: After some consideration, I think this is probably more correct: ``` --- /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/tarfile.py 2016-12-17 12:41:21.0 -0800 +++ tarfile.py 2017-03-10 14:57:15.0 -0800 @@ -2347,9 +2347,10 @@

[issue29760] tarfile chokes on reading .tar file with no entries (but does fine if the same file is bzip2'ed)

Changes by Matt Bogosian : Removed file: http://bugs.python.org/file46717/tarfile.patch ___ Python tracker ___

[issue28810] Document bytecode changes in 3.6

Changes by Brett Cannon : -- pull_requests: +502 ___ Python tracker ___ ___

[issue29741] BytesIO methods don't accept integer types, while StringIO counterparts do

Oren Milman added the comment: thanks :) I would update the original PR soon. -- ___ Python tracker ___ ___

[issue29790] Optional use of /dev/random on linux

Changes by Steven D'Aprano : -- nosy: +haypo, ncoghlan, steven.daprano ___ Python tracker ___

[issue23894] lib2to3 doesn't recognize rb'...' and f'...' in Python 3.6

Ned Deily added the comment: Sorry, the announced deadline for bugfixes for 3.6.1 has already passed; at this point, only showstopper problems with 3.6.1rc1 are on the table for the final. Trivial impact isn't a criterion for post-rc1 changes and there's a good reason for that: we ask

[issue29741] BytesIO methods don't accept integer types, while StringIO counterparts do

Oren Milman added the comment: done -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue29741] BytesIO methods don't accept integer types, while StringIO counterparts do

Changes by Oren Milman : -- pull_requests: +501 ___ Python tracker ___ ___ Python-bugs-list

[issue28810] Document bytecode changes in 3.6

Changes by Brett Cannon : -- pull_requests: +500 ___ Python tracker ___ ___

[issue29688] Document Path.absolute

Brett Cannon added the comment: I'm still thinking about this but I'm still leaning towards deprecating pathlib.absolute(). -- ___ Python tracker ___

[issue23407] os.walk always follows Windows junctions

Changes by Craig Holmquist : Added file: http://bugs.python.org/file46718/issue23407-5.patch ___ Python tracker ___

[issue29778] _Py_CheckPython3 uses uninitialized dllpath when embedder sets module path with Py_SetPath

Changes by Steve Dower : -- stage: -> needs patch type: -> behavior versions: +Python 3.6, Python 3.7 ___ Python tracker ___

[issue29778] _Py_CheckPython3 uses uninitialized dllpath when embedder sets module path with Py_SetPath

Steve Dower added the comment: Ah, I see. We force load it in PC/getpathp.c to ensure that it's ours and not another version's python3.dll. We should probably refactor the GetModuleFileNameW call into its own function so we can call it from anywhere we need. --

[issue29746] Update marshal docs to Python 3

Changes by Serhiy Storchaka : -- nosy: +Mariatta, martin.panter, r.david.murray ___ Python tracker ___

[issue29788] tarfile: Add absolute_path option to tarfile, disabled by default

Changes by Ned Deily : -- nosy: +lars.gustaebel ___ Python tracker ___ ___ Python-bugs-list

[issue24755] asyncio.wrap_future undocumented

Changes by Martin Panter : -- components: +asyncio stage: -> patch review versions: +Python 3.6, Python 3.7 ___ Python tracker ___

[issue29786] asyncio.wrap_future() is not documented

Changes by Martin Panter : -- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> asyncio.wrap_future undocumented ___ Python tracker

[issue29791] print documentation: flush is also a keyword argument

New submission from Lucio Ricardo Montero Valenzuela: In the print() function documentation (https://docs.python.org/3/library/functions.html#print), the first line says "Print objects to the text stream file, separated by sep and followed by end. sep, end and file, if present, must be given

[issue29790] Optional use of /dev/random on linux

New submission from Ivan Anishchuk: Right now secrets module uses SystemRandom which is hardcoded to use os.urandom() which is fine for most users but some have good hardware sources of entropy (or otherwise replenish entropy pool) in which case it would be much better to use getrandom() with

[issue29760] tarfile chokes on reading .tar file with no entries (but does fine if the same file is bzip2'ed)

Matt Bogosian added the comment: This patch (also attached) seems to address this particular use case: ``` --- a/Lib/tarfile.py2016-12-17 12:41:21.0 -0800 +++ b/Lib/tarfile.py2017-03-10 12:23:34.0 -0800 @@ -2347,7 +2347,7 @@ # Advance the file pointer.

[issue29722] heapq.merge docs are misleading with the "reversed" flag

Changes by Terry J. Reedy : -- versions: -Python 3.3, Python 3.4 ___ Python tracker ___

[issue29760] tarfile chokes on reading .tar file with no entries (but does fine if the same file is bzip2'ed)

Matt Bogosian added the comment: I'm not sure if it helps at this point, but I've tried several "flavors" of apparently legit tar files with zero entries. All fail. ``tarfile`` module: ``` $ ( set -x ; cd /tmp || exit 1 ; python -V ; rm -fv test.tar ; python -c 'import os, tarfile ; fd =

[issue29782] Use __builtin_clzl for bits_in_digit if available

Niklas Fiekas added the comment: Oops. Actually clz should commonly be enough. And platforms where clz and clzl are different (<=> unsigned int and unsigned long are different) should be rare. -- ___ Python tracker

[issue29782] Use __builtin_clzl for bits_in_digit if available

Niklas Fiekas added the comment: Thanks for the review. I pushed a change to check if clz can be used (`sizeof(digit) <= sizeof(unsigned int)`). Otherwise use clzl. I believe the latter should be the most common, since unsigned long has 32bits. As you say unsigned long long should never be

[issue29765] 2.7.12 compile error from ssl related

Christian Heimes added the comment: You have some custom, unsupported version of OpenSSL installed in /usr/local. That custom version is not compatible with Python 2.7.12. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___

[issue29782] Use __builtin_clzl for bits_in_digit if available

Mark Dickinson added the comment: True enough. It looks as though someone (*cough*) already documented that restriction, too: https://github.com/mdickinson/cpython/blob/v3.6.0/Include/longintrepr.h#L28-L30 -- ___ Python tracker

[issue27200] make doctest in CPython has failures

Changes by Marco Buttu : -- pull_requests: +499 ___ Python tracker ___ ___

[issue29786] asyncio.wrap_future() is not documented

Adam Höse added the comment: While fixing this issue I found that it's a duplicate of issue 24755. -- nosy: +adisbladis pull_requests: +498 type: -> enhancement ___ Python tracker

[issue24755] asyncio.wrap_future undocumented

Changes by Adam Höse : -- pull_requests: +497 ___ Python tracker ___ ___

[issue29779] New environment variable PYTHONHISTORY

Barry A. Warsaw added the comment: I don't think the Python envar has to follow the contraction from bash. $PYTHONHISTORY reads very nicely. I have similar code in my $PYTHONSTARTUP, but it would be nice to be able to get rid of it and just let Python do the common thing. --

[issue29779] New environment variable PYTHONHISTORY

Changes by Barry A. Warsaw : -- nosy: +barry ___ Python tracker ___ ___ Python-bugs-list

[issue29782] Use __builtin_clzl for bits_in_digit if available

Serhiy Storchaka added the comment: I think we can assume that digit is no larger than unsigned long, otherwise PyLong_AsLong() and like wouldn't work. -- nosy: +serhiy.storchaka ___ Python tracker

[issue29782] Use __builtin_clzl for bits_in_digit if available

Mark Dickinson added the comment: Thanks for the idea, and the PR! To be useful, this would need a bit of tweaking: we can't assume that a digit is always `unsigned long` (in fact, I'd expect that to be rare on 64-bit non-Windows systems, where `unsigned long` typically has 64 bits, and

[issue29258] __init__.py required for pkgutil.walk_packages in python3

Changes by Brett Cannon : -- nosy: -brett.cannon ___ Python tracker ___ ___

[issue29758] Previously-working SWIG code fails in Python 3.6

Brett Cannon added the comment: Please keep this issue closed until you hear back from the SWIG team. Just because your code worked under Python 3.5 doesn't mean SWIG didn't accidentally emit something that breaks under Python 3.6 because we started being more stringent about something.

[issue28739] PEP 498: docstrings as f-strings

Changes by Mariatta Wijaya : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue28739] PEP 498: docstrings as f-strings

Eric V. Smith added the comment: Yes, I think it can be closed. Thanks! -- ___ Python tracker ___ ___

[issue28739] PEP 498: docstrings as f-strings

Mariatta Wijaya added the comment: Thanks for reviewing, Serhiy and Eric. Documentation has been updated and backported to 3.6. OK to close this issue? -- ___ Python tracker

[issue29784] Erroneous link in shutil.copy description

Serhiy Storchaka added the comment: See also issue21818. I suspect there are other incorrect references. -- nosy: +serhiy.storchaka ___ Python tracker

[issue29780] Interpreter hang on self._epoll.poll(timeout, max_ev)

Changes by Guido van Rossum : -- nosy: -gvanrossum ___ Python tracker ___ ___

[issue29784] Erroneous link in shutil.copy description

Xiang Zhang added the comment: Assigned to Mariatta :-). -- assignee: docs@python -> Mariatta nosy: +Mariatta ___ Python tracker ___

[issue28685] Optimizing list.sort() by performing safety checks in advance

Elliot Gorokhovsky added the comment: On Fri, Mar 10, 2017 at 12:26 AM Serhiy Storchaka wrote: > > Serhiy Storchaka added the comment: > > The issue shouldn't be closed until it resolved or rejected. > Ya, sorry about that. This is my first time contributing. > > I

[issue29784] Erroneous link in shutil.copy description

Changes by Mariatta Wijaya : -- pull_requests: +496 ___ Python tracker ___ ___

[issue29784] Erroneous link in shutil.copy description

Xiang Zhang added the comment: Thanks for your report, Maxime! I open PRs to fix it. -- nosy: +xiang.zhang versions: +Python 3.5, Python 3.6, Python 3.7 ___ Python tracker

[issue29784] Erroneous link in shutil.copy description

Changes by Xiang Zhang : -- pull_requests: +495 ___ Python tracker ___ ___ Python-bugs-list

[issue17062] An os.walk inspired replacement for pkgutil.walk_packages

Changes by Mark Lawrence : -- nosy: -BreamoreBoy ___ Python tracker ___ ___

[issue28739] PEP 498: docstrings as f-strings

Changes by Mariatta Wijaya : -- pull_requests: +494 ___ Python tracker ___ ___

[issue29789] zipfile: Add absolute_path option, disabled by default

STINNER Victor added the comment: Oh, it seems like zipfile is not affected by the issue, only tarfile. The documentation is correct: https://docs.python.org/dev/library/zipfile.html#zipfile.ZipFile.extract You can test using attached test2.zip. haypo@selma$ python3 -m zipfile -l ~/test2.zip

[issue29789] zipfile: Add absolute_path option, disabled by default

Serhiy Storchaka added the comment: Is this issue exists on zipfile? -- nosy: +serhiy.storchaka ___ Python tracker ___

[issue29783] Modify codecs.open() to use the io module instead of codecs.StreamReaderWriter()

Serhiy Storchaka added the comment: I think using codecs.open() with a non-text codecs is a legit use case, but is not the best way. I suggest: 1) Encourage of using io.open() rather than codecs.open() for text encodings. codecs.open() was recommended way since it worked in all Python

[issue29789] zipfile: Add absolute_path option, disabled by default

New submission from STINNER Victor: Same issue than tarfile issue #29788, but on zipfile. I suggest to add a boolean absolute_path option to zipfile, disabled by default. -- components: Library (Lib) messages: 289389 nosy: haypo priority: normal severity: normal status: open title:

[issue29788] Add absolute_path option to tarfile, disabled by default

New submission from STINNER Victor: I noticed that "python3 -m tarfile -x archive.tar" uses absolute paths by default, whereas the UNIX tar command doesn't by default. The UNIX tar command requires to add explicitly --absolute-paths (-P) option. I suggest to add a boolean absolute_path option

[issue29788] tarfile: Add absolute_path option to tarfile, disabled by default

Changes by STINNER Victor : -- components: +Library (Lib) title: Add absolute_path option to tarfile, disabled by default -> tarfile: Add absolute_path option to tarfile, disabled by default ___ Python tracker

[issue29478] email.policy.Compat32(max_line_length=None) not as documented

Mircea Cosbuc added the comment: Just to be sure, I performed the same operations with my changes in place, there's no change in behaviour. I think it's expected since I only modified how the Compat32 policy passes `max_line_length` to the header class. --

[issue20087] Mismatch between glibc and X11 locale.alias

Serhiy Storchaka added the comment: I'm feeling there is something wrong with the current locale design. See issues issue504219, issue10466, issue20088, issue25191, issue29571. -- ___ Python tracker

[issue29478] email.policy.Compat32(max_line_length=None) not as documented

R. David Murray added the comment: So what happens when you do that same operation in 3.5/6 with your change in place? Does the behavior change? (I haven't looked back at the code to see if I think it will :) -- ___ Python tracker

[issue29723] 3.6.1rc1 adds the current directory to sys.path when running a subdirectory's __main__.py; previous versions did not

Nick Coghlan added the comment: Paul Moore reporting on trying out the new PR in http://bugs.python.org/issue29319#msg289357 and confirmed that it still solves the originally reported problem in issue 29319. -- ___ Python tracker

[issue29786] asyncio.wrap_future() is not documented

Changes by Guido van Rossum : -- nosy: -gvanrossum ___ Python tracker ___ ___

[issue29478] email.policy.Compat32(max_line_length=None) not as documented

Mircea Cosbuc added the comment: Thanks for the prompt feedback. In Python 3.2, the closest equivalent for the illustrated issue I could find is: >>> from email.message import Message >>> from email.generator import Generator >>> from sys import stdout >>> m = Message() >>> m["Field"] = "x" *

[issue16258] test_local.TestEnUSCollection failures on Solaris 10

Serhiy Storchaka added the comment: May be issue15954 is related to this issue. Is this issue still reproduced? -- nosy: +serhiy.storchaka ___ Python tracker

[issue29787] Internal importlib frames visible when module imported by import_module throws exception

New submission from Ulrich Petri: Importing a module that raises an exception on import trough `importlib.import_module()` causes importlib to not strip it's internal frames from the traceback. Minimal example: --a.py-- import importlib importlib.import_module("b") --a.py-- --b.py--

[issue29783] Modify codecs.open() to use the io module instead of codecs.StreamReaderWriter()

STINNER Victor added the comment: About the issue #12508, would it be possible to modify StreamReader to use an incremental decoder? Or my idea doesn't make sense? -- ___ Python tracker

[issue29783] Modify codecs.open() to use the io module instead of codecs.StreamReaderWriter()

STINNER Victor added the comment: Serhiy Storchaka added the comment: > I agree that it is better to use directly the module implementing the codecs. > But old third-party code still can use non-text codecs. > > There should be good reasons for breaking backward compatibility. Wouldn't be >

[issue29783] Modify codecs.open() to use the io module instead of codecs.StreamReaderWriter()

STINNER Victor added the comment: > The reason for the problem is the UTF-8 decoder (and other > decoders) expecting an extension to the codec decoder API, > which are not implemented in its StreamReader class (it simply > uses the base class). It's not a problem of the base class, but > that of

[issue20087] Mismatch between glibc and X11 locale.alias

Marc-Andre Lemburg added the comment: On 10.03.2017 08:37, Benjamin Peterson wrote: > > Do you believe this program should work? > > import locale, os > for l in open("/usr/share/i18n/SUPPORTED"): > alias, encoding = l.strip().split() > locale.setlocale(locale.LC_ALL, alias) > try:

[issue29786] asyncio.wrap_future() is not documented

New submission from STINNER Victor: The following asyncio function is not documented. Is it deliberate? The function is exported in the asyncio module. def wrap_future(future, *, loop=None): """Wrap concurrent.futures.Future object.""" -- assignee: docs@python components:

[issue29783] Modify codecs.open() to use the io module instead of codecs.StreamReaderWriter()

Serhiy Storchaka added the comment: I agree that it is better to use directly the module implementing the codecs. But old third-party code still can use non-text codecs. There should be good reasons for breaking backward compatibility. Wouldn't be better to deprecate codecs.open()?

[issue29783] Modify codecs.open() to use the io module instead of codecs.StreamReaderWriter()

Marc-Andre Lemburg added the comment: On 10.03.2017 15:17, STINNER Victor wrote: > > The codecs.StreamReaderWriter() class still has old unfixed issues like the > issue #12508 (open since 2011). This issue is even seen as a security > vulnerability by the owasp-pysec project: >

[issue29783] Modify codecs.open() to use the io module instead of codecs.StreamReaderWriter()

STINNER Victor added the comment: > codecs.open() works with bytes-to-bytes codecs. Oh ok. What are non-text encodings? I found: * base64 * bz2 * hex * quopri * rot13 * uu * zlib It seems like all these codecs can be used with codecs.open() to write bytes strings, except of rot13. Last time

[issue29785] Registration link sent via email by the tracker is http

New submission from Maxime Buquet: The link[1] sent via email by the tracker for registration confirmation is http, whereas https is already setup on the tracker itself. Would it be possible to change it to https. [1] http://bugs.python.org/?@action=confrego=TOKEN -- components:

[issue29783] Modify codecs.open() to use the io module instead of codecs.StreamReaderWriter()

Changes by STINNER Victor : -- pull_requests: +492 ___ Python tracker ___ ___

[issue29783] Modify codecs.open() to use the io module instead of codecs.StreamReaderWriter()

Changes by STINNER Victor : -- pull_requests: +493 ___ Python tracker ___ ___

  1   2   >