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 importing unicode_literal
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
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 that `from __future_
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 due
to this occas
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 name
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 th
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 overhead.
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 rest of the thread
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 stra
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 better story for
-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, too
> 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 restoration of u"" literals i
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 restoration of u"" li
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 straddli
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 ha
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 story
> for writing
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
20 matches
Mail list logo