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

[Victor Stinner]

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 such case avoids dictionary lookups in the
guard.

My current patch does not increment if the value is the same, and I'm
unable to see any performance regression on *micro* benchmarks:
https://bugs.python.org/issue26058

So I'm in favor of making guards as efficient as possible and not
increment the version in dict ;-)

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

[Python-Dev] PEP 509

[Jim J. Jewett]

(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 version update?

d[k]=d[k] seems like it should do that (absent the optimization to
prevent it), but I confess that I can't come up with a good use case
that doesn't start seeming internal to a specific optimizer.

(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 version change?


(2)  I would like to see a .get on the guard object, so that it could
be used in place of the dict lookup even from python.  If this doesn't
make sense (e.g., doesn't really save time since the guard has to be
used from python), please mention that in the Guard Example text.


(3)  It would be possible to define the field as reserved in the main
header, and require another header to use it even from C.

(3a)  This level of privacy might be overkill, but I would prefer that
the decision be explicit.

(3b)  The change should almost certainly be hidden from the ABI / Py_LIMITED_API

-jJ
___
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

[Ethan Furman]

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 version change?



Yes it would, but mutating a dictionary value during iteration is legal, 
so we cannot use the __version__ [1] change to tell us that something 
illegal happened.


[1] We're not going to call it __version__ are we?  Seems like 
__cache_token__ is a much better name.


--
~Ethan~
___
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

[Victor Stinner]

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 version, but I changed
my mind, it's not private (only exposed in the C API).

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

[Victor Stinner]

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

> (1b)  Is there a way to force a version update?

No. Why would you do that? (What is your use case.)

FYI there is a private API in _testcapi to set the version, for unit tests.

> (2)  I would like to see a .get on the guard object, so that it could
> be used in place of the dict lookup even from python.  If this doesn't
> make sense (e.g., doesn't really save time since the guard has to be
> used from python), please mention that in the Guard Example text.

Optimizations are out of the scope of this PEP.

Please see https://www.python.org/dev/peps/pep-0510/ to more examples
of specialization with guards.

See also https://faster-cpython.readthedocs.org/fat_python.html for
concrete optimizations using specialization with guards.

> (3)  It would be possible to define the field as reserved in the main
> header, and require another header to use it even from C.
>
> (3a)  This level of privacy might be overkill, but I would prefer that
> the decision be explicit.
>
> (3b)  The change should almost certainly be hidden from the ABI / 
> Py_LIMITED_API

Oh, the PyDictObject structure is not part of the stable ABI. It seems
worth to mention it 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

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

[Victor Stinner]

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 an API to implement a
static Python optimizer specializing functions with guards. I will
post a first version of the PEP 511 to python-ideas soon.

HTML version:
https://www.python.org/dev/peps/pep-0510/#changes

Victor


PEP: 510
Title: Specialize functions with guards
Version: $Revision$
Last-Modified: $Date$
Author: Victor Stinner 
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 4-January-2016
Python-Version: 3.6


Abstract


Add functions to the Python C API to specialize pure Python functions:
add specialized codes with guards. It allows to implement static
optimizers respecting the Python semantics.


Rationale
=

Python semantics


Python is hard to optimize because almost everything is mutable: builtin
functions, function code, global variables, local variables, ... can be
modified at runtime. Implement optimizations respecting the Python
semantics requires to detect when "something changes", we will call these
checks "guards".

This PEP proposes to add a public API to the Python C API to add
specialized codes with guards to a function. When the function is
called, a specialized code is used if nothing changed, otherwise use the
original bytecode.

Even if guards help to respect most parts of the Python semantics, it's
hard to optimize Python without making subtle changes on the exact
behaviour. CPython has a long history and many applications rely on
implementation details. A compromise must be found between "everything
is mutable" and performance.

Writing an optimizer is out of the scope of this PEP.


Why not a JIT compiler?
---

There are multiple JIT compilers for Python actively developed:

* `PyPy `_
* `Pyston `_
* `Numba `_
* `Pyjion `_

Numba is specific to numerical computation.  Pyston and Pyjion are still
young.  PyPy is the most complete Python interpreter, it is much faster
than CPython and has a very good compatibility with CPython (it respects
the Python semantics). There are still issues with Python JIT compilers
which avoid them to be widely used instead of CPython.

Many popular libraries like numpy, PyGTK, PyQt, PySide and wxPython are
implemented in C or C++ and use the Python C API. To have a small memory
footprint and better performances, Python JIT compilers do not use
reference counting to use a faster garbage collector, do not use C
structures of CPython objects and manage memory allocations differently.
PyPy has a ``cpyext`` module which emulates the Python C API but it has
worse performances than CPython and does not support the full Python C
API.

New features are first developped in CPython. In january 2016, the
latest CPython stable version is 3.5, whereas PyPy only supports Python
2.7 and 3.2, and Pyston only supports Python 2.7.

Even if PyPy has a very good compatibility with Python, some modules are
still not compatible with PyPy: see `PyPy Compatibility Wiki
`_. The incomplete
support of the the Python C API is part of this problem. There are also
subtle differences between PyPy and CPython like reference counting:
object destructors are always called in PyPy, but can be called "later"
than in CPython. Using context managers helps to control when resources
are released.

Even if PyPy is much faster than CPython in a wide range of benchmarks,
some users still report worse performances than CPython on some specific
use cases or unstable performances.

When Python is used as a scripting program for programs running less
than 1 minute, JIT compilers can be slower because their startup time is
higher and the JIT compiler takes time to optimize the code. For
example, most Mercurial commands take a few seconds.

Numba now supports ahead of time compilation, but it requires decorator
to specify arguments types and it only supports numerical types.

CPython 3.5 has almost no optimization: the peephole optimizer only
implements basic optimizations. A static compiler is a compromise
between CPython 3.5 and PyPy.

.. note::
   There was also the Unladen Swallow project, but it was abandoned in
   2011.


Examples


Following examples are not written to show powerful optimizations
promising important speedup, but to be short and easy to understand,
just to explain the principle.

Hypothetical myoptimizer module
---

Examples in this PEP uses an hypothetical ``myoptimizer`` module which
provides the following functions and types:

* ``specialize(func, code, guards)``: add the specialized code `code`
  with guar

Re: [Python-Dev] PEP 509

[Ethan Furman]

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/

In the first version I proposed to expose the version, but I changed
my mind, it's not private (only exposed in the C API).


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.)


--
~Ethan~
___
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

[Terry Reedy]

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 strikes me as a 
better description of what it is, and easier on the brain than 
__cache_token__.  Maybe there is something even better, such as 
__seqnum__.  This is literally what the attribute
is, a sequence/revision number, as with the Python repository, without 
the connotations of 'version', as in 'Python version'.  Each commit to 
CPython changes the repository state without changing the 'version'. A 
dict.update may run thru 1000s of sequence numbers, but only the final 
result is a 'version' from the programmers point of view.


--
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

[Victor Stinner]

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 must be prefixed with "ma_". If you read
the prior art of the PEP, you will see that Antoine Pitrou also
proposed the "ma_version" name. The existing version on types used the
"version_tag" name. Maybe I should pick this one.

Dunder names like __version__ is not used in the C language.

Do you expect "__version__" to be somehow "protected" or "private"?
The field is definitely public in the Python C API, and I don't think
that it's a problem. It's not really a choice, there is no way to hide
a field of a C structure. If you start to do random things on the C
API, it's your responsability :-)

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

[Ethan Furman]

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 occasionally, so
>> my question is real.)
>
> Fields of the PyDictObject must be prefixed with "ma_". If you read
> the prior art of the PEP, you will see that Antoine Pitrou also
> proposed the "ma_version" name. The existing version on types used the
> "version_tag" name. Maybe I should pick this one.
>
> Dunder names like __version__ is not used in the C language.
>
> Do you expect "__version__" to be somehow "protected" or "private"?

Nope, I just don't want to be misdirected when I see the name. :)  I 
think ma_version (or ma_seqnum) will be fine.


--
~Ethan~


___
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] Building with VS2015

[Eddy Quicksall]

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 be doing wrong or have misunderstood?

 

Here is the output:

 

1>-- Build started: Project: make_versioninfo, Configuration: Release
Win32 --

2>-- Build started: Project: kill_python, Configuration: Release Win32
--

3>-- Skipped Build: Project: bdist_wininst, Configuration: Release Win32
--

3>Project not selected to build for this solution configuration 

4>-- Build started: Project: python3dll, Configuration: Release Win32
--

5>-- Build started: Project: xxlimited, Configuration: Release Win32
--

1>  make_versioninfo.c

5>  xxlimited.c

2>  kill_python.c

4>

4>  Microsoft (R) Program Maintenance Utility Version 14.00.23026.0

4>  Copyright (C) Microsoft Corporation.  All rights reserved.

4>

4> lib /def:python34stub.def
/out:W:\Python-3.4.4\PCbuild\python34stub.lib /MACHINE:x86

5>LINK : fatal error LNK1104: cannot open file 'python3.lib'

4>  Microsoft (R) Library Manager Version 14.00.23026.0

4>  Copyright (C) Microsoft Corporation.  All rights reserved.

4>

4> Creating library W:\Python-3.4.4\PCbuild\python34stub.lib and object
W:\Python-3.4.4\PCbuild\python34stub.exp

4> cl /LD /FeW:\Python-3.4.4\PCbuild\python3.dll python3dll.c
python3.def W:\Python-3.4.4\PCbuild\python34stub.lib

4>  Microsoft (R) C/C++ Optimizing Compiler Version 19.00.23026 for x86

4>  Copyright (C) Microsoft Corporation.  All rights reserved.

4>

4>  python3dll.c

1>  make_versioninfo.vcxproj -> W:\Python-3.4.4\PCbuild\make_versioninfo.exe

2>  Generating code

2>  All 5 functions were compiled because no usable IPDB/IOBJ from previous
compilation was found.

2>  Finished generating code

4>  Microsoft (R) Incremental Linker Version 14.00.23026.0

4>  Copyright (C) Microsoft Corporation.  All rights reserved.

4>

4>  /dll

4>  /implib:W:\Python-3.4.4\PCbuild\python3.lib

4>  /out:W:\Python-3.4.4\PCbuild\python3.dll

4>  /def:python3.def

4>  python3dll.obj

4>  W:\Python-3.4.4\PCbuild\python34stub.lib

4> Creating library W:\Python-3.4.4\PCbuild\python3.lib and object
W:\Python-3.4.4\PCbuild\python3.exp

6>-- Build started: Project: pylauncher, Configuration: Release Win32
--

7>-- Build started: Project: pywlauncher, Configuration: Release Win32
--

7>  launcher.c

6>  launcher.c

2>  kill_python.vcxproj -> W:\Python-3.4.4\PCbuild\kill_python.exe

8>-- Build started: Project: pythoncore, Configuration: Release Win32
--

9>-- Build started: Project: sqlite3, Configuration: Release Win32
--

9>  sqlite3.c

9>c1 : fatal error C1083: Cannot open source file:
'..\externals\sqlite-3.8.11.0\sqlite3.c': No such file or directory

7>  Generating code

7>  All 41 functions were compiled because no usable IPDB/IOBJ from previous
compilation was found.

7>  Finished generating code

8>  _bisectmodule.c

8>  _codecsmodule.c

6>  Generating code

6>  All 41 functions were compiled because no usable IPDB/IOBJ from previous
compilation was found.

6>  Finished generating code

8>  _collectionsmodule.c

7>  pywlauncher.vcxproj -> W:\Python-3.4.4\PCbuild\pyw.exe

8>  _csv.c

6>  pylauncher.vcxproj -> W:\Python-3.4.4\PCbuild\py.exe

8>  _functoolsmodule.c

8>  _heapqmodule.c

8>  _json.c

8>  _localemodule.c

8>  _lsprof.c

8>  _math.c

8>  _pickle.c

8>  _randommodule.c

8>  _sre.c

8>  _stat.c

8>  _struct.c

8>  _weakref.c

8>  arraymodule.c

8>  atexitmodule.c

8>  audioop.c

8>  binascii.c

8>  Generating Code...

8>  Compiling...

8>  cmathmodule.c

8>  _datetimemodule.c

8>..\Modules\_datetimemodule.c(4843): error C2065: 'daylight': undeclared
identifier

8>..\Modules\_datetimemodule.c(4844): error C2065: 'tzname': undeclared
identifier

8>..\Modules\_datetimemodule.c(4844): error C2109: subscript requires array
or pointer type

8>..\Modules\_datetimemodule.c(4846): error C2065: 'tzname': undeclared
identifier

8>..\Modules\_datetimemodule.c(4846): error C2109: subscript requires array
or pointer type

8>  errnomodule.c

8>  faulthandler.c

8>  gcmodule.c

8>  hashtable.c

8>  itertoolsmodule.c

8>  main.c

8>..\Modules\main.c(521): error C2198: 'wcstok': too few arguments for call

8>..\Modules\main.c(523): error C2198: 'wcstok': too few arguments for call

8>  mathmodule.c

8>  md5module.c

8>  mmapmodule.c

8>  _opcode.c

8>  _operator.c

8>  parsermodule.c

8>  posixmodule.c

8>  rotatingtree.c

8>  sha1module.c

8>  sha256module.c

8>  sha512module.c

8>  signalmodule.c

8>  Generating Code...

8>  Compiling...

8>  symtablemodule.c

8>  _threadmodule.c

8>  _tracemalloc.c

8>  timemodule.c

8>..\Modules\timemodule.c(1325): error C2065: 'timezone': undeclared
identifier

8>..\Modules\timemodule.c(1329): error C2065: 'timezone': undeclared
id

Re: [Python-Dev] Building with VS2015

[Alexander Walters]

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.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 be doing wrong or have misunderstood?

Here is the output:

1>-- Build started: Project: make_versioninfo, Configuration: 
Release Win32 --


2>-- Build started: Project: kill_python, Configuration: Release 
Win32 --


3>-- Skipped Build: Project: bdist_wininst, Configuration: Release 
Win32 --


3>Project not selected to build for this solution configuration

4>-- Build started: Project: python3dll, Configuration: Release 
Win32 --


5>-- Build started: Project: xxlimited, Configuration: Release 
Win32 --


1> make_versioninfo.c

5> xxlimited.c

2> kill_python.c

4>

4> Microsoft (R) Program Maintenance Utility Version 14.00.23026.0

4> Copyright (C) Microsoft Corporation.  All rights reserved.

4>

4>lib /def:python34stub.def 
/out:W:\Python-3.4.4\PCbuild\python34stub.lib /MACHINE:x86


5>LINK : fatal error LNK1104: cannot open file 'python3.lib'

4> Microsoft (R) Library Manager Version 14.00.23026.0

4> Copyright (C) Microsoft Corporation.  All rights reserved.

4>

4> Creating library W:\Python-3.4.4\PCbuild\python34stub.lib and 
object W:\Python-3.4.4\PCbuild\python34stub.exp


4>cl /LD /FeW:\Python-3.4.4\PCbuild\python3.dll python3dll.c 
python3.def W:\Python-3.4.4\PCbuild\python34stub.lib


4> Microsoft (R) C/C++ Optimizing Compiler Version 19.00.23026 for x86

4> Copyright (C) Microsoft Corporation.  All rights reserved.

4>

4> python3dll.c

1> make_versioninfo.vcxproj -> 
W:\Python-3.4.4\PCbuild\make_versioninfo.exe


2> Generating code

2> All 5 functions were compiled because no usable IPDB/IOBJ from 
previous compilation was found.


2> Finished generating code

4> Microsoft (R) Incremental Linker Version 14.00.23026.0

4> Copyright (C) Microsoft Corporation.  All rights reserved.

4>

4> /dll

4> /implib:W:\Python-3.4.4\PCbuild\python3.lib

