[Python-Dev] Re: Deprecating the "u" string literal prefix

[Stephen J. Turnbull]

Steve Holden writes:

 > In which case, wouldn't "_" make a better literal prefix than "i"?

There's no reason to suppose that "i" would be drop-in compatible for
GNU gettext (for example, gettext purely deals with the message
catalog lookup, while i-strings might be able to deal with currency
formatting and date formatting automatically, as POSIX locales (try
to) do), and "_" is already used in a plethora of software as an
abbreviation for gettext.

Those additional functions may not be easy to get right, though, and
that's what bothers me about this feature.  Do we know enough about
localization to freeze its functionality?  If not, how do we provide
for backward compatibility?  Eg, today we might decide that when
localizing to en_GB, we should deal with "l10n is a truckload of
labor" -> "l10n is a truckload of labour", and tomorrow the upgraded
version does "l10n is a lorry-full of labour" (with apologies for not
respecting the correct orthography as the base ;-).

 > A better comparison might be between _"..." and f"...".

It's orthogonal.  i-strings vs. gettext deals with the repetition of
the gettext call and assembling the string:

"".join(_("Today is"), " ", _(dayofweek), ".")# gettext
i"Today is {dayofweek}."  # i-string

while i-string vs. format deals with the DRY ugliness.

Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/VI3RYB73X4SNICTEGSHSEFQIISJ6XUIE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Deprecating the "u" string literal prefix

[Steve Holden]

In which case, wouldn't "_" make a better literal prefix than "i"?

A better comparison might be between _"..." and f"...".

regards
Steve Holden


On Thu, Dec 5, 2019 at 5:37 AM Serhiy Storchaka  wrote:

> 04.12.19 16:02, Anders Munch пише:
> > Victor Stinner [mailto:vstin...@python.org] wrote:
> >> You may want to have a look at the deferred PEP 501 -- General purpose
> string interpolation:
> >> https://www.python.org/dev/peps/pep-0501/
> >
> > I'm struggling to see what i-strings would do for i18n that str.format
> doesn't do better.
>
> You would not need to repeat yourself.
>
>  _('{name} costs ${price:.2f}').format(name=name, price=price)
>
> vs
>
>  i'{name} costs ${price:.2f}'
>
> In addition, you need to translate the format for money (in some
> cultures you need not two digits after dot), and this is hard to do with
> str.format().
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@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/46VZ2Q6QNT444YM7MV66YV26IYNIQEQC/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/EDTCRQYUID356P7LDEMCNGUTAWO4PJFK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Deprecating the "u" string literal prefix

[Victor Stinner]

Le jeu. 5 déc. 2019 à 12:14, Thomas Wouters  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
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/S7MZJHF2QKJTLMJD5TGHAHQO54CR2RGM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Deprecating the "u" string literal prefix

[Victor Stinner]

Please try to get an email client which is able to reply in a thread,
rather than creating a new thread each time you send an email.

You might want to try HyperKitty:
https://mail.python.org/archives/list/python-dev@python.org/

Victor

Le jeu. 5 déc. 2019 à 10:50, Anders Munch  a écrit :
>
> >> I'm struggling to see what i-strings would do for i18n that str.format 
> >> doesn't do better.
> Serhiy Storchaka [mailto:storch...@gmail.com]
> > You would not need to repeat yourself.
> > _('{name} costs ${price:.2f}').format(name=name, price=price)
>
> A small price to pay for having a well-defined interface with the translator.
>
> Security is one reason: A translator could sneak {password} or {signing_key} 
> into an unrelated string, if those names happen to be present in the 
> namespace.  That may not seem like a big issue if you've only ever used 
> gettext/.po-file translation, where the translation is pre-built with the 
> program, but in a more dynamic setting where end-users can supply 
> translations, it's a different story.
>
> You could parse the strings and require translations to have the same 
> variables, but that is limiting. E.g. that would mean you couldn't translate
> 'Welcome, {first_name}'
> into
> 'Willkommen, {title} {last_name}'
>
> Another reason is that you don't want variable names in your program and 
> translations to have to change in lock-step.
> E.g. you might change your code to:
>  _('{name} costs ${price:.2f}').format(name=prod.short_name,
> 
> price=context.convert_to_chosen_currency(price))
> without needing to change any translations.
>
> regards, Anders
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@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/A2PDRFFJWK2XYPHLVGKC26QR2DJ6H4QM/
> Code of Conduct: http://python.org/psf/codeofconduct/



-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/2F3O3CMR2A5NZJ6UQMYW4QJB2MKSEFBH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Deprecating the "u" string literal prefix

[Thomas Wouters]

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

> Le mer. 4 déc. 2019 à 14:49, Thomas Wouters  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 ;-)
>

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!
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/EZRSZQVS4AB6AJQYT4XV4B2H4OCOE4LB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Deprecating the "u" string literal prefix

[Anders Munch]

>> I'm struggling to see what i-strings would do for i18n that str.format 
>> doesn't do better.
Serhiy Storchaka [mailto:storch...@gmail.com]
> You would not need to repeat yourself.
> _('{name} costs ${price:.2f}').format(name=name, price=price)

A small price to pay for having a well-defined interface with the translator.
 
Security is one reason: A translator could sneak {password} or {signing_key} 
into an unrelated string, if those names happen to be present in the namespace. 
 That may not seem like a big issue if you've only ever used gettext/.po-file 
translation, where the translation is pre-built with the program, but in a more 
dynamic setting where end-users can supply translations, it's a different story.

You could parse the strings and require translations to have the same 
variables, but that is limiting. E.g. that would mean you couldn't translate
'Welcome, {first_name}'
into
'Willkommen, {title} {last_name}'

Another reason is that you don't want variable names in your program and 
translations to have to change in lock-step.
E.g. you might change your code to:
 _('{name} costs ${price:.2f}').format(name=prod.short_name, 

price=context.convert_to_chosen_currency(price))
without needing to change any translations.

regards, Anders

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/A2PDRFFJWK2XYPHLVGKC26QR2DJ6H4QM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Deprecating the "u" string literal prefix

[Anders Munch]

Barry Warsaw [mailto:ba...@python.org] wrote:
> str.format() really isn’t enough to do proper i18n; it’s actually a fairly 
> complex topic.

Obviously.

> I’m not convinced that PEP 501 would provide much benefit on the technical 
> side.

My point exactly.

> flufl.i18n - https://flufli18n.readthedocs.io/en/latest/

This seems to retrieve variables from the surrounding scope, in a manner
reminiscent of f-strings (though obviously implemented very differently).  I
would never use that for translatable strings, partly on security grounds, and
partly because it adds coupling between UI texts and code. 

regards, Anders

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/3GENPV6OVV772BTGSYX3KHH7SMWFBARW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Deprecating the "u" string literal prefix

[Serhiy Storchaka]

04.12.19 16:02, Anders Munch пише:

Victor Stinner [mailto:vstin...@python.org] wrote:

You may want to have a look at the deferred PEP 501 -- General purpose string 
interpolation:
https://www.python.org/dev/peps/pep-0501/


I'm struggling to see what i-strings would do for i18n that str.format doesn't 
do better.


You would not need to repeat yourself.

_('{name} costs ${price:.2f}').format(name=name, price=price)

vs

i'{name} costs ${price:.2f}'

In addition, you need to translate the format for money (in some 
cultures you need not two digits after dot), and this is hard to do with 
str.format().

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/46VZ2Q6QNT444YM7MV66YV26IYNIQEQC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Deprecating the "u" string literal prefix

[Barry Warsaw]

On Dec 4, 2019, at 06:02, Anders Munch  wrote:
> 
> Victor Stinner [mailto:vstin...@python.org] wrote:
>> You may want to have a look at the deferred PEP 501 -- General purpose 
>> string interpolation:
>> https://www.python.org/dev/peps/pep-0501/
> 
> I'm struggling to see what i-strings would do for i18n that str.format 
> doesn't do better.

str.format() really isn’t enough to do proper i18n; it’s actually a fairly 
complex topic.

GNU Mailman 2 was one of the first big Python applications to be fully 
internationalized, with active translators, web pages that could be displayed 
in multiple languages, and email messages that could have different parts 
translated to different languages.

I wrote or co-wrote several tools that work together to provide a full i18n 
solution.  This is not just a technical problem, but a social one as well, 
since you have to understand that human translators are often not programmers.  
Take a look at these, especially the latter PyPI package:

gettext - https://docs.python.org/3/library/gettext.html
pygettext - (although now standard xgettext can grok Python)
string.Template - https://docs.python.org/3/library/string.html#template-strings
flufl.i18n - https://flufli18n.readthedocs.io/en/latest/

I’m not convinced that PEP 501 would provide much benefit on the technical side.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/LI56JQCWE46POUDQKB5CZJPRHYOQ53N6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Deprecating the "u" string literal prefix

[Ned Batchelder]

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.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/6WX5GANERILH4TAMJAB2I55HRW5VTT6G/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Deprecating the "u" string literal prefix

[Brett Cannon]

Greg Ewing wrote:
> 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.

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.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/X5SJQXIWBH3T5KGTWK4ZX74L62MGYCIH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Deprecating the "u" string literal prefix

[Mike Miller]

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
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/IQET4TCCPAD4FVQBV23D2UKJ2CV7XYX3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Deprecating the "u" string literal prefix

[Victor Stinner]

