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
W3C <-> Python DOM type mapping docs need updating #43415
Comments
I believe the information at Sorry, I don't have a patch to submit for this. Should |
Logged In: YES Martin, you probably need to make a pronouncement on this. The DOM
|
Logged In: YES If answer #1 is chosen and the others rejected, then the |
Logged In: YES My position on this is that:
Dealing with the last item isn't within scope for handling |
Logged In: YES I agree with Fred that the documentation is not wrong as it If clarification is needed, it should go beyond boolean: I think the intention is this: for the "proper" IDL integer |
'IntType' refers to the 2.x alias types.IntType for int. If the Python type for IDL boolean cannot be changed to 'bool', then please make it 'bool or int' so that people will know that they might get either and so that the doc and minidom will agree with each other. |
I presume you're referring to the documentation for the xml.dom I'd support the changes you recommend for the xml.dom documentation. |
I agree that "IntegerType" makes no sense as a "Python Type" (which is how it is referred to here). Also, the next sentence is a bit obsolete as well: “Additionally, the DOMString defined in the recommendation is mapped to a Python string or Unicode string. Applications should be able to handle Unicode whenever a string is returned from the DOM.” |
Fred: yes, specifically the 3.x versions. I just noticed that the currently specification is 'IntegerType", which was never used in Python, rather than IntType, which was. The dead link you refer to is this at the top: This should be fixed in all versions. Antoine: the 3.x version is "Additionally, the DOMString defined in the recommendation is mapped to a bytes or string object. Applications should be able to handle Unicode whenever a string is returned from the DOM." Assuming the first sentence is true, I would just delete the second (for 3.x) as just about every 3.x app must deal with 3.x (unicode) strings. Summary of recommendations:
3a. Could not first sentence referred to above be replaced by a line in the table mapping 'DOMString' to 'string or bytes'? Or is DOMString not an IDL type? Even so, I would put it in the table with a footnote. 3b. Delete obsolete second sentence.
Once a set of changes is agreed on, this issue could be reassigned to doc maintainer Georg Brandl to make changes and close this. Note: my personal concern is with 3.x docs, except that bad link should be fixed for 2.6,7 also. |
Addendum. Table 1-2 Basic Data Type Mappings in the referenced OMG document, which maps 'OMG IDL' to 'Python' has 'Integer (<type 'int'>)', later shortened to 'Integer'. (It also has 'Long integer(<type 'long int'>)' and 'Floating Point Number (<type 'float'>)' with similar abbreviations.) So 'IntegerType', possibly mashing together 'Integer' with 'IntType', appears to be an erroneous term from the beginning. |
Nobody has objected to Terry Reedy's recommendations so can the docs be updated please. |
Unlike with some issues, my in-message recommendations here do not constitute a patch. docs@python could update the link immediately. I would be willing to review the more extensive patch for 3.x if someone makes one. |
The current link in the docs works; it's http://www.omg.org/spec/PYTH/1.2/PDF/. |
Changed on the trunk in rev83149. I removed both paragraphs after the table, adding null and DOMString to the table, and took the word 'primitive' out of the first sentence (so the table isn't listing just primitive types, but can list DOMString). |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: