On 12/03/2019 09:31 AM, Guido van Rossum wrote:

I think it’s too soon to worry about this. I don’t see a reason to harass people who maintain code based that were just recently migrated.

I'm happy to go with this, since my libraries still do the 2/3 straddle. Do we want to set a date/version where we will drop code that only exists to make 2/3 projects easier? -- ~Ethan~

On 12/3/2019 3:35 PM, Christian Heimes wrote:

On 03/12/2019 21.04, Ethan Furman wrote:

...

On 12/03/2019 09:31 AM, Guido van Rossum wrote:

...

I think it’s too soon to worry about this. I don’t see a reason to harass people who maintain code based that were just recently migrated. I'm happy to go with this, since my libraries still do the 2/3 straddle.

Do we want to set a date/version where we will drop code that only exists to make 2/3 projects easier? How about when the last major Linux distro with Python 2 reaches end of general support? According to Wikipedia that would be 2023 for Ubuntu 18.04 LTS, 2024 for RHEL 8.0, and 2028 for SUSE SLES 15.

I agree we should wait a long time before removing the 'u' prefix. If I'm using a library that uses 'u', but that library is no longer maintained, when do we want to break my app, just because I use this library? Given that 'u' requires so little code to implement, I don't see what's to be gained by removing it. Maybe document it as deprecated (and why), but that's about it. Eric

Guido> I think it’s too soon to worry about this. Simon> +100 Ditto. Besides, isn't support for u"..." just a variable and a couple tests in the earliest phase of compilation? If things are going to get deprecated/removed, I'd prefer the focus be placed on those bits which present a significant support burden. Skip

03.12.19 19:31, Guido van Rossum пише:

I think it’s too soon to worry about this. I don’t see a reason to harass people who maintain code based that were just recently migrated.

Yes, I also think that it is too early to deprecate it just now. Python 2 is not completely dead yet. But I would happy to know some estimated terms. BTW, BytesWarning and the -b option also are only needed for programs ported from Python 2. This great feature helps to catch some porting errors, but makes the pure Python 3 code more cumbersome and less efficient. For example, you can't use just `name[0] in ('.', b'.')`, you have to perform the `isinstance(name, bytes)` check first, and you can't use the same cache for string and bytes keys (you have to use `(type(key), key)` as a key).

On 12/3/19 2:41 PM, Christian Heimes wrote:

On 03/12/2019 19.09, Barry Warsaw wrote:

...

On Dec 3, 2019, at 09:16, Serhiy Storchaka wrote:

...

The 'u" string literal prefix was removed in 3.0 and reintroduced in 3.3 to help writing the code compatible with Python 2 and 3 [1]. After the dead of Python 2.7 we will remove some deprecated features kept for compatibility with 2.7. When we are going to deprecate and remove the "u" prefix? I think removing or even deprecating it will cause unnecessary code churn in third party libraries, for very little value. Let’s just call it a wart until Python 4000. I'm 100% with Barry. We can certainly document the "u" string prefix as deprecated. I'm strongly against removing it from Python 3 or even raising a deprecation warning. Let's leave it to linters and maybe consider deprecation for Python 4. Or maybe not.

Yes, please, please, don't remove this prefix. It will cause needless churn, and force people to revisit code that works just fine.  We should try to keep old code working unless there is a clear benefit in making a breaking change. I haven't heard a benefit to removing this prefix. "We added it just to help people migrate" is not a reason to remove it now. --Ned.

Christian _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/4GGYZ6XN... Code of Conduct: http://python.org/psf/codeofconduct/

Greg Ewing wrote:

...

I'm strongly against removing it from Python 3 or even raising a deprecation warning. I agree. I know there is a maintenance cost to keeping

On 4/12/19 8:41 am, Christian Heimes wrote: things like this around, but in this case it's pretty minor. We've probably already spent more time discussing it than it will cost to keep it for the rest of Python's lifetime.

I agree. Let's document it as unnecessary for new code, linters can point it out to people, and we can slate removal for Py4K.

03.12.19 23:44, Ned Batchelder пише:

On 12/3/19 12:16 PM, Serhiy Storchaka wrote:

...

The 'u" string literal prefix was removed in 3.0 and reintroduced in 3.3 to help writing the code compatible with Python 2 and 3 [1]. After the dead of Python 2.7 we will remove some deprecated features kept for compatibility with 2.7. When we are going to deprecate and remove the "u" prefix?

[1] https://www.python.org/dev/peps/pep-0414/

Can you clarify this?: "we will remove some deprecated features kept for compatibility with 2.7"  Where is the discussion of the features being removed?

See the thread "Should we require all deprecations to have a removal version that we follow through on?". There is no sense to keep old deprecated and useless features long after the death of Python 2. The question is only about the terms.

On 12/3/19 8:13 PM, Inada Naoki wrote:

I think it is too early to determine when to remove it. Even only talking about it causes blaming war.

