[Python-Dev] Building with VS2015

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

Re: [Python-Dev] Building with VS2015

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

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

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

Re: [Python-Dev] PEP 509

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:

Re: [Python-Dev] PEP 509

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

[Python-Dev] PEP 510: Specialize functions with guards

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

Re: [Python-Dev] PEP 509

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

Re: [Python-Dev] PEP 509

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

Re: [Python-Dev] PEP 509

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:

[Python-Dev] PEP 509

(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

Re: [Python-Dev] PEP 509

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

Re: [Python-Dev] PEP 509

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