Le mer. 4 déc. 2019 à 14:49, Thomas Wouters  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.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/DHFWE4UNXJHS6R2NJM32WLZJJVYPLKRH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Deprecating the "u" string literal prefix

[Guido van Rossum]

On Wed, Dec 4, 2019 at 3:35 AM Ned Batchelder  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?)*

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/QXYBCQ4UY2FLKNFBDCDFWQD35DURPWD3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Deprecating the "u" string literal prefix

[Anders Munch]

Victor Stinner [mailto:vstin...@python.org] wrote:
> You may want to have a look at the deferred PEP 501 -- General purpose string 
> interpolation:
> https://www.python.org/dev/peps/pep-0501/

I'm struggling to see what i-strings would do for i18n that str.format doesn't 
do better.

regards, Anders
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/E6Q2QJU656WQNBE6L6BXOFTVNBBFY7DV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Deprecating the "u" string literal prefix

[Thomas Wouters]

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-le...@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/XJ7PF3GIA7HCENHB7CM7BSGSAZ3SWAOT/
> 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!
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/I52ZGAAJJFE6MLBRUMEENKYNQMTUTUYZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Deprecating the "u" string literal prefix

[Batuhan Taskaya]

> 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  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-le...@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/EVKCCO5KMOGEEFMSSY2PZRVGT2LDOB5K/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/5IPCQPWHUDEVAHDBZTHUMXCY4ZGPJSXS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Deprecating the "u" string literal prefix

[Victor Stinner]

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
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/XJ7PF3GIA7HCENHB7CM7BSGSAZ3SWAOT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Deprecating the "u" string literal prefix

[Inada Naoki]

>
> 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  
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/WTEWGFFMJV7A6M5XEE7DFDF2QIQNVFUR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Deprecating the "u" string literal prefix

[Victor Stinner]

You may want to have a look at the deferred PEP 501 -- General purpose
string interpolation:
https://www.python.org/dev/peps/pep-0501/

It was proposed while PEP 498 -- Literal String Interpolation
(f-string) was being discussed, which was accepted:
https://www.python.org/dev/peps/pep-0498/

PEP 501 proposed a solution for i18n.

Victor

Le mer. 4 déc. 2019 à 10:22, Anders Munch  a écrit :
>
> Chris Angelico [mailto:ros...@gmail.com] wrote:
> > 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 
> > [...]
>
> Challenge accepted :)  Here comes my https://xkcd.com/1172/ moment.
>
> I'm using the u prefix to tag user interface strings for translation.  u"..." 
> goes through i18n, "..." doesn't.  I have tools that extract and replace 
> texts, identify new strings for translation etc. based on this.
> I was very happy when 3.3 reintroduced the prefix, because it allowed me to 
> upgrade without losing my very efficient workflow.  Not to mention having to 
> make 10.000 code changes to replace the prefix with something or other.
>
> If the prefix goes, I'm not going to complain, I know my setup is fairly 
> unique and I can't really demand that you keep vestigial syntax around just 
> for that.  But I'd still be sorry to see it go.
>
> regards, Anders
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@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/WCZDU2M2YK6A2UDP7OSN6P3VUOPMKCYI/
> Code of Conduct: http://python.org/psf/codeofconduct/



-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/CEDNHEO3U5OLTOMVMULCY7VDKVAWTOQB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Deprecating the "u" string literal prefix

[Ned Batchelder]

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.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/OGM2SHWH6ZJ434YVHGX2DXTG3HHSUZ6U/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Deprecating the "u" string literal prefix

[Victor Stinner]

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.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/TDZB4TAVEKGD35B56RHIC36M4L7TGFL6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Deprecating the "u" string literal prefix

[Anders Munch]

Chris Angelico [mailto:ros...@gmail.com] wrote:
> 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 
> [...]

Challenge accepted :)  Here comes my https://xkcd.com/1172/ moment.

I'm using the u prefix to tag user interface strings for translation.  u"..." 
goes through i18n, "..." doesn't.  I have tools that extract and replace texts, 
identify new strings for translation etc. based on this.  
I was very happy when 3.3 reintroduced the prefix, because it allowed me to 
upgrade without losing my very efficient workflow.  Not to mention having to 
make 10.000 code changes to replace the prefix with something or other.

If the prefix goes, I'm not going to complain, I know my setup is fairly unique 
and I can't really demand that you keep vestigial syntax around just for that.  
But I'd still be sorry to see it go.

regards, Anders
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/WCZDU2M2YK6A2UDP7OSN6P3VUOPMKCYI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Deprecating the "u" string literal prefix

[Serhiy Storchaka]

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?
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/VMEH2RZJJTGTTOWUSXS526XT5U2FZEXU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Deprecating the "u" string literal prefix