Has anyone yet given a reason to remove it? It will change working code into broken code. Why do that? --Ned.

BTW, I think 2to3 can help to move from 2&3 code to 3-only code.

* "future" fixer can be remove legacy futures. But it seems to remove all futures, including "annotations". It should be kept. * "unicode" fixer can be used to remove u-prefix. But I'm not sure yet.

Are there any other things which are used for writing 2&3 code and will be removed someday in the future? And is there any tool that can convert code using the "six" library to normal Python 3 code?

Regards,

On Wed, Dec 4, 2019 at 2:29 AM Serhiy Storchaka wrote:

...

The 'u" string literal prefix was removed in 3.0 and reintroduced in 3.3 to help writing the code compatible with Python 2 and 3 [1]. After the dead of Python 2.7 we will remove some deprecated features kept for compatibility with 2.7. When we are going to deprecate and remove the "u" prefix?

[1] https://www.python.org/dev/peps/pep-0414/ _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/EMFDKQ57... Code of Conduct: http://python.org/psf/codeofconduct/

BTW, I think 2to3 can help to move from 2&3 code to 3-only code.

Instead, we can do:

* Don't recommend u-prefix except in Python 2&3 code. * Provide a tool to remove the u-prefix.

+1, this seems like the smoothest way of handling it and has very minimal impact on users. In 5+ years from now as u-strings become increasingly rare, we can consider a long term deprecation process. In the meantime, any tools we can provide to automate the process of converting them will make the transition that much easier. On Wed, Dec 4, 2019 at 12:41 AM Inada Naoki wrote:

On Wed, Dec 4, 2019 at 11:49 AM Ned Batchelder wrote:

...

On 12/3/19 8:13 PM, Inada Naoki wrote:

...

I think it is too early to determine when to remove it. Even only talking about it causes blaming war.

Has anyone yet given a reason to remove it?

Note that "never" is included in ”when". I didn't promoting removing it. I just said let's stop discussion about it.

...

It will change working code into broken code. Why do that?

Of course, everyone in this thread understands it. No one proposes remove it now.

On the other hand, we remove some parts from Python language and the stdlib regularly to keep Python clean. All removal will break some code. That's why we have a deprecation period.

Currently, u-prefix is very widely used. It shouldn't be removed anytime soon. And I agree that we shouldn't raise DeprecationWarning for now.

But how about 5, 10, and 20 years later? No one knows it. Let's stop discussing it. It can not be productive.

Instead, we can do:

* Don't recommend u-prefix except in Python 2&3 code. * Provide a tool to remove the u-prefix.

Regards, _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/EVKCCO5K... Code of Conduct: http://python.org/psf/codeofconduct/

Le mer. 4 déc. 2019 à 06:41, Inada Naoki a écrit :

Currently, u-prefix is very widely used. It shouldn't be removed anytime soon. And I agree that we shouldn't raise DeprecationWarning for now.

But how about 5, 10, and 20 years later? No one knows it. Let's stop discussing it. It can not be productive.

Instead, we can do:

* Don't recommend u-prefix except in Python 2&3 code. * Provide a tool to remove the u-prefix.

Another approach is to use linters rather than Python to actively "deprecate" things. Victor -- Night gathers, and now my watch begins. It shall not end until my death.

04.12.19 04:41, Ned Batchelder пише:

On 12/3/19 8:13 PM, Inada Naoki wrote:

...

I think it is too early to determine when to remove it. Even only talking about it causes blaming war.

Has anyone yet given a reason to remove it? It will change working code into broken code. Why do that?

Why the "<>" operator and the "L" suffix was removed?

Is this a serious question? Many things were removed in moving from Python 2 to Python 3.

We remove garbages not only between 2 and 3. We regularly remove garbages. https://docs.python.org/3/whatsnew/3.8.html#api-and-feature-removals https://docs.python.org/3/whatsnew/3.7.html#api-and-feature-removals https://docs.python.org/3/whatsnew/3.6.html#removed https://docs.python.org/3/whatsnew/3.5.html#removed We need to avoid major breakage. But we accept small breakages on every minor release. And u-prefix is major for now.

Maybe I missed something. Python used to pride itself on keeping old code working. When hash randomization was introduced, it was decided to be off by default in Python 2 because even though people shouldn't have counted on the order of dicts, they were counting on it, and turning on hash randomization would break code. So there we decided to keep things insecure because otherwise code would break, even "wrong" code.

It is not a good example because we didn't release Python 2.8. Hash randomization might be enabled by default if we released Python 2.8. Regards, -- Inada Naoki

On Wed, Dec 4, 2019 at 1:26 PM Victor Stinner wrote:

INADA-san:

...

We need to avoid major breakage. But we accept small breakages on every minor release. And u-prefix is major for now.

IMHO we need a metric to measure the risk of an incompatible change: estimate the percentage of broken Python applications. For example, run the test suite of the PyPI top 100 projects with the incompatible change and see how many fails. That's the root of the PEP 608 -- Coordinated Python release: https://www.python.org/dev/peps/pep-0608/

