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 d
It's that time for another reminder: code cutoffs for the last scheduled
releases of 2019 are coming up soon. They are a little earlier than usual to
try to avoid the end-of-December rush of various holidays. Łukasz will have
more details forthcoming about **3.8.1rc1**. For the **3.7 branch**
04.12.19 22:12, Skip Montanaro пише:
This is my last post on this, at least as far as specific usage
instances are concerned. See my question about PEP 7 below. If that is
a discussion people think worthwhile, please start a new thread.
if (!VISIT(...)) {
return 0;
}
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
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
ke
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 probabl
Steven D'Aprano wrote:
> I'm going to second Chris' comment about efficiency. The purposes of
> this PEP (as I read it) are:
> (1) Security (less chance of code intentionally or accidentally
> exceeding low-level machine limits that allow a security exploit);
> (2) Improved memory use;
> (3) And
This is my last post on this, at least as far as specific usage
instances are concerned. See my question about PEP 7 below. If that is
a discussion people think worthwhile, please start a new thread.
> if (!VISIT(...)) {
> return 0;
> }
> if (!VISIT(...)) {
> retur
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 bei
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 r
04.12.19 18:54, Skip Montanaro пише:
I don't think stable code which uses macros should be changed (though
I see the INCREF/DECREF macros just call private inline functions, so
some conversion has clearly been done). Still, in new code, shouldn't
the use of macros for more than trivial use cases
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 tha
Hi,
I'm working on cleaning up the C API, long rationale:
https://pythoncapi.readthedocs.io/
Macros are causing multiple issues:
* They often leak "implementation details" and so are incompatible
with a stable ABI
* They have multiple pitfalls:
https://gcc.gnu.org/onlinedocs/cpp/Macro-Pitfalls.h
> > I don't think stable code which uses macros should be changed (though
> > I see the INCREF/DECREF macros just call private inline functions, so
> > some conversion has clearly been done). Still, in new code, shouldn't
> > the use of macros for more than trivial use cases (constant defs,
> > sim
[Skip Montanaro ]
> ...
> I don't think stable code which uses macros should be changed (though
> I see the INCREF/DECREF macros just call private inline functions, so
> some conversion has clearly been done). Still, in new code, shouldn't
> the use of macros for more than trivial use cases (consta
I am overwhelmed by this thread (and a few other things in real life) but
here are some thoughts.
1. It seems the PEP doesn't sufficiently show that there is a problem to be
solved. There are claims of inefficiency but these aren't substantiated and
I kind of doubt that e.g. representing line numb
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 co
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, Ande
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
* The number of classes in a running interpreter.
* The number of live coroutines in a running interpreter.
These two can (and coroutines actually are always) dynamically generated -
and it is not hard to imagine
scenarios were 1 million for these would easily be beaten.
I don't know the data str
04.12.19 14:08, Skip Montanaro пише:
As I wander around the code base, I keep seeing macro definitions in
the C code. For example, there are four CALL* macros defined in
Python/ast_opt.c which contain not entirely trivial bits of syntax.
That code is from 2017 (as compared to, say, Modules/audioo
> 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 w
On Wed, 4 Dec 2019 at 05:41, Chris Angelico wrote:
>
> On Wed, Dec 4, 2019 at 3:16 PM Steven D'Aprano wrote:
> >
> > On Wed, Dec 04, 2019 at 01:47:53PM +1100, Chris Angelico wrote:
> >
> > > Integer sizes are a classic example of this. Is it acceptable to limit
> > > your integers to 2^16? 2^32?
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
As I wander around the code base, I keep seeing macro definitions in
the C code. For example, there are four CALL* macros defined in
Python/ast_opt.c which contain not entirely trivial bits of syntax.
That code is from 2017 (as compared to, say, Modules/audioop.c, which
first saw the light of day i
>
> 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-featu
Le mer. 4 déc. 2019 à 01:45, Charalampos Stratakis
a écrit :
> Also noting here that the reference leaks builds are triggered once a day so
> many times it's not possible to find the commit that triggered a leak through
> the web ui of buildbot. In this case it's good to also check the previous
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 50
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
co
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 c
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/ mom
Oddly, I did not get Mark's original e-mail, but am seeing replies here.
Piggybacking off of James' email here...
On 03/12/2019 16:15, Mark Shannon wrote:
> Hi Everyone,
>
> I am proposing a new PEP, still in draft form, to impose a limit of one
> million on various aspects
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 "
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
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 ha
35 matches
Mail list logo
