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
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
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
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 installe
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&qu
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/is
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/issu
Shreyan Avigyan added the comment:
Is this issue ready for a PR?
--
___
Python tracker
<https://bugs.python.org/issue43728>
___
___
Python-bugs-list mailin
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/issue43
Change by Shreyan Avigyan :
--
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue43728>
___
___
Python-bugs-list
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
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
&
Change by Shreyan Avigyan :
--
nosy: +gvanrossum
___
Python tracker
<https://bugs.python.org/issue43739>
___
___
Python-bugs-list mailing list
Unsubscribe:
Shreyan Avigyan added the comment:
Please have a review.
--
type: compile error ->
___
Python tracker
<https://bugs.python.org/issue43739>
___
___
Python-
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/Se
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/issue43
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/is
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.
--
__
Change by Shreyan Avigyan :
--
pull_requests: +24063
pull_request: https://github.com/python/cpython/pull/25330
___
Python tracker
<https://bugs.python.org/issue43
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/issu
Change by Shreyan Avigyan :
--
pull_requests: -24064
___
Python tracker
<https://bugs.python.org/issue43478>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Shreyan Avigyan :
--
nosy: -shreyanavigyan
___
Python tracker
<https://bugs.python.org/issue43478>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Shreyan Avigyan :
--
pull_requests: +24065
pull_request: https://github.com/python/cpython/pull/25331
___
Python tracker
<https://bugs.python.org/issue43
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.o
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 revi
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 l
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/issu
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 "a
Shreyan Avigyan added the comment:
Kindly have a review of my PR.
--
___
Python tracker
<https://bugs.python.org/issue43804>
___
___
Python-bugs-list mailin
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
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
Shreyan Avigyan added the comment:
Ok..then submitting the PR in 10 minutes.
--
___
Python tracker
<https://bugs.python.org/issue43803>
___
___
Python-bug
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/issu
Shreyan Avigyan added the comment:
PR opened for this issue.
--
___
Python tracker
<https://bugs.python.org/issue43803>
___
___
Python-bugs-list mailin
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.
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
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/issue43
Shreyan Avigyan added the comment:
Kindly have a review of my PR.
--
___
Python tracker
<https://bugs.python.org/issue43804>
___
___
Python-bugs-list mailin
Change by Shreyan Avigyan :
--
nosy: +shreyanavigyan
___
Python tracker
<https://bugs.python.org/issue43839>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
Change by Shreyan Avigyan :
--
nosy: +shreyanavigyan
___
Python tracker
<https://bugs.python.org/issue28197>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
&
Shreyan Avigyan added the comment:
Please have a review.
--
___
Python tracker
<https://bugs.python.org/issue43804>
___
___
Python-bugs-list mailing list
Unsub
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
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_
Change by Shreyan Avigyan :
--
nosy: +shreyanavigyan
___
Python tracker
<https://bugs.python.org/issue43284>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 t
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, so
Change by Shreyan Avigyan :
--
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue43872>
___
___
Python-bugs-list
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 thi
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
__
Change by Shreyan Avigyan :
--
nosy: +shreyanavigyan
___
Python tracker
<https://bugs.python.org/issue43864>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Shreyan Avigyan :
--
nosy: +shreyanavigyan
___
Python tracker
<https://bugs.python.org/issue43879>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 usin
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
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
Shreyan Avigyan added the comment:
Kindly have a review of my PR.
--
___
Python tracker
<https://bugs.python.org/issue43804>
___
___
Python-bugs-list mailin
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
overwri
Change by Shreyan Avigyan :
--
nosy: +amaury.forgeotdarc, belopolsky, meador.inge
___
Python tracker
<https://bugs.python.org/issue43803>
___
___
Python-bug
Shreyan Avigyan added the comment:
Ok. So are you planning to implement this fix?
--
___
Python tracker
<https://bugs.python.org/issue43284>
___
___
Python-bug
Shreyan Avigyan added the comment:
I would like to help to write the fix for this issue.
--
___
Python tracker
<https://bugs.python.org/issue43284>
___
___
Pytho
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
Shreyan Avigyan added the comment:
Kindly have a review of my patch
--
___
Python tracker
<https://bugs.python.org/issue43804>
___
___
Python-bugs-list mailin
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/issue43
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/issu
Shreyan Avigyan added the comment:
PR opened against master branch.
--
___
Python tracker
<https://bugs.python.org/issue43284>
___
___
Python-bugs-list mailin
Shreyan Avigyan added the comment:
Ping
--
___
Python tracker
<https://bugs.python.org/issue43804>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 c
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
_
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 rec
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/is
Change by Shreyan Avigyan :
--
nosy: +shreyanavigyan
___
Python tracker
<https://bugs.python.org/issue43908>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Shreyan Avigyan :
--
nosy: +shreyanavigyan
___
Python tracker
<https://bugs.python.org/issue43916>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 o
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
Shreyan Avigyan added the comment:
Ping
--
___
Python tracker
<https://bugs.python.org/issue43803>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 c
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 p
Change by Shreyan Avigyan :
Removed file: https://bugs.python.org/file49988/patch.diff
___
Python tracker
<https://bugs.python.org/issue43908>
___
___
Python-bugs-list m
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 cras
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
Shreyan Avigyan added the comment:
Updating the source. https://github.com/python/cpython-source-deps/pull/24
--
___
Python tracker
<https://bugs.python.org/issue43
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/is
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
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/is
Change by Shreyan Avigyan :
--
pull_requests: +24347
pull_request: https://github.com/python/cpython/pull/25656
___
Python tracker
<https://bugs.python.org/issue43
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/issue43
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
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/tes
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 t
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
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
Shreyan Avigyan added the comment:
See issue https://bugs.python.org/issue43955 for the test failures.
--
___
Python tracker
<https://bugs.python.org/issue43
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
<ht
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/issue43
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
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
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/issue43
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/issue43
Shreyan Avigyan added the comment:
I ran the test again and test_signal still modifies sys.gettrace()
--
___
Python tracker
<https://bugs.python.org/issue43
1 - 100 of 238 matches
Mail list logo
