[issue40939] Remove the old parser
Nikita Nemkin added the comment: > Unfortunately there is no official maintained list if those symbols, so is > taking a while On Windows there is PC/python3dll.c. -- ___ Python tracker <https://bugs.python.org/issue40939> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40861] On Windows, liblzma is always built without optimization
New submission from Nikita Nemkin : Windows build system always builds liblzma with optimizations disabled (/Od), even in Release configuration. Compared to optimized build (/O2), compression speed is 2-2.5x slower and module size is 30% larger. -- components: Build messages: 370702 nosy: nnemkin priority: normal severity: normal status: open title: On Windows, liblzma is always built without optimization type: performance versions: Python 3.10, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue40861> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41038] VersionInfo string is corrupted when building on Windows with DBCS or UTF-8 locale
New submission from Nikita Nemkin : In absence of explicit declaration, resource compiler uses system codepage. When this codepage is DBCS or UTF-8, Python's copyright string is corrupted, because it contains copyright sign encoded as \xA9. The fix is to explicitly declare codepage 1252. Another possible fix is to use codepage 65001, but that will require replacing \xA9 with an actual ©, because it seems impossible to escape unicode characters in VersionInfo strings. -- components: Windows messages: 371888 nosy: nnemkin, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: VersionInfo string is corrupted when building on Windows with DBCS or UTF-8 locale type: behavior versions: Python 3.10, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue41038> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41038] VersionInfo string is corrupted when building on Windows with DBCS or UTF-8 locale
Change by Nikita Nemkin : -- keywords: +patch pull_requests: +20159 stage: -> patch review pull_request: https://github.com/python/cpython/pull/20985 ___ Python tracker <https://bugs.python.org/issue41038> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41039] Simplify python3.dll build
New submission from Nikita Nemkin : python3.dll build process can be simplified if we use linker comment #pragma instead of .def files. Custom build targets become unnecessary and hardcoded Python DLL name can be replaced with a macro. Also, python3.dll doesn't need DllMain and can be built with /NOENTRY. -- components: Windows messages: 371894 nosy: nnemkin, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Simplify python3.dll build type: enhancement versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue41039> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41039] Simplify python3.dll build
Change by Nikita Nemkin : -- keywords: +patch pull_requests: +20163 stage: -> patch review pull_request: https://github.com/python/cpython/pull/20989 ___ Python tracker <https://bugs.python.org/issue41039> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40939] Remove the old parser
Nikita Nemkin added the comment: Shouldn't the following files be deleted too? Include/bitset.h Include/grammar.h Include/graminit.h Include/parsetok.h Include/node.h Python/graminit.c Parser/node.c Also declarations: PyNode_Compile in Include/compile.h PyParser_SimpleParse* in Include/pythonrun.h And PyParser_ASTFrom* API need new implementations. -- nosy: +nnemkin ___ Python tracker <https://bugs.python.org/issue40939> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41054] Simplify resource compilation on Windows
New submission from Nikita Nemkin : Every Windows project has a custom target (included from pyproject.props) that generates a header with definitions for resource files. Those definitions (PYTHON_DLL_NAME and FIELD3) can be passed directly to resource compiler. Another definition (MS_DLL_ID) doesn't need to be a resource at all. It was used in the past to initialize PyWin_DLLVersionString in dl_nt.c, but that code is now dead. -- components: Windows messages: 371941 nosy: nnemkin, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Simplify resource compilation on Windows type: enhancement versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue41054> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41054] Simplify resource compilation on Windows
Change by Nikita Nemkin : -- keywords: +patch pull_requests: +20178 stage: -> patch review pull_request: https://github.com/python/cpython/pull/21004 ___ Python tracker <https://bugs.python.org/issue41054> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41070] Simplify pyshellext.dll build
New submission from Nikita Nemkin : pyshellext uses MIDL to generate a header, whose only purpose is to define a class GUID. MIDL generation step can be replaced with a simple #define. This doesn't really matter for VS, but other build systems (CMake, probably Meson too) will benefit. pyshellext has separate .def files for debug and release builds. One .def file is sufficient, because LIBRARY statement is optional. Using __declspec(dllexport) isn't an option, because Windows headers misdeclare DllCanUnloadNow and DllGetClassObject... -- components: Windows messages: 372032 nosy: nnemkin, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Simplify pyshellext.dll build type: enhancement versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue41070> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41070] Simplify pyshellext.dll build
Change by Nikita Nemkin : -- keywords: +patch pull_requests: +20209 stage: -> patch review pull_request: https://github.com/python/cpython/pull/21037 ___ Python tracker <https://bugs.python.org/issue41070> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41039] Simplify python3.dll build
Nikita Nemkin added the comment: Please take your time. FWIW, I tested this patch by 1) comparing dumpbin /exports output; 2) comparing bunaries themselves (.dll and .lib) and 3) linking xxlmited module. It helps that 7-zip can open .dll and .lib files files as if they were archives. -- ___ Python tracker <https://bugs.python.org/issue41039> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41089] Filters and other issues in Visual Studio projects
New submission from Nikita Nemkin : Visual Studio projects need a bit of grooming. * File filters don't reflect recent file movements and additions. * Solution file is missing _zoneinfo project entries, resulting in dirty repo on every save. * bdist_wininst project hasn't been updated with the new zlib location. -- components: Windows messages: 372158 nosy: nnemkin, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Filters and other issues in Visual Studio projects type: enhancement versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue41089> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41089] Filters and other issues in Visual Studio projects
Change by Nikita Nemkin : -- keywords: +patch pull_requests: +20239 stage: -> patch review pull_request: https://github.com/python/cpython/pull/21070 ___ Python tracker <https://bugs.python.org/issue41089> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41070] Simplify pyshellext.dll build
Nikita Nemkin added the comment: Thanks for reviewing my patches so quickly, Steve. There's one last Windows-specific patch left (https://bugs.python.org/issue41038). Single-line change. -- ___ Python tracker <https://bugs.python.org/issue41070> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27417] Call CoInitializeEx on startup
Nikita Nemkin added the comment: COM should be initialized on demand by C modules that need it. They might need STA or MTA, it's their choice to make. Python core (ceval and builtins) doesn't need COM and shouldn't impose COM threading models on any threads it creates. Things like -X:STA are not Python's concern at all. Python code (interpreted) can't access COM objects directly, it always goes through C modules, which know better. Also, COM using apps are very likely to be GUI apps and need STA main thread. MTA by default makes no sense. PS. AMSI is insane. In what world would Pyhton interpteter send my code for analysis to who knows where and without even an option to disable it (because "security")? -- nosy: +nnemkin ___ Python tracker <http://bugs.python.org/issue27417> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17345] Portable and extended type specifiers for array module
New submission from Nikita Nemkin:
Currently array module only provides platform-dependent type specifiers.
It would be very nice to have platform-independent specifiers in addition to
that, matching the struct module.
For example array(' an array of little-endian 2-byte integers.
This issue crops up every time when I use array(). Binary data usually comes in
some predefined format and a manual matching to native format has to be done
(assuming I want to write portable code).
A useful extra would be to support multi-element struct specifiers and present
an array of tuples in this case.
For example array('iff') -> an array of tuples (int, float, float) with native
types.
--
components: Library (Lib)
messages: 183425
nosy: nnemkin
priority: normal
severity: normal
status: open
title: Portable and extended type specifiers for array module
type: enhancement
versions: Python 3.4
___
Python tracker
<http://bugs.python.org/issue17345>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
