Please don't get rid of unicode+literals -- I don't even think we should
depreciate it as a recommendation or discourage it.
Maybe a note or two added as to where issues may arise would be good.
I've found importing unicode_literals to be an excellent way to write py2/3
code. And I have never fou
On 2016-12-16, 23:59 GMT, Guido van Rossum wrote:
> No need to get all bent out of shape. My proposal is to simply
> add a note to the docs recommending against using this.
> I wouldn't change any code, not even a silent deprecation
> warning. (Also, read the rest of the thread to learn why thi
On Mon, 19 Dec 2016 at 06:29 Terry Reedy wrote:
> On 12/19/2016 12:26 AM, Larry Hastings wrote:
> >
> >
> > Python 3.6.0 final just slipped by two weeks. I scheduled 3.5.3 and
> > 3.4.6 to ship about a month after 3.6.0 did, to "let the dust settle"
> > around the release. I expect a flood of a
On 12/19/2016 12:26 AM, Larry Hastings wrote:
Python 3.6.0 final just slipped by two weeks. I scheduled 3.5.3 and
3.4.6 to ship about a month after 3.6.0 did, to "let the dust settle"
around the release. I expect a flood of adoption of 3.6, and people
switching will find bugs, and maybe those
2016-12-16 11:24 GMT+01:00 Antoine Pitrou :
> Since you are cleaning up, you could remove the whole "PROPOSAL: A
> Generic Python Object Interface for Python C Modules" introduction,
> which isn't very interesting to read today.
Done: hg.python.org/cpython/rev/3ab0a6692e25
Victor
2016-12-18 9:31 GMT+01:00 Serhiy Storchaka :
> Originally C API didn't use the const qualifier. Over few last years the
> const qualifier was added to C API if that preserved backward compatibility.
> For example input "char *" parameters were changed to "const char *". This
> makes C API compatibl
> On Dec 18, 2016, at 9:26 PM, Larry Hastings wrote:
>
> So, if you have an opinion, please vote for one of these three options:
> • Don't slip 3.5.3. and 3.4.6.
> • Slip 3.5.3 and 3.4.6 by two weeks to match 3.6.0.
> • Slip 3.5.3 and 3.4.6 by a whole month, to give 3.6.0 the a
