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/
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. On Tue, Dec 3, 2019 at 09:21 Serhiy Storchaka <storchaka@gmail.com> 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/
-- --Guido (mobile)
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 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. Christian
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
On Tue, 3 Dec 2019 09:31:22 -0800 Guido van Rossum <guido@python.org> 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.
Agreed with Guido. Let's wait a couple more years and rethink it. Regards Antoine.
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 03/12/2019 17: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?
You are presupposing that the answer to the question "Are we going to deprecate and remove the "u" prefix" is "Yes". I'm not convinced it is. -- Rhodri James *-* Kynesim Ltd
On 12/03/2019 09:16 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?
Can we gather all the 2.7 compatibility shims and remove them in 3.9? If not, I would say let's deprecate whatever needs deprecating and remove them in 3.10. I don't think the u'' prefix needs the normal 2-cyle deprecation since it was added specifically for 2/3 cross-version code, and, as you say, "the dead of Python 2.7" has occurred (at least for us). -- ~Ethan~
On 12/3/19 1:07 PM, Ethan Furman wrote:
On 12/03/2019 09:16 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?
Can we gather all the 2.7 compatibility shims and remove them in 3.9? If not, I would say let's deprecate whatever needs deprecating and remove them in 3.10. I don't think the u'' prefix needs the normal 2-cyle deprecation since it was added specifically for 2/3 cross-version code, and, as you say, "the dead of Python 2.7" has occurred (at least for us).
A few people in this thread have reasoned, "since we added it just to help people with 2.7, we can remove it now." But that's exactly why it will be a significant cost to the community: lots of people made use of this useful needed thing. Removing the prefix will be a speed bump for people's use of Python, and will slow down people who want to upgrade to newer versions of Python. --Ned.
On Dec 3, 2019, at 09:16, Serhiy Storchaka <storchaka@gmail.com> 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. -Barry
On 03/12/2019 19.09, Barry Warsaw wrote:
On Dec 3, 2019, at 09:16, Serhiy Storchaka <storchaka@gmail.com> 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. Christian
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 <storchaka@gmail.com> 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/
On 4/12/19 8:41 am, Christian Heimes 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 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. -- Greg
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.
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?
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? --Ned.
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?
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.
I think it is too early to determine when to remove it. Even only talking about it causes blaming war. 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 <storchaka@gmail.com> 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/
-- Inada Naoki <songofacandy@gmail.com>
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 <storchaka@gmail.com> 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/
On Wed, Dec 4, 2019 at 11:49 AM Ned Batchelder <ned@nedbatchelder.com> 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,
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 <songofacandy@gmail.com> wrote:
On Wed, Dec 4, 2019 at 11:49 AM Ned Batchelder <ned@nedbatchelder.com> 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/
On Wed, Dec 4, 2019 at 5:22 PM Kyle Stanley <aeros167@gmail.com> wrote:
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.
The first one is already the case. PEP 414 reintroduced the u"..." literal form, specifically as a porting tool. Given that it has absolutely zero value in pure Py3 code, it can be assumed to be not recommended outside of 2/3 compatibility. I'm not sure how much value there'd be in a tool *just* to remove the u prefix, but perhaps a suite of 2to3-like fixers for "hey, now that you're dropping Python 2 support, here's some things you can take advantage of". For instance, "class Foo(object):" can become "class Foo:", and many uses of super() can become the zero-argument form. +1 on getting such a tool started. ChrisA
Le mer. 4 déc. 2019 à 06:41, Inada Naoki <songofacandy@gmail.com> 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.
Instead, we can do:
* Don't recommend u-prefix except in Python 2&3 code. * Provide a tool to remove the u-prefix.
Great idea, +1 from me. On Wed, Dec 4, 2019, 8:39 AM Inada Naoki <songofacandy@gmail.com> wrote:
On Wed, Dec 4, 2019 at 11:49 AM Ned Batchelder <ned@nedbatchelder.com> 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/
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?
On 12/4/19 3:11 AM, Serhiy Storchaka wrote:
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. It was explicitly decided that 2->3 would contain breaking changes. If you recall, this caused a large amount of controversy. Why bring that on ourselves again? 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. Now just because "it isn't needed anymore" we're going to break working code? I don't understand the shift in philosophy. --Ned.
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 <songofacandy@gmail.com>
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. 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
On Wed, Dec 4, 2019 at 1:26 PM Victor Stinner <vstinner@python.org> 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 <thomas@python.org> Hi! I'm an email virus! Think twice before sending your email to help me spread!
Le mer. 4 déc. 2019 à 14:49, Thomas Wouters <thomas@python.org> a écrit :
(...) 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.
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 ;-) 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.
On Wed, Dec 4, 2019 at 6:37 PM Victor Stinner <vstinner@python.org> 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 <thomas@python.org> 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 <thomas@python.org> Hi! I'm an email virus! Think twice before sending your email to help me spread!
Le jeu. 5 déc. 2019 à 12:14, Thomas Wouters <thomas@python.org> a écrit :
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.
What I proposed in the *rejected* PEP is to check the state at each Python release to see the progress, especially during release candidates. My intent is not to prevent incompatible changes, but more the opposite: better drive transitions to be able to make *more* incompatible changes. The PEP is nothing new, core developers are already helping a lot to provide pull requests to projects broken by incompatible changes. See for example of the PEP 570 has been handled in 3rd party code. As far as I recall, we never reverted incompatible changes. So I don't expect that suddenly, we would revert all incompatible changes because a single obscure PyPI project which was made incompatible. Maybe one good example is that the u-prefix of strings (u"unicode") removal was reverted in Python 3.3 for practicability :-) I don't think that we live in a black & white world, it's all a matter of tradeoffs ;-) Victor
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 Wed, Dec 4, 2019 at 3:35 AM Ned Batchelder <ned@nedbatchelder.com> wrote:
On 12/4/19 3:11 AM, Serhiy Storchaka wrote:
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. It was explicitly decided that 2->3 would contain breaking changes. If you recall, this caused a large amount of controversy. Why bring that on ourselves again?
It actually has a serious answer. It is quite easy to write straddling code that avoids using <> and L-suffixed integers -- in 2.7, there's basically no difference between ints and longs except that they are different types and you have to write isinstance(x, (int, long)) in some cases. This is not the case for u"" strings. Without them, it was found quite hard to write straddling code that uses unicode at all; the kludges around it were ugly and inefficient. That's why we brought them back. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...>
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
participants (21)
-
Antoine Pitrou -
Barry Warsaw -
Batuhan Taskaya -
Brett Cannon -
Chris Angelico -
Christian Heimes -
Eric V. Smith -
Ethan Furman -
francismb -
Greg Ewing -
Guido van Rossum -
Inada Naoki -
Kyle Stanley -
Mike Miller -
Ned Batchelder -
Rhodri James -
Serhiy Storchaka -
Simon Cross -
Skip Montanaro -
Thomas Wouters -
Victor Stinner