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
array documentation, method names not 3.x-compliant #47815
Comments
A few weeks ago I fixed the struct module's documentation which wasn't http://docs.python.org/dev/3.0/library/array.html Unfortunately, the method names are wrong as far as Py3K is concerned. There are a few other errors in the documentation too, like the 'c' type I suggest a 3-step process for fixing this:
I'm aware we've got the final beta in 4 days, and there's no way my I've fixed the documentation to accurately describe the current I'll have a go at a "phase 2" patch shortly. Is it feasible to even Commit log: Doc/library/array.rst, Modules/arrayobject.c: Updated array module documentation to be Python 3.0 compliant.
|
I'm not a native speaker (of English), but my understanding is that the |
Ah yes, that's quite right (and computer science literature will However the word "string", unqualified, and in Python 3.0 terminology For array to become a good Py3k citizen, I'd strongly argue that However as a separate issue, I think the documentation update should be |
(Fixed issue title) |
I renamed tostring/fromstring to tobytes/frombytes in the array module, The relatively minor number of these references suggests this won't be a I haven't (yet) renamed tounicode/fromunicode to tostring/fromstring. The patch (doc+bytesmethods.patch) does both the original Renamed array.tostring to array.tobytes, and array.fromstring to Updated all references to these methods in Lib to the new names. |
Oops .. forgot to update the array.rst docs with the new method names. |
A similar issue came up in another bug "IMO it's okay to add encodebytes(), but let's leave encodestring() I think that's probably wise RE this bug as well - my original I'll have another go at this during some spare cycles tomorrow - (Also policy question: When you have deprecated functions, how do you |
Can I just remind people that I have a documentation patch ready here Of course the doc+bytesmethods.patch may be debatable and probably too Current array documentation |
Benjamin, do you think this should be fixed in 3.1? |
It would be nice to deprecate the old names in 3.1 and remove them in |
Note that, irrespective of the changes to the library itself, the (It's from August so it will probably conflict, but I can update it if |
The doc patch is in scope for the Bug Day. |
OK since the patches I submitted are now eight months old, I just did an I'd still like to see doc+bytesmethods.patch applied (since it fixes |
Full method renaming patch. |
I think this patch is unacceptable for Python 3.1. It is an incompatible |
I agree with that -- too big a change to make now. But can we please get the documentation patch accepted? It's been |
In 3.2, a change *was* committed (by who?) but not recorded here: Is there still any idea/intention of renaming .from/.tounicode to |
It was Antoine in fa8b57f987c5, for bpo-8990. |
Indeed, not only it would bring little benefit, but may also confuse users porting from 2.x (since the from/tostring methods would then have a totally different meaning). |
There are still some inconsistencies in the documentation (in particular, incorrectly using the word "string" to refer to a bytes object, which made sense in Python 2 but not 3), which I fixed in my doc-only.patch file that's coming up to its third birthday. Most of it has been fixed with the previous change which added 'tobytes' and 'frombytes' and made tostring and fromstring aliases. But there are some places which don't make sense: array: "If given a list or string" needs to be "If given a list, bytes or string" (since a bytes is not a string). Less importantly, I also recommended renaming "unicode string" to just "string", since in Python 3 there is no such thing as a non-unicode string. For instance, there is an example that uses a variable named "unicodestring" that could be renamed to just "string".
Though I do agree that it would be chaos to rename array.from/tounicode to from/tostring now, given that array.from/tostring already has a different meaning in Python 3. |
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: