[issue17415] Documentation Ambiguity 1
New submission from Gurmeet Singh: This is the first time I am creating an issue. I may be doing something wrong. I will correct that if you make me aware about it! Issue with documentation: Documentation page: http://docs.python.org/3/library/os.path.html Entry: os.path.normpath(path) Contention line: It should be understood that this may change the meaning of the path if it contains symbolic links! Ambiguity Source: Contention line immediately follows the line On Windows, it converts forward slashes to backward slashes. relating contention line to also windows. Ambiguity: I think (i.e. I do not know for sure) that, the contention line should apply to all OS, not just windows. for example, .. after a symlink should, according to me, remove the symlink itself by the normpath function. This would be an incorrect behaviour of the normpath (I consider that incorrect). Hence, should be documented for all OS. -- assignee: docs@python components: Documentation messages: 184152 nosy: docs@python, gsingh priority: normal severity: normal status: open title: Documentation Ambiguity 1 type: enhancement versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17415 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17416] Documentation Ambiguity 2
New submission from Gurmeet Singh: Source page: http://docs.python.org/3/library/os.html Entry: os.walk(...) Ambiguity Source: Name of the argument TopDown and / or its description. The TopDown name is misleading to me. I would suggest BFS or DFS instead. TopDown false would imply to me that the traversal would run bottom up from the directory mentioned in the argument list (even though the name of that argument is top, it is confusing indicating a possibility of another naming mistake instead!) -- assignee: docs@python components: Documentation messages: 184153 nosy: docs@python, gsingh priority: normal severity: normal status: open title: Documentation Ambiguity 2 type: enhancement versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17416 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17417] Documentation Modification Suggestion: os.walk, fwalk
New submission from Gurmeet Singh: Source page: http://docs.python.org/3/library/os.html Entry: os.walk(...), os.fwalk() These functions seems to be a generator functions. An expert like yourself may have no trouble to make this out. But for novice (or for people out of touch) like myself would have preferred a starting line of this function as A generator function that generates file names , rather than currently Generates file names -- assignee: docs@python components: Documentation messages: 184155 nosy: docs@python, gsingh priority: normal severity: normal status: open title: Documentation Modification Suggestion: os.walk, fwalk type: enhancement versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17417 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17418] Documentation Bug
New submission from Gurmeet Singh: Incompletely explained documentation at 2 places: 1. http://docs.python.org/3/library/functions.html#open The buffering argument is not correctly explained when setting to a positive argument in binary mode. 2. http://docs.python.org/3/library/os.html#os.open It is not very clear where to find descriptions of the arguments of this function. Where to find the required information and where to find C run-time documentation could be explained in following preferably: (Python/C API Reference Manual) http://docs.python.org/3/c-api/index.html and / or (The Python Standard Library) http://docs.python.org/3/library and / or (Python Runtime Services) http://docs.python.org/3/library/python.html A hyperlink may be added if so felt. -- assignee: docs@python components: Documentation messages: 184166 nosy: docs@python, gsingh priority: normal severity: normal status: open title: Documentation Bug versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17418 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17416] Clarify docs of os.walk()
Gurmeet Singh added the comment: Hi Terry, I understand it is ok for you. I agree that you are not in favour of changing the argument name. And you are correct that I must get familiar to the convention that has been used. Further since you say, perhaps, I now feel that it may be used in other languages documentation as well. But I still seriously 'request' you again to add the word BFS (Breadth First Search) to the only the documentation of TopDown = True and DFS like for the case of False. If a kid (like me) who reads an algorithms textbook and not familiar with the conventions being followed - 'may' make a mistake and waste time debugging. -- resolution: works for me - ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17416 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17418] Documentation for os.open and io.open
Gurmeet Singh added the comment: The issue with buffering problem mentioned in my previous comment has been raised as issue 17440. However, I need to apologize again! The statement that buffering is not implemented at all was incorrect - instead read1() was not implemented. See the mentioned issue for more details. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17418 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17440] Some IO related problems on x86 windows
New submission from Gurmeet Singh:
1. The read mode is not the default mode as mentioned in the docs.python.org.
In particular see the first Traceback below - b does not work (as it does in
C though) and
you are forced to use rb instead.
2. io.BufferedReader does not implement read1 (the last lines of trace below)
3. io.FileIO does not implements single OS system call on read() - instead
reads a file until EOF i.e. ignores the arguments supplied to read() - larger
arguments are slower to execute (see the read calls in the trace below).
_
import io
fl = io.FileIO('c:/temp9/Capability/Analyzing Data.mp4', 'r')
byt = fl.read()
len(byt)
70934549
fl.close()
fl = io.FileIO('c:/temp9/Capability/Analyzing Data.mp4', 'r')
byt = fl.read(256)
len(byt)
256
byt = fl.read(512)
len(byt)
512
byt = fl.read(1024)
len(byt)
1024
byt = fl.read(4096)
len(byt)
4096
byt = fl.read(10240)
len(byt)
10240
len(fl.read(40960))
40960
len(fl.read(102400))
102400
len(fl.read(1048576))
1048576
fl.close()
fl = io.FileIO('c:/temp9/Capability/Analyzing Data.mp4', 'r')
len(fl.read(70934549))
70934549
len(fl.read(70934549))
0
fl.close()
fl = io.FileIO('c:/temp9/Capability/Analyzing Data.mp4', 'r')
b = bytearray(70934549)
fl.readinto(b)
70934549
fl.close()
fl = open ('c:/temp9/Capability/Analyzing Data.mp4', 'b', buffering = 0)
Traceback (most recent call last):
File pyshell#31, line 1, in module
fl = open ('c:/temp9/Capability/Analyzing Data.mp4', 'b', buffering = 0)
ValueError: Must have exactly one of create/read/write/append mode and at most
one plus
fl = open ('c:/temp9/Capability/Analyzing Data.mp4', 'rb', buffering = 0)
type(fl)
class '_io.FileIO'
cfl = io.FileIO('c:/temp9/Capability/Analyzing Data.mp4', 'r')
type(cfl)
class '_io.FileIO'
cfl.close()
cfl = open ('c:/temp9/Capability/Analyzing Data.mp4', 'rb', buffering = -1)
type(cfl)
class '_io.BufferedReader'
io.DEFAULT_BUFFER_SIZE
8192
len(fl.read(70934549))
70934549
cfl.close()
cfl = open ('c:/temp9/Capability/Analyzing Data.mp4', 'rb', buffering = -1)
len(fl.read1(70934549))
Traceback (most recent call last):
File pyshell#44, line 1, in module
len(fl.read1(70934549))
AttributeError: '_io.FileIO' object has no attribute 'read1'
--
messages: 184330
nosy: gsingh
priority: normal
severity: normal
status: open
title: Some IO related problems on x86 windows
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17440
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17415] Clarify docs of os.path.normpath()
Gurmeet Singh added the comment: At the moment, I running late for creating a program - so I apologize that immediately I would not able to work on creating a patch. Later though I may be able to. I am sorry. To avoid wasted work I think patch should be created only after someone (do not know who though!) has approved of the suggestions. Thanks for the tips. I will read http://docs.python.org/devguide/triaging.html before posting next - but sorry, that I have posted many issues already without reading your response. __ You guys have both understood the issues I tried to say. The collapsing by '..' kills out sym link without realizing it is symlink - since it does not refer to file system - it is just a string manipulation utility (Again, I cannot commit on this since I have not read the source code or experimented this - it is an educated guess by reading only the docs). So, I further suggest to add to the description by Ezio Melotti after the line This collapsing may change the meaning of the path if it contains symbolic links.. We could add the following bracketed line (since os.path.normpath is just string manipulation utility - unaware of the underlying file system). This would remove the source of confusion, that we all here have got confused about. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17415 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17418] Documentation for os.open and io.open
Gurmeet Singh added the comment: Please read the comment completely. For the first point ___ I apologize that there was no mistake in binary mode and I have read it hastily. There is no ambiguity in the binary mode as you said. Reading hastily, I felt '...(only usable in text mode)... applies to all positive values, not just for the case of one. I was wrong there. However, text mode buffering description is not clear. Does the positive non unity buffer size value indicates the number of lines or the size in bytes or size of string characters (as per the system encoding) etc. This description could be made clearer (for both the text as well as the binary modes) I also want to say that buffering is working incorrectly. In fact it is not working at all on windows x86 (I am raising a separate issue for this since that is not a documentation issue). For the second point (My answer here is for Windows part only) The hyperlink http://msdn.microsoft.com/en-us/library/z0kc8e3z.aspx could be great instead of see C-run time documentation. It explains both flag as well as mode. Actually this is the hyperlink given in the page you mentioned (http://docs.python.org/3/library/os.html#open-flag-constants) - I guess I gave up on this link, since I felt function was largely undocumented and useless. I really request you to mention that C runtime library specification is actually http://msdn.microsoft.com/en-us/library/59ey50w6.aspx - I accidentally found this - there is no simple way (without reading extensively, I guess) to know that Python is actually using Microsoft VC++ at the backend and that the runtime library of that would be of that. So you could mention this on the introductory pages that C-API/Library is actually http://msdn.microsoft.com/en-us/library/59ey50w6.aspx. ___ P.S. Please (at least) see my comment on the other documentation ambiguity issue that you have closed already. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17418 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17417] Documentation Modification Suggestion: os.walk, fwalk
Gurmeet Singh added the comment: I am sorry to reopen this issue, if you do not like this comment, then I will reopen issues again. I am not saying to change the convention of the documentation - I just requested you to say something that would indicate that it is function that gives result in multiple calls. Mentioning the generator or iterator word would help a novice (but may not an expert like you) to understand that the object returned by this function needs to be called repeatedly and it does not return a collection of all results. After reading ... would be better floated on python-list, I do not know if my posting this comment would be termed as bugging? -- status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17417 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17440] Some IO related problems on x86 windows
Gurmeet Singh added the comment:
Please consider following before making a decision:
__
io.BufferedReader does not implement read1 (the last lines of trace
below)
It does. You made a mistake in your experiment (you called read1() on a FileIO
object, not a BufferedReader object).
Please see the following lines:
cfl = open ('c:/temp9/Capability/Analyzing Data.mp4', 'rb', buffering = -1)
type(cfl)
class '_io.BufferedReader'
According to me it is a _io.BufferedReader only and not just _io.FileIO (the
base class). Please tell me if I am wrong here.
--
status: pending - open
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17440
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17440] Some IO related problems on x86 windows
Gurmeet Singh added the comment: Please consider following before making a decision: io.FileIO does not implements single OS system call on read() - instead reads a file until EOF i.e. ignores the arguments supplied to read() Your experiments show otherwise, the argument supplied to read() is observed: if you call read(1024), at most 1024 bytes are returned, etc. It's only if you call read() without an argument that the file is being read until EOF. I said this because I saw the following in the docs: class io.RawIOBase read(n=-1) Read up to n bytes from the object and return them. As a convenience, if n is unspecified or -1, readall() is called. Otherwise, only one system call is ever made. Fewer than n bytes may be returned if the operating system call returns fewer than n bytes. If only one system call is being made, then I think that fl.read(256) and fl.read(70934549) should take same amount of time to complete - assuming disk I/O is the time consuming factor in this operation (as compared to memory processing). I am only saying that instead of one system call being made - the whole size specified by read is being read (by multiple system calls - as it appears to me). Please tell me if I am wrong here. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17440 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17440] Some IO related problems on x86 windows
Gurmeet Singh added the comment: @Antoine - wait I will do it -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17440 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17440] Some IO related problems on x86 windows
Gurmeet Singh added the comment: @Antoine It worked. I was wrong to say read1() was not implemented. Sorry. But please do consider other issues. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17440 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17440] Some IO related problems on x86 windows
Gurmeet Singh added the comment:
I did the following to understand time taken for in memory copy:
1 fl = io.FileIO('c:/temp9/Capability/Analyzing Data.mp4', 'rb')
2 byt = fl.read(70934549)
3 byt2 = None
4 byt2 = byt[:]
5 fl.close()
6 fl = io.FileIO('c:/temp9/Capability/Analyzing Data.mp4', 'rb')
7 byt = fl.read(1)
I found that python interpreter blocked for negligible time on line 4 (and line
7), as compared to line 2.
I assume that line 4 is a correct syntax for an in place memory copy.
Therefore, multiple system calls could be taking place - This is how I assumed.
Please suggest if I am incorrect.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17440
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17440] Some IO related problems on x86 windows
Gurmeet Singh added the comment: Sorry, typo in the last post - I meant in memory - memory copy not in place memory copy. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17440 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17440] Some IO related problems on x86 windows
Gurmeet Singh added the comment:
Thanks for letting me know about the optimization.
I trusted you that the system call is made once, though I looked up code to see
if size of the read in buffer is being passed to the C routine. I should
apologize though for raising this issue - since it is incorrect.
But, I think you would be interested (out of CURIOSITY) in findings from the
last experiment that I did to understand this issue:
1 import io
2 fl = io.FileIO('c:/temp9/Capability/Analyzing Data.mp4', 'rb')
3 barr = bytearray(70934549)
4 barr2= bytearray(70934549)
5 id(barr)
29140440
6 id(barr2)
26433560
7 fl.readinto(barr)
70934549
8 barr2 = barr[:]
9 fl.close()
10 fl = io.FileIO('c:/temp9/Capability/Analyzing Data.mp4', 'rb')
11 barrt = bytearray(1)
12 id(barrt)
34022512
13 fl.readinto(barrt)
1
14 fl.close()
The time of line 7 was much greater than line 13. It was also greater than 8
(but not that great as of 11). But I cannot say for sure that the time for line
13 plus line 8 is equal to or lesser than 7 - it looks lesser but needs more
precise testing to say anything further.
I tried to reason the situation as follows (for this I looked up the hyperlink
that you gave). I feel that the underlying system call takes the size argument
- so I guess that large value suggests the C compiler to make ask the disk
subsystem to read up the longer data - hence it takes the time since disk
access is slower.
Thanks for your time. Sorry for the incorrect issue.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17440
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
