-
-
Notifications
You must be signed in to change notification settings - Fork 35.1k
bpo-34953: Implement mmap.mmap.__repr__
#9891
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Changes from all commits
Commits
Show all changes
17 commits
Select commit
Hold shift + click to select a range
75856fb
bpo-34953: Implement `mmap.mmap.__repr__`
thautwarm 718a6b0
done
thautwarm c6900ee
follow PEP7
thautwarm d9d8611
follow PEP7
thautwarm 8f1546a
remove redundant line wraps and compat MS_WINDOWS
thautwarm 9d87c5c
fix accessing data from m_obj
thautwarm 9c77de3
add tests
thautwarm 3226a35
compat windows and add exhaustive tests
thautwarm e4c2440
follow Zhang's guides to refine codes
thautwarm ff18f7d
fix tests
thautwarm 3b1d544
avoid showing entire_contents according to core devs' points of view
thautwarm d5ffb47
test data with long int size & refine repr format args & remove redun…
thautwarm 09b9554
invalid access now causes Py_UNREACHABLE
thautwarm a1b589f
remove 'fileno' due to code review and discussion & refine wording(cl…
thautwarm e5f3237
Merge branch 'master' into bpo-34953
zhangyangyu 39d84a1
adjusts
zhangyangyu bf68fc7
replace PAGESIZE with ALLOCATIONGRANULARITY
zhangyangyu File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, no difference between these. I'd suggest make
closeda local variable and the logic could be clearer.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is a difference, that when
datais not available, gettingoffsetcould be insecure.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I don't get it. Why could it be insecure? After
new_mmap_objectthey are all initialized right? What I am missing here? And if they are secure, I don't think we need to distingiush them between closed and open status, just show whatever they are. One more thing, why leave out the actualoffsetproperty and makepostheoffset? It's confusing.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
First, I'd say sorry for
offsetshould bepos.At the first beginning I mean if
mmapgets closed, thedataofmmap_objecthas already beenNULL. In this situation why should we allow uers to get a few outdated members likeposorsize? I know people might feel like to ask a closedmmapfor the historical records so I think you're right in that case, but in fact, thetellmethod andsizemethod just raise exceptionPyErr_SetString(PyExc_ValueError, "mmap closed or invalid"):So there's no way to get
sizeandposfrom ammapobject when it has been closed, why should we break this in justreprmethod? That's also what now motivates me to still distinguish closed status from the open one.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I know why I once used
offsetnow..It's the argument of mmap constructor: https://github.com/python/cpython/blob/master/Modules/mmapmodule.c#L1058
Also,
lengthis used there instead ofsize.I think we should do more to make it consistent in both low level(C data structures) and high level(interfaces for Python).
It might be better to change
sizetolengthand consist usingoffsetviaThe wording seems to be a thing, e.t.c, in previous codes there're already phrases like
length of mmap,file sizeormemory offset:https://github.com/python/cpython/blob/master/Modules/mmapmodule.c#L1133-L1145
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense. Some properties are meaningless when closed, we don't need them, I mean
pos. For others, I'd suggest just using the constructor arguments,lengthislength,posispos,offsetisoffset. Don't usesizeplease since it's confusing, it's stored internally as a caculated field but unforunately there is also asize()method returns something different. As forfileno, I am okay to omit it for now. Actually noposis also okay for me.