[issue46902] Typo hint message for from-imports?
New submission from Jean Abou Samra : See for example: >>> from pygments.regexopt import regexopt Traceback (most recent call last): File "", line 1, in ImportError: cannot import name 'regexopt' from 'pygments.regexopt' (/home/jean/repos/pygments/pygments/regexopt.py) >>> from pygments.regexopt import regex_opt >>> regexopt Traceback (most recent call last): File "", line 1, in NameError: name 'regexopt' is not defined. Did you mean: 'regex_opt'? In Python 3.10, there is a nice helpful error message suggesting how to correct the typo for NameError and AttributeError. Would it be possible to have the same for ImportError with 'from import'? -- components: Interpreter Core messages: 414385 nosy: Jean_Abou_Samra priority: normal severity: normal status: open title: Typo hint message for from-imports? type: enhancement versions: Python 3.10, Python 3.11 ___ Python tracker <https://bugs.python.org/issue46902> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45139] Simplify source links in documentation?
New submission from Jean Abou Samra : Currently, links to source code in the documentation look like this: **Source code:** :source:`Lib/abc.py` For documentation translators, this means that every module contains a boilerplate string to translate. A small burden perhaps, but avoidable. I propose to refactor the links in a directive, like so: .. source:: Lib/abc.py Then just the text "Source code:" gets translated (in sphinx.po) and the rest is automatic. This could also benefit the presentation in the future, if anyone wants to change the styling of these links. Open question is how to handle the handful of links that contain several source files (async I/O modules in particular). To make it language-agnostic, perhaps the markup .. source:: Lib/asyncio/futures.py, Lib/asyncio/base_futures.py could be rendered as if it were **Source code:** :source:`Lib/asyncio/futures.py` | :source:`Lib/asyncio/base_futures.py` Thoughts? -- assignee: docs@python components: Documentation messages: 401410 nosy: Jean_Abou_Samra, docs@python, mdk priority: normal severity: normal status: open title: Simplify source links in documentation? ___ Python tracker <https://bugs.python.org/issue45139> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44355] Allow spaces in format strings
Jean Abou Samra added the comment:
Maybe leave the current state, keeping backwards compatibility, but improve the
error message by adding "perhaps you wanted no spaces in the format field?"
when the_field.replace(" ", "") would be valid?
--
nosy: +Jean_Abou_Samra
___
Python tracker
<https://bugs.python.org/issue44355>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41315] Add mathematical functions as wrappers to decimal.Decimal methods
Jean Abou Samra added the comment: Okay, understood, thanks for your detailed explanations. -- ___ Python tracker <https://bugs.python.org/issue41315> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41315] Add mathematical functions as wrappers to decimal.Decimal methods
Jean Abou Samra added the comment: I would argue that given a function, from math import * def naive_calc_pi(n=100): u = sqrt(8) v = 4 for _ in range(n): v = 2*u*v/(u + v) u = sqrt(u*v) return u when you realize that floats have limited precision (happened to me several times while being taught and teaching Python), you could just replace from math import * with from decimal import * and use it, instead of the current from decimal import Decimal as D def sqrt(x): return D(x).sqrt() Of course, you can define these, but as I repeatedly ended up doing this, I just thought I'd bring the idea upstream. Another, perhaps more important argument is readability. We all think in terms of functions: log(x), not x.log(). I find it a significant fact that NumPy has both numpy.dot(A, B) and numpy.ndarray.dot(self, B), but the former is generally preferred (the method's documentation points to the function and the first dozen Google search results for "numpy dot product" yield the function). It makes expressions resemble what we are used to: compare (a + b).tan().log() = (a.tan() + b.tan()).sqrt()/(1 - a.tan()*b.tan()).sqrt() with sqrt(tan(a + b)) = sqrt(tan(a) + tan(b))/sqrt(1 - tan(a)*tan(b)) > Also, the APIs aren't completely harmonious because the Decimal methods > accept an optional context object. I don't see a problem with the functions also accepting this parameter. (np.sin() has many parameters after all.) Overall, I think this modest addition would bring an improvement in the usability of the decimal module. I can make a PR. -- nosy: +Jean_Abou_Samra ___ Python tracker <https://bugs.python.org/issue41315> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41315] Add mathematical functions as wrappers to decimal.Decimal methods
Change by Jean Abou Samra : -- title: Add mathematical functions as wrapper to decimal.Decimal methods -> Add mathematical functions as wrappers to decimal.Decimal methods ___ Python tracker <https://bugs.python.org/issue41315> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41315] Add mathematical functions as wrapper to decimal.Decimal methods
New submission from Jean Abou Samra : Common mathematical functions such as sqrt(), exp(), etc. are available for decimal numbers as methods of decimal.Decimal instances (like https://docs.python.org/3/library/decimal.html#decimal.Decimal.exp). This does not pair well with the math and cmath modules as well as NumPy and SymPy which all define these as functions. It also makes it harder to switch to decimals instead of floats when you realize that your program lacks arithmetic precision. It would be nice to have functions in the decimal module that called the corresponding methods. This would unify the interface with other modules while keeping backwards compatibility and preserving the possibility to subclass Decimal. -- components: Library (Lib) messages: 373754 nosy: Jean Abou Samra, facundobatista, mark.dickinson, rhettinger, skrah priority: normal severity: normal status: open title: Add mathematical functions as wrapper to decimal.Decimal methods type: enhancement versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue41315> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