[Serhiy Storchaka]

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.

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/D2VZNNMBHWRHUYV7MUMSTACTUARTLCET/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Deprecating the "u" string literal prefix

[Serhiy Storchaka]

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).

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/XHNXDQYOR7C45ESI54UX46AY3M75HNSN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Deprecating the "u" string literal prefix

[Chris Angelico]

On Wed, Dec 4, 2019 at 5:22 PM Kyle Stanley  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
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/3CEPZAFTMNSRWZ43GV5W3BKU6GJZEIVT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Deprecating the "u" string literal prefix

[Kyle Stanley]

> 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-le...@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/EVKCCO5KMOGEEFMSSY2PZRVGT2LDOB5K/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/AKUXJR6BO4WTO7SLN3ES6PCWNO5H62ZU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Deprecating the "u" string literal prefix

[Inada Naoki]

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-le...@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/EVKCCO5KMOGEEFMSSY2PZRVGT2LDOB5K/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Deprecating the "u" string literal prefix

[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?


--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-le...@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/EMFDKQ57JVWUZ6TPZM5VTFW7EUKVYAOY/
Code of Conduct: http://python.org/psf/codeofconduct/




___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/27OFJ45B4OFDR3ON2QI72XDF7ISVADU3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Deprecating the "u" string literal prefix

[Inada Naoki]

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  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-le...@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/EMFDKQ57JVWUZ6TPZM5VTFW7EUKVYAOY/
> Code of Conduct: http://python.org/psf/codeofconduct/



-- 
Inada Naoki  
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/FDA2UHFY4PBZBWCUKU5HKM73KDKB7FT6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Deprecating the "u" string literal prefix

[Greg Ewing]

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
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/OTYLQJEJDPKU64QQ6F4B6HH3FPIHRVQE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Deprecating the "u" string literal prefix

[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?


--Ned.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/PY24FGY3GLHZP6X4G2UPYEAD5INVEHHV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Deprecating the "u" string literal prefix

[Ned Batchelder]

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-le...@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/4GGYZ6XNEH5OQDYC6VLH2MADUVD5LGF3/
Code of Conduct: http://python.org/psf/codeofconduct/

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/2DBWZFPYW7XOGMO3DT6UEBQMLMVJQMQ3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Deprecating the "u" string literal prefix

[Eric V. Smith]

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
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/44QX46DVMO7MDXKNPXXLEIADNUTR7ZMS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Deprecating the "u" string literal prefix

[Antoine Pitrou]

On Tue, 3 Dec 2019 09:31:22 -0800
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.

Agreed with Guido.  Let's wait a couple more years and rethink it.

Regards

Antoine.

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/IMQQLXZYUFSR43I7KM6V7K2KEQQFIYCY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Deprecating the "u" string literal prefix

[Skip Montanaro]

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
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/WFB7KNWCFK3U2HD6I5UCUT6RQFCB7BMJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Deprecating the "u" string literal prefix

[Christian Heimes]

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
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/3XZZ7FSE3W57VSFBHCNAXIEKTLQWPJBD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Deprecating the "u" string literal prefix

[Simon Cross]

On Tue, Dec 3, 2019 at 7:42 PM 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.
>

+100
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/PSPKIXP4LE6UJBIJAVFECHVWK7GSI5KF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Deprecating the "u" string literal prefix

[Ethan Furman]

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~
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/B7ZK6TQ2L6667R54FGUSGW3H2ELJ243F/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Deprecating the "u" string literal prefix

[Christian Heimes]

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.

Christian
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/4GGYZ6XNEH5OQDYC6VLH2MADUVD5LGF3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Deprecating the "u" string literal prefix

[francismb]

On 12/3/19 6:31 PM, 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.
+1  ... or code that will be migrated in the (near) future ;-) ...


Regards,
francismb
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/ZCQKLLBGCKZRPIA2RGUQHOO5JRP6LEJW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Deprecating the "u" string literal prefix

[Ethan Furman]

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~

 

[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-le...@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/GTCA6FGKF4IVCKW5HFTAP42LC4VPGLLR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Deprecating the "u" string literal prefix

[Barry Warsaw]

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.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/JBOHEFZ6PXSIKBBLNILGKIFYWQZ2WAHZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Deprecating the "u" string literal prefix

[Rhodri James]

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?


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


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
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/YOCNBXZ7K3VN4UBF7ASBKPWB32QAG63L/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Deprecating the "u" string literal prefix

[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.

On Tue, Dec 3, 2019 at 09:21 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-le...@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/EMFDKQ57JVWUZ6TPZM5VTFW7EUKVYAOY/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-- 
--Guido (mobile)
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/DWNANYD2PYTSOOQBOCSNSIZTHSUUTQED/
Code of Conduct: http://python.org/psf/codeofconduct/