What you are think about adding Unicode aliases for some mathematic names in the math module? ;-) math.π = math.pi math.τ = math.tau math.Γ = math.gamma math.ℯ = math.e Unfortunately we can't use ∞, ∑ and √ as identifiers. :-(
On Thu, Jun 01, 2017 at 09:47:57AM +0300, Serhiy Storchaka <storchaka@gmail.com> wrote:
What you are think about adding Unicode aliases for some mathematic names in the math module? ;-)
math.?? = math.pi math.?? = math.tau math.?? = math.gamma math.??? = math.e
Unfortunately we can't use ???, ??? and √ as identifiers. :-(
-1. "There should be one-- and preferably only one --obvious way to do it." And -1 for non-ascii in stdlib. Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.
On 05/31/2017 11:47 PM, Serhiy Storchaka wrote:
What you are think about adding Unicode aliases for some mathematic names in the math module? ;-)
I personally don't like there being multiple symbols with the same meaning and I never find myself confused by the longer names versus the sorter symbols I would use when writing them. Cheers, Thomas
Although it is trivial, I like the idea (except for math.e maybe). (And it would be cool to be able to also write ∑ = sum, etc.) -- Ivan On 1 June 2017 at 08:47, Serhiy Storchaka <storchaka@gmail.com> wrote:
What you are think about adding Unicode aliases for some mathematic names in the math module? ;-)
math.π = math.pi math.τ = math.tau math.Γ = math.gamma math.ℯ = math.e
Unfortunately we can't use ∞, ∑ and √ as identifiers. :-(
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Hi all, Two remarks: 1. Note that ℯ also doesn't really work. While you can assign to this identifier, it actually gets normalized into a plain "e". 2. Unicode has a Σ : GREEK CAPITAL LETTER SIGMA and a ∑ : N-ARY SUMMATION The first is a valid Python identifier, the second not. Unfortunately, the second has the desired semantics... Stephan 2017-06-01 9:14 GMT+02:00 Ivan Levkivskyi <levkivskyi@gmail.com>:
Although it is trivial, I like the idea (except for math.e maybe). (And it would be cool to be able to also write ∑ = sum, etc.)
-- Ivan
On 1 June 2017 at 08:47, Serhiy Storchaka <storchaka@gmail.com> wrote:
What you are think about adding Unicode aliases for some mathematic names in the math module? ;-)
math.π = math.pi math.τ = math.tau math.Γ = math.gamma math.ℯ = math.e
Unfortunately we can't use ∞, ∑ and √ as identifiers. :-(
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Why not simply use from math import pi as π and so on? It makes your math formulas more readable (taking out the "math." entirely), without requiring any change to the module. Le 01/06/17 à 08:47, Serhiy Storchaka a écrit :
What you are think about adding Unicode aliases for some mathematic names in the math module? ;-)
math.π = math.pi math.τ = math.tau math.Γ = math.gamma math.ℯ = math.e
Unfortunately we can't use ∞, ∑ and √ as identifiers. :-(
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Or perhaps create a small module: ============unimath.py============== import math __all__ = ["π", "τ", "Γ"] π = math.pi τ = math.tau Γ = math.gamma ==================================== Then do: from unimath import * Put it on the Python Package index. If it gets wildly popular the case for putting it in `math` will be greatly strengthened. Stephan 2017-06-01 9:17 GMT+02:00 Brice PARENT <contact@brice.xyz>:
Why not simply use
from math import pi as π
and so on? It makes your math formulas more readable (taking out the "math." entirely), without requiring any change to the module.
Le 01/06/17 à 08:47, Serhiy Storchaka a écrit :
What you are think about adding Unicode aliases for some mathematic names in the math module? ;-)
math.π = math.pi math.τ = math.tau math.Γ = math.gamma math.ℯ = math.e
Unfortunately we can't use ∞, ∑ and √ as identifiers. :-(
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Or perhaps create a small module: ============unimath.py============== import math __all__ = ["π", "τ", "Γ"] π = math.pi τ = math.tau Γ = math.gamma ==================================== Then do: from unimath import * Put it on the Python Package index. If it gets wildly popular the case for putting it in `math` will be greatly strengthened. Stephan 2017-06-01 9:17 GMT+02:00 Brice PARENT <contact@brice.xyz>:
Why not simply use
from math import pi as π
and so on? It makes your math formulas more readable (taking out the "math." entirely), without requiring any change to the module.
Le 01/06/17 à 08:47, Serhiy Storchaka a écrit :
What you are think about adding Unicode aliases for some mathematic names in the math module? ;-)
math.π = math.pi math.τ = math.tau math.Γ = math.gamma math.ℯ = math.e
Unfortunately we can't use ∞, ∑ and √ as identifiers. :-(
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
On 01.06.2017 08:47, Serhiy Storchaka wrote:
What you are think about adding Unicode aliases for some mathematic names in the math module? ;-)
math.π = math.pi math.τ = math.tau math.Γ = math.gamma math.ℯ = math.e
Unfortunately we can't use ∞, ∑ and √ as identifiers. :-(
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
No, thank you. :) One way to do it is perfectly fine. Regards, Sven
I like the aesthetic of the idea, but it seems like this would be a better fit in a library namespace like sympy or jupyter. On Thu, Jun 1, 2017 at 12:19 AM, Sven R. Kunze <srkunze@mail.de> wrote:
On 01.06.2017 08:47, Serhiy Storchaka wrote:
What you are think about adding Unicode aliases for some mathematic names in the math module? ;-)
math.π = math.pi math.τ = math.tau math.Γ = math.gamma math.ℯ = math.e
Unfortunately we can't use ∞, ∑ and √ as identifiers. :-(
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
No, thank you. :)
One way to do it is perfectly fine.
Regards, Sven
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
How do you write π (pi) with a keyboard on Windows, Linux or macOS?
On macOS, ⌥ P (Option-P) works. On all platforms: 1. Make sure you are using Vim. 2. In insert mode: Ctrl-K *p You can also define abbrev's which will allow you to type pi\ and it gets replaced by π. See: https://gist.github.com/stephanh42/fc466e62bfb022a890ff2c4643eaf3a5 I presume Emacs can do something similar. Or you get this keyboard: https://imgur.com/gallery/tCNvP ;-) Stephan 2017-06-01 11:49 GMT+02:00 Victor Stinner <victor.stinner@gmail.com>:
2017-06-01 8:47 GMT+02:00 Serhiy Storchaka <storchaka@gmail.com>:
What you are think about adding Unicode aliases for some mathematic names in the math module? ;-)
math.π = math.pi
How do you write π (pi) with a keyboard on Windows, Linux or macOS?
Victor _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
01.06.17 12:49, Victor Stinner пише:
2017-06-01 8:47 GMT+02:00 Serhiy Storchaka <storchaka@gmail.com>:
What you are think about adding Unicode aliases for some mathematic names in the math module? ;-)
math.π = math.pi
How do you write π (pi) with a keyboard on Windows, Linux or macOS?
This shouldn't be a problem for Greek users. ;-) Personally I copied them from a character table.
This shouldn't be a problem for Greek users. ;-)
Well, they still need to switch between keymaps, since presumably they used the Latin keymap to enter `math.` before they can enter π. That is actually another general solution: just install the Greek keymap in addition to your native keymap. The OS typically provides keyboard shortcus to switch between keymaps. Υεσ Ι καν υσε Γρεεκ καρακτερσ! OK, that works. Stephan 2017-06-01 12:14 GMT+02:00 Serhiy Storchaka <storchaka@gmail.com>:
01.06.17 12:49, Victor Stinner пише:
2017-06-01 8:47 GMT+02:00 Serhiy Storchaka <storchaka@gmail.com>:
What you are think about adding Unicode aliases for some mathematic names in the math module? ;-)
math.π = math.pi
How do you write π (pi) with a keyboard on Windows, Linux or macOS?
This shouldn't be a problem for Greek users. ;-)
Personally I copied them from a character table.
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
On Thu, Jun 01, 2017 at 11:49:43AM +0200, Victor Stinner wrote:
How do you write π (pi) with a keyboard on Windows, Linux or macOS?
Use the compose key 🙌 for linux: https://help.ubuntu.com/community/ComposeKey for windows: https://github.com/SamHocevar/wincompose for macosx: http://lol.zoy.org/blog/2012/06/17/compose-key-on-os-x Then I wrote my own ~/.XCompose file with: <Multi_key> <asterisk> <p> : "π" U03C0 # GREEK SMALL LETTER PI so it's like the vim digraphs. Cheers, -- zmo
On Jun 01 2017, Victor Stinner <victor.stinner-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
2017-06-01 8:47 GMT+02:00 Serhiy Storchaka <storchaka@gmail.com>:
What you are think about adding Unicode aliases for some mathematic names in the math module? ;-)
math.π = math.pi
How do you write π (pi) with a keyboard on Windows, Linux or macOS?
Under Linux, you'd use the Compose facility. Take a look at eg. /usr/share/X11/locale/en_US.UTF-8/Compose for all the nice things it let's you enter: $ egrep '[πτΓ]' /usr/share/X11/locale/en_US.UTF-8/Compose <dead_greek> <G> : "Γ" U0393 # GREEK CAPITAL LETTER GAMMA <dead_greek> <p> : "π" U03C0 # GREEK SMALL LETTER PI <dead_greek> <t> : "τ" U03C4 # GREEK SMALL LETTER TAU Best, -Nikolaus -- GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.«
On 01/06/17 20:11, Nikolaus Rath wrote:
On Jun 01 2017, Victor Stinner <victor.stinner-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
2017-06-01 8:47 GMT+02:00 Serhiy Storchaka <storchaka@gmail.com>:
What you are think about adding Unicode aliases for some mathematic names in the math module? ;-)
math.π = math.pi How do you write π (pi) with a keyboard on Windows, Linux or macOS? Under Linux, you'd use the Compose facility. Take a look at eg. /usr/share/X11/locale/en_US.UTF-8/Compose for all the nice things it let's you enter:
$ egrep '[πτΓ]' /usr/share/X11/locale/en_US.UTF-8/Compose <dead_greek> <G> : "Γ" U0393 # GREEK CAPITAL LETTER GAMMA <dead_greek> <p> : "π" U03C0 # GREEK SMALL LETTER PI <dead_greek> <t> : "τ" U03C4 # GREEK SMALL LETTER TAU
Have you ever seen a keyboard with a <dead_greek> key in real life, though? -- Thomas Jollans m ☎ +31 6 42630259 e ✉ tjol@tjol.eu
On Fri, Jun 2, 2017 at 7:52 AM, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
Victor Stinner wrote:
How do you write π (pi) with a keyboard on Windows, Linux or macOS?
On a Mac, π is Option-p and ∑ is Option-w.
I don't have a strong opinion about it being in the stdlib, but I'd also point out that a strong advantage to having these defined in a module at all is that third-party interpreters (e.g. IPython, bpython, some IDEs) that support tab-completion make these easy to type as well, and I find them to be very readable for math-heavy code.
The width of Greek letters is East Asian Ambiguous. Using ambiguous width characters possibly will be a reason that is source code layout break on specific locale. Masayuki 2017-06-01 15:47 GMT+09:00 Serhiy Storchaka <storchaka@gmail.com>:
What you are think about adding Unicode aliases for some mathematic names in the math module? ;-)
math.π = math.pi math.τ = math.tau math.Γ = math.gamma math.ℯ = math.e
Unfortunately we can't use ∞, ∑ and √ as identifiers. :-(
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Hi Masayuki, I admit that my understanding of this issue is very limited. Nevertheless, I would like to point out that the encoding assumed for a Python3 source file never depends on the locale. My understanding is that in the default encoding for Python source files (utf-8), East Asian Ambiguous characters must be assumed narrow. Now there are also legacy encodings where they are fullwidth. But it is always determined by the encoding, which in turn is specified or implied in the source file. So I don't actually see an issue here. Am I missing something? Stephan Op 1 jun. 2017 16:08 schreef "Masayuki YAMAMOTO" <ma3yuki.8mamo10@gmail.com
:
The width of Greek letters is East Asian Ambiguous. Using ambiguous width characters possibly will be a reason that is source code layout break on specific locale. Masayuki 2017-06-01 15:47 GMT+09:00 Serhiy Storchaka <storchaka@gmail.com>:
What you are think about adding Unicode aliases for some mathematic names in the math module? ;-)
math.π = math.pi math.τ = math.tau math.Γ = math.gamma math.ℯ = math.e
Unfortunately we can't use ∞, ∑ and √ as identifiers. :-(
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Hi Stephan, Nevertheless, I would like to point out that the encoding assumed for a
Python3 source file never depends on the locale.
Yeah, as you pointed out. I'd like to correct my said.
My understanding is that in the default encoding for Python source files (utf-8), East Asian Ambiguous characters must be assumed narrow. Now there are also legacy encodings where they are fullwidth. But it is always determined by the encoding, which in turn is specified or implied in the source file.
The mapping for ambiguous width assumes on East Asia legacy encodings and non East Asia legacy encodings, but not recommend to UTF-8 and other Unicode encodings. Displaying ambiguous width characters behave narrow by default, it isn't related to encoding. [*] Let me see... Several softwares have a setting that changes ambiguous width to halfwidth or fullwidth regardless for encoding (e.g. gnome-terminal, vim). And some fonts that are used in East Asia make glyph that is Greek letters and other signs to adjust to fullwidth, they break layout under halfwidth settings. It is possible that avoids these fonts, and uses multi language support font, yet signs that are only used in East Asia don't have halfwidth glyph no matter the ambiguous width. Therefore, in case of using East Asia language, it is difficult that set displaying Greek letters as halfwidth. Regards, Masayuki [*] http://unicode.org/reports/tr11/#Recommendations
I'm slightly confused as to what you mean, but here goes: So you're saying that: - Glyphs like pi have an ambiguous width. - Most text editors/terminals let you choose between halfwidth (roughly normal monospace width?) and fullwidth (double the size). - However, many East Asian fonts do NOT have halfwidth support. Is this correct? -- Ryan (ライアン) Yoko Shimomura > ryo (supercell/EGOIST) > Hiroyuki Sawano >> everyone else http://refi64.com On Jun 1, 2017 2:27 PM, "Masayuki YAMAMOTO" <ma3yuki.8mamo10@gmail.com> wrote: Hi Stephan, Nevertheless, I would like to point out that the encoding assumed for a
Python3 source file never depends on the locale.
Yeah, as you pointed out. I'd like to correct my said.
My understanding is that in the default encoding for Python source files (utf-8), East Asian Ambiguous characters must be assumed narrow. Now there are also legacy encodings where they are fullwidth. But it is always determined by the encoding, which in turn is specified or implied in the source file.
The mapping for ambiguous width assumes on East Asia legacy encodings and non East Asia legacy encodings, but not recommend to UTF-8 and other Unicode encodings. Displaying ambiguous width characters behave narrow by default, it isn't related to encoding. [*] Let me see... Several softwares have a setting that changes ambiguous width to halfwidth or fullwidth regardless for encoding (e.g. gnome-terminal, vim). And some fonts that are used in East Asia make glyph that is Greek letters and other signs to adjust to fullwidth, they break layout under halfwidth settings. It is possible that avoids these fonts, and uses multi language support font, yet signs that are only used in East Asia don't have halfwidth glyph no matter the ambiguous width. Therefore, in case of using East Asia language, it is difficult that set displaying Greek letters as halfwidth. Regards, Masayuki [*] http://unicode.org/reports/tr11/#Recommendations _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Yes, it's correct. I'd show you a link to vim help for ambiguous width setting. http://vimdoc.sourceforge.net/htmldoc/options.html#'ambiwidth' Masayuki 2017-06-02 5:05 GMT+09:00 Ryan Gonzalez <rymg19@gmail.com>:
I'm slightly confused as to what you mean, but here goes:
So you're saying that:
- Glyphs like pi have an ambiguous width. - Most text editors/terminals let you choose between halfwidth (roughly normal monospace width?) and fullwidth (double the size). - However, many East Asian fonts do NOT have halfwidth support.
Is this correct?
-- Ryan (ライアン) Yoko Shimomura > ryo (supercell/EGOIST) > Hiroyuki Sawano >> everyone else http://refi64.com
On Jun 1, 2017 2:27 PM, "Masayuki YAMAMOTO" <ma3yuki.8mamo10@gmail.com> wrote:
Hi Stephan,
Nevertheless, I would like to point out that the encoding assumed for a
Python3 source file never depends on the locale.
Yeah, as you pointed out. I'd like to correct my said.
My understanding is that in the default encoding for Python source files (utf-8), East Asian Ambiguous characters must be assumed narrow. Now there are also legacy encodings where they are fullwidth. But it is always determined by the encoding, which in turn is specified or implied in the source file.
The mapping for ambiguous width assumes on East Asia legacy encodings and non East Asia legacy encodings, but not recommend to UTF-8 and other Unicode encodings. Displaying ambiguous width characters behave narrow by default, it isn't related to encoding. [*]
Let me see... Several softwares have a setting that changes ambiguous width to halfwidth or fullwidth regardless for encoding (e.g. gnome-terminal, vim). And some fonts that are used in East Asia make glyph that is Greek letters and other signs to adjust to fullwidth, they break layout under halfwidth settings. It is possible that avoids these fonts, and uses multi language support font, yet signs that are only used in East Asia don't have halfwidth glyph no matter the ambiguous width. Therefore, in case of using East Asia language, it is difficult that set displaying Greek letters as halfwidth.
Regards, Masayuki
[*] http://unicode.org/reports/tr11/#Recommendations
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
On Thu, Jun 1, 2017, at 10:08, Masayuki YAMAMOTO wrote:
The width of Greek letters is East Asian Ambiguous. Using ambiguous width characters possibly will be a reason that is source code layout break on specific locale.
I don't think PEP 8 approves anyway of doing the kind of column alignment that this (or for that matter proportional fonts) would break. One example is specifically called out as a "pet peeve". Of course, it also doesn't exactly approve of non-ASCII identifiers (PEP 3131 specifically forbids them in the standard library).
On Fri, Jun 2, 2017 at 2:40 AM, Random832 <random832@fastmail.com> wrote:
On Thu, Jun 1, 2017, at 10:08, Masayuki YAMAMOTO wrote:
The width of Greek letters is East Asian Ambiguous. Using ambiguous width characters possibly will be a reason that is source code layout break on specific locale.
I don't think PEP 8 approves anyway of doing the kind of column alignment that this (or for that matter proportional fonts) would break. One example is specifically called out as a "pet peeve".
Of course, it also doesn't exactly approve of non-ASCII identifiers (PEP 3131 specifically forbids them in the standard library).
PEP 8 has nothing against non-ASCII identifiers where they make sense. The Py3 grammar was changed to be full Unicode specifically to permit that sort of thing. Personally, I would continue to use math.pi because it's easier to type *on my keyboard* than something involving letters I have to compose, but it may well be different for someone who already shifts keyboard from Latin to Greek regularly. Regardless, the stdlib does, as you say, avoid non-ASCII. ChrisA
On Thu, Jun 1, 2017 at 9:47 AM, Serhiy Storchaka <storchaka@gmail.com> wrote:
What you are think about adding Unicode aliases for some mathematic names in the math module? ;-)
math.π = math.pi math.τ = math.tau math.Γ = math.gamma math.ℯ = math.e
Unfortunately we can't use ∞, ∑ and √ as identifiers. :-(
If this were to happen, I would only add π and forget about the others. It is the only one that is nearly 100 percent unambiguous. And seeing that in code or listed in math or builtins might have a nice wow factor to some. If π were in builtins, it might actually be useful as being more readable and faster to type than math.pi or np.pi. As math.π, I'm not sure it's worth it, although less harmful than math.tau. In IPython/Jupyter, you can type \pi + tab, and you'll get π. This even works on command line! -- Koos (mobile)
I think it's silliness and I don't even know how to type those characters. On May 31, 2017 11:49 PM, "Serhiy Storchaka" <storchaka@gmail.com> wrote:
What you are think about adding Unicode aliases for some mathematic names in the math module? ;-)
math.π = math.pi math.τ = math.tau math.Γ = math.gamma math.ℯ = math.e
Unfortunately we can't use ∞, ∑ and √ as identifiers. :-(
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
On Thu, Jun 1, 2017 at 8:47 AM, Serhiy Storchaka <storchaka@gmail.com> wrote:
What you are think about adding Unicode aliases for some mathematic names in the math module? ;-)
math.π = math.pi math.τ = math.tau math.Γ = math.gamma math.ℯ = math.e
Unfortunately we can't use ∞, ∑ and √ as identifiers. :-(
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
* it duplicates functionality * I have no idea how to write those chars on Linux; if I did, I'm not sure it'd be the same on OSX and Windows (probably not) * duplicated aliases might make sense if they add readability; in this case they don't unless (maybe) you have a mathematical background. I can infer what "math.gamma" stands for but not being a mathematician math.Γ makes absolutely zero sense to me. * if you really want to do that you can simply do "from math import gamma as Γ" but it's something I wouldn't like if I were to read your code * I generally dislike any non-ASCII API; the fact that Python 3 allows you to do that should not be an incentive to promote such habit in the stdlib or anywhere else except in the end-user code, and it's something I still wouldn't like it except if in comments or docstrings -1 -- Giampaolo - http://grodola.blogspot.com
On 2 June 2017 at 12:17, Giampaolo Rodola' <g.rodola@gmail.com> wrote: > On Thu, Jun 1, 2017 at 8:47 AM, Serhiy Storchaka <storchaka@gmail.com> > wrote: > >> What you are think about adding Unicode aliases for some mathematic names >> in the math module? ;-) >> >> math.π = math.pi >> math.τ = math.tau >> math.Γ = math.gamma >> math.ℯ = math.e >> >> Unfortunately we can't use ∞, ∑ and √ as identifiers. :-( >> >> [...] > * duplicated aliases might make sense if they add readability; in this > case they don't unless (maybe) you have a mathematical background. I can > infer what "math.gamma" stands for but not being a mathematician math.Γ > makes absolutely zero sense to me. > > There is a significant number of scientific Python programmers (21% according to PyCharm 2016), so it is not that rare to meet someone who knows what is Gamma function. And for many of them π is much more readable than np.pi. Also there is another problem, confusion between Gamma function and Euler–Mascheroni constant, the first one is Γ, the second one is γ (perfectly opposite to PEP 8 capitalization rules :-), while both of them are frequently denoted as just gamma (in particular math.gamma follows the PEP8 rules, but is counter-intuitive for most scientist). All that said, I agree that these problems are easily solved by a custom import from. Still there is something in (or related to?) this proposal I think is worth considering: Can we also allow identifiers like ∫ or √. This will make many expressions more similar to usual TeX, plus it will be useful for projects like SymPy. -- Ivan
I would love to show how easy it is to write from math import pi as π, gamma as Γ but I had to cheat by copying from the OP since I don't know how to type these (and even if you were to tell me how I'd forget tomorrow). So, I am still in favor of the rule "only ASCII in the stdlib". On Fri, Jun 2, 2017 at 3:48 PM, Ivan Levkivskyi <levkivskyi@gmail.com> wrote: > On 2 June 2017 at 12:17, Giampaolo Rodola' <g.rodola@gmail.com> wrote: > >> On Thu, Jun 1, 2017 at 8:47 AM, Serhiy Storchaka <storchaka@gmail.com> >> wrote: >> >>> What you are think about adding Unicode aliases for some mathematic >>> names in the math module? ;-) >>> >>> math.π = math.pi >>> math.τ = math.tau >>> math.Γ = math.gamma >>> math.ℯ = math.e >>> >>> Unfortunately we can't use ∞, ∑ and √ as identifiers. :-( >>> >>> [...] >> * duplicated aliases might make sense if they add readability; in this >> case they don't unless (maybe) you have a mathematical background. I can >> infer what "math.gamma" stands for but not being a mathematician math.Γ >> makes absolutely zero sense to me. >> >> > There is a significant number of scientific Python programmers (21% > according to PyCharm 2016), so it is not that rare to meet someone who > knows what is Gamma function. > And for many of them π is much more readable than np.pi. Also there is > another problem, confusion between Gamma function and Euler–Mascheroni > constant, the first one is Γ, > the second one is γ (perfectly opposite to PEP 8 capitalization rules :-), > while both of them are frequently denoted as just gamma (in particular > math.gamma follows the PEP8 rules, > but is counter-intuitive for most scientist). > > All that said, I agree that these problems are easily solved by a custom > import from. Still there is something in (or related to?) this proposal > I think is worth considering: Can we also allow identifiers like ∫ or √. > This will make many expressions more similar to usual TeX, > plus it will be useful for projects like SymPy. > > -- > Ivan > > > > _______________________________________________ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > > -- --Guido van Rossum (python.org/~guido)
On 3 June 2017 at 00:55, Guido van Rossum <guido@python.org> wrote:
[...] So, I am still in favor of the rule "only ASCII in the stdlib".
But what about the other question? Currently, integral, sum, infinity, square root etc. Unicode symbols are all prohibited in identifiers. Is it possible to allow them? (Btw IPython just supports normal TeX notations like \pi, \lambda etc, so it is very easy to remember) -- Ivan
Are those characters not considered Unicode letters? Maybe we could add their category to the allowed set? On Jun 2, 2017 4:02 PM, "Ivan Levkivskyi" <levkivskyi@gmail.com> wrote:
On 3 June 2017 at 00:55, Guido van Rossum <guido@python.org> wrote:
[...] So, I am still in favor of the rule "only ASCII in the stdlib".
But what about the other question? Currently, integral, sum, infinity, square root etc. Unicode symbols are all prohibited in identifiers. Is it possible to allow them?
(Btw IPython just supports normal TeX notations like \pi, \lambda etc, so it is very easy to remember)
-- Ivan
On 3 June 2017 at 01:29, Guido van Rossum <guido@python.org> wrote:
Are those characters not considered Unicode letters? Maybe we could add their category to the allowed set?
Yes, they are not considered letters, they are in category Sm. Unfortunately, +, -, |, and other symbol that clearly should not be in identifiers are also in this category, so we cannot add the whole category. It is possible to include particular ranges, but there should be a discussion about what exactly can/should be included. -- Ivan
On 6/2/2017 7:56 PM, Ivan Levkivskyi wrote:
On 3 June 2017 at 01:29, Guido van Rossum <guido@python.org <mailto:guido@python.org>> wrote:
Are those characters not considered Unicode letters? Maybe we could add their category to the allowed set?
Yes, they are not considered letters, they are in category Sm.
I presume that is Symbol - math.
Unfortunately, +, -, |, and other symbol that clearly should not be in identifiers are also in this category, so we cannot add the whole category. It is possible to include particular ranges,
Having to test ranges will slow down identifier recognition.
but there should be a discussion about what exactly can/should be included.
I believe the current python definition of 'identifier' is taken from the Unicode Standard for default identifiers. Any change would have to be propagated to regex engines, IDEs, and anything else that parses python. I suggest that you ask Martin Loewis for his opinion on changing the identifier definition. -- Terry Jan Reedy
On Fri, Jun 02, 2017 at 04:29:16PM -0700, Guido van Rossum wrote:
Are those characters not considered Unicode letters? Maybe we could add their category to the allowed set?
They're not letters: py> {unicodedata.category(c) for c in '∑√∫∞'} {'Sm'} That's Symbol, Math. One problem is that the 'Sm' category includes a whole lot of mathematical symbols that we probably don't want in identifiers: ∴ ∣ ≈ ≒ ≝ ≫ ≮ ⊞ (plus MANY more variations on = < and > operators) including some "Confusables": ∁ ∊ ∨ ∗ ∑ etc C ε v * Σ http://www.unicode.org/reports/tr39/ Of course a language can define identifiers however it likes, but I think it is relevant that the Unicode Consortium's default algorithm for determining an identifier excludes Sm. http://www.unicode.org/reports/tr31/ I also disagree with Ivan that these symbols would be particularly useful in general, even for maths-heavy code, although I wouldn't say no to special casing ∞ (infinity) and maybe √ as a unary square root operator. -- Steve
OK, I think this discussion is pretty much dead then. We definitely shouldn't allow math operators in identifiers, otherwise in Python 4 or 5 we couldn't introduce them as operators. On Fri, Jun 2, 2017 at 5:10 PM, Steven D'Aprano <steve@pearwood.info> wrote:
On Fri, Jun 02, 2017 at 04:29:16PM -0700, Guido van Rossum wrote:
Are those characters not considered Unicode letters? Maybe we could add their category to the allowed set?
They're not letters:
py> {unicodedata.category(c) for c in '∑√∫∞'} {'Sm'}
That's Symbol, Math.
One problem is that the 'Sm' category includes a whole lot of mathematical symbols that we probably don't want in identifiers:
∴ ∣ ≈ ≒ ≝ ≫ ≮ ⊞ (plus MANY more variations on = < and > operators)
including some "Confusables":
∁ ∊ ∨ ∗ ∑ etc
C ε v * Σ
http://www.unicode.org/reports/tr39/
Of course a language can define identifiers however it likes, but I think it is relevant that the Unicode Consortium's default algorithm for determining an identifier excludes Sm.
http://www.unicode.org/reports/tr31/
I also disagree with Ivan that these symbols would be particularly useful in general, even for maths-heavy code, although I wouldn't say no to special casing ∞ (infinity) and maybe √ as a unary square root operator.
-- Steve _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido van Rossum (python.org/~guido)
Sorry for probably stupid question! Is something like -> class A: def __oper__(self, '⊞', other): return something(self.value, other) a = A() a ⊞ 3 thinkable? On 6/3/17, Guido van Rossum <guido@python.org> wrote:
OK, I think this discussion is pretty much dead then. We definitely shouldn't allow math operators in identifiers, otherwise in Python 4 or 5 we couldn't introduce them as operators.
On Fri, Jun 2, 2017 at 5:10 PM, Steven D'Aprano <steve@pearwood.info> wrote:
On Fri, Jun 02, 2017 at 04:29:16PM -0700, Guido van Rossum wrote:
Are those characters not considered Unicode letters? Maybe we could add their category to the allowed set?
They're not letters:
py> {unicodedata.category(c) for c in '∑√∫∞'} {'Sm'}
That's Symbol, Math.
One problem is that the 'Sm' category includes a whole lot of mathematical symbols that we probably don't want in identifiers:
∴ ∣ ≈ ≒ ≝ ≫ ≮ ⊞ (plus MANY more variations on = < and > operators)
including some "Confusables":
∁ ∊ ∨ ∗ ∑ etc
C ε v * Σ
http://www.unicode.org/reports/tr39/
Of course a language can define identifiers however it likes, but I think it is relevant that the Unicode Consortium's default algorithm for determining an identifier excludes Sm.
http://www.unicode.org/reports/tr31/
I also disagree with Ivan that these symbols would be particularly useful in general, even for maths-heavy code, although I wouldn't say no to special casing ∞ (infinity) and maybe √ as a unary square root operator.
-- Steve _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido van Rossum (python.org/~guido)
On Sat, Jun 3, 2017 at 3:42 PM, Pavol Lisy <pavol.lisy@gmail.com> wrote:
Sorry for probably stupid question! Is something like ->
class A: def __oper__(self, '⊞', other): return something(self.value, other)
a = A() a ⊞ 3
thinkable?
No, because operators need to be defined before you get to individual objects, and they need precedence and associativity. So it'd have to be defined at the compiler level. Also, having arbitrary operators gets extremely confusing. It's not easy to reason about code when you don't know what's even an operator. Not a stupid question, but one for which the answer is "definitely not like that". ChrisA
For reference, haskell is perhaps the closest language to providing arbitrary infix operators, and it requires that they be surrounded by backticks. That is A `op` B is equivalent to op(A, B) That doesn't work for python (backtick is taken) and I don't think anything similar is a good idea. On Sat, Jun 3, 2017 at 1:56 AM Chris Angelico <rosuav@gmail.com> wrote:
On Sat, Jun 3, 2017 at 3:42 PM, Pavol Lisy <pavol.lisy@gmail.com> wrote:
Sorry for probably stupid question! Is something like ->
class A: def __oper__(self, '⊞', other): return something(self.value, other)
a = A() a ⊞ 3
thinkable?
No, because operators need to be defined before you get to individual objects, and they need precedence and associativity. So it'd have to be defined at the compiler level.
Also, having arbitrary operators gets extremely confusing. It's not easy to reason about code when you don't know what's even an operator.
Not a stupid question, but one for which the answer is "definitely not like that".
ChrisA _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Hi Joshua,
A `op` B
is equivalent to
op(A, B
This can of course be faked in Python. https://gist.github.com/stephanh42/a4d6d66b10cfecf935c9531150afb247 Now you can do: ======== @BinopCallable def add(x, y): return x + y print(3 @add@ 5) =========== Stephan 2017-06-03 7:59 GMT+02:00 Joshua Morton <joshua.morton13@gmail.com>:
For reference, haskell is perhaps the closest language to providing arbitrary infix operators, and it requires that they be surrounded by backticks. That is
A `op` B
is equivalent to
op(A, B)
That doesn't work for python (backtick is taken) and I don't think anything similar is a good idea.
On Sat, Jun 3, 2017 at 1:56 AM Chris Angelico <rosuav@gmail.com> wrote:
On Sat, Jun 3, 2017 at 3:42 PM, Pavol Lisy <pavol.lisy@gmail.com> wrote:
Sorry for probably stupid question! Is something like ->
class A: def __oper__(self, '⊞', other): return something(self.value, other)
a = A() a ⊞ 3
thinkable?
No, because operators need to be defined before you get to individual objects, and they need precedence and associativity. So it'd have to be defined at the compiler level.
Also, having arbitrary operators gets extremely confusing. It's not easy to reason about code when you don't know what's even an operator.
Not a stupid question, but one for which the answer is "definitely not like that".
ChrisA _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Julia lets you define new infix operators directly, including using mathematical symbols as operators. Not that I think that is a good idea, but you can do it. On Jun 3, 2017 2:00 AM, "Joshua Morton" <joshua.morton13@gmail.com> wrote: For reference, haskell is perhaps the closest language to providing arbitrary infix operators, and it requires that they be surrounded by backticks. That is A `op` B is equivalent to op(A, B) That doesn't work for python (backtick is taken) and I don't think anything similar is a good idea. On Sat, Jun 3, 2017 at 1:56 AM Chris Angelico <rosuav@gmail.com> wrote:
On Sat, Jun 3, 2017 at 3:42 PM, Pavol Lisy <pavol.lisy@gmail.com> wrote:
Sorry for probably stupid question! Is something like ->
class A: def __oper__(self, '⊞', other): return something(self.value, other)
a = A() a ⊞ 3
thinkable?
No, because operators need to be defined before you get to individual objects, and they need precedence and associativity. So it'd have to be defined at the compiler level.
Also, having arbitrary operators gets extremely confusing. It's not easy to reason about code when you don't know what's even an operator.
Not a stupid question, but one for which the answer is "definitely not like that".
ChrisA _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
On 6/3/17, Chris Angelico <rosuav@gmail.com> wrote:
On Sat, Jun 3, 2017 at 3:42 PM, Pavol Lisy <pavol.lisy@gmail.com> wrote:
Sorry for probably stupid question! Is something like ->
class A: def __oper__(self, '⊞', other): return something(self.value, other)
a = A() a ⊞ 3
thinkable?
No, because operators need to be defined before you get to individual objects, and they need precedence and associativity. So it'd have to be defined at the compiler level.
Thanks for clarifying this point. Sorry for another stupid question: coding import machinery couldn't be used too, right? (I mean something like hylang.org ) Because ast could not understand these operators (and precedence and associativity)? BTW there could be also question about "multipliability". I mean something like a↑↑↑n ( see https://en.wikipedia.org/wiki/Knuth%27s_up-arrow_notation )
Also, having arbitrary operators gets extremely confusing. It's not easy to reason about code when you don't know what's even an operator.
I was thinking about it, but python is like this! You couldn't be really sure what is operator + doing! :) And it could be much easier to learn what some operator means in some library than for example understand async paradigm. (at least for some people)
Not a stupid question, but one for which the answer is "definitely not like that".
Thanks again! :) Although I am not sure it is definitely impossible I see that it is pretty pretty difficult.
On 3 June 2017 at 17:22, Pavol Lisy <pavol.lisy@gmail.com> wrote:
On 6/3/17, Chris Angelico <rosuav@gmail.com> wrote:
On Sat, Jun 3, 2017 at 3:42 PM, Pavol Lisy <pavol.lisy@gmail.com> wrote:
Sorry for probably stupid question! Is something like ->
class A: def __oper__(self, '⊞', other): return something(self.value, other)
a = A() a ⊞ 3
thinkable?
No, because operators need to be defined before you get to individual objects, and they need precedence and associativity. So it'd have to be defined at the compiler level.
Thanks for clarifying this point.
Sorry for another stupid question: coding import machinery couldn't be used too, right? (I mean something like hylang.org ) Because ast could not understand these operators (and precedence and associativity)?
Source translation frontends *can* define new in-fix operators, but they need to translate them into explicit method and/or function calls before they reach the AST. So a frontend that added "A @ B" support to Python 2.7 (for example), would need to translate it into something like "numpy.dot(A, B)" or "matmul(A, B)" at the Python AST level. It would then be up to that function to emulate Python 3's __matmul__ special method support (or not, if the frontend was happy to only support a particular type, such as NumPy arrays) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 3 June 2017 at 15:55, Chris Angelico <rosuav@gmail.com> wrote:
On Sat, Jun 3, 2017 at 3:42 PM, Pavol Lisy <pavol.lisy@gmail.com> wrote:
Sorry for probably stupid question! Is something like ->
class A: def __oper__(self, '⊞', other): return something(self.value, other)
a = A() a ⊞ 3
thinkable?
No, because operators need to be defined before you get to individual objects, and they need precedence and associativity. So it'd have to be defined at the compiler level.
Also, having arbitrary operators gets extremely confusing. It's not easy to reason about code when you don't know what's even an operator.
Not a stupid question, but one for which the answer is "definitely not like that".
A useful background read on this question specifically in the context of Python is PEP 465 (which added A@B for matrix multiplication), and in particular its discussion of the rejected alternatives: https://www.python.org/dev/peps/pep-0465/#rejected-alternatives-to-adding-a-... For most purposes, the existing set of operators is sufficient, since we can alias them for unusual purposes (e.g. "/" for path joining in pathlib) when we don't need access to the more conventional meaning (division in that case, since "dividing one path segment by another" is nonsensical) and context makes it possible for the reader to understand what is going on ("filepath = segment1 / segment2 / segment3" looks a lot like writing out a filesystem path as a string and the name of the assignment target makes it clear this is a filesystem path operation, not a division operation). Matrix multiplication turned out to be a genuine expection, since all the other binary operators had well defined meanings as elementwise-operators, so borrowing one of them for matrix multiplication meant losing access to the corresponding elementwise operation, and there typically *weren't* enough hints from the context to let you know whether "*" was by element or the dot product. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
03.06.17 03:31, Guido van Rossum пише:
OK, I think this discussion is pretty much dead then. We definitely shouldn't allow math operators in identifiers, otherwise in Python 4 or 5 we couldn't introduce them as operators.
Sorry. I proposed this idea as a joke. math.π is useless, but mostly harmless. But I don't want to change Python grammar. The rule for Python identifiers already is not easy, there is no simple regular expression for them, and I'm sure most tools proceeding Python sources (even the tokenize module and IDLE) do not handle all Python identifier correctly. For example they don't recognize the symbol ℘ (U+2118, SCRIPT CAPITAL P) as a valid identifier.
On Sat, Jun 03, 2017 at 03:51:50PM +0300, Serhiy Storchaka wrote:
The rule for Python identifiers already is not easy, there is no simple regular expression for them, and I'm sure most tools proceeding Python sources (even the tokenize module and IDLE) do not handle all Python identifier correctly. For example they don't recognize the symbol ℘ (U+2118, SCRIPT CAPITAL P) as a valid identifier.
They shouldn't, because it isn't a valid identifier: it's a Maths Symbol, not a letter, same as ∑ √ ∫ ∞ etc. https://en.wikipedia.org/wiki/Weierstrass_p py> unicodedata.category('℘') 'Sm' But Python 3.5 does treat it as an identifier! py> ℘ = 1 # should be a SyntaxError ? py> ℘ 1 There's a bug here, somewhere, I'm just not sure where... The PEP for non-ASCII identifiers is quite old now (it was written for Unicode 4!) but it excludes category 'Sm' in its identifier algorithm: https://www.python.org/dev/peps/pep-3131/#id16 -- Steve
On Sun, Jun 04, 2017 at 02:36:50AM +1000, Steven D'Aprano wrote:
But Python 3.5 does treat it as an identifier!
py> ℘ = 1 # should be a SyntaxError ? py> ℘ 1
There's a bug here, somewhere, I'm just not sure where...
That appears to be the only Symbol Math character which is accepted as an identifier in Python 3.5: py> import unicodedata py> all_unicode = map(chr, range(0x110000)) py> symbols = [c for c in all_unicode if unicodedata.category(c) == 'Sm'] py> len(symbols) 948 py> ns = {} py> for c in symbols: ... try: ... exec(c + " = 1", ns) ... except SyntaxError: ... pass ... else: ... print(c, unicodedata.name(c)) ... ℘ SCRIPT CAPITAL P py> -- Steve
On Sun, Jun 4, 2017 at 2:48 AM, Steven D'Aprano <steve@pearwood.info> wrote:
On Sun, Jun 04, 2017 at 02:36:50AM +1000, Steven D'Aprano wrote:
But Python 3.5 does treat it as an identifier!
py> ℘ = 1 # should be a SyntaxError ? py> ℘ 1
There's a bug here, somewhere, I'm just not sure where...
That appears to be the only Symbol Math character which is accepted as an identifier in Python 3.5:
py> import unicodedata py> all_unicode = map(chr, range(0x110000)) py> symbols = [c for c in all_unicode if unicodedata.category(c) == 'Sm'] py> len(symbols) 948 py> ns = {} py> for c in symbols: ... try: ... exec(c + " = 1", ns) ... except SyntaxError: ... pass ... else: ... print(c, unicodedata.name(c)) ... ℘ SCRIPT CAPITAL P py>
Curious. And not specific to 3.5 - the exact same thing happens in 3.7. Here's the full category breakdown: cats = collections.defaultdict(int) ns = {} for c in map(chr, range(1, 0x110000)): try: exec(c + " = 1", ns) except SyntaxError: pass except UnicodeEncodeError: if unicodedata.category(c) != "Cs": raise else: cats[unicodedata.category(c)] += 1 defaultdict(<class 'int'>, {'Po': 1, 'Lu': 1702, 'Pc': 1, 'Ll': 2063, 'Lo': 112703, 'Lt': 31, 'Lm': 245, 'Nl': 236, 'Mn': 2, 'Sm': 1, 'So': 1}) For reference, as well as the 948 Sm, there are 1690 Mn and 5777 So, but only these characters are valid from them: \u1885 Mn MONGOLIAN LETTER ALI GALI BALUDA \u1886 Mn MONGOLIAN LETTER ALI GALI THREE BALUDA ℘ Sm SCRIPT CAPITAL P ℮ So ESTIMATED SYMBOL 2118 SCRIPT CAPITAL P and 212E ESTIMATED SYMBOL are listed in PropList.txt as Other_ID_Start, so they make sense. But that doesn't explain the two characters from category Mn. It also doesn't explain why U+309B and U+309C are *not* valid, despite being declared Other_ID_Start. Maybe it's a bug? Maybe 309B and 309C somehow got switched into 1885 and 1886?? ChrisA
On 03/06/17 20:41, Chris Angelico wrote:
[snip] For reference, as well as the 948 Sm, there are 1690 Mn and 5777 So, but only these characters are valid from them:
\u1885 Mn MONGOLIAN LETTER ALI GALI BALUDA \u1886 Mn MONGOLIAN LETTER ALI GALI THREE BALUDA ℘ Sm SCRIPT CAPITAL P ℮ So ESTIMATED SYMBOL
2118 SCRIPT CAPITAL P and 212E ESTIMATED SYMBOL are listed in PropList.txt as Other_ID_Start, so they make sense. But that doesn't explain the two characters from category Mn. It also doesn't explain why U+309B and U+309C are *not* valid, despite being declared Other_ID_Start. Maybe it's a bug? Maybe 309B and 309C somehow got switched into 1885 and 1886??
\u1885 and \u1886 are categorised as letters (category Lo) by my Python 3.5. (Which makes sense, right?) If your system puts them in category Mn, that's bound to be a bug somewhere. As for \u309B and \u309C - it turns out this is a question of normalisation. PEP 3131 requires NFKC normalisation:
for c in unicodedata.normalize('NFKC', '\u309B'): ... print('%s\tU+%04X\t%s' % (c, ord(c), unicodedata.name(c))) ... U+0020 SPACE U+3099 COMBINING KATAKANA-HIRAGANA VOICED SOUND MARK for c in unicodedata.normalize('NFKC', '\u309C'): ... print('%s\tU+%04X\t%s' % (c, ord(c), unicodedata.name(c))) ... U+0020 SPACE U+309A COMBINING KATAKANA-HIRAGANA SEMI-VOICED SOUND MARK
This is.... interesting. Thomas
On 03/06/17 21:02, Thomas Jollans wrote:
On 03/06/17 20:41, Chris Angelico wrote:
[snip] For reference, as well as the 948 Sm, there are 1690 Mn and 5777 So, but only these characters are valid from them:
\u1885 Mn MONGOLIAN LETTER ALI GALI BALUDA \u1886 Mn MONGOLIAN LETTER ALI GALI THREE BALUDA ℘ Sm SCRIPT CAPITAL P ℮ So ESTIMATED SYMBOL
2118 SCRIPT CAPITAL P and 212E ESTIMATED SYMBOL are listed in PropList.txt as Other_ID_Start, so they make sense. But that doesn't explain the two characters from category Mn. It also doesn't explain why U+309B and U+309C are *not* valid, despite being declared Other_ID_Start. Maybe it's a bug? Maybe 309B and 309C somehow got switched into 1885 and 1886?? \u1885 and \u1886 are categorised as letters (category Lo) by my Python 3.5. (Which makes sense, right?) If your system puts them in category Mn, that's bound to be a bug somewhere.
Actually it turns out that these characters were changed to category Mn in Unicode 9.0, but remain in (X)ID_Start for compatibility. All is right with the world. (All of this just goes to show how much subtlety there is in the science that goes into making Unicode) See: http://www.unicode.org/reports/tr44/tr44-18.html#Unicode_9.0.0
As for \u309B and \u309C - it turns out this is a question of normalisation. PEP 3131 requires NFKC normalisation:
for c in unicodedata.normalize('NFKC', '\u309B'): ... print('%s\tU+%04X\t%s' % (c, ord(c), unicodedata.name(c))) ... U+0020 SPACE U+3099 COMBINING KATAKANA-HIRAGANA VOICED SOUND MARK for c in unicodedata.normalize('NFKC', '\u309C'): ... print('%s\tU+%04X\t%s' % (c, ord(c), unicodedata.name(c))) ... U+0020 SPACE U+309A COMBINING KATAKANA-HIRAGANA SEMI-VOICED SOUND MARK This is.... interesting.
Thomas
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
-- Thomas Jollans m ☎ +31 6 42630259 e ✉ tjol@tjol.eu
On Sun, Jun 4, 2017 at 5:02 AM, Thomas Jollans <tjol@tjol.eu> wrote:
On 03/06/17 20:41, Chris Angelico wrote:
[snip] For reference, as well as the 948 Sm, there are 1690 Mn and 5777 So, but only these characters are valid from them:
\u1885 Mn MONGOLIAN LETTER ALI GALI BALUDA \u1886 Mn MONGOLIAN LETTER ALI GALI THREE BALUDA ℘ Sm SCRIPT CAPITAL P ℮ So ESTIMATED SYMBOL
2118 SCRIPT CAPITAL P and 212E ESTIMATED SYMBOL are listed in PropList.txt as Other_ID_Start, so they make sense. But that doesn't explain the two characters from category Mn. It also doesn't explain why U+309B and U+309C are *not* valid, despite being declared Other_ID_Start. Maybe it's a bug? Maybe 309B and 309C somehow got switched into 1885 and 1886??
\u1885 and \u1886 are categorised as letters (category Lo) by my Python 3.5. (Which makes sense, right?) If your system puts them in category Mn, that's bound to be a bug somewhere.
rosuav@sikorsky:~$ python3.7 -c "import unicodedata; print(unicodedata.unidata_version, unicodedata.category('\u1885'))" 9.0.0 Mn rosuav@sikorsky:~$ python3.6 -c "import unicodedata; print(unicodedata.unidata_version, unicodedata.category('\u1885'))" 8.0.0 Lo rosuav@sikorsky:~$ python3.5 -c "import unicodedata; print(unicodedata.unidata_version, unicodedata.category('\u1885'))" 8.0.0 Lo rosuav@sikorsky:~$ python3.4 -c "import unicodedata; print(unicodedata.unidata_version, unicodedata.category('\u1885'))" 6.3.0 Lo Is it possible that there's a discrepancy between the Unicode version used by the unicodedata module and the one used by the parser? ChrisA
On 04/06/17 00:04, Chris Angelico wrote:
On 03/06/17 20:41, Chris Angelico wrote:
[snip] For reference, as well as the 948 Sm, there are 1690 Mn and 5777 So, but only these characters are valid from them:
\u1885 Mn MONGOLIAN LETTER ALI GALI BALUDA \u1886 Mn MONGOLIAN LETTER ALI GALI THREE BALUDA ℘ Sm SCRIPT CAPITAL P ℮ So ESTIMATED SYMBOL
2118 SCRIPT CAPITAL P and 212E ESTIMATED SYMBOL are listed in PropList.txt as Other_ID_Start, so they make sense. But that doesn't explain the two characters from category Mn. It also doesn't explain why U+309B and U+309C are *not* valid, despite being declared Other_ID_Start. Maybe it's a bug? Maybe 309B and 309C somehow got switched into 1885 and 1886?? \u1885 and \u1886 are categorised as letters (category Lo) by my Python 3.5. (Which makes sense, right?) If your system puts them in category Mn, that's bound to be a bug somewhere. rosuav@sikorsky:~$ python3.7 -c "import unicodedata;
On Sun, Jun 4, 2017 at 5:02 AM, Thomas Jollans <tjol@tjol.eu> wrote: print(unicodedata.unidata_version, unicodedata.category('\u1885'))" 9.0.0 Mn rosuav@sikorsky:~$ python3.6 -c "import unicodedata; print(unicodedata.unidata_version, unicodedata.category('\u1885'))" 8.0.0 Lo rosuav@sikorsky:~$ python3.5 -c "import unicodedata; print(unicodedata.unidata_version, unicodedata.category('\u1885'))" 8.0.0 Lo rosuav@sikorsky:~$ python3.4 -c "import unicodedata; print(unicodedata.unidata_version, unicodedata.category('\u1885'))" 6.3.0 Lo
Is it possible that there's a discrepancy between the Unicode version used by the unicodedata module and the one used by the parser?
It appear to be Unicode policy to keep characters in ID_Start (etc) even if this no longer fits their character category. So in Unicode 9.0, 1885 and 1886 were added to Other_ID_Start for backwards compatibility (like ℘). Thomas
On 03/06/17 18:48, Steven D'Aprano wrote:
On Sun, Jun 04, 2017 at 02:36:50AM +1000, Steven D'Aprano wrote:
But Python 3.5 does treat it as an identifier!
py> ℘ = 1 # should be a SyntaxError ? py> ℘ 1
There's a bug here, somewhere, I'm just not sure where... That appears to be the only Symbol Math character which is accepted as an identifier in Python 3.5:
py> import unicodedata py> all_unicode = map(chr, range(0x110000)) py> symbols = [c for c in all_unicode if unicodedata.category(c) == 'Sm'] py> len(symbols) 948 py> ns = {} py> for c in symbols: ... try: ... exec(c + " = 1", ns) ... except SyntaxError: ... pass ... else: ... print(c, unicodedata.name(c)) ... ℘ SCRIPT CAPITAL P py>
This is actually not a bug in Python, but a quirk in Unicode. I've had a closer look at PEP 3131 [1], which specifies that Python identifiers follow the Unicode classes XID_Start and XID_Continue. ℘ is listed in the standard [2][3] as XID_Start, so Python correctly accepts it as an identifier.
import unicodedata all_unicode = map(chr, range(0x110000)) for c in all_unicode: ... category = unicodedata.category(c) ... if not category.startswith('L') and category != 'Nl': # neither letter nor letter-number ... if c.isidentifier(): ... print('%s\tU+%04X\t%s' % (c, ord(c), unicodedata.name(c))) ... _ U+005F LOW LINE ℘ U+2118 SCRIPT CAPITAL P ℮ U+212E ESTIMATED SYMBOL
℘ and ℮ are actually explicitly mentioned in the Unicode annnex [3]:
2.5Backward Compatibility
Unicode General_Category values are kept as stable as possible, but they can change across versions of the Unicode Standard. The bulk of the characters having a given value are determined by other properties, and the coverage expands in the future according to the assignment of those properties. In addition, the Other_ID_Start property provides a small list of characters that qualified as ID_Start characters in some previous version of Unicode solely on the basis of their General_Category properties, but that no longer qualify in the current version. These are called /grandfathered/ characters.
The Other_ID_Start property includes characters such as the following:
U+2118 ( ℘ ) SCRIPT CAPITAL P U+212E ( ℮ ) ESTIMATED SYMBOL U+309B ( ゛ ) KATAKANA-HIRAGANA VOICED SOUND MARK U+309C ( ゜ ) KATAKANA-HIRAGANA SEMI-VOICED SOUND MARK
I have no idea why U+309B and U+309C are not accepted as identifiers by Python 3.5. This could be a question of Python following an old version of the Unicode standard, or it *could* be a bug. Thomas [1] https://www.python.org/dev/peps/pep-3131/#specification-of-language-changes [2] http://www.unicode.org/Public/4.1.0/ucd/DerivedCoreProperties.txt [3] http://www.unicode.org/reports/tr31/
On 2017-06-03 19:50, Thomas Jollans wrote:
On 03/06/17 18:48, Steven D'Aprano wrote:
On Sun, Jun 04, 2017 at 02:36:50AM +1000, Steven D'Aprano wrote:
But Python 3.5 does treat it as an identifier!
py> ℘ = 1 # should be a SyntaxError ? py> ℘ 1
There's a bug here, somewhere, I'm just not sure where... That appears to be the only Symbol Math character which is accepted as an identifier in Python 3.5:
py> import unicodedata py> all_unicode = map(chr, range(0x110000)) py> symbols = [c for c in all_unicode if unicodedata.category(c) == 'Sm'] py> len(symbols) 948 py> ns = {} py> for c in symbols: ... try: ... exec(c + " = 1", ns) ... except SyntaxError: ... pass ... else: ... print(c, unicodedata.name(c)) ... ℘ SCRIPT CAPITAL P py>
This is actually not a bug in Python, but a quirk in Unicode.
I've had a closer look at PEP 3131 [1], which specifies that Python identifiers follow the Unicode classes XID_Start and XID_Continue. ℘ is listed in the standard [2][3] as XID_Start, so Python correctly accepts it as an identifier.
import unicodedata all_unicode = map(chr, range(0x110000)) for c in all_unicode: ... category = unicodedata.category(c) ... if not category.startswith('L') and category != 'Nl': # neither letter nor letter-number ... if c.isidentifier(): ... print('%s\tU+%04X\t%s' % (c, ord(c), unicodedata.name(c))) ... _ U+005F LOW LINE ℘ U+2118 SCRIPT CAPITAL P ℮ U+212E ESTIMATED SYMBOL
℘ and ℮ are actually explicitly mentioned in the Unicode annnex [3]:
2.5Backward Compatibility
Unicode General_Category values are kept as stable as possible, but they can change across versions of the Unicode Standard. The bulk of the characters having a given value are determined by other properties, and the coverage expands in the future according to the assignment of those properties. In addition, the Other_ID_Start property provides a small list of characters that qualified as ID_Start characters in some previous version of Unicode solely on the basis of their General_Category properties, but that no longer qualify in the current version. These are called /grandfathered/ characters.
The Other_ID_Start property includes characters such as the following:
U+2118 ( ℘ ) SCRIPT CAPITAL P U+212E ( ℮ ) ESTIMATED SYMBOL U+309B ( ゛ ) KATAKANA-HIRAGANA VOICED SOUND MARK U+309C ( ゜ ) KATAKANA-HIRAGANA SEMI-VOICED SOUND MARK
I have no idea why U+309B and U+309C are not accepted as identifiers by Python 3.5. This could be a question of Python following an old version of the Unicode standard, or it *could* be a bug.
[snip] U+309B and U+309C have had the property ID_Start since at least Unicode 6.0 (August 2010). Interestingly, '_' doesn't have that property, although Python does allow identifiers to start with it.
On 3 June 2017 at 21:55, MRAB <python@mrabarnett.plus.com> wrote:
[...]
Interestingly, '_' doesn't have that property, although Python does allow identifiers to start with it.
Yes, it is special cased: if (!_PyUnicode_IsXidStart(first) && first != 0x5F /* LOW LINE */) return 0; -- Ivan
On Fri, Jun 2, 2017 at 7:29 PM, Guido van Rossum <guido@python.org> wrote: Are those characters not considered Unicode letters? Maybe we could add
their category to the allowed set?
Speaking of which, it would be convenient to be able to build strings with non-ascii characters using their Unicode codepoint name: greek_pi = "\u:greek_small_letter_pi" Or something like that. -- Juancarlo *Añez*
On Sat, Jun 3, 2017 at 10:38 AM, Juancarlo Añez <apalala@gmail.com> wrote:
Speaking of which, it would be convenient to be able to build strings with non-ascii characters using their Unicode codepoint name:
greek_pi = "\u:greek_small_letter_pi"
Or something like that.
You mean:
greek_pi = "\N{GREEK SMALL LETTER PI}" greek_pi 'π'
Time machine strikes again :) ChrisA
(Btw IPython just supports normal TeX notations like \pi, \lambda etc, so it is very easy to remember)
IPython dev here. I am the one who implemented (most of) that. We do support it, but it's not easy to remember unless you know how to write latex, and know said character. Question, how would you type the following: In [3]: ℸ = 1 Hint it's easy it's \CHARACTERNAME<tab>, but if you don't know how ℸ is named[1], you are screwed[3]. It's cute, it's compact, it's extremely useful for some internal code, but _exporting_ this as an interface is IMHO an extremely bad idea that hinders readability[2] and usability of the code. On Fri, Jun 2, 2017 at 4:29 PM, Guido van Rossum <guido@python.org> wrote:
Are those characters not considered Unicode letters? Maybe we could add their category to the allowed set?
+1 on allowing more of math symbols and be more flexible on allowed identifiers though. In particular the one mentioned above are part of mathematical operators[4]. It also would be great for some of these to be parsed as infix operators, but that's another topic :-) -- M [1] \daleth [2] and that's assuming your font support said character. [3] Tab completion on full unicode character name does work as well so \GREEK SMALL LETTER GAMMA<tab> will give you γ. And \γ<tab> will expand to \gamma, so you can figure it out, but users still struggle for unknown symbols [4] http://www.fileformat.info/info/unicode/block/mathematical_operators/images.... On Fri, Jun 2, 2017 at 4:02 PM, Ivan Levkivskyi <levkivskyi@gmail.com> wrote:
On 3 June 2017 at 00:55, Guido van Rossum <guido@python.org> wrote:
[...] So, I am still in favor of the rule "only ASCII in the stdlib".
But what about the other question? Currently, integral, sum, infinity, square root etc. Unicode symbols are all prohibited in identifiers. Is it possible to allow them?
(Btw IPython just supports normal TeX notations like \pi, \lambda etc, so it is very easy to remember)
-- Ivan
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
On Sat, Jun 03, 2017 at 01:02:12AM +0200, Ivan Levkivskyi wrote:
On 3 June 2017 at 00:55, Guido van Rossum <guido@python.org> wrote:
[...] So, I am still in favor of the rule "only ASCII in the stdlib".
But what about the other question? Currently, integral, sum, infinity, square root etc. Unicode symbols are all prohibited in identifiers. Is it possible to allow them?
In the last few months, I've been making a lot of use of the TI Nspire CAS calculator, and I think that there is very little benefit to allowing symbols like ∑ √ ∫ (sum, radical/root, integral) unless you have a proper 2-dimensional template system. There's not much, if any, benefit to writing: ∫(expression, lower_limit, upper_limit, name) In fact, that's probably *harder* to read than integrate(expression, lower_limit, upper_limit, name) because the important thing, the fact that this is an integral, is barely visible. Its only a single character. That's not how mathematicians write it! If we had a 2D template system, like the Nspire, we could write what mathematicians do: (best viewed with a non-proportional font) b ⌠ ⎮ 3 2 1 ⎮ x + 2 x − ─── dx ⎮ x ⌡ a I say "best", but of course even with a monospaced font, it still looks pretty awful. You really need a proper GUI interface and support for resizing characters. I'm not suggesting this be part of Python the language! But It might be a nice application written for users of Python, perhaps part of Sage or IPython/Jupiter or a GUI interface to Sympy. You don't need ∫ to be legal in identifies for that. -- Steve
Steven D'Aprano wrote:
There's not much, if any, benefit to writing:
∫(expression, lower_limit, upper_limit, name)
More generally, there's a kind of culture clash between mathematical notation and programming notation. Mathematical notation tends to almost exclusively use single-character names, relying on different fonts and alphabets, and superscripts and subscripts, to get a large enough set of identifiers. Whereas in programming we use a much smaller alphabet and longer names. Having terse symbols for just a few things, and having to spell everything else out longhand, doesn't really help. -- Greg
On Fri, 2 Jun 2017 at 15:56 Guido van Rossum <guido@python.org> wrote: > I would love to show how easy it is to write > > from math import pi as π, gamma as Γ > > but I had to cheat by copying from the OP since I don't know how to type > these (and even if you were to tell me how I'd forget tomorrow). So, I am > still in favor of the rule "only ASCII in the stdlib". > Since this regularly comes up, why don't we add a note to the math module that you can do the above import(s) to bind various mathematical constants to their traditional symbol counterparts? The note can even start off with something like "While Python's standard library only uses ASCII characters to maximize ease of use and contribution, individuals are allowed to use various Unicode characters for variable names." This would also help with making sure people don't come back later and say, "why don't you just add the constants to the module?" -Brett > > On Fri, Jun 2, 2017 at 3:48 PM, Ivan Levkivskyi <levkivskyi@gmail.com> > wrote: > >> On 2 June 2017 at 12:17, Giampaolo Rodola' <g.rodola@gmail.com> wrote: >> >>> On Thu, Jun 1, 2017 at 8:47 AM, Serhiy Storchaka <storchaka@gmail.com> >>> wrote: >>> >>>> What you are think about adding Unicode aliases for some mathematic >>>> names in the math module? ;-) >>>> >>>> math.π = math.pi >>>> math.τ = math.tau >>>> math.Γ = math.gamma >>>> math.ℯ = math.e >>>> >>>> Unfortunately we can't use ∞, ∑ and √ as identifiers. :-( >>>> >>>> [...] >>> * duplicated aliases might make sense if they add readability; in this >>> case they don't unless (maybe) you have a mathematical background. I can >>> infer what "math.gamma" stands for but not being a mathematician math.Γ >>> makes absolutely zero sense to me. >>> >>> >> There is a significant number of scientific Python programmers (21% >> according to PyCharm 2016), so it is not that rare to meet someone who >> knows what is Gamma function. >> And for many of them π is much more readable than np.pi. Also there is >> another problem, confusion between Gamma function and Euler–Mascheroni >> constant, the first one is Γ, >> the second one is γ (perfectly opposite to PEP 8 capitalization rules >> :-), while both of them are frequently denoted as just gamma (in particular >> math.gamma follows the PEP8 rules, >> but is counter-intuitive for most scientist). >> >> All that said, I agree that these problems are easily solved by a custom >> import from. Still there is something in (or related to?) this proposal >> I think is worth considering: Can we also allow identifiers like ∫ or √. >> This will make many expressions more similar to usual TeX, >> plus it will be useful for projects like SymPy. >> >> -- >> Ivan >> >> >> >> _______________________________________________ >> Python-ideas mailing list >> Python-ideas@python.org >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of Conduct: http://python.org/psf/codeofconduct/ >> >> > > > -- > --Guido van Rossum (python.org/~guido) > _______________________________________________ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ >
03.06.17 20:45, Brett Cannon пише:
Since this regularly comes up, why don't we add a note to the math module that you can do the above import(s) to bind various mathematical constants to their traditional symbol counterparts? The note can even start off with something like "While Python's standard library only uses ASCII characters to maximize ease of use and contribution, individuals are allowed to use various Unicode characters for variable names." This would also help with making sure people don't come back later and say, "why don't you just add the constants to the module?"
Nice idea!
On Sat, 03 Jun 2017 17:45:43 +0000, Brett Cannon wrote:
On Fri, 2 Jun 2017 at 15:56 Guido van Rossum <guido@python.org> wrote:
I would love to show how easy it is to write
from math import pi as π, gamma as Γ
[...]
but I had to cheat by copying from the OP since I don't know how to type these (and even if you were to tell me how I'd forget tomorrow). So, I am still in favor of the rule "only ASCII in the stdlib".
Since this regularly comes up, why don't we add a note to the math module that you can do the above import(s) to bind various mathematical constants to their traditional symbol counterparts? ...
Because in order to add that note to the math module, you have to violate the "only ASCII in the stdlib" rule. ;-) People who would benefit from seeing ϖ (or π) in their code will arrange to type it in proportion to that benefit (and probably already have). I know how to type those characters in my environments, but it might not be that easy if I had to do so on a random computer with a random keyboard running a random OS. Ob XKCD: https://xkcd.com/1806/ (my apologies if someone else already brought this up; I haven't been following along that closely). And I want to say something about this argument being like the one about being able to represent people's names correctly, but while the ratio between the circumference of a circle to its diameter has a name, it isn't a person. Dan
On 4 June 2017 at 05:02, Dan Sommers <dan@tombstonezero.net> wrote:
On Sat, 03 Jun 2017 17:45:43 +0000, Brett Cannon wrote:
On Fri, 2 Jun 2017 at 15:56 Guido van Rossum <guido@python.org> wrote:
I would love to show how easy it is to write
from math import pi as π, gamma as Γ
[...]
but I had to cheat by copying from the OP since I don't know how to type these (and even if you were to tell me how I'd forget tomorrow). So, I am still in favor of the rule "only ASCII in the stdlib".
Since this regularly comes up, why don't we add a note to the math module that you can do the above import(s) to bind various mathematical constants to their traditional symbol counterparts? ...
Because in order to add that note to the math module, you have to violate the "only ASCII in the stdlib" rule. ;-)
The ASCII-only restriction in the standard library is merely "all public APIs will use ASCII-only identifiers", rather than "We don't allow the use of Unicode anywhere" (Several parts of the documentation would be rather unreadable if they were restricted to ASCII characters). However, clarifying that made me realise we've never actually written that down anywhere - it's just been an assumed holdover from the fact that Python 2.7 is still being supported, and doesn't allow for Unicode identifiers in the first place. https://github.com/python/peps/pull/285 is a PR to explicitly document the standard library API restriction in the "Names to Avoid" part of PEP 8. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
AFAK it was in whatever PEP introduced Unicode identifiers. On Jun 3, 2017 11:24 PM, "Nick Coghlan" <ncoghlan@gmail.com> wrote:
On 4 June 2017 at 05:02, Dan Sommers <dan@tombstonezero.net> wrote:
On Sat, 03 Jun 2017 17:45:43 +0000, Brett Cannon wrote:
On Fri, 2 Jun 2017 at 15:56 Guido van Rossum <guido@python.org> wrote:
I would love to show how easy it is to write
from math import pi as π, gamma as Γ
[...]
but I had to cheat by copying from the OP since I don't know how to type these (and even if you were to tell me how I'd forget tomorrow). So, I am still in favor of the rule "only ASCII in the stdlib".
Since this regularly comes up, why don't we add a note to the math module that you can do the above import(s) to bind various mathematical constants to their traditional symbol counterparts? ...
Because in order to add that note to the math module, you have to violate the "only ASCII in the stdlib" rule. ;-)
The ASCII-only restriction in the standard library is merely "all public APIs will use ASCII-only identifiers", rather than "We don't allow the use of Unicode anywhere" (Several parts of the documentation would be rather unreadable if they were restricted to ASCII characters).
However, clarifying that made me realise we've never actually written that down anywhere - it's just been an assumed holdover from the fact that Python 2.7 is still being supported, and doesn't allow for Unicode identifiers in the first place.
https://github.com/python/peps/pull/285 is a PR to explicitly document the standard library API restriction in the "Names to Avoid" part of PEP 8.
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
On 5 June 2017 at 07:00, Guido van Rossum <gvanrossum@gmail.com> wrote:
AFAK it was in whatever PEP introduced Unicode identifiers.
Ah, indeed it is: https://www.python.org/dev/peps/pep-3131/#policy-specification Interestingly, that's stricter than my draft PR for PEP 8, and I'm not entirely sure we follow the "string literals and comments must be in ASCII" part in its entirety: ============ All identifiers in the Python standard library MUST use ASCII-only identifiers, and SHOULD use English words wherever feasible (in many cases, abbreviations and technical terms are used which aren't English). In addition, string literals and comments must also be in ASCII. The only exceptions are (a) test cases testing the non-ASCII features, and (b) names of authors. Authors whose names are not based on the Latin alphabet MUST provide a Latin transliteration of their names. ============ That said, all the potential counter-examples that come to mind are in the documentation, but *not* in the corresponding docstrings (e.g. the Euro symbol used in in the docs for chr() and ord()). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
I think the strictness comes from the observation that the stdlib is read and edited using *lots* of different tools and not every tool is with the program. That argument may be weaker now than when that PEP was written, but I still get emails and see websites with mojibake. (Most recently, the US-PyCon badges had spaces for all non-ASCII letters.) The argument is also weaker for comments than it is for identifiers, since stdlib identifiers will be used through *even more* tools (anyone who uses a name imported from stdlib). Docstrings are perhaps halfway in between. On Sun, Jun 4, 2017 at 8:33 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 5 June 2017 at 07:00, Guido van Rossum <gvanrossum@gmail.com> wrote:
AFAK it was in whatever PEP introduced Unicode identifiers.
Ah, indeed it is: https://www.python.org/dev/peps/pep-3131/#policy- specification
Interestingly, that's stricter than my draft PR for PEP 8, and I'm not entirely sure we follow the "string literals and comments must be in ASCII" part in its entirety:
============ All identifiers in the Python standard library MUST use ASCII-only identifiers, and SHOULD use English words wherever feasible (in many cases, abbreviations and technical terms are used which aren't English). In addition, string literals and comments must also be in ASCII. The only exceptions are (a) test cases testing the non-ASCII features, and (b) names of authors. Authors whose names are not based on the Latin alphabet MUST provide a Latin transliteration of their names. ============
That said, all the potential counter-examples that come to mind are in the documentation, but *not* in the corresponding docstrings (e.g. the Euro symbol used in in the docs for chr() and ord()).
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
-- --Guido van Rossum (python.org/~guido)
On 6/1/17, Serhiy Storchaka <storchaka@gmail.com> wrote:
What you are think about adding Unicode aliases for some mathematic names in the math module? ;-)
math.π = math.pi math.τ = math.tau math.Γ = math.gamma math.ℯ = math.e
Unfortunately we can't use ∞, ∑ and √ as identifiers. :-(
My humble opinion: I would rather like to see something like: from some_wide_used_scientific_library.math_constants import * with good acceptance from scientific users before thinking to add it into stdlib. PS. Maybe this could be interesting for some vim users -> http://gnosis.cx/bin/.vim/after/syntax/python.vim (I am not author of this file) If you apply it in vim then vim show lines (where is not cursor) "translated". Means for example that math.pi is replaced by π. So you still edit "math.pi" but if you move cursor outside of this line then you could see formula simplified/prettified. (or more complicated - because you need a little train your brain to accept new view) I am pretty skeptic how popular this conceal technique could be in vim pythonistas community! ( why skeptic? For example I am testing to improve readability of line similar to self.a = self.b + self.c using with this technique and see in vim ᐠa = ᐠb + ᐠc but **I am not sure if it is really useful** (probably I have to add that I am editing code much more in other editor than vim) ᐠ U+1420 CANADIAN SYLLABICS FINAL GRAVE )
This is a horrible thing that nobody else should do :-), but I *am* the author of the file linked by Pavol. It's based on someone else's version (credited in the file), but I fine tuned it for what I want. I'm also not the author of the conceal plugin for vim, which is pretty much exactly for just this. The screenshot attached is a little bit of a vim session editing a Python file. The key thing is that I *type* only regular ASCII characters; I just tell vim to show my something different on lines I am not currently editing. On Fri, Jun 2, 2017 at 11:26 PM, Pavol Lisy <pavol.lisy@gmail.com> wrote:
On 6/1/17, Serhiy Storchaka <storchaka@gmail.com> wrote:
What you are think about adding Unicode aliases for some mathematic names in the math module? ;-)
math.π = math.pi math.τ = math.tau math.Γ = math.gamma math.ℯ = math.e
Unfortunately we can't use ∞, ∑ and √ as identifiers. :-(
My humble opinion: I would rather like to see something like:
from some_wide_used_scientific_library.math_constants import *
with good acceptance from scientific users before thinking to add it into stdlib.
PS. Maybe this could be interesting for some vim users -> http://gnosis.cx/bin/.vim/after/syntax/python.vim (I am not author of this file)
If you apply it in vim then vim show lines (where is not cursor) "translated". Means for example that math.pi is replaced by π.
So you still edit "math.pi" but if you move cursor outside of this line then you could see formula simplified/prettified. (or more complicated - because you need a little train your brain to accept new view)
I am pretty skeptic how popular this conceal technique could be in vim pythonistas community!
( why skeptic? For example I am testing to improve readability of line similar to
self.a = self.b + self.c
using with this technique and see in vim
ᐠa = ᐠb + ᐠc
but **I am not sure if it is really useful** (probably I have to add that I am editing code much more in other editor than vim)
ᐠ U+1420 CANADIAN SYLLABICS FINAL GRAVE ) _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
-- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th.
I use the conceal feature for this purpose, but I use https://github.com/ehamberg/vim-cute-python instead, which is a more toned-down version of the same idea. I personally find x ≤ y, a ∉ B more readable than x <= y, a not in B etc. Especially the conceal lambda => λ is useful for de-cluttering the code. Stephan 2017-06-03 8:50 GMT+02:00 David Mertz <mertz@gnosis.cx>:
This is a horrible thing that nobody else should do :-), but I *am* the author of the file linked by Pavol. It's based on someone else's version (credited in the file), but I fine tuned it for what I want. I'm also not the author of the conceal plugin for vim, which is pretty much exactly for just this.
The screenshot attached is a little bit of a vim session editing a Python file. The key thing is that I *type* only regular ASCII characters; I just tell vim to show my something different on lines I am not currently editing.
On Fri, Jun 2, 2017 at 11:26 PM, Pavol Lisy <pavol.lisy@gmail.com> wrote:
On 6/1/17, Serhiy Storchaka <storchaka@gmail.com> wrote:
What you are think about adding Unicode aliases for some mathematic names in the math module? ;-)
math.π = math.pi math.τ = math.tau math.Γ = math.gamma math.ℯ = math.e
Unfortunately we can't use ∞, ∑ and √ as identifiers. :-(
My humble opinion: I would rather like to see something like:
from some_wide_used_scientific_library.math_constants import *
with good acceptance from scientific users before thinking to add it into stdlib.
PS. Maybe this could be interesting for some vim users -> http://gnosis.cx/bin/.vim/after/syntax/python.vim (I am not author of this file)
If you apply it in vim then vim show lines (where is not cursor) "translated". Means for example that math.pi is replaced by π.
So you still edit "math.pi" but if you move cursor outside of this line then you could see formula simplified/prettified. (or more complicated - because you need a little train your brain to accept new view)
I am pretty skeptic how popular this conceal technique could be in vim pythonistas community!
( why skeptic? For example I am testing to improve readability of line similar to
self.a = self.b + self.c
using with this technique and see in vim
ᐠa = ᐠb + ᐠc
but **I am not sure if it is really useful** (probably I have to add that I am editing code much more in other editor than vim)
ᐠ U+1420 CANADIAN SYLLABICS FINAL GRAVE ) _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
-- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th.
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
My humble opinion: I would rather like to see something like:
from some_wide_used_scientific_library.math_constants import *
with good acceptance from scientific users before thinking to add it into stdlib.
Agree with this, but note that a similar proposal has once been made to scipy. It was rejected for now since they still also target Python2. So once scipy drops Python2 supports (presumable around 2020 at the latest), this could be re-proposed there. Stephan 2017-06-03 8:26 GMT+02:00 Pavol Lisy <pavol.lisy@gmail.com>:
On 6/1/17, Serhiy Storchaka <storchaka@gmail.com> wrote:
What you are think about adding Unicode aliases for some mathematic names in the math module? ;-)
math.π = math.pi math.τ = math.tau math.Γ = math.gamma math.ℯ = math.e
Unfortunately we can't use ∞, ∑ and √ as identifiers. :-(
My humble opinion: I would rather like to see something like:
from some_wide_used_scientific_library.math_constants import *
with good acceptance from scientific users before thinking to add it into stdlib.
PS. Maybe this could be interesting for some vim users -> http://gnosis.cx/bin/.vim/after/syntax/python.vim (I am not author of this file)
If you apply it in vim then vim show lines (where is not cursor) "translated". Means for example that math.pi is replaced by π.
So you still edit "math.pi" but if you move cursor outside of this line then you could see formula simplified/prettified. (or more complicated - because you need a little train your brain to accept new view)
I am pretty skeptic how popular this conceal technique could be in vim pythonistas community!
( why skeptic? For example I am testing to improve readability of line similar to
self.a = self.b + self.c
using with this technique and see in vim
ᐠa = ᐠb + ᐠc
but **I am not sure if it is really useful** (probably I have to add that I am editing code much more in other editor than vim)
ᐠ U+1420 CANADIAN SYLLABICS FINAL GRAVE ) _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Hi, What you are think about adding Unicode aliases for some mathematic names in the math module? ;-) math.π = math.pi math.τ = math.tau math.Γ = math.gamma math.ℯ = math.e Unfortunately we can't use ∞, ∑ and √ as identifiers. :-( It may be the role of editors to do it if one really want it. I personally use the `pretty-mode` emacs mode, it replaces pi, sum, sqrt, None (∅), tau, gamma, but not math.e obviously. It replaces some other strings like lambda (λ x: ...), and is customizable (I added ∈ ∉ for "in" and "not in"). It only "messes" with visual numbers of characters in a line, but flake8 sees the correct python thrue flycheck so it reports errors properly, and you're still notified you're more than 80 columns long, even if visually there may be a longer valid line. Oh and it's also messing with copying and pasting to share, found myself yesterday pasting a "prettyfied" line of code on IRC and it (legitimately) surprised someone. -- Julien Palard https://mdk.fr
participants (35)
-
Brett Cannon -
Brice PARENT -
Chris Angelico -
Dan Sommers -
David Mertz -
Erik Bray -
Giampaolo Rodola' -
Greg Ewing -
Guido van Rossum -
Guido van Rossum -
Guyzmo -
Ivan Levkivskyi -
Joshua Morton -
Juancarlo Añez -
Julien Palard -
Koos Zevenhoven -
Lucas Wiman -
Masayuki YAMAMOTO -
Matthias Bussonnier -
MRAB -
Nick Coghlan -
Nikolaus Rath -
Oleg Broytman -
Pavol Lisy -
Random832 -
Ryan Gonzalez -
Serhiy Storchaka -
Stephan Houben -
Steven D'Aprano -
Sven R. Kunze -
Terry Reedy -
Thomas Jollans -
Thomas Nyberg -
Todd -
Victor Stinner