Mailman 3 August 2014 - Python-Dev

Cleaning up surrogate escaped strings (was Bytes path related questions for Guido)
by Nick Coghlan Aug. 30, 2014

Aug. 30, 2014

On 26 Aug 2014 21:34, "MRAB" <python(a)mrabarnett.plus.com> wrote: > > On 2014-08-26 03:11, Stephen J. Turnbull wrote: >> >> Nick Coghlan writes: >> >> > "purge_surrogate_escapes" was the other term that occurred to me. >> >> "purge" suggests removal, not replacement. That may be useful too. >> >> neutralize_surrogate_escapes(s, remove=False, replacement='\uFFFD') >> > How about: > > replace_surrogate_escapes(s,… [View More]

5 9

Summary of Python tracker Issues
by Python tracker Aug. 29, 2014

Aug. 29, 2014

ACTIVITY SUMMARY (2014-08-22 - 2014-08-29) 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 4638 (+17) closed 29431 (+32) total 34069 (+49) Open issues with patches: 2193 Issues opened (41) ================== #17095: Modules/Setup *shared* support broken http://bugs.python.org/issue17095 reopened by haypo #22200: Remove distutils checks for Python … [View More]

1 0

Bytes path related questions for Guido
by Nick Coghlan Aug. 29, 2014

Aug. 29, 2014

At Guido's request, splitting out two specific questions from Serhiy's thread where I believe we could do with an explicit "yes or no" from him. 1. Should we accept patches adding support for the direct use of bytes paths in lower level filesystem manipulation APIs? (i.e. everything that isn't pathlib) This was Serhiy's original question (due to some open issues [1,2]). I think the answer is yes, as we already do in some cases, and the "pathlib doesn't support binary paths" design decision is … [View More]

8 17

Windows Unicode console support [Was: Bytes path support]
by Paul Moore Aug. 28, 2014

Aug. 28, 2014

On 24 August 2014 04:27, Nick Coghlan <ncoghlan(a)gmail.com> wrote: > One of those areas is the fact that we still use the old 8-bit APIs to > interact with the Windows console. Those are just as broken in a > multilingual world as the other Windows 8-bit APIs, so Drekin came up > with a project to expose the Windows console as a UTF-16-LE stream > that uses the 16-bit APIs instead: > https://pypi.python.org/pypi/win_unicode_console > > I personally hope we'll be … [View More]

2 3

Bytes path support
by Serhiy Storchaka Aug. 28, 2014

Aug. 28, 2014

Builting open(), io classes, os and os.path functions and some other functions in the stdlib support bytes paths as well as str paths. But many functions doesn't. There are requests about adding this support ([1], [2]) in some modules. It is easy (just call os.fsdecode() on argument) but I'm not sure it is worth to do. Pathlib doesn't support bytes path and it looks intentional. What is general policy about support of bytes path in the stdlib? [1] http://bugs.python.org/issue19997 [2] http://bugs.python.org/issue20797

26 107

pip enhancement
by Neal Becker Aug. 27, 2014

Aug. 27, 2014

On systems where os-level packaging is available (e.g., fedora linux), it is not unusual to want a newer python package installed than available from the vendor. pip install --user can be used for this. But then there is the danger that these pip installed packages are not maintained. At least, pip should have the ability to alert the user to potential updates, pip update could list which packages need updating, and offer to perform the update. I think this would go a long way to … [View More]

4 7

Fwd: Accepting PEP 440: Version Identification and Dependency Specification
by Nick Coghlan Aug. 26, 2014

Aug. 26, 2014

Antoine pointed out that it would still be a good idea to forward packaging PEP acceptance announcements to python-dev, even when the actual acceptance happens on distutils-sig. That makes sense to me, so here's last week's notice of the acceptance of PEP 440, the implementation independent versioning standard derived from pkg_resources, PEP 386, and ideas from both Linux distributions and other open source language communities. Regards, Nick. ---------- Forwarded message ---------- From: … [View More]

1 0

Summary of Python tracker Issues
by Python tracker Aug. 22, 2014

Aug. 22, 2014

ACTIVITY SUMMARY (2014-08-15 - 2014-08-22) 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 4621 (+19) closed 29399 (+28) total 34020 (+47) Open issues with patches: 2179 Issues opened (41) ================== #22207: Test for integer overflow on Py_ssize_t: explicitly cast to si http://bugs.python.org/issue22207 opened by haypo #22208: tarfile can'… [View More]

1 0

PEP 4000 to explicitly declare we won't be doing a Py3k style compatibility break again?
by Nick Coghlan Aug. 21, 2014

Aug. 21, 2014

I've seen a few people on python-ideas express the assumption that there will be another Py3k style compatibility break for Python 4.0. I've also had people express the concern that "you broke compatibility in a major way once, how do we know you won't do it again?". Both of those contrast strongly with Guido's stated position that he never wants to go through a transition like the 2->3 one again. Barry wrote PEP 404 to make it completely explicit that python-dev had no plans to create a … [View More]

12 19

Fwd: PEP 467: Minor API improvements for bytes & bytearray
by Ian Cordasco Aug. 19, 2014

Aug. 19, 2014

On Aug 17, 2014 12:17 PM, "Donald Stufft" <donald(a)stufft.io> wrote: >> On Aug 17, 2014, at 1:07 PM, Raymond Hettinger <raymond.hettinger(a)gmail.com> wrote: >> >> >> On Aug 17, 2014, at 1:41 AM, Nick Coghlan <ncoghlan(a)gmail.com> wrote: >> >>> If I see "bytearray(10)" there is nothing there that suggests "this >>> creates an array of length 10 and initialises it to zero" to me. I'd >>> be more inclined to guess it … [View More]would be equivalent to "bytearray([10])". >>> >>> "bytearray.zeros(10)", on the other hand, is relatively clear, >>> independently of user expectations. >> >> >> Zeros would have been great but that should have been done originally. >> The time to get API design right is at inception. >> Now, you're just breaking code and invalidating any published examples. >> >>>> >>>> Another thought is that the core devs should be very reluctant to deprecate >>>> anything we don't have to while the 2 to 3 transition is still in progress. >>>> Every new deprecation of APIs that existed in Python 2.7 just adds another >>>> obstacle to converting code. Individually, the differences are trivial. >>>> Collectively, they present a good reason to never migrate code to Python 3. >>> >>> >>> This is actually one of the inconsistencies between the Python 2 and 3 >>> binary APIs: >> >> >> However, bytearray(n) is the same in both Python 2 and Python 3. >> Changing it in Python 3 increases the gulf between the two. >> >> The further we let Python 3 diverge from Python 2, the less likely that >> people will convert their code and the harder you make it to write code >> that runs under both. >> >> FWIW, I've been teaching Python full time for three years. I cover the >> use of bytearray(n) in my classes and not a single person out of 3000+ >> engineers have had a problem with it. I seriously question the PEP's >> assertion that there is a real problem to be solved (i.e. that people >> are baffled by bytearray(bufsiz)) and that the problem is sufficiently >> painful to warrant the headaches that go along with API changes. >> >> The other proposal to add bytearray.byte(3) should probably be named >> bytearray.from_byte(3) for clarity. That said, I question whether there is >> actually a use case for this. I have never seen seen code that has a >> need to create a byte array of length one from a single integer. >> For the most part, the API will be easiest to learn if it matches what >> we do for lists and for array.array. >> >> Sorry Nick, but I think you're making the API worse instead of better. >> This API isn't perfect but it isn't flat-out broken either. There is some >> unfortunate asymmetry between bytes() and bytearray() in Python 2, >> but that ship has sailed. The current API for Python 3 is pretty good >> (though there is still a tension between wanting to be like lists and like >> strings both at the same time). >> >> >> Raymond >> >> >> P.S. The most important problem in the Python world now is getting >> Python 2 users to adopt Python 3. The core devs need to develop >> a strong distaste for anything that makes that problem harder. >> > > For the record I’ve had all of the problems that Nick states and I’m > +1 on this change. I've run into these problems as well, but I'm swayed by Raymond's argument regarding bytearray's constructor. I wouldn't be adverse to adding zeroes (for some parity between bytes and bytearray) to that but I'm not sure deprecating te behaviour of bytearray's constructor is necessary. (Whilst on my phone I only replied to Donald, so I'm forwarding this to the list.) [View Less]

10 18