[issue43728] Change the exception type and message raised when _curses is not found.
New submission from Shreyan Avigyan : When importing the curses module, be it on Windows or Darwin or UNIX-based OS or any other platform, if the _curses module is not found then just a ModuleNotFoundError is raised. But this error is not very informational in case of _curses module. Since the curses module is packaged with the Python interpreter itself at first it may seem, to beginners especially, that the Python interpreter was not installed correctly and then they would go searching for an answer for about 4-5 days. We know that curses library is not installed on windows by default and may or may not be present on other operating systems. Most UNIX system have ncurses or other curses library installed by default. Python errors have a reputation of being very informational. I would like to submit a PR to modify the curses module a little bit by declaring a BaseException class and raising that Exception with the message "_curses module not found. Make sure a curses library is installed" or some kind of message like that. But before I do that I would like to take advice from experienced developers about somethings. Is this change in the exception, raised when _curses module is not found, acceptable by the Python Community? If it is then should a draft PEP be submitted or should a PR be directly submitted to python/cpython? -- components: Library (Lib) messages: 390195 nosy: shreyanavigyan priority: normal severity: normal status: open title: Change the exception type and message raised when _curses is not found. type: enhancement versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue43728> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43728] Change the exception type and message raised when _curses is not found.
Shreyan Avigyan added the comment: The curses module is not supported on all platforms is very clear. But beginners may seem to think that their python was not installed properly and then they would go around looking for answer. To make it clear I was thinking of how about changing just the message and if required then the type (maybe CursesNotFoundError exception class derived from ModuleNotFoundError class) so that the error message became a little bit informational. The message could be like "_curses library not installed. Install a supported curses library to use the curses module" or something like that? The exception right now looks like this :- ModuleNotFoundError: No module named '_curses' What about something like this :- CursesNotFoundError: "_curses library not installed. Install a supported curses library to use the curses module." N.B.: The curses library still can be used on Windows by using the UniCurses library or Christoph Gohlke's unofficial curses or some other third party library. -- ___ Python tracker <https://bugs.python.org/issue43728> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43728] Change the exception type and message raised when _curses is not found.
Shreyan Avigyan added the comment: What about only changing the error message to make it a little bit informational? Something like :- ModuleNotFoundError: _curses library not found. Install a supported _curses library to use the curses module. -- ___ Python tracker <https://bugs.python.org/issue43728> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43728] Change the exception type and message raised when _curses is not found.
Shreyan Avigyan added the comment: > Is installing _curses possible, on any supported platform? Or would a better > message say that curses is not supported on this platform? No _curses can't be installed on any platform. I don't know about macOS but _curses can be installed on Windows and Linux (and presumably any UNIX-based OS). On Windows, Christoph Gohlke's unofficial curses, windows-curses and lot's of libraries allows us to use _curses library. Though I think curses can't be used directly on Windows cmd or powershell. Terminals provided by the Mingw-w64 project, the Cygwin project, etc., most presumably support curses library. WSL terminal also seem to support curses (ncurses). So what about a error message like this :- ModuleNotFoundError: _curses library not found. Install a supported _curses library to use the curses module or migrate to a supported platform. N.B.: UniCurses library may work with Windows cmd or powershell because it wraps up the PDCurses library on Windows which was developed specifically to work with Windows. Though UniCurses actually can't be used with the Python built-in module curses. We have to specifically import 'unicurses' to use it. -- ___ Python tracker <https://bugs.python.org/issue43728> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43728] Change the exception type and message raised when _curses is not found.
Shreyan Avigyan added the comment: > "migrate to a supported platform" is almost never practical advice. If we > make any change, I'd just say it's not supported on this platform. Or maybe > "you may be running on platform that is not supported by curses". Ok...So what about a message like this :- ModuleNotFoundError: _curses library not found. Install a supported _curses library to use the curses module (The _curses library may not be supported on your platform). -- ___ Python tracker <https://bugs.python.org/issue43728> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43728] Change the exception type and message raised when _curses is not found.
Shreyan Avigyan added the comment: Is this confirmed? If yes then I'll open a PR on https://github.com/python/cpython -- ___ Python tracker <https://bugs.python.org/issue43728> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43728] Change the exception message raised when _curses is not found.
Change by Shreyan Avigyan : -- title: Change the exception type and message raised when _curses is not found. -> Change the exception message raised when _curses is not found. ___ Python tracker <https://bugs.python.org/issue43728> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43728] Change the exception message raised when _curses is not found.
Shreyan Avigyan added the comment: Is this issue ready for a PR? -- ___ Python tracker <https://bugs.python.org/issue43728> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43728] Change the exception message raised when _curses is not found.
Shreyan Avigyan added the comment: Yeah...I agree. Therefore this issue is resolved and I will close this issue now. Thanks everyone for the advice. With Regards -- ___ Python tracker <https://bugs.python.org/issue43728> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43728] Change the exception message raised when _curses is not found.
Change by Shreyan Avigyan : -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue43728> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43739] Fixing the example code in Doc/extending/extending.rst to declare and initialize the pmodule variable to be of the right type.
New submission from Shreyan Avigyan : In the example code of the Extending Python with C/C++ documentation the pmodule variable (that stores the return value of PyImport_ImportModule) was never declared. The PR(s) attached to this issue fixes it by declaring and initializing the pmodule variable. This issue is common in all the documentation versions. The first PR will be for documentation version 3.10. If it's accepted then I would request other developers to submit PRs for documentation 3.9, 3.8, 3.7 and 3.6 because I'm having a problem switching to those branches (I'm continuously facing the problem "HEAD detached" if I switch to those branches). Thanking you With Regards -- assignee: docs@python components: Documentation messages: 390281 nosy: docs@python, shreyanavigyan priority: normal severity: normal status: open title: Fixing the example code in Doc/extending/extending.rst to declare and initialize the pmodule variable to be of the right type. type: compile error versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue43739> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43739] Fixing the example code in Doc/extending/extending.rst to declare and initialize the pmodule variable to be of the right type.
Shreyan Avigyan added the comment: Please have a review of my change in the documentation. (Note: I have not signed the Python CLA because I think a simple fix in the documentation doesn't require it.) -- ___ Python tracker <https://bugs.python.org/issue43739> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43739] Fixing the example code in Doc/extending/extending.rst to declare and initialize the pmodule variable to be of the right type.
Change by Shreyan Avigyan : -- nosy: +gvanrossum ___ Python tracker <https://bugs.python.org/issue43739> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43739] Fixing the example code in Doc/extending/extending.rst to declare and initialize the pmodule variable to be of the right type.
Shreyan Avigyan added the comment: Please have a review. -- type: compile error -> ___ Python tracker <https://bugs.python.org/issue43739> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43790] CLA check fails with a 500 error
Shreyan Avigyan added the comment: I agree with you. I've faced the same problem. The server sometimes fails with a 500 error and sometimes it works fine. I'm attaching a screenshot of the problem. -- nosy: +shreyanavigyan Added file: https://bugs.python.org/file49951/Server Error 500.png ___ Python tracker <https://bugs.python.org/issue43790> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43790] CLA check fails with a 500 error
Shreyan Avigyan added the comment: I believe that maybe the Heroku server, the CLA Checking tool is deployed to, is facing an internal server problem or the server is down. -- ___ Python tracker <https://bugs.python.org/issue43790> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43739] Fixing the example code in Doc/extending/extending.rst to declare and initialize the pmodule variable to be of the right type.
Shreyan Avigyan added the comment: I've signed the PSF CLA (as it is required) now. Please have a review. -- ___ Python tracker <https://bugs.python.org/issue43739> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43739] Fixing the example code in Doc/extending/extending.rst to declare and initialize the pmodule variable to be of the right type.
Shreyan Avigyan added the comment: I've managed to overcome the "HEAD Detached" problem I was facing when switching to the 3.9, 3.8, 3.7 and 3.6 branches. So I'm also submitting the PRs for those documentation versions. -- ___ Python tracker <https://bugs.python.org/issue43739> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43739] Fixing the example code in Doc/extending/extending.rst to declare and initialize the pmodule variable to be of the right type.
Change by Shreyan Avigyan : -- pull_requests: +24063 pull_request: https://github.com/python/cpython/pull/25330 ___ Python tracker <https://bugs.python.org/issue43739> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43478] Disallow Mock spec arguments from being Mocks
Change by Shreyan Avigyan : -- nosy: +shreyanavigyan nosy_count: 8.0 -> 9.0 pull_requests: +24064 pull_request: https://github.com/python/cpython/pull/25207 ___ Python tracker <https://bugs.python.org/issue43478> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43478] Disallow Mock spec arguments from being Mocks
Change by Shreyan Avigyan : -- pull_requests: -24064 ___ Python tracker <https://bugs.python.org/issue43478> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43478] Disallow Mock spec arguments from being Mocks
Change by Shreyan Avigyan : -- nosy: -shreyanavigyan ___ Python tracker <https://bugs.python.org/issue43478> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43739] Fixing the example code in Doc/extending/extending.rst to declare and initialize the pmodule variable to be of the right type.
Change by Shreyan Avigyan : -- pull_requests: +24065 pull_request: https://github.com/python/cpython/pull/25331 ___ Python tracker <https://bugs.python.org/issue43739> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43790] CLA check fails with a 500 error
Shreyan Avigyan added the comment: Thanks Mariatta. It works now. I'm able to check if I've signed the CLA now. Thanks a lot. -- ___ Python tracker <https://bugs.python.org/issue43790> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43739] Fixing the example code in Doc/extending/extending.rst to declare and initialize the pmodule variable to be of the right type.
Shreyan Avigyan added the comment: Documentation versions older than 3.8 describes a different approach to import the module. Therefore those documentation versions are not to be messed with. I've attached the PRs for documentation versions 3.10, 3.9 and 3.8. Please anyone have a review of my PR as soon as possible. Thanking you, With Regards -- versions: -Python 3.6, Python 3.7 ___ Python tracker <https://bugs.python.org/issue43739> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43804] Add more info about building C/C++ Extensions on Windows using MSVC
New submission from Shreyan Avigyan : In the context of Docs/extending/windows.rst, the command provided, for compiling the source code and linking the libraries to create a DLL, only works for Python 32-bit versions. But the documentation doesn't inform anything about that. The PR linked with this issue adds a note section with the text :- """ The above commands are only applicable for Python 32-bit versions. """ This PR is against the master branch and if accepted, it needs to be backported to all the previous supported versions. Kindly have a review of my PR. Thanking you, With Regards -- assignee: docs@python components: Documentation messages: 390773 nosy: docs@python, shreyanavigyan priority: normal severity: normal status: open title: Add more info about building C/C++ Extensions on Windows using MSVC versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue43804> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43804] Add more info about building C/C++ Extensions on Windows using MSVC
Change by Shreyan Avigyan : -- keywords: +patch pull_requests: +24077 stage: -> patch review pull_request: https://github.com/python/cpython/pull/25343 ___ Python tracker <https://bugs.python.org/issue43804> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43803] ctypes string_at/wstring_at - bad argument name used in docs and in docstring
Shreyan Avigyan added the comment: > I'd favor updating them all to say "ptr", because changing the name of the > runtime parameter would risk breaking users' code. I also certainly agree with that. Moreover, the documentation and docstring uses the name "address" and "addr" respectively which are misleading because it is asking for ctypes.c_char_p or ctypes.c_wchar_p which are C pointer types, it is not asking for the address of instances of ctypes.c_char_p or ctypes.c_wchar_p. Therefore a change in the documentation and docstring is required. Note - If this issue is confirmed then I'll submit a PR to apply the change as described in this issue. -- assignee: -> docs@python components: +Documentation nosy: +docs@python, shreyanavigyan title: ctypes string_at/wstring_at bad argument name -> ctypes string_at/wstring_at - bad argument name used in docs and in docstring ___ Python tracker <https://bugs.python.org/issue43803> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43804] Add more info about building C/C++ Extensions on Windows using MSVC
Shreyan Avigyan added the comment: Kindly have a review of my PR. -- ___ Python tracker <https://bugs.python.org/issue43804> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43803] ctypes string_at/wstring_at - bad argument name used in docs and in docstring
Shreyan Avigyan added the comment: Yeah, you're right and also it is true that changing the docstring to "ptr" can succinctly say "Return the byte string at void *ptr." But it's a kind of problem if different argument names are used for the same argument in docstring, argument list and documentation. If that's the problem then why not change all of them to use the name "address" or "addr" to avoid confusion and make it clear simple. What is your view? -- ___ Python tracker <https://bugs.python.org/issue43803> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43803] ctypes string_at/wstring_at - bad argument name used in docs and in docstring
Shreyan Avigyan added the comment: Ok...let me review again. Having different names for the same argument can cause confusion, right? So are you telling that we should change the name to "ptr" to avoid a breaking change? If this issue is confirmed, I'm ready to submit a PR to make this change. -- ___ Python tracker <https://bugs.python.org/issue43803> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43803] ctypes string_at/wstring_at - bad argument name used in docs and in docstring
Shreyan Avigyan added the comment: Ok..then submitting the PR in 10 minutes. -- ___ Python tracker <https://bugs.python.org/issue43803> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43803] ctypes string_at/wstring_at - bad argument name used in docs and in docstring
Change by Shreyan Avigyan : -- keywords: +patch pull_requests: +24116 stage: -> patch review pull_request: https://github.com/python/cpython/pull/25384 ___ Python tracker <https://bugs.python.org/issue43803> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43803] ctypes string_at/wstring_at - bad argument name used in docs and in docstring
Shreyan Avigyan added the comment: PR opened for this issue. -- ___ Python tracker <https://bugs.python.org/issue43803> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43833] Unexpected Parsing of Numeric Literals Concatenated with Boolean Operators
Shreyan Avigyan added the comment: Hi. I'm totally confused about other keywords but I'm a little concerned about the "and", "or" operator when used on, not only "int" (also known as "long") but also most Python objects other then bool type. Mostly when used on Python built-in objects "and", "or" keyword returns a very peculiar result. The "and" keyword returns the Python object on the left hand side while "or" returns the Python object on the right hand side. This applies to all Python object, built-in or user-defined, unless it has a specific __and__ or __or__ method defined. What is actually going on? -- nosy: +shreyanavigyan ___ Python tracker <https://bugs.python.org/issue43833> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43833] Unexpected Parsing of Numeric Literals Concatenated with Boolean Operators
Shreyan Avigyan added the comment: Hi. I just want to know why is and, or operators behaving like this. The behavior is described in https://bugs.python.org/issue43833#msg390996. Moreover I researched a little more and found out even if __and__, __or__ methods are defined the and, or operators doesn't seem to work. As Serhiy described in https://bugs.python.org/issue43833#msg390998 the parser reads [0x1for x in (1,2)] as [0x1f or x in (1,2)] which is the parser's fault but why is the or operator behaving like that? -- ___ Python tracker <https://bugs.python.org/issue43833> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43833] Unexpected Parsing of Numeric Literals Concatenated with Boolean Operators
Shreyan Avigyan added the comment: @Carl.Friedrich.Bolz Thanks a lot for clarifying. For a second, I thought it was maybe a bug. -- ___ Python tracker <https://bugs.python.org/issue43833> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43804] Add more info about building C/C++ Extensions on Windows using MSVC
Shreyan Avigyan added the comment: Kindly have a review of my PR. -- ___ Python tracker <https://bugs.python.org/issue43804> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43839] [easy] test_cmd_line: DeprecationWarning: invalid escape sequence \u
Change by Shreyan Avigyan : -- nosy: +shreyanavigyan ___ Python tracker <https://bugs.python.org/issue43839> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43492] Upgrade to SQLite 3.35.4 in macOS and Windows
Shreyan Avigyan added the comment: As @steve.dower mentioned that maybe the SQLite team is busy fixing bugs and implementing features in SQLite 3.35. But @erlendaasland, https://sqlite.org/forum/forumpost/d36426225c?t=h has a question related to SQLite 3.35.5 but there was no reply or confirmation from the SQLite team. There maybe a direct SQLite 3.36.0 instead of 3.35.5. Moreover if n o bugs are found in the upcoming SQLite 3.35 release I think it's time to implement that version of SQLite to work with python/cpython or it'll be too late and SQLite 3.36 may be released. -- nosy: +shreyanavigyan ___ Python tracker <https://bugs.python.org/issue43492> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28197] Add start and stop parameters to the range.index() ABC method
Change by Shreyan Avigyan : -- nosy: +shreyanavigyan ___ Python tracker <https://bugs.python.org/issue28197> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43856] Docs for importlib.metadata should mention Python version
Shreyan Avigyan added the comment: importlib.metadata was introduced in Python 3.8. But you're right the docs should mention about the version importlib.metadata was introduced in. -- nosy: +shreyanavigyan ___ Python tracker <https://bugs.python.org/issue43856> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43804] Add more info about building C/C++ Extensions on Windows using MSVC
Shreyan Avigyan added the comment: Please have a review. -- ___ Python tracker <https://bugs.python.org/issue43804> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43858] Provide method to get list of logging level names
Shreyan Avigyan added the comment: I agree with you. It would be nice to have a function to list or dictionary of level names. Moreover I suggest that there should be an argument to the function like format_level which can take in "dict:level_name" for returning a dictionary with the level as keys and name as values, "dict:name_level" for returning a dictionary with the name as keys and level as values or "list" for returning just the list of level names ordered by priority. -- nosy: +shreyanavigyan ___ Python tracker <https://bugs.python.org/issue43858> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43865] win32_ver and getwindowsversion return different Windows 10 build numbers
Shreyan Avigyan added the comment: I'm also able to reproduce the problem you just described. It's actually not the fault of platform.win32_ver. Just type in sys.getwindowsversion().platform_version and you'll achieve a similar result. Behind the scenes platform.win32_ver is actually deriving it's result from sys.getwindowsversion().platform_version. I'm not sure if the result is intended or is a bug but Microsoft seems to claim in this post https://answers.microsoft.com/en-us/insider/forum/insider_wintp-insider_install-insiderplat_pc/wrong-version-of-kernel32dll-in-win10-insider/b0053ba0-f6e5-48f1-86e3-ddac28d6c4eb that both builds are same just the versions are different. -- nosy: +shreyanavigyan ___ Python tracker <https://bugs.python.org/issue43865> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43284] sys.getwindowsversion().platform_version is incorrect
Change by Shreyan Avigyan : -- nosy: +shreyanavigyan ___ Python tracker <https://bugs.python.org/issue43284> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43284] sys.getwindowsversion().platform_version is incorrect
Shreyan Avigyan added the comment: When we're talking about version are we talking about the kernel32.dll version or the Windows version? If we're talking about Windows version then why not use the return value of sys.getwindowsversion() itself? How is that function getting the Windows version? Moreover shouldn't the documentation provide the information that sys.getwindowsversion().platform_version returns the kernel32.dll version? -- ___ Python tracker <https://bugs.python.org/issue43284> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43872] Unable to compile cpython in Visual Studio 2019
New submission from Shreyan Avigyan : Recently, I'm having some problem compiling cpython from Visual Studio 2019. I'm able to compile using the build.bat script. I'm using Visual Studio 2019 for about 2-3 months now for compiling and developing cpython. But unfortunately, some error occurs. While compiling cpython from Visual Studio 2019 the asdl_c.py, if I remember correctly, raises an exception that it was passed no arguments and therefore the build fails. After I compile cpython using build.bat script I'm able to build and rebuild cpython from Visual Studio 2019 without facing any problem for 2-3 days. Then again the error occurs. Can anyone explain to why this is happening? Or is this a bug in cpython? -- messages: 391239 nosy: shreyanavigyan priority: normal severity: normal status: open title: Unable to compile cpython in Visual Studio 2019 type: compile error ___ Python tracker <https://bugs.python.org/issue43872> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43872] Unable to compile cpython in Visual Studio 2019
Change by Shreyan Avigyan : -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue43872> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43872] Unable to compile cpython in Visual Studio 2019
Shreyan Avigyan added the comment: I'm not able to reproduce the error right now. I think I forgot to clean all object files and other stuff created during compilation and therefore was witnessing the error during rebuilding. I'm closing this issue for now. If I come across this error in the future I'll reopen this issue and attach a screenshot of the error. -- ___ Python tracker <https://bugs.python.org/issue43872> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43873] bz2.open() docs give conflicting defaults for mode
Shreyan Avigyan added the comment: The documentation has been corrected in 3.9. Prior to 3.9 the header was bz2.open(filename, mode='r' ...). Now in 3.9 or later the header is bz2.open(filename, mode='rb' ...). -- nosy: +shreyanavigyan ___ Python tracker <https://bugs.python.org/issue43873> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43864] [Windows] test_importlib logs: DeprecationWarning: WindowsRegistryFinder.find_module() is deprecated and slated for removal in Python 3.12; use find_spec() instead
Change by Shreyan Avigyan : -- nosy: +shreyanavigyan ___ Python tracker <https://bugs.python.org/issue43864> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43879] Add native_id to PyThreadState
Change by Shreyan Avigyan : -- nosy: +shreyanavigyan ___ Python tracker <https://bugs.python.org/issue43879> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43284] sys.getwindowsversion().platform_version is incorrect
Shreyan Avigyan added the comment: @eryksun described "Apparently the developers do not want to guarantee that the version information on any particular system DLL can be used to get the system version. Apparently they also do not want to officially sanction using the "CurrentMajorVersionNumber", "CurrentMinorVersionNumber", and "CurrentBuildNumber" values in the registry." If that's the case why not get the version from CurrentBuild registry key present in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion. This key at least goes back to Windows 7 and this is the key that's currently being used by winver command. And I don't think anyone at all uses windows version older than Windows 7. And chances are that the key maybe present even before Windows 7. At least the CurrentBuild is accurate. -- ___ Python tracker <https://bugs.python.org/issue43284> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43284] sys.getwindowsversion().platform_version is incorrect
Shreyan Avigyan added the comment: I researched a little more and found that before Vista the winver command used the CurrentBuildNumber key instead of CurrentBuild key. In fact before Vista CurrentBuild was marked as obsolete by Microsoft. But that changed in Vista, when Microsoft started using CurrentBuild key instead of the CurrentBuildNumber key. Though still today CurrentBuildNumber key actually gives the exact version (for backward compatibilities maybe?). Therefore why not use CurrentBuildNumber? At least CurrentBuildNumber gives the right info. The only problem is that we have to only use that key to determine the windows version (Eg - Windows 10, 8.1, 8, 7, Vista, etc.) and to do that we have to use a very long switch or if-else statement. https://en.wikipedia.org/wiki/Comparison_of_Microsoft_Windows_versions#Windows_NT has the whole list with the column "RTM build" as the CurrentBuildNumber value. -- ___ Python tracker <https://bugs.python.org/issue43284> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43284] sys.getwindowsversion().platform_version is incorrect
Shreyan Avigyan added the comment: But kernel32.dll (since it's of a different version) isn't accurate at all right? To find the accurate result we have to use the CurrentBuildNumber registry key. I think this key will not be removed so easily by Microsoft. This key have been in existence from NT 3.5 till today. I think it's the safest and reliable way to get the version number other than WMI query. I know the key can be removed in the future but if it that happens what about reimplementing the kernel32.dll then. We need a way to get the accurate version right? -- ___ Python tracker <https://bugs.python.org/issue43284> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43804] Add more info about building C/C++ Extensions on Windows using MSVC
Shreyan Avigyan added the comment: Kindly have a review of my PR. -- ___ Python tracker <https://bugs.python.org/issue43804> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43284] sys.getwindowsversion().platform_version is incorrect
Shreyan Avigyan added the comment: But isn't calling CMD's VER command risky? A process can overwrite its PEB OSMajorVersion, OSMinorVersion, and OSBuildNumber. If the cmd has been set to compatibility mode somehow then the same problem will occur since it will then overwrite its PEB OSMajorVersion, OSMinorVersion, and OSBuildNumber. Using a DLL or registry key bypasses this risk. -- ___ Python tracker <https://bugs.python.org/issue43284> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43803] ctypes string_at/wstring_at - bad argument name used in docs and in docstring
Change by Shreyan Avigyan : -- nosy: +amaury.forgeotdarc, belopolsky, meador.inge ___ Python tracker <https://bugs.python.org/issue43803> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43284] sys.getwindowsversion().platform_version is incorrect
Shreyan Avigyan added the comment: Ok. So are you planning to implement this fix? -- ___ Python tracker <https://bugs.python.org/issue43284> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43284] sys.getwindowsversion().platform_version is incorrect
Shreyan Avigyan added the comment: I would like to help to write the fix for this issue. -- ___ Python tracker <https://bugs.python.org/issue43284> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43284] sys.getwindowsversion().platform_version is incorrect
Shreyan Avigyan added the comment: For Windows 10.0.17134 (1803) or above why don't we use the format "maj.min.build.ubr" in platform._norm_version (the function that post-processes the version string and then returns the version string in the format "maj.min.build")? -- ___ Python tracker <https://bugs.python.org/issue43284> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43804] Add more info about building C/C++ Extensions on Windows using MSVC
Shreyan Avigyan added the comment: Kindly have a review of my patch -- ___ Python tracker <https://bugs.python.org/issue43804> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43284] sys.getwindowsversion().platform_version is incorrect
Shreyan Avigyan added the comment: I have a patch for this issue. Should I attach it or should I directly open a PR? -- ___ Python tracker <https://bugs.python.org/issue43284> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43284] sys.getwindowsversion().platform_version is incorrect
Change by Shreyan Avigyan : -- keywords: +patch pull_requests: +24220 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/25500 ___ Python tracker <https://bugs.python.org/issue43284> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43284] sys.getwindowsversion().platform_version is incorrect
Shreyan Avigyan added the comment: PR opened against master branch. -- ___ Python tracker <https://bugs.python.org/issue43284> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43804] Add more info about building C/C++ Extensions on Windows using MSVC
Shreyan Avigyan added the comment: Ping -- ___ Python tracker <https://bugs.python.org/issue43804> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43804] "Building C and C++ Extensions on Windows" docs are very out-of-date
Shreyan Avigyan added the comment: Both https://docs.python.org/3/extending/windows.html#building-on-windows and https://docs.python.org/3/extending/building.html recommends using distutils. As mentioned in PEP 632 distutils will soon be deprecated. I think it'll be a good idea to change the docs to recommend using setuptools and also change the source code for setup.py to use setuptools instead of distutils. -- ___ Python tracker <https://bugs.python.org/issue43804> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43804] "Building C and C++ Extensions on Windows" docs are very out-of-date
Shreyan Avigyan added the comment: I'm attaching a patch for improving "Building C and C++ Extensions on Windows" and "Building C and C++ Extensions" docs. -- Added file: https://bugs.python.org/file49973/patch.patch ___ Python tracker <https://bugs.python.org/issue43804> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43284] sys.getwindowsversion().platform_version is incorrect
Shreyan Avigyan added the comment: @steve.dower Would you mind merging the backport of the PR to the 3.9 branch manually? Apparently there seems to a test failure. I'm not sure why. But it reports that test has been failing recently. -- ___ Python tracker <https://bugs.python.org/issue43284> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43492] Upgrade to SQLite 3.35.5 in macOS and Windows
Shreyan Avigyan added the comment: Do anyone notice any bug in SQLite 3.35.5? If not then I think it's time to upgrade to SQLite 3.35.5. -- ___ Python tracker <https://bugs.python.org/issue43492> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43908] array.array should remain immutable
Change by Shreyan Avigyan : -- nosy: +shreyanavigyan ___ Python tracker <https://bugs.python.org/issue43908> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43916] Check that new heap types cannot be created uninitialised
Change by Shreyan Avigyan : -- nosy: +shreyanavigyan ___ Python tracker <https://bugs.python.org/issue43916> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43908] array.array should remain immutable
Shreyan Avigyan added the comment: > No, multiple tests fail. First test_distutils fails, then during the re-run, > test_multiprocessing_forkserver, test_multiprocessing_spawn, and test_pdb > fail. Can you provide the error output log you're getting? I'm getting a lot of errors for a lot of tests by applying your patch. But the test_pdb error looks related. If test_pdb fails then all the tests after that also fail. I'm not sure if they are related at all. -- ___ Python tracker <https://bugs.python.org/issue43908> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43908] array.array should remain immutable
Shreyan Avigyan added the comment: > I think it is safer to merge apply-to-all.diff, and revert the changes for > individual types if we have reasons to make them mutable. I don't think it's a good idea though. About 10 or 8 tests are failing if apply-to-all.diff is applied. The tests that are not related to it are also failing because of it. After test_pdb fails a segfault error occurs and the remaining tests are never executed. If we want to merge apply-to-all.diff then we need to make some modifications first. -- ___ Python tracker <https://bugs.python.org/issue43908> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43803] ctypes string_at/wstring_at - bad argument name used in docs and in docstring
Shreyan Avigyan added the comment: Ping -- ___ Python tracker <https://bugs.python.org/issue43803> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43908] array.array should remain immutable
Shreyan Avigyan added the comment: > If merely making them immutable again makes tests failing then perhaps there > is something wrong with these tests or there are other bugs which are needed > to be fixed. I've noticed that the test_pdb fails because it expected the a class method to have the __repr__ "some func" but it got "bound method some func at 0x000". This may be the affect of this apply-to-all.diff. Other tests failing were actually fixed in other issues but somehow apply-to-all.diff is suddenly triggering them I think. The most fatal test failures is the test_pdb and test_logging because after those tests failed there were some unexpected behaviors like other tests were executed randomly, segfault and most prominent is that they started compiling by themselves! These are the two tests we should really look into right now. -- ___ Python tracker <https://bugs.python.org/issue43908> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43908] array.array should remain immutable
Shreyan Avigyan added the comment: @serhiy.storchaka I have no idea what's causing the errors I described in https://bugs.python.org/msg391947. I looked at all the changes in apply-to-all.diff and I don't think any of the errors are related. Do you have any thoughts about this problem? Is it even reproducible? (I'm attaching a diff combining the patch.diff and apply-to-all.diff together in one file.) -- Added file: https://bugs.python.org/file49988/patch.diff ___ Python tracker <https://bugs.python.org/issue43908> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43908] array.array should remain immutable
Change by Shreyan Avigyan : Removed file: https://bugs.python.org/file49988/patch.diff ___ Python tracker <https://bugs.python.org/issue43908> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43908] array.array should remain immutable
Shreyan Avigyan added the comment:
> The solution would be bisection -- apply half of the changes from
apply-to-all, and see if you still get the errors. Etc.
Getting the same error. These are the errors :-
0:12:14 load avg: 0.92 [115/426] test_distutils
test test_distutils crashed -- Traceback (most recent call last):
File "C:\github\cpython\lib\test\libregrtest\runtest.py", line 282, in
_runtest_inner
refleak = _runtest_inner2(ns, test_name)
File "C:\github\cpython\lib\test\libregrtest\runtest.py", line 229, in
_runtest_inner2
the_module = importlib.import_module(abstest)
File "C:\github\cpython\lib\importlib\__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "", line 1050, in _gcd_import
File "", line 1027, in _find_and_load
File "", line 1006, in _find_and_load_unlocked
File "", line 688, in _load_unlocked
File "", line 881, in exec_module
File "", line 241, in _call_with_frames_removed
File "C:\github\cpython\lib\test\test_distutils.py", line 15, in
import distutils.tests
File "C:\github\cpython\lib\contextlib.py", line 140, in __exit__
next(self.gen)
File "C:\github\cpython\lib\test\support\warnings_helper.py", line 179, in
_filterwarnings
raise AssertionError("filter (%r, %s) did not catch any warning" %
AssertionError: filter ('The distutils package is deprecated',
DeprecationWarning) did not catch any warning
0:19:05 load avg: 0.07 [212/426/1] test_logging
--- Logging error ---
Traceback (most recent call last):
File "C:\github\cpython\lib\logging\handlers.py", line 74, in emit
self.doRollover()
File "C:\github\cpython\lib\logging\handlers.py", line 179, in doRollover
self.rotate(self.baseFilename, dfn)
File "C:\github\cpython\lib\logging\handlers.py", line 117, in rotate
self.rotator(source, dest)
File "C:\github\cpython\lib\test\test_logging.py", line 5222, in rotator
os.rename(source, dest + ".rotated")
FileExistsError: [WinError 183] Cannot create a file when that file already
exists: 'C:\\Users\\shrey\\AppData\\Local\\Temp\\test_logging-2-lh2g0lpt.log'
->
'C:\\Users\\shrey\\AppData\\Local\\Temp\\test_logging-2-lh2g0lpt.log.1.test.rotated'
Call stack:
File "C:\github\cpython\lib\runpy.py", line 196, in _run_module_as_main
return _run_code(code, main_globals, None,
File "C:\github\cpython\lib\runpy.py", line 86, in _run_code
exec(code, run_globals)
File "C:\github\cpython\lib\test\__main__.py", line 2, in
main()
File "C:\github\cpython\lib\test\libregrtest\main.py", line 719, in main
Regrtest().main(tests=tests, **kwargs)
File "C:\github\cpython\lib\test\libregrtest\main.py", line 641, in main
self._main(tests, kwargs)
File "C:\github\cpython\lib\test\libregrtest\main.py", line 694, in _main
self.run_tests()
File "C:\github\cpython\lib\test\libregrtest\main.py", line 521, in run_tests
self.run_tests_sequential()
File "C:\github\cpython\lib\test\libregrtest\main.py", line 423, in
run_tests_sequential
result = runtest(self.ns, test_name)
File "C:\github\cpython\lib\test\libregrtest\runtest.py", line 194, in runtest
return _runtest(ns, test_name)
File "C:\github\cpython\lib\test\libregrtest\runtest.py", line 154, in
_runtest
result = _runtest_inner(ns, test_name,
File "C:\github\cpython\lib\test\libregrtest\runtest.py", line 282, in
_runtest_inner
refleak = _runtest_inner2(ns, test_name)
File "C:\github\cpython\lib\test\libregrtest\runtest.py", line 246, in
_runtest_inner2
test_runner()
File "C:\github\cpython\lib\test\support\__init__.py", line 682, in inner
return func(*args, **kwds)
File "C:\github\cpython\lib\test\test_logging.py", line 5503, in test_main
support.run_unittest(*tests)
File "C:\github\cpython\lib\test\support\__init__.py", line 1082, in
run_unittest
_run_suite(suite)
File "C:\github\cpython\lib\test\support\__init__.py", line 959, in _run_suite
result = runner.run(suite)
File "C:\github\cpython\lib\test\support\testresult.py", line 169, in run
test(self.result)
File "C:\github\cpython\lib\unittest\suite.py", line 84, in __call__
return self.run(*args, **kwds)
File "C:\github\cpython\lib\unittest\suite.py", line 122, in run
test(result)
File "C:\github\cpython\lib\unittest\suite.py", line 84, in __call__
return self.run(*args, **kwds)
File "C:\github\cpython\lib\unittest\suite.py", line 122, in run
test(result)
File "C:\github\cpython\lib\unittest\case.py", line 652,
[issue43908] array.array should remain immutable
Shreyan Avigyan added the comment: I ran the test suite without the changes and they still fail. Therefore apply-to-all.diff does not have any bug at all. But the test failures are also a major issue not only for this change but also for others. I'm opening a new issue for those test failures. (apply-to-all.diff is outdated because Erlend changed the flag name from Py_TPFLAGS_IMMUTABLE to Py_TPFLAGS_IMMUTABLETYPE in the PR. I'm attaching the modified apply-to-all.diff) -- Added file: https://bugs.python.org/file49990/apply-to-all.diff ___ Python tracker <https://bugs.python.org/issue43908> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43492] Upgrade to SQLite 3.35.5 in macOS and Windows
Shreyan Avigyan added the comment: Updating the source. https://github.com/python/cpython-source-deps/pull/24 -- ___ Python tracker <https://bugs.python.org/issue43492> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43492] Upgrade to SQLite 3.35.5 in macOS and Windows
Shreyan Avigyan added the comment: Ok. I'm closing https://github.com/python/cpython-source-deps/pull/24 then. -- ___ Python tracker <https://bugs.python.org/issue43492> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43908] array.array should remain immutable
Shreyan Avigyan added the comment: Re-running the failed tests doesn't trigger the errors but running the whole test suite does. And some errors I described are fixed in any of the last 22 commits and PRs. Therefore should we actually look into this matter or should we leave it as it is? -- ___ Python tracker <https://bugs.python.org/issue43908> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43864] [Windows] test_importlib logs: DeprecationWarning: WindowsRegistryFinder.find_module() is deprecated and slated for removal in Python 3.12; use find_spec() instead
Shreyan Avigyan added the comment: Can you reopen this issue? Brett forgot to silence another warning in WindowsRegistryFinderTests class. I'm opening a PR for that. -- ___ Python tracker <https://bugs.python.org/issue43864> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43864] [Windows] test_importlib logs: DeprecationWarning: WindowsRegistryFinder.find_module() is deprecated and slated for removal in Python 3.12; use find_spec() instead
Change by Shreyan Avigyan : -- pull_requests: +24347 pull_request: https://github.com/python/cpython/pull/25656 ___ Python tracker <https://bugs.python.org/issue43864> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43908] array.array should remain immutable
Shreyan Avigyan added the comment: Let me re-run the test suite again and see if the tests have been fixed in the most recent commits. -- ___ Python tracker <https://bugs.python.org/issue43908> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43908] array.array should remain immutable
Shreyan Avigyan added the comment: > Shreyan, are you running the tests against the PR, or something else? Have > you tried make clean (or git clean -fdx)? I always have a clean branch checked out but the last time I ran the tests it was unsuccessful. I'm re-running the tests now and hoping that the tests will be successful this time. However lot of tests have been fixed. -- ___ Python tracker <https://bugs.python.org/issue43908> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43908] array.array should remain immutable
Shreyan Avigyan added the comment: Re-running tests complete. I'm attaching the results. If the errors are not reproducible then please tell. I'll then rebuild and rerun the tests once more. -- Added file: https://bugs.python.org/file49994/tests_log.txt ___ Python tracker <https://bugs.python.org/issue43908> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43908] array.array should remain immutable
Shreyan Avigyan added the comment: There are no errors in apply-to-all.diff because I've ran the tests both with and without the changes and both give me the same output. It's safe to proceed with apply-to-all.diff. The only problem is why are the tests failing at all? I ran the tests a few days earlier on this machine only (Windows 10) and it was successful then. -- ___ Python tracker <https://bugs.python.org/issue43908> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43908] array.array should remain immutable
Shreyan Avigyan added the comment: Since, these changes and the test failures are not related to each other at all, I'm opening a new issue addressing the test failures only. I'm adding everyone in this issue's nosy to the new issue's nosy as well. -- ___ Python tracker <https://bugs.python.org/issue43908> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43955] Test Failures on Windows 10
New submission from Shreyan Avigyan : Recent test failures have been noticed on Windows 10. The full test log has been attached. The tests test_distutils, test_pdb, test_signal and test_threading require a little bit of attention since there seems to be some kind of error. -- components: Windows files: tests_log.txt messages: 392104 nosy: Guido.van.Rossum, Mark.Shannon, christian.heimes, corona10, erlendaasland, gvanrossum, pablogsal, paul.moore, serhiy.storchaka, shihai1991, shreyanavigyan, steve.dower, tim.golden, vstinner, zach.ware priority: normal severity: normal status: open title: Test Failures on Windows 10 versions: Python 3.10 Added file: https://bugs.python.org/file49995/tests_log.txt ___ Python tracker <https://bugs.python.org/issue43955> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43908] array.array should remain immutable
Shreyan Avigyan added the comment: See issue https://bugs.python.org/issue43955 for the test failures. -- ___ Python tracker <https://bugs.python.org/issue43908> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43955] Test Failures on Windows 10
Shreyan Avigyan added the comment: Pdb error source - https://github.com/python/cpython/blob/9aea31deddf7458be3546f72185740f3cd06687f/Lib/test/test_pdb.py#L1270 This is where the error in Pdb is originating from. -- ___ Python tracker <https://bugs.python.org/issue43955> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43955] Test Failures on Windows 10
Shreyan Avigyan added the comment: The test expects the but gets sigint_handler method of a pdb.Pdb instance instead. -- ___ Python tracker <https://bugs.python.org/issue43955> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43955] Test Failures on Windows 10
Shreyan Avigyan added the comment: Yes you're right. Running the failed tests individually does not trigger the errors. And the (Pdb) continue (Pdb) continue (Pdb) continue (Pdb) continue actually is manually entered by me. My tests also stop at that prompt but somehow entering these commands again allow us to continue. Why are the errors triggering at all? The tests that are failing when ran alongside the test suite haven't been messed with for a very long time now and still somehow out of the blue they are failing. Any thoughts? -- ___ Python tracker <https://bugs.python.org/issue43955> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43955] Windows: Running the Python test suite sequentially is interrupted by (Pdb) prompt
Shreyan Avigyan added the comment: Another issue with the tests is that it has become terribly slow. It's taking about 45 minutes to complete 1 run of the test suite. A few days ago, it took only 10 - 15 minutes. And moreover I think test_threading is also modifying sys.gettrace. The logs have the full error message. --Snippet-- 0:33:17 load avg: 0.80 [307/426/2] test_signal (Pdb) continue Warning -- sys.gettrace was modified by test_signal Before: None After: > test test_signal failed -- Traceback (most recent call last): File "C:\github\cpython\lib\test\test_signal.py", line 1345, in test_sigint signal.raise_signal(signal.SIGINT) AssertionError: KeyboardInterrupt not raised --Snippet-- 0:38:22 load avg: 0.04 [353/426/3] test_threading (Pdb) continue (Pdb) continue (Pdb) continue (Pdb) continue Warning -- sys.gettrace was modified by test_threading Before: None After: > --Snippet-- -- ___ Python tracker <https://bugs.python.org/issue43955> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43955] Windows: Running the Python test suite sequentially is interrupted by (Pdb) prompt
Shreyan Avigyan added the comment: Same errors. (Recompilation was done 1 or 2 hours ago against the then updated master branch. It may not include the latest commit) -- ___ Python tracker <https://bugs.python.org/issue43955> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43955] Windows: Running the Python test suite sequentially is interrupted by (Pdb) prompt
Shreyan Avigyan added the comment: FYI test_signal is no longer modifying sys.gettrace thanks to your fix. But test_threading still does. Do you have a fix for that? -- ___ Python tracker <https://bugs.python.org/issue43955> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43955] Windows: Running the Python test suite sequentially is interrupted by (Pdb) prompt
Shreyan Avigyan added the comment: I ran the test again and test_signal still modifies sys.gettrace() -- ___ Python tracker <https://bugs.python.org/issue43955> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