The "PEP 606 -- Python Compatibility Version" elaborates on incompatible changes: https://www.python.org/dev/peps/pep-0606/

These two PEPs have been rejected since the proposed concrete changes which were not the best options.

It seems like the common denominator is the need for a tool to run the testsuite of popular projects on a modified Python and/or the master of Python, to measure how many projects are broken by recent Python changes.

It's very different if an incompatible change break 1% or 90% of Python projects.

Unfortunately there is a distinctive bias if you select popular projects, or even packages from PyPI. There is a very large body of work that never appears there, but is nonetheless used, useful and maintained lacklusterly enough to pose a big problem for changes like these. Tutorials, examples in documentation, random github repos, plugins for programs that embed Python, etc. The latter also represents an example of cases where you can't just decide to use an older version of Python to use something that wasn't updated yet. It's not just about how much code it will break, but also about how easy it is to work around the problem or fix the code for users of it. In the specific case of u"", it seems clear to me that we should silently deprecate it, discourage its use, provide tools to get rid of them, and wait another five or more years before considering a noisier deprecation.

Right now, we take decisions on assumptions without validating them. We push changes and hope that we don't break too many projects. It's rare that we revert incompatible changes that break too many projects, because too few developers test their projects on the beta versions of Python. Most developers and users only test final Python versions.

Victor _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/XJ7PF3GI... Code of Conduct: http://python.org/psf/codeofconduct/

-- Thomas Wouters Hi! I'm an email virus! Think twice before sending your email to help me spread!

On Wed, Dec 4, 2019 at 6:37 PM Victor Stinner wrote:

...

...

(...) It's very different if an incompatible change break 1% or 90% of Python projects.

Unfortunately there is a distinctive bias if you select popular

Le mer. 4 déc. 2019 à 14:49, Thomas Wouters a écrit : projects, or even packages from PyPI. There is a very large body of work that never appears there, but is nonetheless used, useful and maintained lacklusterly enough to pose a big problem for changes like these. Tutorials, examples in documentation, random github repos, plugins for programs that embed Python, etc. The latter also represents an example of cases where you can't just decide to use an older version of Python to use something that wasn't updated yet.

My point is that currently, we have no data to take decisions. We can only make assumptions. Having more data than nothing should help to take smarter decisions ;-)

It should, but it doesn't always :) If you forget how your data is flawed, the 'smarter' decision can easily be wrong, instead. I do think it's a good idea to reject ideas that would break a certain number of PyPI packages, say, but just because it won't break them doesn't mean it won't break a significant number of others.

I know that there is closed source and unpublished projects. But if 20% (for example) of the most popular projects on PyPI are broken by an incompatible change, it's not hard to extrapolate that *at least* 20% of unpublished will be broken at least. Usually, closed source and unpublished projects are getting less attention and so are less up to date than PyPI projects.

Even if you restrict the scope to PyPI: most PyPI top 100 modules are the most common dependencies in projects. It's easy to extrapolate that if 20% of these PyPI top 100 modules are broken, all applications using at least one of these broken projects will be broken as well.

Another point of the PEP 608 is that there are not often resources to fix the most popular dependencies on PyPI, it's likely better to *revert* the incompatible change causing the issue. Again, to be able to revert a change, we need the information that we broke something. If a change goes through the final release, usually we prefer to acknoledge that the "ship has sailed" and deal with it, rather than reverting the annoying change.

Victor -- Night gathers, and now my watch begins. It shall not end until my death.

-- Thomas Wouters Hi! I'm an email virus! Think twice before sending your email to help me spread!

On 12/04/2019 04:21 AM, Victor Stinner wrote:

IMHO we need a metric to measure the risk of an incompatible change: estimate the percentage of broken Python applications. For example, run the test suite of the PyPI top 100 projects with the incompatible change and see how many fails. That's the root of the PEP 608 -- Coordinated Python release: https://www.python.org/dev/peps/pep-0608/

The problem with 608 is that it was effectively a release blocker. If somebody has the resources to put the testing and measuring into place I think it would be valuable data -- especially if those resources could then also notify the responsible parties that a breaking change was coming, or mass-media it, or something. But Python should not be held hostage to others' unwillingness to fix/upgrade their own code base, nor their inability to fix/upgrade their dependencies -- moving to the latest Python is not a requirement, and if a company chooses to maintain aging resources to support aging software, that is their prerogative. -- ~Ethan~

On 2019-12-03 18:41, Ned Batchelder wrote:

Has anyone yet given a reason to remove it? It will change working code into broken code. Why do that?

I've heard a few complaints over the years about the number of combinations of string prefixes being a problem and a high barrier to new ones being accepted. Especially since they are allowed to be capital letters as well, which I've never actually seen used in the real world. Some code formatters already fix these. At the appropriate time, hopefully we can deprecate u… and the capital prefixes too. -Mike