[Python-Dev] Re: Should we require all deprecations to have a removal version that we follow through on?
06.12.19 21:16, Kyle Stanley пише: Would it be reasonable to require an minimum amount of versions to be specified (such as n versions ahead), but provide flexibility in terms to delaying the removal, as needed? IMO, it would be more convenient for users to have a "minimum removal" version in mind, rather than an unscheduled deprecation that could have a version+2 (deprecation and removal in 2 versions) assigned at any point in time. We have a special deprecated-removed directive in docs for this. ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/PZT35WQJBPZUAFSX77H455UG6LSIEYK5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Deprecating the "u" string literal prefix
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:[email protected]] 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 -- [email protected] > To unsubscribe send an email to [email protected] > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/[email protected]/message/46VZ2Q6QNT444YM7MV66YV26IYNIQEQC/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/EDTCRQYUID356P7LDEMCNGUTAWO4PJFK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP proposal to limit various aspects of a Python program to one million.
On Sat, 7 Dec 2019 at 06:29, Steven D'Aprano wrote: > > A million seems reasonable for lines of source code, if we're prepared > to tell people using machine generated code to split their humongous .py > files into multiple scripts. A small imposition on a small subset of > Python users, for the benefit of all. I'm okay with that. I recently hit on a situation that created a one million line code file: https://github.com/pytest-dev/pytest/issues/4406#issuecomment-439629715 The original file (which is included in SymPy) has 3000 lines averaging 500 characters per line so that the total file is 1.5MB. Since it is a test file pytest rewrites the corresponding pyc file and adds extra lines to annotate the intermediate results in the large expressions. The pytest-rewritten code has just over a million lines. When I first tried pytest with this file it lead to a CPython segfault. It seems that the crash in CPython was fixed in 3.7.1 though so subsequent versions can work fine with this (although it is slow). The tests in the file are skipped anyway so I just made sure that the file was blacklisted in SymPy's pytest configuration. -- Oscar ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/IUG6EBERWZJKWOF2LJTQJKCUXTJTQXS5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Deprecating the "u" string literal prefix
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 -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/VI3RYB73X4SNICTEGSHSEFQIISJ6XUIE/
Code of Conduct: http://python.org/psf/codeofconduct/
