On Mon, Dec 19, 2016 at 11:50 PM, Chris Barker
wrote:
> 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
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
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
I have updated the porting HOWTO to drop recommending unicode_literals and
also to mention running optional type checkers like mypy and pytype twice
(once under Python 2 and again under Python 3).
On Fri, 16 Dec 2016 at 11:25 Guido van Rossum wrote:
> I am beginning to think
On 17 December 2016 at 21:58, Serhiy Storchaka wrote:
> On 17.12.16 13:44, Christian Heimes wrote:
>
>> On 2016-12-17 10:06, Serhiy Storchaka wrote:
>>
>>> On 16.12.16 21:24, Guido van Rossum wrote:
>>>
e.g. the argument to getattr() -- I still hear of code that breaks
On 17.12.16 13:44, Christian Heimes wrote:
On 2016-12-17 10:06, Serhiy Storchaka wrote:
On 16.12.16 21:24, Guido van Rossum wrote:
e.g. the argument to getattr() -- I still hear of code that breaks due
to this occasionally)
What is the problem with unicode in getattr()? Unicode attribute
On 2016-12-17 10:06, Serhiy Storchaka wrote:
> On 16.12.16 21:24, Guido van Rossum wrote:
>> e.g. the argument to getattr() -- I still hear of code that breaks due
>> to this occasionally)
>
> What is the problem with unicode in getattr()? Unicode attribute name is
> converted to str, and since
On 16.12.16 21:24, Guido van Rossum wrote:
e.g. the argument to getattr() -- I still hear of code that breaks due
to this occasionally)
What is the problem with unicode in getattr()? Unicode attribute name is
converted to str, and since the result is cached, this even don't add
much
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 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 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
-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,
> 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 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
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 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
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 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
19 matches
Mail list logo