Python Version in Blender 2.79 and 2.79a #54355

New Issue

Johannes Dietmar Breuer · 2018-03-19T04:41:06+01:00

2018-03-19 04:41:06 +01:00

Why is the Python version of Blender 2.79 higher than the Python version in 2.79a.

Blender 2.79a will not work on a Windows10 system with Python 3.6.4.
The Python Version of Blender 2.79a is 3.5x
I have to delete the path to my Python 3.6.4 to make Blender work.

With the older Blender 2.79 the Python version is 3.6.2 and it works without any
problem on my Win10 and Python 3.6.4.

Why is the Python version downgraded from Blender 2.79 to 2.79a?

Why is the Python version of Blender 2.79 higher than the Python version in 2.79a. Blender 2.79a will not work on a Windows10 system with Python 3.6.4. The Python Version of Blender 2.79a is 3.5x I have to delete the path to my Python 3.6.4 to make Blender work. With the older Blender 2.79 the Python version is 3.6.2 and it works without any problem on my Win10 and Python 3.6.4. Why is the Python version downgraded from Blender 2.79 to 2.79a?

Johannes Dietmar Breuer commented

2018-03-19 04:41:06 +01:00

Added subscriber: @JD-13

Ray molenkamp commented

2018-03-19 05:14:01 +01:00

Added subscriber: @LazyDodo

Ray molenkamp commented

2018-03-19 05:14:01 +01:00

both 2.79 and 2.79a shipped with the same python verison nothing changed on our side

2.79   PYTHON INTERACTIVE CONSOLE 3.5.3 (default, May 20 2017, 19:10:40) [MSC v.1800 64 bit (AMD64)]
2.79a  PYTHON INTERACTIVE CONSOLE 3.5.3 (default, May 20 2017, 19:10:40) [MSC v.1800 64 bit (AMD64)]

something else must be causing issues for you, what is the exact error your are having?

edit: You are most likely comparing a build from the buildbot which does have a higher python version, however the official released versions have always been on 3.5.3.

both 2.79 and 2.79a shipped with the same python verison nothing changed on our side ``` 2.79 PYTHON INTERACTIVE CONSOLE 3.5.3 (default, May 20 2017, 19:10:40) [MSC v.1800 64 bit (AMD64)] 2.79a PYTHON INTERACTIVE CONSOLE 3.5.3 (default, May 20 2017, 19:10:40) [MSC v.1800 64 bit (AMD64)] ``` something else must be causing issues for you, what is the exact error your are having? edit: You are most likely comparing a build from the buildbot which does have a higher python version, however the official released versions have always been on 3.5.3.

Johannes Dietmar Breuer commented

2018-03-19 12:36:11 +01:00

@LazyDodo
Hi,
please check the python folders in the 2 versions!

2.79 : Folder \2.79\python\bin there are a python.exe and a python36.dll

      after running a cmd and calling python.exe in the folder:

      Python 3.6.2 (default, Sep 19 2017, 20:20:57) [MSC v.1900 64 bit (AMD64)] on win32

2.79a : Folder \2.79\python\bin there are a python.exe, a python 35.dll and a python36.dll

      after running a cmd and calling python.exe in the folder:

      a) with on_system python 3.6.4

        2.79\python\bin\python.exe Failed to import the site module Traceback (most recent call last): File "C:\Python364\Lib\site.py", line 73, in <module>

                                                                 import os File "C:\Python364\Lib\os.py", line 652, in <module> from _collections_abc import MutableMapping
                                                                  File "C:\Python364\Lib\_collections_abc.py", line 64  async def _ag(): yield SyntaxError: 'yield' inside async function

      b) on_system python disabled
          blender-2.79a-windows64\2.79\python\bin\python.exe
          Python 3.5.3 (default, May 20 2017, 19:10:40) [MSC v.1800 64 bit (AMD64)] on win32

