Re: [Python-Dev] Code formatter bot

[Ben Finney]

francismb  writes:

> what's your opinion about a code-formatter bot for cpython.

What is the proposal? The opinions will surely depend on:

* What formatting is to be applied automatically?

  * If you propose to enforce rigid interpretations of the style-guide
PEPs as automatic rules, that will incur the wrath of those who have
made clear those PEPs are not to be used that way. There is a clear
opinion (from at least the BDFL) that the style guide PEPs are
guidelines to be applied with human judgement.

  * If on the other hand you propose to enforce only those rules which
are strict enough to be applied automatically (e.g. “don't mix
spaces and TABs”, “encode source using UTF-8 only”) then that's best
done by editor plug-ins like EditorConfig[0].

* At which point in the workflow will the formatting be applied?

  * If you propose to change the code *after* the programmer sees it in
their text editor, that is sure to be unpopular. The code committed
to VCS should exactly match what the programmer sees when they
choose to commit.

  * If you propose to reject the code at time of committing, there are
VCS hooks that can do that; I don't know what different system you
propose.

  * If you propose to present formatting violations as errors in the
programmer's text editor so they can be corrected before using the
VCS, then there are tools like EditorConfig[0] to do that.

[0]: EditorConfig http://editorconfig.org/>

-- 
 \ “Pinky, are you pondering what I'm pondering?” “I think so, |
  `\ Brain, but isn't a cucumber that small called a gherkin?” |
_o__)   —_Pinky and The Brain_ |
Ben Finney

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Devguide: Add a table summarizing status of Python branches

[Victor Stinner]

Hi,

I proposed a patch for the devguide to give the current status of all
Python branches: active, bugfix, security only, end-of-line, with
their end-of-life when applicable (past date or scheduled date)
http://bugs.python.org/issue26165

What do you think? Does it look correct?

We will have to update this table each time that the status of a
branch change. Hopefully, it's not a common event, so it will not
require a lot of work for release managers :-)

Victor
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Update PEP 7 to require curly braces in C

[Brett Cannon]

On Tue, 19 Jan 2016 at 19:33 Martin Panter  wrote:

> On 19 January 2016 at 20:12, Brett Cannon  wrote:
> > Here is a proposed update:
> >
> > diff -r 633f51d10a67 pep-0007.txt
> > --- a/pep-0007.txt Mon Jan 18 10:52:57 2016 -0800
> > +++ b/pep-0007.txt Tue Jan 19 12:11:44 2016 -0800
> > @@ -75,9 +75,9 @@
> >}
> >
> >  * Code structure: one space between keywords like ``if``, ``for`` and
> > -  the following left paren; no spaces inside the paren; braces may be
> > -  omitted where C permits but when present, they should be formatted
> > -  as shown::
> > +  the following left paren; no spaces inside the paren; braces are
> > +  strongly preferred but may be omitted where C permits, and they
> > +  should be formatted as shown::
> >
> >if (mro != NULL) {
> >...
>
> This change seems to be accidentally smuggled in, in the guise of a
> PEP 512 update :)
>

Darn, sorry about that; forgot I had that change sitting in my peps
checkout. I'll revert it when I get home (unless the change is actually
acceptable to Guido).

-Brett


>
> My view is I prefer always using curly brackets in my own code. It is
> easier to add printf() debugging without making mistakes. I support
> “strongly preferring” them in the style guide, which is as much as a
> style guide can do anyway.
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Devguide: Add a table summarizing status of Python branches

[Brett Cannon]

On Wed, 20 Jan 2016 at 09:41 Victor Stinner 
wrote:

> Hi,
>
> I proposed a patch for the devguide to give the current status of all
> Python branches: active, bugfix, security only, end-of-line, with
> their end-of-life when applicable (past date or scheduled date)
> http://bugs.python.org/issue26165
>
> What do you think? Does it look correct?
>

I would update it have a "first release" date column and also the projected
EOL for Python 3.5. Otherwise LGTM.

-Brett


>
> We will have to update this table each time that the status of a
> branch change. Hopefully, it's not a common event, so it will not
> require a lot of work for release managers :-)
>
> Victor
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Code formatter bot

[Andrew Barnert via Python-Dev]

On Jan 20, 2016, at 00:35, Ben Finney  wrote:
> 
> francismb  writes:
> 
>> what's your opinion about a code-formatter bot for cpython.
> 
> What is the proposal? The opinions will surely depend on:

... plus:

* How does the formatter bot deal with "legacy code"? Large parts of CPython 
predate PEPs 7 and 8, and the decision was made long ago not to reformat 
existing code unless that code is being substantially modified for some other 
reason. Similarly, when the PEPs are updated, the usual decision is to not 
reformat old code.

* When code _is_ auto-reformatted, what tools do you have to help git's merge 
logic, Reitveld, human readers looking at diffs or blame/annotate locally or on 
the web, etc. look past the hundreds of trivial changes to highlight the ones 
that matter?

* What's the argument for specifically automating code formatting instead of 
any of the other things a commit-triggered linter can catch just as easily?

But one comment on Ben's comment:

>  * If on the other hand you propose to enforce only those rules which
>are strict enough to be applied automatically (e.g. “don't mix
>spaces and TABs”, “encode source using UTF-8 only”) then that's best
>done by editor plug-ins like EditorConfig[0].

In my experience (although mostly with projects with a lot fewer contributors 
than CPython...), it can be helpful to have both suggested editor plugins that 
do the auto formatting on the dev's computer, and VCS-triggered checkers that 
ensure the formatting was correct. That catches those occasional cases where 
you do a quick "trivial" edit in nano instead of your usual editor and then 
forget you did so and try to check in), without the nasty side-effects you 
mention later (like committing code you haven't seen).

(Of course writing plugins that understand "legacy code" in the exact same way 
as the commit filter can be tricky, but in that case, it's better to know that 
one or the other isn't working as intended--both so a human can decide, and so 
people can see the bug in the plugin or filter--than to automatically make 
changes that weren't wanted.)

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Code formatter bot

[Ben Finney]

Andrew Barnert via Python-Dev  writes:

> […] it can be helpful to have both suggested editor plugins that do
> the auto formatting on the dev's computer, and VCS-triggered checkers
> that ensure the formatting was correct.

Right, I was not intending the different stages to be exclusive. I was
seeking clarification from the OP on the intended stages proposed to be
automated.

It's also worth noting that neither of the above approaches you mention
would qualify IMO to be termed a “bot”, since they still leave it to the
human operator to deal with formatting violations before the edits
reach the VCS.

But that's another clarification I'm seeking from the OP: what “bot” is
being proposed?

-- 
 \  “Nothing is more sacred than the facts.” —Sam Harris, _The End |
  `\   of Faith_, 2004 |
_o__)  |
Ben Finney

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 509: Add a private version to dict

[Yury Selivanov]

On 2016-01-18 5:43 PM, Victor Stinner wrote:

Is someone opposed to this PEP 509?

The main complain was the change on the public Python API, but the PEP
doesn't change the Python API anymore.

I'm not aware of any remaining issue on this PEP.


Victor,

I've been experimenting with the PEP to implement a per-opcode
cache in ceval loop (I'll share my progress on that in a few
days).  This allows to significantly speedup LOAD_GLOBAL and
LOAD_METHOD opcodes, to the point, where they don't require
any dict lookups at all.  Some macro-benchmarks (such as
chameleon_v2) demonstrate impressive ~10% performance boost.

I rely on your dict->ma_version to implement cache invalidation.

However, besides guarding against version change, I also want
to guard against the dict being swapped for another dict, to
avoid situations like this:


def foo():
print(bar)

exec(foo.__code__, {'bar': 1}, {})
exec(foo.__code__, {'bar': 2}, {})


What I propose is to add a pointer "ma_extra" (same 64bits),
which will be set to NULL for most dict instances (instead of
ma_version).  "ma_extra" can then point to a struct that has a
globally unique dict ID (uint64), and a version tag (unit64).
A macro like PyDict_GET_ID and PyDict_GET_VERSION could then
efficiently fetch the version/unique ID of the dict for guards.

"ma_extra" would also make it easier for us to extend dicts
in the future.

Yury
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 509: Add a private version to dict

[Maciej Fijalkowski]

The easiest version is to have global numbering (as opposed to local).

Anyway, I would strongly suggest getting some benchmarks done and
showing performance benefits first, because you don't want PEPs to be
final when you don't exactly know the details.

On Wed, Jan 20, 2016 at 7:02 PM, Yury Selivanov  wrote:
> On 2016-01-18 5:43 PM, Victor Stinner wrote:
>>
>> Is someone opposed to this PEP 509?
>>
>> The main complain was the change on the public Python API, but the PEP
>> doesn't change the Python API anymore.
>>
>> I'm not aware of any remaining issue on this PEP.
>
>
> Victor,
>
> I've been experimenting with the PEP to implement a per-opcode
> cache in ceval loop (I'll share my progress on that in a few
> days).  This allows to significantly speedup LOAD_GLOBAL and
> LOAD_METHOD opcodes, to the point, where they don't require
> any dict lookups at all.  Some macro-benchmarks (such as
> chameleon_v2) demonstrate impressive ~10% performance boost.
>
> I rely on your dict->ma_version to implement cache invalidation.
>
> However, besides guarding against version change, I also want
> to guard against the dict being swapped for another dict, to
> avoid situations like this:
>
>
> def foo():
> print(bar)
>
> exec(foo.__code__, {'bar': 1}, {})
> exec(foo.__code__, {'bar': 2}, {})
>
>
> What I propose is to add a pointer "ma_extra" (same 64bits),
> which will be set to NULL for most dict instances (instead of
> ma_version).  "ma_extra" can then point to a struct that has a
> globally unique dict ID (uint64), and a version tag (unit64).
> A macro like PyDict_GET_ID and PyDict_GET_VERSION could then
> efficiently fetch the version/unique ID of the dict for guards.
>
> "ma_extra" would also make it easier for us to extend dicts
> in the future.
>
> Yury
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/fijall%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 509: Add a private version to dict

[Brett Cannon]

On Wed, 20 Jan 2016 at 10:11 Yury Selivanov  wrote:

> On 2016-01-18 5:43 PM, Victor Stinner wrote:
> > Is someone opposed to this PEP 509?
> >
> > The main complain was the change on the public Python API, but the PEP
> > doesn't change the Python API anymore.
> >
> > I'm not aware of any remaining issue on this PEP.
>
> Victor,
>
> I've been experimenting with the PEP to implement a per-opcode
> cache in ceval loop (I'll share my progress on that in a few
> days).  This allows to significantly speedup LOAD_GLOBAL and
> LOAD_METHOD opcodes, to the point, where they don't require
> any dict lookups at all.  Some macro-benchmarks (such as
> chameleon_v2) demonstrate impressive ~10% performance boost.
>

Ooh, now my brain is trying to figure out the design of the cache. :)


>
> I rely on your dict->ma_version to implement cache invalidation.
>
> However, besides guarding against version change, I also want
> to guard against the dict being swapped for another dict, to
> avoid situations like this:
>
>
>  def foo():
>  print(bar)
>
>  exec(foo.__code__, {'bar': 1}, {})
>  exec(foo.__code__, {'bar': 2}, {})
>
>
> What I propose is to add a pointer "ma_extra" (same 64bits),
> which will be set to NULL for most dict instances (instead of
> ma_version).  "ma_extra" can then point to a struct that has a
> globally unique dict ID (uint64), and a version tag (unit64).
> A macro like PyDict_GET_ID and PyDict_GET_VERSION could then
> efficiently fetch the version/unique ID of the dict for guards.
>
> "ma_extra" would also make it easier for us to extend dicts
> in the future.
>

Why can't you simply use the id of the dict object as the globally unique
dict ID? It's already globally unique amongst all Python objects which
makes it inherently unique amongst dicts.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 509: Add a private version to dict

[Maciej Fijalkowski]

On Wed, Jan 20, 2016 at 7:22 PM, Brett Cannon  wrote:
>
>
> On Wed, 20 Jan 2016 at 10:11 Yury Selivanov  wrote:
>>
>> On 2016-01-18 5:43 PM, Victor Stinner wrote:
>> > Is someone opposed to this PEP 509?
>> >
>> > The main complain was the change on the public Python API, but the PEP
>> > doesn't change the Python API anymore.
>> >
>> > I'm not aware of any remaining issue on this PEP.
>>
>> Victor,
>>
>> I've been experimenting with the PEP to implement a per-opcode
>> cache in ceval loop (I'll share my progress on that in a few
>> days).  This allows to significantly speedup LOAD_GLOBAL and
>> LOAD_METHOD opcodes, to the point, where they don't require
>> any dict lookups at all.  Some macro-benchmarks (such as
>> chameleon_v2) demonstrate impressive ~10% performance boost.
>
>
> Ooh, now my brain is trying to figure out the design of the cache. :)
>
>>
>>
>> I rely on your dict->ma_version to implement cache invalidation.
>>
>> However, besides guarding against version change, I also want
>> to guard against the dict being swapped for another dict, to
>> avoid situations like this:
>>
>>
>>  def foo():
>>  print(bar)
>>
>>  exec(foo.__code__, {'bar': 1}, {})
>>  exec(foo.__code__, {'bar': 2}, {})
>>
>>
>> What I propose is to add a pointer "ma_extra" (same 64bits),
>> which will be set to NULL for most dict instances (instead of
>> ma_version).  "ma_extra" can then point to a struct that has a
>> globally unique dict ID (uint64), and a version tag (unit64).
>> A macro like PyDict_GET_ID and PyDict_GET_VERSION could then
>> efficiently fetch the version/unique ID of the dict for guards.
>>
>> "ma_extra" would also make it easier for us to extend dicts
>> in the future.
>
>
> Why can't you simply use the id of the dict object as the globally unique
> dict ID? It's already globally unique amongst all Python objects which makes
> it inherently unique amongst dicts.
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/fijall%40gmail.com
>

Brett, you need two things - the ID of the dict and the version tag.
What we do in pypy is we have a small object (called, surprisingly,
VersionTag()) and we use the ID of that. That way you can change the
version id of an existing dict and have only one field.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Devguide: Add a table summarizing status of Python branches

[Terry Reedy]

On 1/20/2016 12:40 PM, Victor Stinner wrote:

Hi,

I proposed a patch for the devguide to give the current status of all
Python branches: active, bugfix, security only, end-of-line, with
their end-of-life when applicable (past date or scheduled date)
http://bugs.python.org/issue26165

What do you think? Does it look correct?


I thought end-of-life was 5 years after initial release, not 5 years 
after last bugfix.  That would put eol for 3.4 in Feb 2019, I believe.



We will have to update this table each time that the status of a
branch change. Hopefully, it's not a common event, so it will not
require a lot of work for release managers :-)


I believe there is some text describing current releases somewhere that 
also needs to be changed.  The release pep or scripts should have a 
reminder in the sections about the transitions.


--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 509: Add a private version to dict

[Yury Selivanov]

On 2016-01-20 1:15 PM, Maciej Fijalkowski wrote:

[..]

Anyway, I would strongly suggest getting some benchmarks done and
showing performance benefits first, because you don't want PEPs to be
final when you don't exactly know the details.


I agree 100%.

Yury

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Update PEP 7 to require curly braces in C

[Terry Reedy]

On 1/20/2016 12:45 PM, Brett Cannon wrote:



On Tue, 19 Jan 2016 at 19:33 Martin Panter mailto:vadmium%2...@gmail.com>> wrote:

On 19 January 2016 at 20:12, Brett Cannon mailto:br...@python.org>> wrote:
 > Here is a proposed update:
 >
 > diff -r 633f51d10a67 pep-0007.txt
 > --- a/pep-0007.txt Mon Jan 18 10:52:57 2016 -0800
 > +++ b/pep-0007.txt Tue Jan 19 12:11:44 2016 -0800
 > @@ -75,9 +75,9 @@
 >}
 >
 >  * Code structure: one space between keywords like ``if``,
``for`` and
 > -  the following left paren; no spaces inside the paren; braces
may be
 > -  omitted where C permits but when present, they should be formatted
 > -  as shown::
 > +  the following left paren; no spaces inside the paren; braces are
 > +  strongly preferred but may be omitted where C permits, and they
 > +  should be formatted as shown::
 >
 >if (mro != NULL) {
 >...

This change seems to be accidentally smuggled in, in the guise of a
PEP 512 update :)


Darn, sorry about that; forgot I had that change sitting in my peps
checkout. I'll revert it when I get home (unless the change is actually
acceptable to Guido).


I thought that the above was your intentional compromise change given 
the range of opinions ;-).


--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 509: Add a private version to dict

[Yury Selivanov]

Brett,

On 2016-01-20 1:22 PM, Brett Cannon wrote:



On Wed, 20 Jan 2016 at 10:11 Yury Selivanov > wrote:


On 2016-01-18 5:43 PM, Victor Stinner wrote:
> Is someone opposed to this PEP 509?
>
> The main complain was the change on the public Python API, but
the PEP
> doesn't change the Python API anymore.
>
> I'm not aware of any remaining issue on this PEP.

Victor,

I've been experimenting with the PEP to implement a per-opcode
cache in ceval loop (I'll share my progress on that in a few
days).  This allows to significantly speedup LOAD_GLOBAL and
LOAD_METHOD opcodes, to the point, where they don't require
any dict lookups at all.  Some macro-benchmarks (such as
chameleon_v2) demonstrate impressive ~10% performance boost.


Ooh, now my brain is trying to figure out the design of the cache. :)


Yeah, it's tricky.  I'll need some time to draft a comprehensible
overview.  And I want to implement a couple more optimizations and
benchmark it better.

BTW, I've some updates (html5lib benchmark for py3, new benchmarks
for calling C methods, and I want to port some PyPy benchmakrs)
to the benchmarks suite.  Should I just commit them, or should I
use bugs.python.org?



I rely on your dict->ma_version to implement cache invalidation.

However, besides guarding against version change, I also want
to guard against the dict being swapped for another dict, to
avoid situations like this:


 def foo():
 print(bar)

 exec(foo.__code__, {'bar': 1}, {})
 exec(foo.__code__, {'bar': 2}, {})


What I propose is to add a pointer "ma_extra" (same 64bits),
which will be set to NULL for most dict instances (instead of
ma_version).  "ma_extra" can then point to a struct that has a
globally unique dict ID (uint64), and a version tag (unit64).
A macro like PyDict_GET_ID and PyDict_GET_VERSION could then
efficiently fetch the version/unique ID of the dict for guards.

"ma_extra" would also make it easier for us to extend dicts
in the future.


Why can't you simply use the id of the dict object as the globally 
unique dict ID? It's already globally unique amongst all Python 
objects which makes it inherently unique amongst dicts.


We have a freelist for dicts -- so if the dict dies, there
could be a new dict in its place, with the same ma_version.

While the probability of such hiccups is low, we still have
to account for it.

Yury

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 509: Add a private version to dict

[Yury Selivanov]

On 2016-01-20 1:36 PM, Maciej Fijalkowski wrote:

On Wed, Jan 20, 2016 at 7:22 PM, Brett Cannon  wrote:


On Wed, 20 Jan 2016 at 10:11 Yury Selivanov  wrote:

[..]

"ma_extra" would also make it easier for us to extend dicts
in the future.


Why can't you simply use the id of the dict object as the globally unique
dict ID? It's already globally unique amongst all Python objects which makes
it inherently unique amongst dicts.



Brett, you need two things - the ID of the dict and the version tag.
What we do in pypy is we have a small object (called, surprisingly,
VersionTag()) and we use the ID of that. That way you can change the
version id of an existing dict and have only one field.



Yeah, that's essentially what I propose with ma_extra.

Yury
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 509: Add a private version to dict

[Maciej Fijalkowski]

On Wed, Jan 20, 2016 at 8:00 PM, Yury Selivanov  wrote:
>
>
> On 2016-01-20 1:36 PM, Maciej Fijalkowski wrote:
>>
>> On Wed, Jan 20, 2016 at 7:22 PM, Brett Cannon  wrote:
>>>
>>>
>>> On Wed, 20 Jan 2016 at 10:11 Yury Selivanov 
>>> wrote:
>
> [..]

 "ma_extra" would also make it easier for us to extend dicts
 in the future.
>>>
>>>
>>> Why can't you simply use the id of the dict object as the globally unique
>>> dict ID? It's already globally unique amongst all Python objects which
>>> makes
>>> it inherently unique amongst dicts.
>>>
>>>
>> Brett, you need two things - the ID of the dict and the version tag.
>> What we do in pypy is we have a small object (called, surprisingly,
>> VersionTag()) and we use the ID of that. That way you can change the
>> version id of an existing dict and have only one field.
>
>
>
> Yeah, that's essentially what I propose with ma_extra.
>
> Yury

The trick is we use only one field :-)

you're proposing to have both fields - version tag and dict id. Why
not just use the id of the object (without any fields)?
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 509: Add a private version to dict

[Yury Selivanov]

On 2016-01-20 2:02 PM, Maciej Fijalkowski wrote:

On Wed, Jan 20, 2016 at 8:00 PM, Yury Selivanov  wrote:


[..]

Brett, you need two things - the ID of the dict and the version tag.
What we do in pypy is we have a small object (called, surprisingly,
VersionTag()) and we use the ID of that. That way you can change the
version id of an existing dict and have only one field.

Yeah, that's essentially what I propose with ma_extra.

Yury

The trick is we use only one field :-)

you're proposing to have both fields - version tag and dict id. Why
not just use the id of the object (without any fields)?


What if your old dict is GCed, its "VersionTag()" (1) object is
freed, and you have a new dict, for which a new "VersionTag()" (2)
object happens to be allocated at the same address as (1)?

Yury

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 509: Add a private version to dict

[Maciej Fijalkowski]

On Wed, Jan 20, 2016 at 8:08 PM, Yury Selivanov  wrote:
>
> On 2016-01-20 2:02 PM, Maciej Fijalkowski wrote:
>>
>> On Wed, Jan 20, 2016 at 8:00 PM, Yury Selivanov 
>> wrote:
>>
> [..]

 Brett, you need two things - the ID of the dict and the version tag.
 What we do in pypy is we have a small object (called, surprisingly,
 VersionTag()) and we use the ID of that. That way you can change the
 version id of an existing dict and have only one field.
>>>
>>> Yeah, that's essentially what I propose with ma_extra.
>>>
>>> Yury
>>
>> The trick is we use only one field :-)
>>
>> you're proposing to have both fields - version tag and dict id. Why
>> not just use the id of the object (without any fields)?
>
>
> What if your old dict is GCed, its "VersionTag()" (1) object is
> freed, and you have a new dict, for which a new "VersionTag()" (2)
> object happens to be allocated at the same address as (1)?
>
> Yury
>

You don't free a version tag that's stored in the guard. You store the
object and not id
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 509: Add a private version to dict

[Yury Selivanov]

On 2016-01-20 2:09 PM, Maciej Fijalkowski wrote:

>

You don't free a version tag that's stored in the guard. You store the
object and not id


Ah, got it.  Although for my current cache design it would be
more memory efficient to use the dict itself to store its own
unique id and tag, hence my "ma_extra" proposal.  In any case,
the current "ma_version" proposal is flawed :(

Yury
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 509: Add a private version to dict

[Maciej Fijalkowski]

there is also the problem that you don't want it on all dicts. So
having two extra words is more to pay than having extra objects (also,
comparison is cheaper for guards)

On Wed, Jan 20, 2016 at 8:23 PM, Yury Selivanov  wrote:
>
>
> On 2016-01-20 2:09 PM, Maciej Fijalkowski wrote:
>>>
>>> >
>>
>> You don't free a version tag that's stored in the guard. You store the
>> object and not id
>
>
> Ah, got it.  Although for my current cache design it would be
> more memory efficient to use the dict itself to store its own
> unique id and tag, hence my "ma_extra" proposal.  In any case,
> the current "ma_version" proposal is flawed :(
>
> Yury
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 509: Add a private version to dict

[Glenn Linderman]

On 1/20/2016 10:36 AM, Maciej Fijalkowski wrote:

Why can't you simply use the id of the dict object as the globally unique
>dict ID? It's already globally unique amongst all Python objects which makes
>it inherently unique amongst dicts.
>
>___
>Python-Dev mailing list
>Python-Dev@python.org
>https://mail.python.org/mailman/listinfo/python-dev
>Unsubscribe:
>https://mail.python.org/mailman/options/python-dev/fijall%40gmail.com
>

Brett, you need two things - the ID of the dict and the version tag.
What we do in pypy is we have a small object (called, surprisingly,
VersionTag()) and we use the ID of that. That way you can change the
version id of an existing dict and have only one field.
For the reuse case, can't you simply keep the ma_version "live" in dict 
items on the free list, rather than starting over at (presumably) 0 ?  
Then if the dict is reused, it bumps the ma_version, and the fallback 
code goes on with (presumably) relocating the original dict (oops, it's 
gone), and dealing with the fallout.


Then you can use the regular dict id as the globally unique dict id?  
And only need the one uint64, rather than a separately allocated extra 
pair of uint64?
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Update PEP 7 to require curly braces in C

[Brett Cannon]

On Wed, 20 Jan 2016 at 10:45 Terry Reedy  wrote:

> On 1/20/2016 12:45 PM, Brett Cannon wrote:
> >
> >
> > On Tue, 19 Jan 2016 at 19:33 Martin Panter  > > wrote:
> >
> > On 19 January 2016 at 20:12, Brett Cannon  > > wrote:
> >  > Here is a proposed update:
> >  >
> >  > diff -r 633f51d10a67 pep-0007.txt
> >  > --- a/pep-0007.txt Mon Jan 18 10:52:57 2016 -0800
> >  > +++ b/pep-0007.txt Tue Jan 19 12:11:44 2016 -0800
> >  > @@ -75,9 +75,9 @@
> >  >}
> >  >
> >  >  * Code structure: one space between keywords like ``if``,
> > ``for`` and
> >  > -  the following left paren; no spaces inside the paren; braces
> > may be
> >  > -  omitted where C permits but when present, they should be
> formatted
> >  > -  as shown::
> >  > +  the following left paren; no spaces inside the paren; braces
> are
> >  > +  strongly preferred but may be omitted where C permits, and they
> >  > +  should be formatted as shown::
> >  >
> >  >if (mro != NULL) {
> >  >...
> >
> > This change seems to be accidentally smuggled in, in the guise of a
> > PEP 512 update :)
> >
> >
> > Darn, sorry about that; forgot I had that change sitting in my peps
> > checkout. I'll revert it when I get home (unless the change is actually
> > acceptable to Guido).
>
> I thought that the above was your intentional compromise change given
> the range of opinions ;-).
>

It is, but Guido is the author of PEP 7 and so I didn't want to check in
the change without his approval first.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Devguide: Add a table summarizing status of Python branches

[Brett Cannon]

On Wed, 20 Jan 2016 at 10:40 Terry Reedy  wrote:

> On 1/20/2016 12:40 PM, Victor Stinner wrote:
> > Hi,
> >
> > I proposed a patch for the devguide to give the current status of all
> > Python branches: active, bugfix, security only, end-of-line, with
> > their end-of-life when applicable (past date or scheduled date)
> > http://bugs.python.org/issue26165
> >
> > What do you think? Does it look correct?
>
> I thought end-of-life was 5 years after initial release, not 5 years
> after last bugfix.


It is, which is why I requested the first release date be a column.


>   That would put eol for 3.4 in Feb 2019, I believe.
>
> > We will have to update this table each time that the status of a
> > branch change. Hopefully, it's not a common event, so it will not
> > require a lot of work for release managers :-)
>
> I believe there is some text describing current releases somewhere that
> also needs to be changed.  The release pep or scripts should have a
> reminder in the sections about the transitions.
>

PEP 101 would need a tweak to remind the RM to update the devguide.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 509: Add a private version to dict

[Brett Cannon]

On Wed, 20 Jan 2016 at 10:46 Yury Selivanov  wrote:

> Brett,
>
> On 2016-01-20 1:22 PM, Brett Cannon wrote:
> >
> >
> > On Wed, 20 Jan 2016 at 10:11 Yury Selivanov  > > wrote:
> >
> > On 2016-01-18 5:43 PM, Victor Stinner wrote:
> > > Is someone opposed to this PEP 509?
> > >
> > > The main complain was the change on the public Python API, but
> > the PEP
> > > doesn't change the Python API anymore.
> > >
> > > I'm not aware of any remaining issue on this PEP.
> >
> > Victor,
> >
> > I've been experimenting with the PEP to implement a per-opcode
> > cache in ceval loop (I'll share my progress on that in a few
> > days).  This allows to significantly speedup LOAD_GLOBAL and
> > LOAD_METHOD opcodes, to the point, where they don't require
> > any dict lookups at all.  Some macro-benchmarks (such as
> > chameleon_v2) demonstrate impressive ~10% performance boost.
> >
> >
> > Ooh, now my brain is trying to figure out the design of the cache. :)
>
> Yeah, it's tricky.  I'll need some time to draft a comprehensible
> overview.  And I want to implement a couple more optimizations and
> benchmark it better.
>
> BTW, I've some updates (html5lib benchmark for py3, new benchmarks
> for calling C methods, and I want to port some PyPy benchmakrs)
> to the benchmarks suite.  Should I just commit them, or should I
> use bugs.python.org?
>

I actually emailed speed@ to see if people were interested in finally
sitting down with all the various VM implementations at PyCon and trying to
come up with a reasonable base set of benchmarks that better reflect modern
Python usage, but I never heard back.

Anyway, issues on bugs.python.org are probably best to talk about new
benchmarks before adding them (fixes and updates to pre-existing benchmarks
can just go in).


>
> >
> > I rely on your dict->ma_version to implement cache invalidation.
> >
> > However, besides guarding against version change, I also want
> > to guard against the dict being swapped for another dict, to
> > avoid situations like this:
> >
> >
> >  def foo():
> >  print(bar)
> >
> >  exec(foo.__code__, {'bar': 1}, {})
> >  exec(foo.__code__, {'bar': 2}, {})
> >
> >
> > What I propose is to add a pointer "ma_extra" (same 64bits),
> > which will be set to NULL for most dict instances (instead of
> > ma_version).  "ma_extra" can then point to a struct that has a
> > globally unique dict ID (uint64), and a version tag (unit64).
> > A macro like PyDict_GET_ID and PyDict_GET_VERSION could then
> > efficiently fetch the version/unique ID of the dict for guards.
> >
> > "ma_extra" would also make it easier for us to extend dicts
> > in the future.
> >
> >
> > Why can't you simply use the id of the dict object as the globally
> > unique dict ID? It's already globally unique amongst all Python
> > objects which makes it inherently unique amongst dicts.
>
> We have a freelist for dicts -- so if the dict dies, there
> could be a new dict in its place, with the same ma_version.
>

Ah, I figured it would be too simple to use something we already had.


>
> While the probability of such hiccups is low, we still have
> to account for it.
>

Yep.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 509: Add a private version to dict

[Yury Selivanov]

On 2016-01-20 2:45 PM, Glenn Linderman wrote:
For the reuse case, can't you simply keep the ma_version "live" in 
dict items on the free list, rather than starting over at (presumably) 
0 ?  Then if the dict is reused, it bumps the ma_version, and the 
fallback code goes on with (presumably) relocating the original dict 
(oops, it's gone), and dealing with the fallout.


Not all dicts are created from a freelist, and not all dicts go to the 
freelist when they are GCed.


You still can have this situation:

- dict "A" is used as f_locals for a frame, its ma_version is set to X
- dict "A" is GCed, but the freelist is full, so it's just freed
- after a while, you call the code object, a new dict "B" is allocated 
with malloc (since now the freelist happens to be empty) for f_locals
- it happens that "B" is allocated where "A" was, and its ma_version 
happens to be X by an accident




Then you can use the regular dict id as the globally unique dict id?  
And only need the one uint64, rather than a separately allocated extra 
pair of uint64?


In my design only namespace dicts will have a non-NULL ma_extra, which 
means that only a fraction of dicts will actually have a separated pair 
of uint64s.


I think that we should either use one global ma_version (as Maciej 
suggested) or ma_extra, as it gives more flexibility for us to extend 
dicts in the future.


A global (shared between all dicts) unit64 ma_version is actually quite 
reliable -- if a program does 1,000,000 dict modifications per second, 
it would take it 600,000 years till wrap-around.


Yury
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 509: Add a private version to dict

[Brett Cannon]

On Wed, 20 Jan 2016 at 12:27 Yury Selivanov  wrote:

>
>
> On 2016-01-20 2:45 PM, Glenn Linderman wrote:
> > For the reuse case, can't you simply keep the ma_version "live" in
> > dict items on the free list, rather than starting over at (presumably)
> > 0 ?  Then if the dict is reused, it bumps the ma_version, and the
> > fallback code goes on with (presumably) relocating the original dict
> > (oops, it's gone), and dealing with the fallout.
>
> Not all dicts are created from a freelist, and not all dicts go to the
> freelist when they are GCed.
>
> You still can have this situation:
>
> - dict "A" is used as f_locals for a frame, its ma_version is set to X
> - dict "A" is GCed, but the freelist is full, so it's just freed
> - after a while, you call the code object, a new dict "B" is allocated
> with malloc (since now the freelist happens to be empty) for f_locals
> - it happens that "B" is allocated where "A" was, and its ma_version
> happens to be X by an accident
>
> >
> > Then you can use the regular dict id as the globally unique dict id?
> > And only need the one uint64, rather than a separately allocated extra
> > pair of uint64?
>
> In my design only namespace dicts will have a non-NULL ma_extra, which
> means that only a fraction of dicts will actually have a separated pair
> of uint64s.
>
> I think that we should either use one global ma_version (as Maciej
> suggested) or ma_extra, as it gives more flexibility for us to extend
> dicts in the future.
>
> A global (shared between all dicts) unit64 ma_version is actually quite
> reliable -- if a program does 1,000,000 dict modifications per second,
> it would take it 600,000 years till wrap-around.
>

Since you're going to need to hold the GIL for the modifications there
won't be any locking or contention problems, so it sounds like the global
value is the best since that's simple, uses the least amount of memory, and
will be easiest to use as a modification check since that will be a simple
uint64 comparison instead of comparing a GUID + version.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 509: Add a private version to dict

[Mark Shannon]

On 11/01/16 16:49, Victor Stinner wrote:

Hi,

After a first round on python-ideas, here is the second version of my
PEP. The main changes since the first version are that the dictionary
version is no more exposed at the Python level and the field type now
also has a size of 64-bit on 32-bit platforms.

The PEP is part of a serie of 3 PEP adding an API to implement a
static Python optimizer specializing functions with guards. The second
PEP is currently discussed on python-ideas and I'm still working on
the third PEP.


If anyone wants to experiment (at the C, not Python, level) with dict 
versioning to optimise load-global/builtins, then you can do so without 
adding a version number.


A "version" can created by splitting the dict with "make_keys_shared" 
and then making the keys-object immutable by setting "dk_usable" to zero.
This means that any change to the keys will force a keys-object change, 
but changes to the values will not.

For many optimisations, this is want you want.

Using this trick:
To read a global, check that the keys is the expected keys and read the 
value straight out of the values array at the known index.


To read a builtins, check that the module keys is the expected keys and 
thus cannot shadow the builtins, then read the builtins as above.


I don't know how much help this will be for a static optimiser, but it 
could work well for a dynamic optimiser. I used this optimisation in 
HotPy for optimising object attribute lookups.



Cheers,
Mark.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Devguide: Add a table summarizing status of Python branches

[Victor Stinner]

I pushed my table, it will be online in a few hours (I don't know when
the devguide is recompiled?):
http://docs.python.org/devguide/triaging.html#generating-special-links-in-a-comment

By the way, it would be super cool to rebuild the PEPs with a
post-commit hook server-side, rather than having to wait the crontab
which requires to wait ~30 minutes (1h? I don't know exactly).

2016-01-20 21:20 GMT+01:00 Brett Cannon :
> It is, which is why I requested the first release date be a column.

I added a Scheduled column with a link to the Release Schedule PEP of
each version. I also added a column with the date of the first date. I
added 5 years to estimate the end-of-line. I used the same month and
same date, with a comment above explaining that the release manager is
free to adujst the end-of-line date.

Thanks for the feedback.

> PEP 101 would need a tweak to remind the RM to update the devguide.

Can someone please mention this table in the PEP

Victor
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 509: Add a private version to dict

[Glenn Linderman]

On 1/20/2016 12:50 PM, Brett Cannon wrote:


A global (shared between all dicts) unit64 ma_version is actually
quite
reliable -- if a program does 1,000,000 dict modifications per second,
it would take it 600,000 years till wrap-around.



But would invalidate everything, instead of just a fraction of things, 
on every update to anything that is monitored...
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 509: Add a private version to dict

[Greg Ewing]

Yury Selivanov wrote:

What I propose is to add a pointer "ma_extra" (same 64bits),
which will be set to NULL for most dict instances (instead of
ma_version).  "ma_extra" can then point to a struct that has a
globally unique dict ID (uint64), and a version tag (unit64).


Why not just use a single global counter for allocating
dict version tags, instead of one per dict?

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Devguide: Add a table summarizing status of Python branches

[Brett Cannon]

On Wed, 20 Jan 2016 at 13:22 Victor Stinner 
wrote:

> I pushed my table, it will be online in a few hours (I don't know when
> the devguide is recompiled?):
>
> http://docs.python.org/devguide/triaging.html#generating-special-links-in-a-comment
>
> By the way, it would be super cool to rebuild the PEPs with a
> post-commit hook server-side, rather than having to wait the crontab
> which requires to wait ~30 minutes (1h? I don't know exactly).
>

This is a proposed optional, future feature leading from moving to GitHub:
https://www.python.org/dev/peps/pep-0512/#web-hooks-for-re-generating-web-content

-Brett
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Code formatter bot

[francismb]

Thanks again to all persons that commented so far.

> what's your opinion about a code-formatter bot for cpython.
> Pros, Cons, where could be applicable (new commits, new workflow, it
> doesn't make sense), ...
> 
> 
> - At least it should follow PEP 7 ;-)
> - ...

There seems to be too much implicit information on the lines above.
Sorry for that. I'll try to clarify.

>From my point of view (not a core-dev) the reviews seem to be one
of the bottlenecks to the commit throughput, and I noticed on the
other PEP 7 thread that time is taken to review such, IMHO, (and as
Andrew also noted) trivialities. Thus the basic idea was to get that
noise away from the reviews, somehow (better upfront, but why not
after, accidental PEP 7 noise commits can happen). Well, people
should first agree on that PEP and then some automatic could come.

Please notice that the interaction is not just: core-dev committing
to a repo or a bot committing to a repo but external-contributor that
tries to minimize review iterations. I have no problem with some
process (call it now a bot or script) that just changes a patch/file to
reduce that cycle (but it could, run on all the workflow points you
mentioned, plus on the PR-site as a kind of an advisor/mentor).


Regards,
francis
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Devguide: Add a table summarizing status of Python branches

[Victor Stinner]

2016-01-20 23:01 GMT+01:00 Brett Cannon :
> This is a proposed optional, future feature leading from moving to GitHub:
> https://www.python.org/dev/peps/pep-0512/#web-hooks-for-re-generating-web-content

I'm using the free service ReadTheDocs.org and it's really impressive
how fast it is to update the HTML page after a push. It's usually less
than 10 seconds.

Victor
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Update PEP 7 to require curly braces in C

[Guido van Rossum]

The wording is totally fine! You might still want to revert it and
re-commit it so it doesn't look like a mistake when reviewing the log.

BTW When can we start using git for the peps repo?

On Wed, Jan 20, 2016 at 12:18 PM, Brett Cannon  wrote:

>
>
> On Wed, 20 Jan 2016 at 10:45 Terry Reedy  wrote:
>
>> On 1/20/2016 12:45 PM, Brett Cannon wrote:
>> >
>> >
>> > On Tue, 19 Jan 2016 at 19:33 Martin Panter > > > wrote:
>> >
>> > On 19 January 2016 at 20:12, Brett Cannon > > > wrote:
>> >  > Here is a proposed update:
>> >  >
>> >  > diff -r 633f51d10a67 pep-0007.txt
>> >  > --- a/pep-0007.txt Mon Jan 18 10:52:57 2016 -0800
>> >  > +++ b/pep-0007.txt Tue Jan 19 12:11:44 2016 -0800
>> >  > @@ -75,9 +75,9 @@
>> >  >}
>> >  >
>> >  >  * Code structure: one space between keywords like ``if``,
>> > ``for`` and
>> >  > -  the following left paren; no spaces inside the paren; braces
>> > may be
>> >  > -  omitted where C permits but when present, they should be
>> formatted
>> >  > -  as shown::
>> >  > +  the following left paren; no spaces inside the paren; braces
>> are
>> >  > +  strongly preferred but may be omitted where C permits, and
>> they
>> >  > +  should be formatted as shown::
>> >  >
>> >  >if (mro != NULL) {
>> >  >...
>> >
>> > This change seems to be accidentally smuggled in, in the guise of a
>> > PEP 512 update :)
>> >
>> >
>> > Darn, sorry about that; forgot I had that change sitting in my peps
>> > checkout. I'll revert it when I get home (unless the change is actually
>> > acceptable to Guido).
>>
>> I thought that the above was your intentional compromise change given
>> the range of opinions ;-).
>>
>
> It is, but Guido is the author of PEP 7 and so I didn't want to check in
> the change without his approval first.
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>
>


-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Update PEP 7 to require curly braces in C

[Brett Cannon]

On Wed, 20 Jan 2016 at 14:31 Guido van Rossum  wrote:

> The wording is totally fine! You might still want to revert it and
> re-commit it so it doesn't look like a mistake when reviewing the log.
>

Sure thing!


>
> BTW When can we start using git for the peps repo?
>

Depends on how fast the parts covered in
https://www.python.org/dev/peps/pep-0512/#requirements-for-code-only-repositories
 and
https://www.python.org/dev/peps/pep-0512/#requirements-for-web-related-repositories
takes.
My hope is before PyCon US (although if we choose to not enforce the CLA on
PEP contributions then it could happen even faster).

-Brett


>
> On Wed, Jan 20, 2016 at 12:18 PM, Brett Cannon  wrote:
>
>>
>>
>> On Wed, 20 Jan 2016 at 10:45 Terry Reedy  wrote:
>>
>>> On 1/20/2016 12:45 PM, Brett Cannon wrote:
>>> >
>>> >
>>> > On Tue, 19 Jan 2016 at 19:33 Martin Panter >> > > wrote:
>>> >
>>> > On 19 January 2016 at 20:12, Brett Cannon >> > > wrote:
>>> >  > Here is a proposed update:
>>> >  >
>>> >  > diff -r 633f51d10a67 pep-0007.txt
>>> >  > --- a/pep-0007.txt Mon Jan 18 10:52:57 2016 -0800
>>> >  > +++ b/pep-0007.txt Tue Jan 19 12:11:44 2016 -0800
>>> >  > @@ -75,9 +75,9 @@
>>> >  >}
>>> >  >
>>> >  >  * Code structure: one space between keywords like ``if``,
>>> > ``for`` and
>>> >  > -  the following left paren; no spaces inside the paren; braces
>>> > may be
>>> >  > -  omitted where C permits but when present, they should be
>>> formatted
>>> >  > -  as shown::
>>> >  > +  the following left paren; no spaces inside the paren; braces
>>> are
>>> >  > +  strongly preferred but may be omitted where C permits, and
>>> they
>>> >  > +  should be formatted as shown::
>>> >  >
>>> >  >if (mro != NULL) {
>>> >  >...
>>> >
>>> > This change seems to be accidentally smuggled in, in the guise of a
>>> > PEP 512 update :)
>>> >
>>> >
>>> > Darn, sorry about that; forgot I had that change sitting in my peps
>>> > checkout. I'll revert it when I get home (unless the change is actually
>>> > acceptable to Guido).
>>>
>>> I thought that the above was your intentional compromise change given
>>> the range of opinions ;-).
>>>
>>
>> It is, but Guido is the author of PEP 7 and so I didn't want to check in
>> the change without his approval first.
>>
>> ___
>> Python-Dev mailing list
>> Python-Dev@python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>>
> Unsubscribe:
>> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>>
>>
>
>
> --
> --Guido van Rossum (python.org/~guido)
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 509: Add a private version to dict

[Victor Stinner]

Hi,

2016-01-20 22:18 GMT+01:00 Glenn Linderman :
> On 1/20/2016 12:50 PM, Brett Cannon wrote:
>>
>> A global (shared between all dicts) unit64 ma_version is actually quite
>> reliable -- if a program does 1,000,000 dict modifications per second,
>> it would take it 600,000 years till wrap-around.

I think that Yury found a bug in FAT Python. I didn't test the case
when the builtins dictionary is replaced after the definition of the
function. To be more concrete: when a function is executed in a
different namespace using exec(code, namespace). That's why I like the
PEP process, it helps to find all issues before going too far :-)

I like the idea of global counter for dictionary versions. It means
that the dictionary constructor increases this counter instead of
always starting to 0.

FYI a fat.GuardDict keeps a strong reference to the dictionary. For
some guards, I hesitated to store the object identifier and/or using a
weak reference. An object identifier is not reliable because the
object can be destroyed and a new object, completly different, or of
the same type, can get the same identifier.

> But would invalidate everything, instead of just a fraction of things, on
> every update to anything that is monitored...

I don't understand this point.

In short, the guard only has to compare two 64 bit integers in the
fast-path, when nothing changed. For a namespace, it means that no
value was replaced in this namespace.

If a different namespace is modified, the version of the watched
namespace does not change, so we are still in the fast-path.

If a value is replaced in the watched namespace, but not the watched
variable, we have to take a slow-path, hopefully only once.

The worst case is when a value different than the watched value is
modified between each guard check. In this case, we always need a dict
lookup. An heuristic can be chosen to decide to give up after N tries.
Currently, fat.GuardDict always retries.

Victor
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 509: Add a private version to dict

[Brett Cannon]

On Wed, 20 Jan 2016 at 15:46 Victor Stinner 
wrote:

> Hi,
>
> 2016-01-20 22:18 GMT+01:00 Glenn Linderman :
> > On 1/20/2016 12:50 PM, Brett Cannon wrote:
> >>
> >> A global (shared between all dicts) unit64 ma_version is actually quite
> >> reliable -- if a program does 1,000,000 dict modifications per second,
> >> it would take it 600,000 years till wrap-around.
>
> I think that Yury found a bug in FAT Python. I didn't test the case
> when the builtins dictionary is replaced after the definition of the
> function. To be more concrete: when a function is executed in a
> different namespace using exec(code, namespace). That's why I like the
> PEP process, it helps to find all issues before going too far :-)
>
> I like the idea of global counter for dictionary versions. It means
> that the dictionary constructor increases this counter instead of
> always starting to 0.
>
> FYI a fat.GuardDict keeps a strong reference to the dictionary. For
> some guards, I hesitated to store the object identifier and/or using a
> weak reference. An object identifier is not reliable because the
> object can be destroyed and a new object, completly different, or of
> the same type, can get the same identifier.
>
> > But would invalidate everything, instead of just a fraction of things, on
> > every update to anything that is monitored...
>
> I don't understand this point.
>

I think Glenn was assuming we had a single, global version # that all dicts
shared *without* having a per-dict version ID. The key thing here is that
we have a global counter that tracks the number of mutations for *all*
dictionaries
but whose value we store as a *per-dictionary* value. That ends up making
the version ID inherently both a token representing the state of any dict
but also the uniqueness of the dict since no two dictionaries will ever
have the same version ID.


>
> In short, the guard only has to compare two 64 bit integers in the
> fast-path, when nothing changed. For a namespace, it means that no
> value was replaced in this namespace.
>
> If a different namespace is modified, the version of the watched
> namespace does not change, so we are still in the fast-path.
>
> If a value is replaced in the watched namespace, but not the watched
> variable, we have to take a slow-path, hopefully only once.
>
> The worst case is when a value different than the watched value is
> modified between each guard check. In this case, we always need a dict
> lookup. An heuristic can be chosen to decide to give up after N tries.
> Currently, fat.GuardDict always retries.
>

Does "retries" mean "check if the value really changed, and if it hasn't
then just update the version ID the guard checks"?
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 509: Add a private version to dict

[Glenn Linderman]

On 1/20/2016 4:08 PM, Brett Cannon wrote:



On Wed, 20 Jan 2016 at 15:46 Victor Stinner > wrote:


Hi,

2016-01-20 22:18 GMT+01:00 Glenn Linderman mailto:v%2bpyt...@g.nevcal.com>>:
> On 1/20/2016 12:50 PM, Brett Cannon wrote:
>>
>> A global (shared between all dicts) unit64 ma_version is
actually quite
>> reliable -- if a program does 1,000,000 dict modifications per
second,
>> it would take it 600,000 years till wrap-around.

I think that Yury found a bug in FAT Python. I didn't test the case
when the builtins dictionary is replaced after the definition of the
function. To be more concrete: when a function is executed in a
different namespace using exec(code, namespace). That's why I like the
PEP process, it helps to find all issues before going too far :-)

I like the idea of global counter for dictionary versions. It means
that the dictionary constructor increases this counter instead of
always starting to 0.

FYI a fat.GuardDict keeps a strong reference to the dictionary. For
some guards, I hesitated to store the object identifier and/or using a
weak reference. An object identifier is not reliable because the
object can be destroyed and a new object, completly different, or of
the same type, can get the same identifier.

> But would invalidate everything, instead of just a fraction of
things, on
> every update to anything that is monitored...

I don't understand this point.


I think Glenn was assuming we had a single, global version # that all 
dicts shared *without* having a per-dict version ID. The key thing 
here is that we have a global counter that tracks the number of 
mutations for *all* dictionaries but whose value we store as a 
*per-dictionary* value. That ends up making the version ID inherently 
both a token representing the state of any dict but also the 
uniqueness of the dict since no two dictionaries will ever have the 
same version ID.


This would work. You were correct about my assumptions.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Devguide: Add a table summarizing status of Python branches

[Brett Cannon]

On Wed, 20 Jan 2016 at 14:28 Victor Stinner 
wrote:

> 2016-01-20 23:01 GMT+01:00 Brett Cannon :
> > This is a proposed optional, future feature leading from moving to
> GitHub:
> >
> https://www.python.org/dev/peps/pep-0512/#web-hooks-for-re-generating-web-content
>
> I'm using the free service ReadTheDocs.org and it's really impressive
> how fast it is to update the HTML page after a push. It's usually less
> than 10 seconds.
>

I have no idea if the way our docs are built would work on readthedocs.org,
but if it could then I would definitely vote to move our docs there and
have the PSF make a regular donation for the service.

But this is a discussion to have on core-workflow@ and not here.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Update PEP 7 to require curly braces in C

[Brett Cannon]

I just checked with Van and we should have CLAs for even PEP contributors,
so it will have to go through the same steps as the other ancillary
repositories.

On Wed, 20 Jan 2016 at 14:41 Brett Cannon  wrote:

> On Wed, 20 Jan 2016 at 14:31 Guido van Rossum  wrote:
>
>> The wording is totally fine! You might still want to revert it and
>> re-commit it so it doesn't look like a mistake when reviewing the log.
>>
>
> Sure thing!
>
>
>>
>> BTW When can we start using git for the peps repo?
>>
>
> Depends on how fast the parts covered in
> https://www.python.org/dev/peps/pep-0512/#requirements-for-code-only-repositories
>  and
> https://www.python.org/dev/peps/pep-0512/#requirements-for-web-related-repositories
>  takes.
> My hope is before PyCon US (although if we choose to not enforce the CLA on
> PEP contributions then it could happen even faster).
>
> -Brett
>
>
>>
>> On Wed, Jan 20, 2016 at 12:18 PM, Brett Cannon  wrote:
>>
>>>
>>>
>>> On Wed, 20 Jan 2016 at 10:45 Terry Reedy  wrote:
>>>
 On 1/20/2016 12:45 PM, Brett Cannon wrote:
 >
 >
 > On Tue, 19 Jan 2016 at 19:33 Martin Panter >>> > > wrote:
 >
 > On 19 January 2016 at 20:12, Brett Cannon >>> > > wrote:
 >  > Here is a proposed update:
 >  >
 >  > diff -r 633f51d10a67 pep-0007.txt
 >  > --- a/pep-0007.txt Mon Jan 18 10:52:57 2016 -0800
 >  > +++ b/pep-0007.txt Tue Jan 19 12:11:44 2016 -0800
 >  > @@ -75,9 +75,9 @@
 >  >}
 >  >
 >  >  * Code structure: one space between keywords like ``if``,
 > ``for`` and
 >  > -  the following left paren; no spaces inside the paren; braces
 > may be
 >  > -  omitted where C permits but when present, they should be
 formatted
 >  > -  as shown::
 >  > +  the following left paren; no spaces inside the paren;
 braces are
 >  > +  strongly preferred but may be omitted where C permits, and
 they
 >  > +  should be formatted as shown::
 >  >
 >  >if (mro != NULL) {
 >  >...
 >
 > This change seems to be accidentally smuggled in, in the guise of
 a
 > PEP 512 update :)
 >
 >
 > Darn, sorry about that; forgot I had that change sitting in my peps
 > checkout. I'll revert it when I get home (unless the change is
 actually
 > acceptable to Guido).

 I thought that the above was your intentional compromise change given
 the range of opinions ;-).

>>>
>>> It is, but Guido is the author of PEP 7 and so I didn't want to check in
>>> the change without his approval first.
>>>
>>> ___
>>> Python-Dev mailing list
>>> Python-Dev@python.org
>>> https://mail.python.org/mailman/listinfo/python-dev
>>>
>> Unsubscribe:
>>> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>>>
>>>
>>
>>
>> --
>> --Guido van Rossum (python.org/~guido)
>>
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 509: Add a private version to dict

[Victor Stinner]

2016-01-21 1:08 GMT+01:00 Brett Cannon :
> On Wed, 20 Jan 2016 at 15:46 Victor Stinner 
>> The worst case is when a value different than the watched value is
>> modified between each guard check. In this case, we always need a dict
>> lookup. An heuristic can be chosen to decide to give up after N tries.
>> Currently, fat.GuardDict always retries.
>
> Does "retries" mean "check if the value really changed, and if it hasn't
> then just update the version ID the guard checks"?

If the dict version changes (because a value different than the
watched value is modified) each time that the guard is checked, the
guard always require a dict lookup to check if the watched value
changed.

Victor
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Devguide: Add a table summarizing status of Python branches

[Victor Stinner]

2016-01-21 1:09 GMT+01:00 Brett Cannon :
> On Wed, 20 Jan 2016 at 14:28 Victor Stinner 
>> I'm using the free service ReadTheDocs.org and it's really impressive
>> how fast it is to update the HTML page after a push. It's usually less
>> than 10 seconds.
>
> I have no idea if the way our docs are built would work on readthedocs.org,
> but if it could then I would definitely vote to move our docs there and have
> the PSF make a regular donation for the service.

Oh, I was talking about small documentations of personal projects. I
didn't propose to move Python docs to readthedocs.org. I don't know if
it makes sense.

It's just to say that we can do better than 30 minutes of the current system :-)

Victor
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 509: Add a private version to dict

[Andrew Barnert via Python-Dev]

On Wednesday, January 20, 2016 4:10 PM, Brett Cannon  wrote:


>I think Glenn was assuming we had a single, global version # that all dicts 
>shared without having a per-dict version ID. The key thing here is that we 
>have a global counter that tracks the number of mutations for all dictionaries 
>but whose value we store as a per-dictionary value. That ends up making the 
>version ID inherently both a token representing the state of any dict but also 
>the uniqueness of the dict since no two dictionaries will ever have the same 
>version ID.

This idea worries me. I'm not sure why, but I think because of threading. After 
all, it's pretty rare for two threads to both want to work on the same dict, 
but very, very common for two threads to both want to work on _any_ dict. So, 
imagine someone manages to remove the GIL from CPython by using STM: now most 
transactions are bumping that global counter, meaning most transactions fail 
and have to be retried, so you end up with 8 cores each running at 1/64th the 
speed of a single core but burning 100% CPU. Obviously a real-life 
implementation wouldn't be _that_ stupid; you'd special-case the 
version-bumping (maybe unconditionally bump it N times before starting the 
transaction, and then as long as you don't bump more than N times during the 
transaction, you can commit without touching it), but there's still going to be 
a lot of contention.

And that also affects something like PyPy being able to use FAT-Python-style 
AoT optimizations via cpyext. At first glance that sounds like a stupid 
idea--why would you want to run an optimizer through a slow emulator? But the 
optimizer only runs once and transforms the function code, which runs a zillion 
times, so who cares how slow the optimizer is? Of course it may still be true 
that many of the AoT optimizations that FAT makes don't apply very well to 
PyPy, in which case it doesn't matter. But I don't think we can assume that a 
priori.

Is there a way to define this loosely enough so that the implementation _can_ 
be a single global counter, if that turns out to be most efficient, but can 
also be a counter per dictionary and a globally-unique ID per dictionary?
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 509: Add a private version to dict

[Brett Cannon]

On Wed, 20 Jan 2016, 17:54 Andrew Barnert  wrote:

> On Wednesday, January 20, 2016 4:10 PM, Brett Cannon 
> wrote:
>
>
> >I think Glenn was assuming we had a single, global version # that all
> dicts shared without having a per-dict version ID. The key thing here is
> that we have a global counter that tracks the number of mutations for all
> dictionaries but whose value we store as a per-dictionary value. That ends
> up making the version ID inherently both a token representing the state of
> any dict but also the uniqueness of the dict since no two dictionaries will
> ever have the same version ID.
>
> This idea worries me. I'm not sure why, but I think because of threading.
> After all, it's pretty rare for two threads to both want to work on the
> same dict, but very, very common for two threads to both want to work on
> _any_ dict. So, imagine someone manages to remove the GIL from CPython by
> using STM: now most transactions are bumping that global counter, meaning
> most transactions fail and have to be retried, so you end up with 8 cores
> each running at 1/64th the speed of a single core but burning 100% CPU.
> Obviously a real-life implementation wouldn't be _that_ stupid; you'd
> special-case the version-bumping (maybe unconditionally bump it N times
> before starting the transaction, and then as long as you don't bump more
> than N times during the transaction, you can commit without touching it),
> but there's still going to be a lot of contention.
>

This is all being regarded as an implementation detail of CPython, so in
this hypothetical STM world we can drop all of this (or lock it).


> And that also affects something like PyPy being able to use
> FAT-Python-style AoT optimizations via cpyext. At first glance that sounds
> like a stupid idea--why would you want to run an optimizer through a slow
> emulator? But the optimizer only runs once and transforms the function
> code, which runs a zillion times, so who cares how slow the optimizer is?
> Of course it may still be true that many of the AoT optimizations that FAT
> makes don't apply very well to PyPy, in which case it doesn't matter. But I
> don't think we can assume that a priori.
>
> Is there a way to define this loosely enough so that the implementation
> _can_ be a single global counter, if that turns out to be most efficient,
> but can also be a counter per dictionary and a globally-unique ID per
> dictionary?
>

There's no need to if this is all under the hood and in no way affects
anyone but the eval loop and those who choose to use it. We can make sure
to preface all of this with underscores so it's obvious they are private
and so use at your own peril.

>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 509: Add a private version to dict

[Yury Selivanov]

On 2016-01-20 8:54 PM, Andrew Barnert via Python-Dev wrote:

>I think Glenn was assuming we had a single, global version # that all dicts 
shared without having a per-dict version ID. The key thing here is that we have a 
global counter that tracks the number of mutations for all dictionaries but whose 
value we store as a per-dictionary value. That ends up making the version ID 
inherently both a token representing the state of any dict but also the uniqueness 
of the dict since no two dictionaries will ever have the same version ID.

This idea worries me. I'm not sure why, but I think because of threading. After 
all, it's pretty rare for two threads to both want to work on the same dict, 
but very, very common for two threads to both want to work on_any_  dict. So, 
imagine someone manages to remove the GIL from CPython by using STM: now most 
transactions are bumping that global counter, meaning most transactions fail 
and have to be retried, so you end up with 8 cores each running at 1/64th the 
speed of a single core but burning 100% CPU. Obviously a real-life 
implementation wouldn't be_that_  stupid; you'd special-case the 
version-bumping (maybe unconditionally bump it N times before starting the 
transaction, and then as long as you don't bump more than N times during the 
transaction, you can commit without touching it), but there's still going to be 
a lot of contention.


Well, PEP 509 proposes to add ma_version only for CPython.  It's an 
implementation detail of CPython.  Victor's FAT optimizer is also 
tailored specifically for CPython, and making it work on PyPy would 
require a completely different set of hacks.


To remove the GIL or implement an efficient STM one will have to rewrite 
(and potentially break) so much code in CPython, that ma_version won't 
be a concern.


For now, though, ma_version will be protected by GIL, so threading 
shouldn't be a problem.




And that also affects something like PyPy being able to use FAT-Python-style 
AoT optimizations via cpyext. At first glance that sounds like a stupid 
idea--why would you want to run an optimizer through a slow emulator? But the 
optimizer only runs once and transforms the function code, which runs a zillion 
times, so who cares how slow the optimizer is? Of course it may still be true 
that many of the AoT optimizations that FAT makes don't apply very well to 
PyPy, in which case it doesn't matter. But I don't think we can assume that a 
priori.


The idea of FAT is that it will also generate optimized code objects 
with guards.  I doubt it would make any sense to use it under PyPy or 
any jitted Python implementation.  JITs have a far better understanding 
of the code than any static optimizer.




Is there a way to define this loosely enough so that the implementation_can_  
be a single global counter, if that turns out to be most efficient, but can 
also be a counter per dictionary and a globally-unique ID per dictionary?


Defining it "loosely" means that you can't trust it.  I'd just 
explicitly say that:


- ma_version is an implementation detail of CPython and may not be 
implemented on other platforms;

- ma_version can be removed from future CPython releases;
- ma_version can be used by code optimizers tailored specifically for 
CPython and CPython itself.


Yury
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 509: Add a private version to dict

[Yury Selivanov]

On 2016-01-20 5:01 PM, Greg Ewing wrote:

Yury Selivanov wrote:

What I propose is to add a pointer "ma_extra" (same 64bits),
which will be set to NULL for most dict instances (instead of
ma_version).  "ma_extra" can then point to a struct that has a
globally unique dict ID (uint64), and a version tag (unit64).


Why not just use a single global counter for allocating
dict version tags, instead of one per dict?




Yeah, I think that's what we agreed on: 
https://mail.python.org/pipermail/python-dev/2016-January/142837.html


The only advantage of ma_extra pointer is that it allows to add more 
stuff to dicts in the future.


Yury
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Update PEP 7 to require curly braces in C

[Nick Coghlan]

On 21 January 2016 at 10:16, Brett Cannon  wrote:
> I just checked with Van and we should have CLAs for even PEP contributors,
> so it will have to go through the same steps as the other ancillary
> repositories.

We should probably mention that in PEP 1 - I wasn't aware of that
requirement, so I've never explicitly checked CLA status for folks
contributing packaging related PEPs. (And looking at the
just-checked-in PEP 513, I apparently have a CLA to chase up...)

Regards,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Devguide: Add a table summarizing status of Python branches

[Victor Stinner]

2016-01-20 22:22 GMT+01:00 Victor Stinner :
> I pushed my table, it will be online in a few hours (I don't know when
> the devguide is recompiled?):
> http://docs.python.org/devguide/triaging.html#generating-special-links-in-a-comment

Hum ok, it takes more than a few hours in fact. It's still not online
10 hours after my push :-/
https://docs.python.org/devguide/

Victor
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 509: Add a private version to dict

[Greg Ewing]

Andrew Barnert via Python-Dev wrote:

imagine someone manages to remove the GIL from CPython by using
STM: now most transactions are bumping that global counter, meaning most
transactions fail and have to be retried,


If this becomes a problem, the tag could be split into two
parts of m and n bits, with m + n = 64. Use a global counter
for allocating the high half, and increment the low half
locally. When the low half overflows, allocate a new high
half.

A value of n = 16 or so ought to reduce contention for the
global counter to something fairly negligible, I would
think, without much risk of the high half ever wrapping
around.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com