Re: [Python-Dev] Deprecate `from __future__ import unicode_literals`?

2016-12-17 Thread Serhiy Storchaka 

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.



___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Deprecate `from __future__ import unicode_literals`?

2016-12-17 Thread Christian Heimes 
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 the result is cached, this even don't add
> much overhead.

It breaks the str optimization of dicts. Dict with str-only keys are
special-cased in Python 2.

Christian


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Deprecate `from __future__ import unicode_literals`?

2016-12-17 Thread Serhiy Storchaka 

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 is
converted to str, and since the result is cached, this even don't add
much overhead.


It breaks the str optimization of dicts. Dict with str-only keys are
special-cased in Python 2.


getattr() converts a unicode to str and passes a str to PyObject_GetAttr().

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Deprecate `from __future__ import unicode_literals`?

2016-12-17 Thread Nick Coghlan 
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 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.
>>>
>>
>> It breaks the str optimization of dicts. Dict with str-only keys are
>> special-cased in Python 2.
>>
>
> getattr() converts a unicode to str and passes a str to PyObject_GetAttr().


getattr() may do the right thing, but directly accessing __dict__ doesn't.

python-future has a good write-up of the benefits and drawbacks, as they
originally recommended it unconditionally when modernising code, and
myself, Armin Ronacher, and a few others convinced them to be a little more
judicious in suggesting it to people:
http://python-future.org/unicode_literals.html

However, that page also points out that whether or not it's likely to help
more than it hurts depends a lot on which version of Python you're starting
from:

- if you're making originally Python 3 only code also work on Python 2, and
hence defining the first ever version of its Python 2 API, then you
probably *do* want to use unicode_literals, and then explicitly mark bytes
literals to get Python 2 working
- if you're modernising Python 2 code and have a lot of existing API users
on Python 2, then you probably *don't* want to use unicode_literals, and
instead explicitly mark your text literals as Unicode to get Python 3
working

In cases like Django where folks successfully adopted the
"unicode_literals" import for modernisation purposes, it was a matter of
aiming to get to that "Python 3 native, with Python 2 also supported"
structure as soon as possible (the fact that Django is structured primarily
as an object oriented framework likely helped with that, as it has a lot of
control over the data types user applications end up encountering).

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] [RELEASE] Python 2.7.13

2016-12-17 Thread Benjamin Peterson 
It is my pleasure to announce the release of Python 2.7.13, the latest
bugfix release of the venerable Python 2.7 series. This release
incorporates conservative bugfixes as well as improvements to keep
Python 2.7 running on modern systems.

The only change from the 2.7.13 release candidate 2 weeks ago is the
revert of a change that broke backwards compatibility with some rare C
extension patterns. See https://bugs.python.org/issue5322 for more
details.

Source archives and binaries are available at
https://www.python.org/downloads/release/python-2713/

Please report bugs to our tracker:
https://bugs.python.org/

2.7.14 will appear mid-2017.

All the best in the new year,
Benjamin Peterson
2.7 release manager
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Deprecate `from __future__ import unicode_literals`?

2016-12-17 Thread Brett Cannon 
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__ 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 the future import does both too much and not enough --
> it does too much because it changes literals to unicode even in contexts
> where there is no benefit (e.g. the argument to getattr() -- I still hear
> of code that breaks due to this occasionally) and at the same time it
> doesn't do anything for strings that you read from files, receive from the
> network, or even from other files that don't use the future import.
>
> I wonder if we can add an official note to the 2.7 docs recommending
> against it? (And maybe even to the 3.x docs if it's mentioned there at all.)
>
> --
> --Guido van Rossum (python.org/~guido )
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython (2.7): Update the porting HOWTO

2016-12-17 Thread Martin Panter 
On 17 December 2016 at 20:39, brett.cannon  wrote:
> https://hg.python.org/cpython/rev/287d4290b1b4
> changeset:   105714:287d4290b1b4
> branch:  2.7
> parent:  105677:eb02db65e148
> user:Brett Cannon 
> date:Sat Dec 17 12:38:54 2016 -0800
> summary:
>   Update the porting HOWTO
>
> diff --git a/Doc/howto/pyporting.rst b/Doc/howto/pyporting.rst
> --- a/Doc/howto/pyporting.rst
> +++ b/Doc/howto/pyporting.rst
> . . .
>  Have good test coverage
>  ---
>
> @@ -106,10 +107,11 @@
>  thumb is that if you want to be confident enough in your test suite that any
>  failures that appear after having tools rewrite your code are actual bugs in 
> the
>  tools and not in your code. If you want a number to aim for, try to get over 
> 80%
> -coverage (and don't feel bad if you can't easily get past 90%). If you
> +coverage (and don't feel bad if you can't easily get passed 90%). If you
>  don't already have a tool to measure test coverage then coverage.py_ is
>  recommended.

Hi Brett, why did you make the above change (get past → get passed)?
To me, “get past 90%” means achieving over 90%, but “you can’t get
passed 90%” would mean that 90% cannot be given (passed) to you. The
original made more sense. Another option would be “get over 90%”,
consistent with the previous sentence.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com