4> /out:W:\Python-3.4.4\PCbuild\python3.dll

4> /def:python3.def

4> python3dll.obj

4> W:\Python-3.4.4\PCbuild\python34stub.lib

4> Creating library W:\Python-3.4.4\PCbuild\python3.lib and object 
W:\Python-3.4.4\PCbuild\python3.exp


6>-- Build started: Project: pylauncher, Configuration: Release 
Win32 --


7>-- Build started: Project: pywlauncher, Configuration: Release 
Win32 --


7> launcher.c

6> launcher.c

2> kill_python.vcxproj -> W:\Python-3.4.4\PCbuild\kill_python.exe

8>-- Build started: Project: pythoncore, Configuration: Release 
Win32 --


9>-- Build started: Project: sqlite3, Configuration: Release Win32 
--


9> sqlite3.c

9>c1 : fatal error C1083: Cannot open source file: 
'..\externals\sqlite-3.8.11.0\sqlite3.c': No such file or directory


7> Generating code

7> All 41 functions were compiled because no usable IPDB/IOBJ from 
previous compilation was found.


7> Finished generating code

8> _bisectmodule.c

8> _codecsmodule.c

6> Generating code

6> All 41 functions were compiled because no usable IPDB/IOBJ from 
previous compilation was found.


6> Finished generating code

8> _collectionsmodule.c

7> pywlauncher.vcxproj -> W:\Python-3.4.4\PCbuild\pyw.exe

8> _csv.c

6> pylauncher.vcxproj -> W:\Python-3.4.4\PCbuild\py.exe

8> _functoolsmodule.c

8> _heapqmodule.c

8> _json.c

8> _localemodule.c

8> _lsprof.c

8> _math.c

8> _pickle.c

8> _randommodule.c

8> _sre.c

8> _stat.c

8> _struct.c

8> _weakref.c

8> arraymodule.c

8> atexitmodule.c

8> audioop.c

8> binascii.c

8> Generating Code...

8> Compiling...

8> cmathmodule.c

8> _datetimemodule.c

8>..\Modules\_datetimemodule.c(4843): error C2065: 'daylight': 
undeclared identifier


8>..\Modules\_datetimemodule.c(4844): error C2065: 'tzname': 
undeclared identifier


8>..\Modules\_datetimemodule.c(4844): error C2109: subscript requires 
array or pointer type


8>..\Modules\_datetimemodule.c(4846): error C2065: 'tzname': 
undeclared identifier


8>..\Modules\_datetimemodule.c(4846): error C2109: subscript requires 
array or pointer type


8> errnomodule.c

8> faulthandler.c

8> gcmodule.c

8> hashtable.c

8> itertoolsmodule.c

8> main.c

8>..\Modules\main.c(521): error C2198: 'wcstok': too few arguments for 
call


8>..\Modules\main.c(523): error C2198: 'wcstok': too few arguments for 
call


8> mathmodule.c

8> md5module.c

8> mmapmodule.c

8> _opcode.c

8> _operator.c

8> parsermodule.c

8> posixmodule.c

8> rotatingtree.c

8> sha1module.c

8> sha256module.c

8> sha512module.c

8> signalmodule.c

8> Generating Code...

8> Compiling...

8> symta

Re: [Python-Dev] Building with VS2015

[Zachary Ware]

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.5 with VS 2015, or 3.4 with VS
2010.  You might coerce things the other way around, but you won't get
official support for it and you won't match the rest of the world (in
particular, binary packages from PyPI won't work).

> It also looks like you have a lot of missing dependencies.

Run `PCbuild\get_externals.bat` after installing Subversion (and
ensuring that svn.exe is on PATH) to resolve the missing dependencies.
The other errors will require patching the source, and it's too late
in the 3.4 release cycle for those patches to be accepted for 3.4.5.
I also find it much simpler to use `PCbuild\build.bat` instead of
building from the VS GUI.  A 32bit Release build with all the optional
pieces can be accomplished with `PCbuild\build.bat -e`; add '-p x64'
for a 64bit build.

-- 
Zach
___
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