- Python Home
- About
- News
- Documentation
- Downloads
- Community
- Foundation
- Developer's Guide
- Issue Tracker
- Issues
- Summaries
- User
- Administration
- Help
Issue40340
This issue tracker has been migrated to GitHub,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2020-04-20 19:37 by Dominik V., last changed 2022-04-11 14:59 by admin. This issue is now closed.
| Pull Requests | |||
|---|---|---|---|
| URL | Status | Linked | Edit |
| PR 19688 | merged | python-dev, 2020-04-23 21:24 | |
| Messages (5) | |||
|---|---|---|---|
| msg366870 - (view) | Author: Dominik Vilsmeier (Dominik V.) * | Date: 2020-04-20 19:37 | |
The paragraph about [How do I convert a string to a number?](https://docs.python.org/3/faq/programming.html#how-do-i-convert-a-string-to-a-number) contains the following sentence: > By default, these interpret the number as decimal, so that `int('0144') == 144` and `int('0x144')` raises ValueError. The first part however doesn't raise an error. Most likely octal notation was meant, i.e. `int('0o144') == 144`. For consistency with the `int('0x144')` part one could also omit the equality comparison, i.e. just write `int('0o144')`. In order to emphasize that the "and" is not part of the code (though this should be displayed by the browser) once could also write: > [...] so that _both_ `int('0o144')` and `int('0x144')` raise ValueError. (emphasis added) |
|||
| msg366871 - (view) | Author: Cajetan Rodrigues (cajetan.rodrigues) * | Date: 2020-04-20 20:00 | |
> these interpret the number as decimal
I'm no linguist, but I feel both expressions in the subordinate clause have their purposes, with respect to the the main clause:
* `int('0144') == 144` to show what works
* `int('0x144')` to show what does not work
I don't believe the octal notation was meant in the first example, as the equality wouldn't then hold, even if somehow the typecast worked (which it doesn't). The point was to positively reinforce the idea that the content of the string would be interpreted as a decimal. So something like `int('000000144') == 144` would still hold True. Negative reinforcement is provided in the second example.
But I agree that the sentence itself does not clearly separate the two examples, so I would suggest adding a comma after the first example, like so:
> By default, these interpret the number as decimal, so that `int('0144') == 144`, and `int('0x144')` raises ValueError.
|
|||
| msg366875 - (view) | Author: Dominik Vilsmeier (Dominik V.) * | Date: 2020-04-20 20:24 | |
Indeed, thanks for clarifying. It seems I misunderstood the example, and perhaps that calls for a better separation. What about adding
> By default, these interpret the number as decimal, so that `int('0144') == 144` holds true and `int('0x144')` raises ValueError.
|
|||
| msg367144 - (view) | Author: Cajetan Rodrigues (cajetan.rodrigues) * | Date: 2020-04-23 20:22 | |
Yes, I think that's acceptable. |
|||
| msg367239 - (view) | Author: Kyle Stanley (aeros) * ![]() |
Date: 2020-04-24 23:39 | |
New changeset 5aafa548794d23b6d4cafb4fd88289cd0ba2a2a8 by Cajetan Rodrigues in branch 'master': bpo-40340: Separate examples more clearly in the programming FAQ (GH-19688) https://github.com/python/cpython/commit/5aafa548794d23b6d4cafb4fd88289cd0ba2a2a8 |
|||
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2022-04-11 14:59:29 | admin | set | github: 84520 |
| 2020-04-25 06:33:42 | aeros | set | status: open -> closed resolution: fixed stage: patch review -> resolved |
| 2020-04-24 23:39:11 | aeros | set | nosy:
+ aeros messages: + msg367239 |
| 2020-04-23 21:24:33 | python-dev | set | keywords:
+ patch nosy: + python-dev pull_requests: + pull_request19007 stage: patch review |
| 2020-04-23 20:22:46 | cajetan.rodrigues | set | messages: + msg367144 |
| 2020-04-20 20:24:13 | Dominik V. | set | messages: + msg366875 |
| 2020-04-20 20:00:13 | cajetan.rodrigues | set | nosy:
+ cajetan.rodrigues messages: + msg366871 |
| 2020-04-20 19:37:45 | Dominik V. | create | |


