GeezerVison is showing github.com — Add version info to python · Issue #67207 · python/cpython
Add version info to python #67207Description
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = 'https://github.com/zooba'
closed_at = <Date 2015-02-20.17:13:35.201>
created_at = <Date 2014-12-09.05:27:42.744>
labels = ['type-feature', 'OS-windows']
title = 'Add version info to python'
updated_at = <Date 2015-02-20.17:13:35.201>
user = 'https://github.com/zooba' bugs.python.org fields:
activity = <Date 2015-02-20.17:13:35.201>
actor = 'python-dev'
assignee = 'steve.dower'
closed = True
closed_date = <Date 2015-02-20.17:13:35.201>
closer = 'python-dev'
components = ['Windows']
creation = <Date 2014-12-09.05:27:42.744>
creator = 'steve.dower'
dependencies = []
files = ['37393']
hgrepos = []
issue_num = 23018
keywords = ['patch']
message_count = 13.0
messages = ['232345', '232346', '233267', '233868', '233906', '233947', '234018', '234089', '236267', '236303', '236307', '236309', '236311']
nosy_count = 5.0
nosy_names = ['tim.golden', 'python-dev', 'zach.ware', 'serhiy.storchaka', 'steve.dower']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue23018'
versions = ['Python 3.5'] Activityzooba commented on Dec 9, 2014 We should include the version resource in python[w].exe as well as python35.dll so that it can be properly identified. (If possible, we should do .pyd files too, though I don't think the version info will be displayed, so it's probably not worth it.) zooba commented on Dec 9, 2014 Patch for the version info, and also for half of bpo-19143 since I was there. zooba commented on Dec 31, 2014 zooba commented on Jan 12, 2015 Anyone have any opinions on this? My only hesitation is adding the Windows 10 UUID, which will fix GetVersion but may cause other API problems, and we're certainly not testing against Windows 10 yet. (On the other hand, it's easy enough to remove that single UUID later if there's an issue we can't fix.)
I'm keen to put it in and forget about it, so if not, I'll just do it :) tjguk commented on Jan 13, 2015 Steve, could you outline the need / impact for this, please? (ie can you inform my ignorance?). zooba commented on Jan 13, 2015 Sure :)
If you view Properties in Windows for Python 3.4's python[w].exe and look at the Details tab, it's very blank (for me it shows 'Application', the size and the modification date). However, if you look at python34.dll or py.exe it has a description, version, copyright message, etc. The first part of the patch adds this information to python[w].exe as well.
The second part is dealing with bpo-19143, which is where GetVersion() lies about the Windows version if you haven't explicitly declared that you know about that version. Currently on Windows 8.1 (and 10), sys.getwindowsversion() will tell you that it's Windows 8 (6.2.9200).
The patch here adds the declarations to a manifest file such that Python 3.5 is "aware" of Windows 8.1 and so it doesn't need the compatibility shims/version lies that are otherwise applied. (The patch on bpo-19143 is for the platform module so that it will always read the correct version, but this is intended for logging/system info rather than making decisions about API availability and behaviour.) tjguk commented on Jan 14, 2015 changed the title [-]Add version info to python[w].exe[/-] [+]Add version info to python[/+] on Jan 14, 2015python-dev commented on Jan 15, 2015 serhiy-storchaka commented on Feb 20, 2015 PC/python_ver_rc.h now is not compatible with clinic.py.
$ ./python Tools/clinic/clinic.py --make
Traceback (most recent call last):
File "Tools/clinic/clinic.py", line 4204, in <module>
sys.exit(main(sys.argv[1:]))
File "Tools/clinic/clinic.py", line 4184, in main
parse_file(path, force=ns.force, verify=not ns.force)
File "Tools/clinic/clinic.py", line 1743, in parse_file
raw = f.read()
File "/home/serhiy/py/cpython/Lib/codecs.py", line 321, in decode
(result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xa9 in position 199: invalid start byteEither convert PC/python_ver_rc.h to UTF-8, or escape copyright sign "©" as "\xa9" (if Latin1 is needed), or replace it witch ASCII "(c)". zooba commented on Feb 20, 2015 Looks like the .rc files should actually be UCS-2, since that's how the strings are going to be stored into the executables.
If I rename the .h file to .h_ (and change the encoding to UCS-2 with BOM), will it be ignored by argument clinic? serhiy-storchaka commented on Feb 20, 2015 I afraid that adding source file that can't be easy handled by Unix text tools (such as diff) is not good idea. Does "\xa9" work? zooba commented on Feb 20, 2015 Digging around the likely encodings to be running on Windows machines, it looks like 0xA9 is always the right symbol, so that change should be fine. python-dev commented on Feb 20, 2015
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|