Well, it was just a remark.
2016-01-12 0:35 GMT+01:00 Andrew Barnert :
> Are you saying that d[key] = d[key] may or may not increment the version, so
> any optimizer can't rely on the fact that it doesn't?
Optimizers don't have to rely on this exactly behaviour. Not
incrementing the version on s
(1) Please make it clear within the abstract what counts as a change.
(1a) E.g., a second paragraph such as "Adding or removing a key, or
replacing a value, counts as a change. Modifying an object in place,
or replacing it with itself may not be picked up."
(1b) Is there a way to force a vers
On 01/12/2016 10:34 AM, Jim J. Jewett wrote:
(1c) Section "Guard against changing dict during iteration" says
"Sadly, the dictionary version proposed in this PEP doesn't help to
detect dictionary mutation." Why not? Wouldn't that mutation involve
replacing a value, which ought to trigger a ve
2016-01-12 19:52 GMT+01:00 Ethan Furman :
> [1] We're not going to call it __version__ are we? Seems like
> __cache_token__ is a much better name.
See the online version to the most recent version of the PEP:
https://www.python.org/dev/peps/pep-0509/
In the first version I proposed to expose the
2016-01-12 19:34 GMT+01:00 Jim J. Jewett :
> (1) Please make it clear within the abstract what counts as a change.
I don't think that an abstract must give the long list of cases when
the version is modified or not. It's explained in detail at:
https://www.python.org/dev/peps/pep-0509/#changes
>
Hi,
I posted a first version of this PEP on python-ideas and I got
interesting feedback. The main changes in this second version is that
the whole API is now private: no more exposed in Python at all, only
in the Python C API (C level).
The PEP is part of a serie of 3 PEP (509, 510, 511) adding a
On 01/12/2016 01:34 PM, Victor Stinner wrote:
2016-01-12 19:52 GMT+01:00 Ethan Furman :
[1] We're not going to call it __version__ are we? Seems like
__cache_token__ is a much better name.
See the online version to the most recent version of the PEP:
https://www.python.org/dev/peps/pep-0509/
On 1/12/2016 5:24 PM, Ethan Furman wrote:
On 01/12/2016 01:34 PM, Victor Stinner wrote:
2016-01-12 19:52 GMT+01:00 Ethan Furman :
[1] We're not going to call it __version__ are we? Seems like
__cache_token__ is a much better name.
While I understand the rationale against __version__, it stri
2016-01-12 23:24 GMT+01:00 Ethan Furman :
> Even if not exposed at the Python layer, it's still exposed when working at
> the C layer. Is __version__ any less confusing there? (I only work in C
> when working on Python, and only occasionally, so my question is real.)
Fields of the PyDictObject m
On 01/12/2016 03:24 PM, Victor Stinner wrote:
> 2016-01-12 23:24 GMT+01:00 Ethan Furman wrote:
>> Even if not exposed at the Python layer, it's still exposed when
>> working at the C layer. Is __version__ any less confusing there?
>> (I only work in C when working on Python, and only occasionall
I downloaded https://www.python.org/ftp/python/3.4.4/Python-3.4.4.tgz.
After reading Python-3.4.4\PCbuild\readme.txt I opened pcbuild.sln and
selected release/winn32 then tried a build all (F7). But that give lots of
errors and missing .h files (mostly sqlite3.h).
Does anyone know what I may
This is a mailing list for the development of python itself, not support
for building it. That said...
3.4 uses visual studio 2010, for starters. 3.5 uses 2015.
It also looks like you have a lot of missing dependencies.
On 1/12/2016 21:55, Eddy Quicksall wrote:
I downloaded https://www.pyt
On Tue, Jan 12, 2016 at 9:32 PM, Alexander Walters
wrote:
> This is a mailing list for the development of python itself, not support for
> building it. That said...
>
> 3.4 uses visual studio 2010, for starters. 3.5 uses 2015.
Agreed with all of the above.
You'll be much happier using either 3
13 matches
Mail list logo
