Ned Deily:
> Alas, in the last few days at least one outstanding issue that we had hoped
> would not be a real-world problem has proven to be a showstopper during
> third-party package testing and I have been persuaded that we do need to fix
> it before 3.6.0 final. I take responsibility and
Hello, this week-end is the last two days for the Call For Proposals of
PythonFOSDEM 2017. We have received a lot of topics, but if you want to
become a speaker and that you have a very cool topic to submit, please
don't hesite and send us your proposal.
Deadline is 2016-12-18.
Stephane
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.
Ah right, I noticed this huge comment but I
[sending this independently to python-dev and core-workflow]
I have promised Ned that we will not migrate before 3.6.0 is released and
not for a week following in case an emergency 3.6.1 is necessary. I also
promised Larry we wouldn't migrate the week before 3.5.3 is released. That
means the
On 17 December 2016 at 08:24, Guido van Rossum wrote:
> I am beginning to think that `from __future__ import unicode_literals` does
> more harm than good. I don't recall exactly why we introduced it, but with
> the restoration of u"" literals in Python 3.3 we have a much better
I am beginning to think that `from __future__ import unicode_literals` does
more harm than good. I don't recall exactly why we introduced it, but with
the restoration of u"" literals in Python 3.3 we have a much better story
for writing straddling code that is unicode-correct.
The problem is that
Many eons ago, Jim created abstract.h. The proposal comment (which you're
right to be cutting out now) was his and at some point it was accepted, but
I just copied-pasted the whole text into abstract.h. So yes, please keep
the "many thanks to Jim Fulton" in there!
On Fri, Dec 16, 2016 at 7:03 AM,
ACTIVITY SUMMARY (2016-12-09 - 2016-12-16)
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:
open5639 (+18)
closed 35107 (+50)
total 40746 (+68)
Open issues
On Dec 16, 2016, at 01:07 PM, Ethan Furman wrote:
>On 12/16/2016 11:24 AM, Guido van Rossum wrote:
>
>> I am beginning to think that `from __future__ import unicode_literals` does
>> more harm than good. I don't recall exactly why we introduced it, but with
>> the restoration of u"" literals in
I personally used it when I was forced to use python 2 and working
mainly with unicode processing (It is particularly handy when working
with json for example)
Le 16/12/2016 à 20:24, Guido van Rossum a écrit :
> I am beginning to think that `from __future__ import unicode_literals`
> does more
On 12/16/2016 11:24 AM, Guido van Rossum wrote:
I am beginning to think that `from __future__ import unicode_literals` does
more harm than good. I don't recall exactly why we introduced it, but with
the restoration of u"" literals in Python 3.3 we have a much better story
for writing
On Sat, Dec 17, 2016 at 8:07 AM, Ethan Furman wrote:
> On 12/16/2016 11:24 AM, Guido van Rossum wrote:
>
>> I am beginning to think that `from __future__ import unicode_literals`
>> does
>> more harm than good. I don't recall exactly why we introduced it, but
>> with
>> the
> On 16 Dec 2016, at 16:07, Ethan Furman wrote:
>
> On 12/16/2016 11:24 AM, Guido van Rossum wrote:
>
>> I am beginning to think that `from __future__ import unicode_literals` does
>> more harm than good. I don't recall exactly why we introduced it, but with
>> the
On Fri, Dec 16, 2016 at 3:52 PM, Matěj Cepl wrote:
> I don’t understand.
>
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
> On Dec 16, 2016, at 11:24 AM, Guido van Rossum wrote:
>
> I am beginning to think that `from __future__ import unicode_literals` does
> more harm than good. I don't recall exactly why we introduced it, but with
> the restoration of u"" literals in Python 3.3 we have a much
On 2016-12-16, 19:24 GMT, Guido van Rossum wrote:
> I am beginning to think that `from __future__ import unicode_literals` does
> more harm than good. I don't recall exactly why we introduced it, but with
> the restoration of u"" literals in Python 3.3 we have a much better story
> for writing
I've actually found unicode_literals useful in getting code to be Python
2/3-compatible. I try to use a Python 3-like model of always using unicode
for text data and only using str for binary data, and unicode_literals
helps achieve that, since most string literals are meant to be text, not
binary
On Thu, 15 Dec 2016 11:22:10 +0100
Victor Stinner wrote:
>
> Before:
> https://hg.python.org/cpython/file/f692dafe6797/Include/abstract.h
>
> Now:
> https://hg.python.org/cpython/file/c4bcca326c0a/Include/abstract.h
Since you are cleaning up, you could remove the
On behalf of the Python development community and the Python 3.6 release
team, I would like to announce the availability of Python 3.6.0rc2. 3.6.0rc2
is the second release candidate for Python 3.6, the next major release of
Python.
Code for 3.6.0 is now frozen. 3.6.0rc2 is the same code base as
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/16/2016 04:27 PM, Barry Warsaw wrote:
> Getting rid of cruft like this is one of the more satisfying edits
> when dropping Python 2 support. :)
Ripping it out and replacing with explicit unicode literals is pretty
satisfying when straddling,
20 matches
Mail list logo