[issue32133] documentation: numbers module nitpick
Bhaskara Aditya Sriram added the comment: I would like work on this, but I'm very new to fixing bugs. Could someone please help me on how to proceed with this bug. Thank You in advance -- nosy: +adityasriram.b ___ Python tracker <https://bugs.python.org/issue32133> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35375] name shadowing while a module tries to import another
Sriram Krishna added the comment: Already covered in issue29929: https://bugs.python.org/issue29929. Thanks xtreak for the link to the message thread. PEP 432 seems to have methods to resolve this. Currently if the code doesn't access to .local, one can use the -I commandline option and use from . import module for local imports. -- resolution: -> duplicate stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue35375> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35375] name shadowing while a module tries to import another
Sriram Krishna added the comment: My contention is that this behaviour breaks the Principle of Least Astonishment. In the particular example I gave, the user doesn't know (and can't be expected to know) the existence of a module called profile in the standard library. Here the user is not explicitly importing profile. The user can't be expected to know which submodules are imported by the modules they use. Hence they wouldn't expect another file sitting in the same directory to get imported when they are not explicitly importing it. on 2018-12-02 10:35, pmpp said: > you can avoid that with > import sys,os > sys.path.remove( os.getcwd() ) > at the start of your program. completely removing cwd from sys.path would disable the option of importing user modules. Any method of fixing this would be backwards incompatible, and will break some (most likely badly written) code. My hack solution was to have cwd in sys.path only if __name__ is '__main__'. -- ___ Python tracker <https://bugs.python.org/issue35375> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35375] name shadowing while a module tries to import another
New submission from Sriram Krishna : Suppose I have a file profile.py in the same directory as the file I am running (say test.py) Let the contents of the files be: profile.py: raise Exception test.py: import cProfile now if I run test.py $ python test.py Traceback (most recent call last): File "test.py", line 1, in import cProfile File "/usr/lib/python3.7/cProfile.py", line 10, in import profile as _pyprofile File "/home/username/profile.py", line 1, in raise Exception Exception The file profile.py in '/usr/lib/python3.7' should have been loaded. This would also happen if test.py imported a module or package which imported cProfile. The only possible way of avoiding this problem completely is by ensuring that the name of any the python files don't match a builtin python file or the name of any installed package. A python user can't be expected to know the name of every possible file in the Python standard library. Maybe the current working directory should be removed from sys.path when importing from within another module not in the same directory. -- components: Interpreter Core messages: 330874 nosy: ksriram priority: normal severity: normal status: open title: name shadowing while a module tries to import another type: behavior versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue35375> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31090] import error for numpy
Sriram added the comment: Yes, i just found that after creating the issue, Sorry. Anyhow thanks for quick response, i have addressed this to numpy team. https://github.com/numpy/numpy/issues/9501 -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31090> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31090] import error for numpy
New submission from Sriram: When i tried to import numpy for any program in VS 2017, it returns with Import Error. Traceback (most recent call last): File "C:\Program Files\Python36\lib\site-packages\numpy\core\__init__.py", line 16, in from . import multiarray ImportError: DLL load failed: The specified procedure could not be found. During handling of the above exception, another exception occurred: Traceback (most recent call last): File "C:\Users\Sriram Sudharsan\documents\visual studio 2017\Projects\TestApp1\TestApp1\TestApp1.py", line 1, in import numpy as np File "C:\Program Files\Python36\lib\site-packages\numpy\__init__.py", line 142, in from . import add_newdocs File "C:\Program Files\Python36\lib\site-packages\numpy\add_newdocs.py", line 13, in from numpy.lib import add_newdoc File "C:\Program Files\Python36\lib\site-packages\numpy\lib\__init__.py", line 8, in from .type_check import * File "C:\Program Files\Python36\lib\site-packages\numpy\lib\type_check.py", line 11, in import numpy.core.numeric as _nx File "C:\Program Files\Python36\lib\site-packages\numpy\core\__init__.py", line 26, in raise ImportError(msg) ImportError: Importing the multiarray numpy extension module failed. Most likely you are trying to import a failed build of numpy. If you're working with a numpy git repo, try `git clean -xdf` (removes all files not under version control). Otherwise reinstall numpy. Original error was: DLL load failed: The specified procedure could not be found. Press any key to continue . . . -- components: Library (Lib) files: Capture.JPG messages: 299559 nosy: SriramSudharsan priority: normal severity: normal status: open title: import error for numpy versions: Python 3.6 Added file: http://bugs.python.org/file47053/Capture.JPG ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31090> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26779] pdb continue followed by an exception in the same frame shows incorrect frame linenumber
Sriram Rajagopalan added the comment: ping. Gentle reminder to review the patch -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26779> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26779] pdb continue followed by an exception in the same frame shows incorrect frame linenumber
Sriram Rajagopalan added the comment: ping -- nosy: +bglsriram ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26779> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26779] pdb continue followed by an exception in the same frame shows incorrect frame linenumber
Changes by Sriram Rajagopalan <bglsri...@gmail.com>: Removed file: http://bugs.python.org/file42486/bdbfix.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26779> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26779] pdb continue followed by an exception in the same frame shows incorrect frame linenumber
Changes by Sriram Rajagopalan <bglsri...@gmail.com>: Added file: http://bugs.python.org/file42508/bdbfix.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26779> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26779] pdb continue followed by an exception in the same frame shows incorrect frame linenumber
New submission from Sriram Rajagopalan:
Consider this simple python program -
1 #!/usr/bin/python
2
3 import pdb
4 import sys
5 import traceback
6
7 def trace_exception( type, value, tb ):
8 traceback.print_tb( tb )
9 pdb.post_mortem( tb )
10
11 sys.excepthook = trace_exception
12
13 def func():
14 print ( "Am here in func" )
15 pdb.set_trace()
16 print ( "Am here after pdb" )
17 print ( "Am going to assert now" )
18 assert False
19 print ( "Am here after exception" )
20
21 def main():
22 func()
23
24 if __name__ == "__main__":
25 main()
On running this program -
% ./python /tmp/test.py
Am here in func
> /tmp/test.py(16)func()
-> print ( "Am here after pdb" )
(Pdb) c
Am here after pdb
Am going to assert now
File "/tmp/test.py", line 25, in
main()
File "/tmp/test.py", line 22, in main
func()
File "/tmp/test.py", line 16, in func
print ( "Am here after pdb" )
> /tmp/test.py(16)func()
-> print ( "Am here after pdb" ) >>>> This should have been at the line
corresponding to "Am going to assert now"
(Pdb)
This seems to be an bug ( due to a performance consideration ) with the way
python bdb's set_continue() has been implemented -
https://hg.python.org/cpython/file/2.7/Lib/bdb.py#l227
def set_continue(self):
# Don't stop except at breakpoints or when finished
self._set_stopinfo(self.botframe, None, -1)
if not self.breaks:
# no breakpoints; run without debugger overhead
sys.settrace(None)
frame = sys._getframe().f_back
while frame and frame is not self.botframe:
del frame.f_trace
frame = frame.f_back
Basically what happens after "c" in a "(Pdb)" prompt is that bdb optimizes for
the case where there are no more break points found by cleaning up the trace
callback from all the frames.
However, all of this happens in the context of tracing itself and hence the
trace_dispatch function in
https://hg.python.org/cpython/file/2.7/Lib/bdb.py#l45 still returns back the
trace_dispatch as the new system trace function. For more details on
sys.settrace(), check https://docs.python.org/2/library/sys.html#sys.settrace
Check, the function trace_trampoline at
https://hg.python.org/cpython/file/2.7/Python/sysmodule.c#l353
which sets f->f_trace back to result at
https://hg.python.org/cpython/file/2.7/Python/sysmodule.c#l377
This seems to be an bug ( due to a performance consideration ) with the way
python bdb's set_continue() has been implemented -
https://hg.python.org/cpython/file/2.7/Lib/bdb.py#l227
def set_continue(self):
# Don't stop except at breakpoints or when finished
self._set_stopinfo(self.botframe, None, -1)
if not self.breaks:
# no breakpoints; run without debugger overhead
sys.settrace(None)
frame = sys._getframe().f_back
while frame and frame is not self.botframe:
del frame.f_trace
frame = frame.f_back
Basically what happens after "c" in a "(Pdb)" prompt is that bdb optimizes for
the case where there are no more break points found by cleaning up the trace
callback from all the frames.
However, all of this happens in the context of tracing itself and hence the
trace_dispatch function in
https://hg.python.org/cpython/file/2.7/Lib/bdb.py#l45 still returns back the
trace_dispatch as the new system trace function. For more details on
sys.settrace(), check https://docs.python.org/2/library/sys.html#sys.settrace
Check, the function trace_trampoline at
https://hg.python.org/cpython/file/2.7/Python/sysmodule.c#l353
which sets f->f_trace back to result at
https://hg.python.org/cpython/file/2.7/Python/sysmodule.c#l377
Now, check the function PyFrame_GetLineNumber() which is used by the traceback
to get the frame line number
https://hg.python.org/cpython/file/2.7/Objects/frameobject.c#l63
int
PyFrame_GetLineNumber(PyFrameObject *f)
{
if (f->f_trace)
return f->f_lineno;
else
return PyCode_Addr2Line(f->f_code, f->f_lasti);
}
Basically this function returns back the stored f->f_lineno in case the
f->f_trace is enabled.
The fix is fortunately simple -
Just set self.trace_dispatch to None if pdb set_continue decides to run without
debugger overhead.
--
components: Library (Lib)
files: bdbfix.patch
keywords: patch
messages: 263553
nosy: Sriram Rajagopalan
priority: normal
severity: normal
status: open
title: pdb continue followed by an exception in the same frame shows incorrect
frame linenumber
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3,
[issue14157] time.strptime without a year fails on Feb 29
Sriram Rajagopalan added the comment: Opened issue 26460 for fixing the leap day bug in datetime.datetime.strptime() -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue14157> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26460] datetime.strptime without a year fails on Feb 29
New submission from Sriram Rajagopalan:
$ python
Python 3.5.1 (default, Dec 7 2015, 12:58:09)
[GCC 5.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>
>>>
>>>
>>> import time
>>>
>>> time.strptime("Feb 29", "%b %d")
time.struct_time(tm_year=1900, tm_mon=2, tm_mday=29, tm_hour=0, tm_min=0,
tm_sec=0, tm_wday=0, tm_yday=60, tm_isdst=-1)
>>>
>>>
>>> import datetime
>>>
>>> datetime.datetime.strptime("Feb 29", "%b %d")
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3.5/_strptime.py", line 511, in _strptime_datetime
return cls(*args)
ValueError: day is out of range for month
The same issue is seen in all versions of Python
--
components: Library (Lib)
messages: 261014
nosy: Sriram Rajagopalan
priority: normal
severity: normal
status: open
title: datetime.strptime without a year fails on Feb 29
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26460>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14157] time.strptime without a year fails on Feb 29
Sriram Rajagopalan added the comment: datetime.strptime() uses the return value of _strptime() [ which returns 1900 for 29th Feb without an year ] and eventually ends up calling datetime_new()->check_date_args() [ datetimemodule.c ] with 29th Feb 1900 and eventual failure. Should we enhance check_date_args to take a year_dont_care flag and validate the input year argument only if it is explicitly passed? -- nosy: +Sriram Rajagopalan ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue14157> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5727] doctest pdb readline broken
Sriram sriramrathinav...@yahoo.com added the comment: Hi, On second thoughts, it made more sense to validate pdb directly instead of validating doctest's debugger. I have also used few inputs, I got from irc chat at #python-dev room in writing the test case. Thanks to them. I have attached the svn diff. Please review them Thanks Sriram -- Added file: http://bugs.python.org/file17204/pdb_doctest_readline.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5727 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8619] Doc bug for urllib.request._urlopener in Python 3.1+
New submission from Sriram Thaiyar sriram.thai...@gmail.com: http://docs.python.org/dev/py3k/library/urllib.request.html#urllib.request._urlopener [in the body] urllib._urlopener should be urllib.request._urlopener -- assignee: d...@python components: Documentation messages: 104998 nosy: Sriram.Thaiyar, d...@python priority: normal severity: normal status: open title: Doc bug for urllib.request._urlopener in Python 3.1+ versions: Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8619 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5727] doctest pdb readline broken
Sriram sriramrathinav...@yahoo.com added the comment: Hi, I believe this behaviour can be tested if we can prove that Cmd's cmdloop uses raw_input to get the data as against self.stdin.readline(). To test it, ideally I would have liked to override sys.stdin with a fake input stream and pass the list of args (like it's done in test_doctest.py). I can then pass the character codes for Up and Down Arrows in our fake stream and check if the raw_input can use readline and move through the fake input stream but that won't be possible because the C implementation of raw_input uses the readline functionality if only both stdin and stdout are from a terminal. So alternatively, if we can just ensure that doctest's pdb (_OutputREdirectingPdb) has use_rawinput as 1, we can be assured that readline will be used. I have attached the svn diff with trunk. Please review and comment Thanks Sriram -- Added file: http://bugs.python.org/file17109/pdbreadline.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5727 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5727] doctest pdb readline broken
Sriram sriramrathinav...@yahoo.com added the comment: Hi, This is the first bug am working in python, kindly excuse my mistakes, if any. As far as I can understand, the pdb disabled readline when an explicit stdin or stdout is passed, to allow remote debugging. I found this in Python 2.5.4 Release log. Patch #721464: pdb.Pdb instances can now be given explicit stdin and stdout arguments, making it possible to redirect input and output for remote debugging. Now in doctest.py since we pass the stdout argument (which is always sys.stdout) to pdb.py, readline is always disabled when pdb is invoked from doctest.py. One fix I can think of is to have pdb disable use of readline, not if any output stream is passed but only if a output stream other than sys.stdout is passed. I infact believe, this will preserve the functionality of pdb.py that existed before release of version 2.5.4 The above fix would still not solve the problem because before we pass the output stream to pdb.py, we override sys.stdout in doctest to doctest's spoofout. So in pdb.py, sys.stdout will not point to real sys.stdout. This can be fixed by overriding sys.stdout after we initialize the debugger. Please find the patch for doctest and pdb as an attachment. Thanks Sriram -- Added file: http://bugs.python.org/file15681/readline.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5727 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5727] doctest pdb readline broken
Sriram sriramrathinav...@yahoo.com added the comment: Hi, How about changing pdb's behavior, that it disables readline only if the passed stream is not the stdout stream? Also when looking at doctest module, I found that bdb's trace_dispatch was overridden to set the debugger's output stream to something other than stdout. I presume, that since prior to 2.5, pdb never took the stdin and stdout arguments and that overridden method was needed to make pdb use a stream other than stdout, but now that 2.5 allows us to pass the output stream in init method of pdb, that function is no longer needed. Thanks -- nosy: +sriram ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5727 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