Thus, blender 2.79a will open cmd window when started and terminate it again. Blender will not start. Only if on_system python is disabled it will start and python version is 3.5.3!
Even that there is a python35.dll in the python\bin folder, doesn't seem to sow identical python versions. I am using the windows 64 bit version, and after update from 2.79 to 2.79a even compared now the 2.79win64_vic14 version to 2.79, same result.

with regards,
jd breuer

@LazyDodo Hi, please check the python folders in the 2 versions! 2.79 : Folder \2.79\python\bin there are a python.exe and a python36.dll ``` after running a cmd and calling python.exe in the folder: ``` ``` Python 3.6.2 (default, Sep 19 2017, 20:20:57) [MSC v.1900 64 bit (AMD64)] on win32 ``` 2.79a : Folder \2.79\python\bin there are a python.exe, a python 35.dll and a python36.dll ``` after running a cmd and calling python.exe in the folder: ``` ``` a) with on_system python 3.6.4 ``` 2.79\python\bin\python.exe Failed to import the site module Traceback (most recent call last): File "C:\Python364\Lib\site.py", line 73, in <module> ``` import os File "C:\Python364\Lib\os.py", line 652, in <module> from _collections_abc import MutableMapping File "C:\Python364\Lib\_collections_abc.py", line 64 async def _ag(): yield SyntaxError: 'yield' inside async function ``` ``` b) on_system python disabled blender-2.79a-windows64\2.79\python\bin\python.exe Python 3.5.3 (default, May 20 2017, 19:10:40) [MSC v.1800 64 bit (AMD64)] on win32 ``` Thus, blender 2.79a will open cmd window when started and terminate it again. Blender will not start. Only if on_system python is disabled it will start and python version is 3.5.3! Even that there is a python35.dll in the python\bin folder, doesn't seem to sow identical python versions. I am using the windows 64 bit version, and after update from 2.79 to 2.79a even compared now the 2.79win64_vic14 version to 2.79, same result. with regards, jd breuer

Sybren A. Stüvel commented

2018-03-19 13:05:09 +01:00

Added subscriber: @dr.sybren

Sybren A. Stüvel commented

2018-03-19 13:05:09 +01:00

@JD-13 where did you get the files for 2.79b? If you're basing this on the daily builds, then you're not looking at what will become 2.79b. The daily builds are based on the master branch, which indeed has moved to Python 3.6. However, 2.79b will be a different build, and include the changes listed in #54255.

@JD-13 where did you get the files for 2.79b? If you're basing this on the daily builds, then you're not looking at what will become 2.79b. The daily builds are based on the master branch, which indeed has moved to Python 3.6. However, 2.79b will be a different build, and include the changes listed in [#54255](https://developer.blender.org/T54255).

Johannes Dietmar Breuer commented

2018-03-19 13:32:53 +01:00

we are talking of 2.79a and it is from blender.org

Ray molenkamp commented

2018-03-19 14:18:20 +01:00

The build you have with python 3.6 MUST be a daily build from http://builder.blender.org since both 2.79 and 2.79a shipped with python 3.5.3, (as will the soon to be released 2.79b) no downgrades have taken place. master (while keeping the 2.79 version number, which is indeed a tad confusing) and 2.8 have moved forward while the 2.79 branch didn't. you can validate the build you have as genuine by looking at the build hash , run blender -v and it should display the build hash, this is 5bd8ac9 for 2.79 and 8928d99270 for 2.79a . if your build says anything else, please post the hash.
I can't reproduce your issue I installed 64 bit python 3.6.4 from the python site, it's in my path and blender runs fine, i'm not doubting you have an issue, but if i can't reproduce it, i can't fix any problems.....

f:\Tools\blender\blender-2.79a-windows64>python
Python 3.6.4 (v3.6.4:d48eceb, Dec 19 2017, 06:54:40) [MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> ^Z



f:\Tools\blender\blender-2.79a-windows64>2.79\python\bin\python.exe
Python 3.5.3 (default, May 20 2017, 19:10:40) [MSC v.1800 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> ^Z



f:\Tools\blender\blender-2.79a-windows64>blender -v
Blender 2.79 (sub 0)
        build date: Wed 02/21/2018
        build time: 11:40 AM
        build commit date: 2018-02-21
        build commit time: 10:41
        build hash: 8928d99270f
        build platform: Windows
        build type:
        build c flags: /W3 /w34062 /wd4018 /wd4146 /wd4065 /wd4127 /wd4181 /wd4200 /wd4244 /wd4267 /wd4305 /wd4800 /we4013 /we4431  /DWIN32 /D_WINDOWS /W3 /nologo /J /Gd /MP /openmp
        build c++ flags: /W3 /w34062 /wd4018 /wd4146 /wd4065 /wd4127 /wd4181 /wd4200 /wd4244 /wd4267 /wd4305 /wd4800 /we4013 /we4431  /DWIN32 /D_WINDOWS /W3 /GR /EHsc /nologo /J /Gd /MP /EHsc /openmp

        build link flags: /MACHINE:X64 /SUBSYSTEM:CONSOLE /STACK:2097152 /INCREMENTAL:NO  /NODEFAULTLIB:msvcrt.lib /NODEFAULTLIB:msvcmrt.lib /NODEFAULTLIB:msvcurt.lib /NODEFAULTLIB:msvcrtd.lib  /ignor
e:4049 /ignore:4217 /ignore:4221
        build system: CMake

1) The build you have with python 3.6 *MUST* be a daily build from http://builder.blender.org since both 2.79 and 2.79a shipped with python 3.5.3, (as will the soon to be released 2.79b) no downgrades have taken place. master (while keeping the 2.79 version number, which is indeed a tad confusing) and 2.8 have moved forward while the 2.79 branch didn't. you can validate the build you have as genuine by looking at the build hash , run blender -v and it should display the build hash, this is 5bd8ac9 for 2.79 and 8928d99270f for 2.79a . if your build says anything else, please post the hash. 2) I can't reproduce your issue I installed 64 bit python 3.6.4 from the python site, it's in my path and blender runs fine, i'm not doubting you have an issue, but if i can't reproduce it, i can't fix any problems..... ``` f:\Tools\blender\blender-2.79a-windows64>python Python 3.6.4 (v3.6.4:d48eceb, Dec 19 2017, 06:54:40) [MSC v.1900 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> ^Z f:\Tools\blender\blender-2.79a-windows64>2.79\python\bin\python.exe Python 3.5.3 (default, May 20 2017, 19:10:40) [MSC v.1800 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> ^Z f:\Tools\blender\blender-2.79a-windows64>blender -v Blender 2.79 (sub 0) build date: Wed 02/21/2018 build time: 11:40 AM build commit date: 2018-02-21 build commit time: 10:41 build hash: 8928d99270f build platform: Windows build type: build c flags: /W3 /w34062 /wd4018 /wd4146 /wd4065 /wd4127 /wd4181 /wd4200 /wd4244 /wd4267 /wd4305 /wd4800 /we4013 /we4431 /DWIN32 /D_WINDOWS /W3 /nologo /J /Gd /MP /openmp build c++ flags: /W3 /w34062 /wd4018 /wd4146 /wd4065 /wd4127 /wd4181 /wd4200 /wd4244 /wd4267 /wd4305 /wd4800 /we4013 /we4431 /DWIN32 /D_WINDOWS /W3 /GR /EHsc /nologo /J /Gd /MP /EHsc /openmp build link flags: /MACHINE:X64 /SUBSYSTEM:CONSOLE /STACK:2097152 /INCREMENTAL:NO /NODEFAULTLIB:msvcrt.lib /NODEFAULTLIB:msvcmrt.lib /NODEFAULTLIB:msvcurt.lib /NODEFAULTLIB:msvcrtd.lib /ignor e:4049 /ignore:4217 /ignore:4221 build system: CMake ```

Johannes Dietmar Breuer commented

2018-03-19 15:33:21 +01:00

yes, I installed a 2.79_v14 version because I deleted the old 2.79 version I used to have.
the old 2.79 version was nicely working until I installed the 2.79a version. Only if I disable my installed python 3.6.4, the 2.79a with the correct hash will start.

here is the built I installed to be able to continue working:
C:\Program Files\Blender Foundation\Blender>blender -v
Blender 2.79 (sub 3)

      build date: Sat 03/10/2018
      build time: 05:12 AM
      build commit date: 2018-03-09
      build commit time: 20:22
      build hash: 41b38c5
      build platform: Windows
      build type: Release

yes, I installed a 2.79_v14 version because I deleted the old 2.79 version I used to have. the old 2.79 version was nicely working until I installed the 2.79a version. Only if I disable my installed python 3.6.4, the 2.79a with the correct hash will start. here is the built I installed to be able to continue working: C:\Program Files\Blender Foundation\Blender>blender -v Blender 2.79 (sub 3) ``` build date: Sat 03/10/2018 build time: 05:12 AM build commit date: 2018-03-09 build commit time: 20:22 build hash: 41b38c5 build platform: Windows build type: Release

Ray molenkamp commented

2018-03-19 15:49:39 +01:00

Yeah the version you have is NOT 2.79 that is a master build, this will have many new features (and possibly problems) that'll never make it into the official 2.79 build, it's not recommended to use these builds for any production work.

can you run a trace with procmon while starting blender 2.79a and post the trace here? (please filter for just the blender.exe entries)

also please validate that python35.dll is in the same folder as blender.exe

you can also try the .zip version of 2.79a and unpacking it somewhere to see if that helps

Yeah the version you have is *NOT* 2.79 that is a master build, this will have many new features (and possibly problems) that'll never make it into the official 2.79 build, it's not recommended to use these builds for any production work. can you run a trace with [procmon ](https://docs.microsoft.com/en-us/sysinternals/downloads/procmon) while starting blender 2.79a and post the trace here? (please filter for just the blender.exe entries) also please validate that python35.dll is in the same folder as blender.exe you can also try the [.zip version of 2.79a ](http://ftp.nluug.nl/graphics/blender/release/Blender2.79/blender-2.79a-windows64.zip) and unpacking it somewhere to see if that helps

Johannes Dietmar Breuer commented

2018-03-20 03:38:56 +01:00

Logfile.PML

Yep, I just use 2.79 as I do not like to always rename my Python folder only to start Blender 2.79a.
It just started when I started to use python 3.64 and installed blender 2.79a.
When I start blender in the the cmd window with blender -d, there is the following failure message:

When I rename my c:\Python364 folder in c:\oldPython364, blender 279a starts and works fine

[Logfile.PML](https://archive.blender.org/developer/F2468452/Logfile.PML) Yep, I just use 2.79 as I do not like to always rename my Python folder only to start Blender 2.79a. It just started when I started to use python 3.64 and installed blender 2.79a. When I start blender in the the cmd window with blender -d, there is the following failure message: ![279a.JPG](https://archive.blender.org/developer/F2468500/279a.JPG) When I rename my c:\Python364 folder in c:\oldPython364, blender 279a starts and works fine

Ray molenkamp commented

2018-03-20 04:52:12 +01:00

that log file is a little too filtered, just filter all of blender.exe not just the bits you think are relevant.

Johannes Dietmar Breuer commented

2018-03-20 05:21:14 +01:00

Hahah, was not sure I was doing it right..... here we go:
Logfile.PML

Hahah, was not sure I was doing it right..... here we go: [Logfile.PML](https://archive.blender.org/developer/F2469068/Logfile.PML)

Johannes Dietmar Breuer commented

2018-03-23 03:05:32 +01:00

HI, LazyDodo!

I fond now the solution to the problem.

When Python is being installed for only one user, it sets the PYTHONPATH variable in the user environment variable.
In Win 10 one has to go to useraccount settings and there to set environmental variables for this user by

leftclick on start button type account
leftclick manage my account
in the search window (upper l/h corner) type env
2 options come up, *edit system environmental variables and *edit environmental variables for your account
select the ..for your account
in the upper window you can add new variables, edit existing variables or, what I did, delete the PYTHONPATH variable
That did the trick, blender 279a works fine now!

Thanks for your patience with me, hope this will help some other users.

Regards,
didi, Philippines

HI, LazyDodo! I fond now the solution to the problem. When Python is being installed for only one user, it sets the PYTHONPATH variable in the user environment variable. In Win 10 one has to go to useraccount settings and there to set environmental variables for this user by - leftclick on start button type account - leftclick manage my account - in the search window (upper l/h corner) type env - 2 options come up, *edit system environmental variables and *edit environmental variables for your account - select the ..for your account - in the upper window you can add new variables, edit existing variables or, what I did, delete the PYTHONPATH variable That did the trick, blender 279a works fine now! Thanks for your patience with me, hope this will help some other users. Regards, didi, Philippines

Ray molenkamp commented

2018-03-26 02:23:35 +02:00

Thanks for reporting back, I'm still trying to reproduce the issue so i can see if we can do something to make things easier for people running into this in the future.

the python installer doesn't seem to allow me to install for just one user, the option to install for all users is selected and grayed out so i can't change it, i tried manually setting PYTHONPATH but i guess i picked a wrong path cause i still didn't have your issue, do you remember what this variable was set to?

Thanks for reporting back, I'm still trying to reproduce the issue so i can see if we can do something to make things easier for people running into this in the future. the python installer doesn't seem to allow me to install for just one user, the option to install for all users is selected and grayed out so i can't change it, i tried manually setting PYTHONPATH but i guess i picked a wrong path cause i still didn't have your issue, do you remember what this variable was set to?

Johannes Dietmar Breuer commented

2018-03-26 08:22:48 +02:00

I can imagine that this is caused by the Win10 Version, in my case it is the home edition.
When I installed it for all users, I ran into problems with the user rights and could not make it run at all.
After installing Python for only me, python 3.6x win installer msi, I could select either for all users or just me in manual mode.

As I forgot about this, when I wanted to change the env variable, I was always forced to do this with Admin rights, thus never seeing the path variable for myself.....

Only after browsing some time and learning that several people had this problem, I recognized that there was a difference between the easy accessible system env variables and the user env variable. (but even in cmd with path command, I did not see the PYTHONPATH variable)

Only after knowing how to edit the user env variables, I saw the PYTHONPATH, set to C:\Python364

Hope this helps a little!

Greetings, Didi

I can imagine that this is caused by the Win10 Version, in my case it is the home edition. When I installed it for all users, I ran into problems with the user rights and could not make it run at all. After installing Python for only me, python 3.6x win installer msi, I could select either for all users or just me in manual mode. As I forgot about this, when I wanted to change the env variable, I was always forced to do this with Admin rights, thus never seeing the path variable for myself..... Only after browsing some time and learning that several people had this problem, I recognized that there was a difference between the easy accessible system env variables and the user env variable. (but even in cmd with path command, I did not see the PYTHONPATH variable) Only after knowing how to edit the user env variables, I saw the PYTHONPATH, set to C:\Python364 Hope this helps a little! Greetings, Didi

Philipp Oeser commented

2018-04-06 11:26:34 +02:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2018-04-06 11:26:34 +02:00

Changed status from 'Open' to: 'Resolved'

Philipp Oeser closed this issue

2018-04-06 11:26:34 +02:00

Philipp Oeser commented

2018-04-06 11:26:34 +02:00

Skimming over this I assume this is resolved and can be closed then?

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Python Version in Blender 2.79 and 2.79a #54355