Do you have the infinity symbol on your keyboard? I don't!.
Why does what you have on your keyboard matter? Just because the example uses a string literal, doesn't mean that's the only use case. I can pass infinity symbols along in any text medium.
Ummm...cause that's what I use when programming? This is a truly silly idea. What next? float('pi') = 3.14159... float('e') = 2.71828... float('phi') = 1.618... etc. Note that I don't have any of those symbols on my keyboard either. Now, if I were Greek... -- Gerald Britton
On Fri, Jul 12, 2013 at 3:21 PM, Gerald Britton <gerald.britton@gmail.com>wrote:
Do you have the infinity symbol on your keyboard? I don't!.
Why does what you have on your keyboard matter? Just because the example uses a string literal, doesn't mean that's the only use case. I can pass infinity symbols along in any text medium.
Ummm...cause that's what I use when programming?
My point is that this doesn't have to come from source code. It can come from any kind of user input, which is the more common use case for calling float or int in the first place. If you just wanted the number, you'd just type the literal. (Infinity, of course, is a little special, since it doesn't have a literal -- just float("inf")).
-- Gerald Britton _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
OK, so you need users with Greek keyboards, I suppose. I'm not sure the number of those that also use Python applications justifies adding this kind of sugar to the language. On Fri, Jul 12, 2013 at 9:43 AM, Laurens Van Houtven <_@lvh.io> wrote:
On Fri, Jul 12, 2013 at 3:21 PM, Gerald Britton <gerald.britton@gmail.com> wrote:
Do you have the infinity symbol on your keyboard? I don't!.
Why does what you have on your keyboard matter? Just because the example uses a string literal, doesn't mean that's the only use case. I can pass infinity symbols along in any text medium.
Ummm...cause that's what I use when programming?
My point is that this doesn't have to come from source code. It can come from any kind of user input, which is the more common use case for calling float or int in the first place. If you just wanted the number, you'd just type the literal. (Infinity, of course, is a little special, since it doesn't have a literal -- just float("inf")).
-- Gerald Britton _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
-- Gerald Britton
On Fri, Jul 12, 2013 at 3:48 PM, Gerald Britton <gerald.britton@gmail.com>wrote:
OK, so you need users with Greek keyboards, I suppose. I'm not sure the number of those that also use Python applications justifies adding this kind of sugar to the language.
I'm not sure why you're so focused on keyboards. Perhaps "user input" was a poor choice of words on my part: that may just as well come from a different computer :) Or maybe it's a parsed mathematical document. It doesn't necessarily literally have to be typed in by someone. Joshua, elsewhere in this thread, already enumerated all the things float currently accepts. I hope you'll agree that they're far, far more exotic than an infinity sign.
-- Gerald Britton
On 12 July 2013 14:43, Laurens Van Houtven <_@lvh.io> wrote:
On Fri, Jul 12, 2013 at 3:21 PM, Gerald Britton <gerald.britton@gmail.com> wrote:
Do you have the infinity symbol on your keyboard? I don't!.
Why does what you have on your keyboard matter? Just because the example uses a string literal, doesn't mean that's the only use case. I can pass infinity symbols along in any text medium.
Ummm...cause that's what I use when programming?
My point is that this doesn't have to come from source code. It can come from any kind of user input, which is the more common use case for calling float or int in the first place. If you just wanted the number, you'd just type the literal. (Infinity, of course, is a little special, since it doesn't have a literal -- just float("inf")).
I'd try phrasing it as the same sort of thing as what caused the internationalisation aspect to what float and int can receive -- they now accept foreign numbers:
float("߂߃߄") 234.0
Consider also that float accepts "infinity" as well as "inf", and any variant of capitalization. I think it's reasonable that unicode infinity is allowed. However, we don't take all forms of negative symbols or decimal points, so it's not like anything goes.
Man I don't know how you are doing this! I just tried: float('<greek letter pi>') and got Value error: could not convert string to float '<greek letter pi>' For that matter, I can't figure out how to type the greek letter for pi in gmail! Guess I have some things to learn. So, if Python doesn't recognize the symbol for pi, why should it recognize the one for infinity? On Fri, Jul 12, 2013 at 10:02 AM, Joshua Landau <joshua@landau.ws> wrote:
On 12 July 2013 14:43, Laurens Van Houtven <_@lvh.io> wrote:
On Fri, Jul 12, 2013 at 3:21 PM, Gerald Britton <gerald.britton@gmail.com> wrote:
Do you have the infinity symbol on your keyboard? I don't!.
Why does what you have on your keyboard matter? Just because the example uses a string literal, doesn't mean that's the only use case. I can pass infinity symbols along in any text medium.
Ummm...cause that's what I use when programming?
My point is that this doesn't have to come from source code. It can come from any kind of user input, which is the more common use case for calling float or int in the first place. If you just wanted the number, you'd just type the literal. (Infinity, of course, is a little special, since it doesn't have a literal -- just float("inf")).
I'd try phrasing it as the same sort of thing as what caused the internationalisation aspect to what float and int can receive -- they now accept foreign numbers:
float("߂߃߄") 234.0
Consider also that float accepts "infinity" as well as "inf", and any variant of capitalization. I think it's reasonable that unicode infinity is allowed.
However, we don't take all forms of negative symbols or decimal points, so it's not like anything goes.
-- Gerald Britton
On Fri, Jul 12, 2013 at 4:43 PM, Gerald Britton <gerald.britton@gmail.com>wrote:
Man I don't know how you are doing this! I just tried:
float('<greek letter pi>') and got
Value error: could not convert string to float '<greek letter pi>'
For that matter, I can't figure out how to type the greek letter for pi in gmail! Guess I have some things to learn.
So, if Python doesn't recognize the symbol for pi, why should it recognize the one for infinity?
The example he posted is of digits, not of any particular symbol for a constant. The difference, obviously, is that you can't write infinity as a bunch of digits, whereas you can at least approximate pi with any number of digits. lvh
On 12 July 2013 15:46, Laurens Van Houtven <_@lvh.io> wrote:
On Fri, Jul 12, 2013 at 4:43 PM, Gerald Britton <gerald.britton@gmail.com> wrote:
Man I don't know how you are doing this! I just tried:
float('<greek letter pi>') and got
Value error: could not convert string to float '<greek letter pi>'
For that matter, I can't figure out how to type the greek letter for pi in gmail! Guess I have some things to learn.
So, if Python doesn't recognize the symbol for pi, why should it recognize the one for infinity?
The example he posted is of digits, not of any particular symbol for a constant. The difference, obviously, is that you can't write infinity as a bunch of digits, whereas you can at least approximate pi with any number of digits.
Ahem:
float("1"*310) inf
Just because. My personal reason for thinking that unicode infinity is reasonable whereas unicode pi/tau/phi/etc. is not, is simply that we *already* special-case infinity. We do not do so for other mathematical constants. Additionally, Pi only holds the value of half the circle constant by default -- other branches of mathematics uses for other things and some use it as a variable. They are rare, granted, but Pi is not as clear cut as, say, "9" or "infinity".
I was speaking generally about numbers; it's certainly true that any floating point implementation with a limited mantissa and exponent has some upper limit as to which integer it can store exactly; and at some point above that it's going to have to either throw an error, give you a smaller number, or give you infinity ;) On Fri, Jul 12, 2013 at 5:02 PM, Joshua Landau <joshua@landau.ws> wrote:
On 12 July 2013 15:46, Laurens Van Houtven <_@lvh.io> wrote:
On Fri, Jul 12, 2013 at 4:43 PM, Gerald Britton < gerald.britton@gmail.com> wrote:
Man I don't know how you are doing this! I just tried:
float('<greek letter pi>') and got
Value error: could not convert string to float '<greek letter pi>'
For that matter, I can't figure out how to type the greek letter for pi in gmail! Guess I have some things to learn.
So, if Python doesn't recognize the symbol for pi, why should it recognize the one for infinity?
The example he posted is of digits, not of any particular symbol for a constant. The difference, obviously, is that you can't write infinity as a bunch of digits, whereas you can at least approximate pi with any number of digits.
Ahem:
float("1"*310) inf
Just because.
My personal reason for thinking that unicode infinity is reasonable whereas unicode pi/tau/phi/etc. is not, is simply that we *already* special-case infinity. We do not do so for other mathematical constants. Additionally, Pi only holds the value of half the circle constant by default -- other branches of mathematics uses for other things and some use it as a variable. They are rare, granted, but Pi is not as clear cut as, say, "9" or "infinity".
"Just because." so, maybe we should have the interpreter spit out ∞ instead? I get that we special case infinity. Its an IEEE thing. I can sure the next request coming: The various constants represented by unicode characters. On Fri, Jul 12, 2013 at 11:02 AM, Joshua Landau <joshua@landau.ws> wrote:
On 12 July 2013 15:46, Laurens Van Houtven <_@lvh.io> wrote:
On Fri, Jul 12, 2013 at 4:43 PM, Gerald Britton <gerald.britton@gmail.com> wrote:
Man I don't know how you are doing this! I just tried:
float('<greek letter pi>') and got
Value error: could not convert string to float '<greek letter pi>'
For that matter, I can't figure out how to type the greek letter for pi in gmail! Guess I have some things to learn.
So, if Python doesn't recognize the symbol for pi, why should it recognize the one for infinity?
The example he posted is of digits, not of any particular symbol for a constant. The difference, obviously, is that you can't write infinity as a bunch of digits, whereas you can at least approximate pi with any number of digits.
Ahem:
float("1"*310) inf
Just because.
My personal reason for thinking that unicode infinity is reasonable whereas unicode pi/tau/phi/etc. is not, is simply that we *already* special-case infinity. We do not do so for other mathematical constants. Additionally, Pi only holds the value of half the circle constant by default -- other branches of mathematics uses for other things and some use it as a variable. They are rare, granted, but Pi is not as clear cut as, say, "9" or "infinity".
-- Gerald Britton
On Fri, Jul 12, 2013 at 5:14 PM, Gerald Britton <gerald.britton@gmail.com>wrote:
I get that we special case infinity. Its an IEEE thing. I can sure the next request coming: The various constants represented by unicode characters.
This is just a slippery slope argument: what anyone suggests otherwise has nothing to do with *this particular issue*.
On 12 July 2013 16:14, Gerald Britton <gerald.britton@gmail.com> wrote:
"Just because."
so, maybe we should have the interpreter spit out ∞ instead?
I don't know whether this was a joke, but just as int("߅") spits out 5 and not ߅, there is no reason that float("inf") should split out anything other than "inf".
I get that we special case infinity. Its an IEEE thing. I can sure the next request coming: The various constants represented by unicode characters.
I don't see how one leads to the next. None thinks that that's a good idea. This is a *very* restricted change that fits with what we have already done. I don't get the hostility to it. I do get the objections that this isn't needed or that float() has a more restricted scope but this overt dislike to this extent surprises me. This is *minor* extension of the leniency there already is. I'm approximately neutral on the issue, but I'm definitely not as negative as a lot of the reviews it's getting.
On Sat, Jul 13, 2013 at 12:43 AM, Gerald Britton <gerald.britton@gmail.com> wrote:
Man I don't know how you are doing this! I just tried:
float('<greek letter pi>') and got
Value error: could not convert string to float '<greek letter pi>'
For that matter, I can't figure out how to type the greek letter for pi in gmail! Guess I have some things to learn.
So, if Python doesn't recognize the symbol for pi, why should it recognize the one for infinity?
Considering that Python can't represent π in a float anyway, I wouldn't be too bothered. And what else? float('τ') for twice that value? Not really necessary imho. ChrisA
12.07.13 17:52, Chris Angelico написав(ла):
On Sat, Jul 13, 2013 at 12:43 AM, Gerald Britton <gerald.britton@gmail.com> wrote:
So, if Python doesn't recognize the symbol for pi, why should it recognize the one for infinity?
Considering that Python can't represent π in a float anyway, I wouldn't be too bothered.
However Python can represent ½ in a float. Shouldn't it recognize the symbol for ½?
On 12 July 2013 16:42, Serhiy Storchaka <storchaka@gmail.com> wrote:
12.07.13 17:52, Chris Angelico написав(ла):
On Sat, Jul 13, 2013 at 12:43 AM, Gerald Britton <gerald.britton@gmail.com> wrote:
So, if Python doesn't recognize the symbol for pi, why should it recognize the one for infinity?
Considering that Python can't represent π in a float anyway, I wouldn't be too bothered.
However Python can represent ½ in a float. Shouldn't it recognize the symbol for ½?
No. Why would we special-case ½? We'd need a ton of code just to special-case ½, ¾, ⅛, ¼, ⅜, ⅝, ⅞, etc. We don't need or want to special-case any more values.
On Fri, Jul 12, 2013 at 11:45 AM, Joshua Landau <joshua@landau.ws> wrote:
No. Why would we special-case ½? We'd need a ton of code just to special-case ½, ¾, ⅛, ¼, ⅜, ⅝, ⅞, etc. We don't need or want to special-case any more values.
You don't need to special-case every fraction:
import unicodedata [unicodedata.numeric(c) for c in ['½', '¾', '⅛', '¼', '⅜', '⅝', '⅞']] [0.5, 0.75, 0.125, 0.25, 0.375, 0.625, 0.875]
I would actually support the idea for float() to accept whatever unicodedata.numeric() accepts.
On 12 July 2013 17:09, Alexander Belopolsky <alexander.belopolsky@gmail.com> wrote:
On Fri, Jul 12, 2013 at 11:45 AM, Joshua Landau <joshua@landau.ws> wrote:
No. Why would we special-case ½? We'd need a ton of code just to special-case ½, ¾, ⅛, ¼, ⅜, ⅝, ⅞, etc. We don't need or want to special-case any more values.
You don't need to special-case every fraction:
import unicodedata [unicodedata.numeric(c) for c in ['½', '¾', '⅛', '¼', '⅜', '⅝', '⅞']] [0.5, 0.75, 0.125, 0.25, 0.375, 0.625, 0.875]
That's a good point.
I would actually support the idea for float() to accept whatever unicodedata.numeric() accepts.
It doesn't free us from tons of special cases. We already have people arguing over whether 3½ is the traditional 3.5 or whether it's 1.5. We'll need tons of new parsing rules. I'm not convinced, in other words. Additionally, core devs have rejected multiple "negative signs" despite the fact that there is an alternate standard "negative sign". A change of this size is a bit further than reasonable. If it were as simple as just calling "unicodedata.numeric" rather than rewriting the whole float and int parser, I'd not be so hesitant.
On Fri, Jul 12, 2013 at 12:15 PM, Joshua Landau <joshua@landau.ws> wrote:
I would actually support the idea for float() to accept whatever unicodedata.numeric() accepts.
It doesn't free us from tons of special cases. We already have people arguing over whether 3½ is the traditional 3.5 or whether it's 1.5. We'll need tons of new parsing rules. I'm not convinced, in other words.
I should have explained my idea in more detail. I am not suggesting that float('3½') should work. I wrote: "float() to accept whatever unicodedata.numeric() accepts" and
unicodedata.numeric('3½') Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: need a single Unicode character as parameter
Since python does not have a character type, I think it is acceptable for single-character strings to be special.
On 12 July 2013 18:21, Alexander Belopolsky <alexander.belopolsky@gmail.com> wrote:
On Fri, Jul 12, 2013 at 12:15 PM, Joshua Landau <joshua@landau.ws> wrote:
I would actually support the idea for float() to accept whatever unicodedata.numeric() accepts.
It doesn't free us from tons of special cases. We already have people arguing over whether 3½ is the traditional 3.5 or whether it's 1.5. We'll need tons of new parsing rules. I'm not convinced, in other words.
I should have explained my idea in more detail. I am not suggesting that float('3½') should work. I wrote: "float() to accept whatever unicodedata.numeric() accepts" and
unicodedata.numeric('3½') Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: need a single Unicode character as parameter
Since python does not have a character type, I think it is acceptable for single-character strings to be special.
For reference, you want to define these: ៲: 2 ᛰ: 19 𝍱: 90 ៶: 6 ⓴: 20 ൵: 3/4 ⅞: 7/8 ፹: 80 ⑿: 12 ⅽ: 100 𐅱: 1000 𑁜: 20 Ⅵ: 6 𐹫: 30 仨: 3 𝍩: 10 ⑯: 16 ⓬: 12 Ⅽ: 100 ㉓: 23 〩: 9 ⅕: 1/5 ㉛: 31 ௱: 100 ፵: 40 𐡟: 10000 ⅝: 5/8 什: 10 十: 10 𒑇: 9 𐅅: 500 ㉋: 40 𒑏: 1 𐅍: 1000 零: 0 𐩆: 100 ༱: 15/2 𒐷: 3 𐄓: 40 ㊸: 43 𒐿: 4 ¼: 1/4 𐄛: 300 ㈣: 4 ⅶ: 7 𐌡: 5 〧: 7 𐄥: 4000 幺: 1 廾: 9 𐩾: 50 Ⅳ: 4 𒐯: 3 𐄭: 30000 ㆒: 1 玖: 9 𒐗: 3 ⒔: 13 𐄕: 60 𠬙: 3 𒐟: 2 𐄝: 500 ↂ: 10000 七: 7 ㊀: 1 Ⅱ: 2 〇: 0 ⒄: 17 𣬛: 3 𐆊: 0 ㊈: 9 ᛯ: 18 𒐏: 4 𐄍: 7 𐅲: 5000 𐹰: 80 ៱: 1 ୶: 1/8 ৵: 1/8 ⅺ: 11 陸: 6 ៹: 9 𐭾: 100 ꠰: 1/4 ౼: 1 什: 10 Ⅲ: 3 𝍦: 7 𑁤: 100 Ⅺ: 11 ꛫ: 6 𝍮: 60 ꛨ: 3 ⑬: 13 ⅒: 1/10 ⒂: 15 Ⅹ: 10 𒐴: 1 𒑔: 5 ⅚: 5/6 四: 4 ㉘: 28 𐡞: 1000 𐭞: 100 𒑜: 5/6 𐡜: 20 𐅂: 1 叁: 3 𒑄: 8 𐅊: 50 ⒆: 19 ㉈: 10 六: 6 𐅳: 5 〸: 10 𒑌: 4 𐄲: 80000 ㊳: 38 ꠴: 1/8 ㊻: 46 𒐅: 7 𒐼: 4 ㊿: 50 𐄢: 1000 ㈠: 1 ⅑: 1/9 〤: 4 𐄋: 5 𠤪: 1 ㈨: 9 ⑾: 11 ༮: 9/2 萬: 10000 𐄒: 30 ⅙: 1/6 𒐉: 4 𐄖: 70 ⒗: 16 𒐔: 9 ㆕: 4 𐄚: 200 𐅕: 10000 ୳: 1/2 𒐜: 8 ൱: 100 ㊃: 4 一: 1 漆: 7 ⒇: 20 𒐄: 6 ↅ: 6 𐄊: 4 ➉: 10 弎: 3 𒐌: 7 ⓲: 18 ፳: 20 ௰: 10 𐭙: 2 零: 0 𐅷: 2/3 ৴: 1/16 ፻: 100 ៸: 8 𐹹: 800 拾: 10 ⅿ: 1000 𑁟: 50 𠃢: 4 𐄪: 9000 壱: 1 ꛦ: 1 Ⅷ: 8 𑁥: 1000 𝍫: 30 𐹩: 10 ꛮ: 9 Ⅿ: 1000 ⑭: 14 ㉑: 21 𐅗: 10 𒑕: 5 ㉜: 32 𐭛: 4 ㉙: 29 Ⅻ: 12 ⅟: 1 𐡝: 100 千: 1000 𐍁: 90 𐅇: 50000 𒑅: 8 ㉉: 20 𐅸: 3/4 𐅰: 500 𒑍: 5 ༳: -1/2 捌: 8 ㊶: 41 ꠵: 3/16 𐹾: 2/3 卅: 30 ㊾: 49 𒐽: 4 𐭹: 2 𐌣: 50 ㈡: 2 𐄧: 6000 〣: 3 〥: 5 ༫: 3/2 ㈩: 10 𐄯: 50000 𒐭: 2 ⒒: 11 𒑢: 1/4 𢎐: 2 𐅟: 5 亖: 4 𐄗: 80 ㆔: 3 𒐕: 1 ⒚: 19 ⅳ: 4 𐄟: 700 𠦜: 40 𒐝: 9 ⑽: 10 𐤚: 2 ㊆: 7 𐄇: 1 㐅: 5 三: 3 𐄏: 9 𠦌: 40 𒐍: 8 ⑲: 19 ៳: 3 佰: 100 𐹶: 500 ৷: 1/4 ൴: 1/2 ౺: 2 ፸: 70 百: 100 ⅼ: 50 ⳽: 1/2 𑁢: 80 𝍠: 1 Ⅴ: 5 ⑪: 11 𝍨: 9 ꛩ: 4 𐹮: 60 Ⅸ: 9 Ⅼ: 50 ⓭: 13 𒑒: 4 𐏓: 10 ㉖: 26 ⅔: 2/3 ⒃: 16 𐡚: 3 𐡙: 2 𐭘: 1 ㉞: 34 𐅜: 2 𒑂: 7 參: 3 ㈥: 6 陆: 6 𐅬: 500 𐅄: 50 𒑊: 2 贰: 2 ㉎: 70 𐅌: 500 ꠲: 3/4 ༰: 13/2 ㊱: 36 ൳: 1/4 ፼: 10000 陸: 6 〺: 30 ㊹: 44 ⅐: 1/7 ½: 1/2 𒐢: 5 𐌠: 1 ㈦: 7 𐄤: 3000 㠪: 5 𐄬: 20000 𒐒: 7 ➓: 10 弐: 2 ↉: 0 𐅔: 1000 𐄔: 50 ⒕: 14 𐹽: 1/3 𐄜: 400 𒐂: 4 𒑚: 1/3 ㊁: 2 ↇ: 50000 億: 100000000⒅: 18 𒐊: 5 ㊉: 10 ⅘: 4/5 𐄌: 6 𒐧: 5 ௲: 1000 ⑳: 20 ⓰: 16 ⅱ: 2 ৶: 3/16 𐹷: 600 ୵: 1/16 ౻: 3 ⅹ: 10 ៰: 0 𐭽: 20 𑁣: 90 𐅡: 10 ⅜: 3/8 𝍥: 6 ៷: 7 ⑫: 12 兩: 2 𐹯: 70 ꛬ: 7 𝍭: 50 柒: 7 𒑓: 4 𐅑: 50 ㉗: 27 𑁛: 10 𐅙: 1 ㉟: 35 𐭝: 20 参: 3 𒑃: 7 𐅁: 1/2 𐩇: 1000 𐭻: 4 𒑋: 3 𐅉: 10 ㉏: 80 㭍: 7 𐅩: 50 ꠳: 1/16 𐄱: 70000 ፴: 30 ㊴: 39 𒐻: 3 ㊼: 47 𐭸: 1 𒐣: 2 𠄡: 5 ㈧: 8 𒐫: 9 𐄩: 8000 ༭: 7/2 𒐓: 8 廾: 9 𐄑: 20 ⅷ: 8 五: 5 𝍣: 4 𒐛: 7 ⒘: 17 𐄙: 100 𒐬: 1 𒐃: 5 𐄡: 900 𑁡: 70 ↆ: 50 万: 10000 ㊄: 5 𒐋: 6 𐄉: 3 二: 2 弍: 2 ୲: 1/4 ⓳: 19 ⑰: 17 𐤙: 100 𐅶: 1/2 𐅤: 10 ៵: 5 𐭺: 3 𐅝: 2 ౸: 0 ৹: 16 ⅾ: 500 廿: 20 𐹼: 1/4 𝍢: 3 ꛪ: 5 𑁠: 60 𐅦: 50 ꛧ: 2 𐅫: 300 𝍪: 20 ⓫: 11 Ⅾ: 500 ꛯ: 0 𐹬: 40 𒑐: 2 六: 6 ⅖: 2/5 𒑛: 2/3 ㉔: 24 𐏕: 100 𐭚: 3 ᛮ: 17 𐡘: 1 𐅞: 2 ⒀: 13 𝍰: 80 𐅯: 500 𒐺: 3 𒑀: 6 ㉊: 30 兆: 1000000000000𐩄: 10 𐍊: 900 𒑈: 9 𐹭: 50 𐅎: 5000 ㉌: 50 陌: 100 ༲: 17/2 貳: 2 𒐰: 4 ㊷: 42 八: 8 ⅓: 1/3 𒐸: 4 亿: 100000000兩: 2 𐌢: 10 𒐠: 3 𐄦: 5000 ㈤: 5 ༪: 1/2 〨: 8 𐄮: 40000 Ⅰ: 1 ⅗: 3/5 ⒓: 12 𒐐: 5 𐤖: 1 𐹱: 90 ⒛: 20 𒐘: 4 𐄞: 600 㒃: 2 𒐀: 2 ↁ: 5000 ㊇: 8 ⅛: 1/8 ⅵ: 6 〦: 6 𒐈: 3 伍: 5 𐄎: 8 〢: 2 ൲: 1000 ⑱: 18 𐹳: 200 ୷: 3/16 ៴: 4 𐹵: 400 𐅆: 5000 ⅻ: 12 ৸: 3/4 ౹: 1 ⓾: 10 𐭿: 1000 𐩽: 1 𐅣: 10 𒑡: 1/6 𐹻: 1/2 𝍧: 8 𠫪: 6 ፶: 50 𑁝: 30 ⓮: 14 𝍯: 70 𦉭: 4 𐅓: 500 𒑑: 3 ❿: 10 𐹴: 300 𐏔: 20 ㉕: 25 𐅛: 2 𒑙: 2 𐭟: 1000 ൰: 10 九: 9 ፺: 90 𒑁: 7 𐅀: 1/4 叄: 3 𐩅: 20 ⅴ: 5 𐅋: 100 𒑉: 9 𐹸: 700 𐡛: 10 ㊲: 37 𐄳: 90000 ꠱: 1/2 𐤗: 10 ㊺: 45 〹: 20 ¾: 3/4 𒑟: 1/8 𐄣: 2000 𒐡: 4 𐅭: 500 𐄫: 10000 𒐩: 7 貮: 2 ༯: 11/2 𝍡: 2 𐅧: 50 𒐑: 6 ⒖: 15 𐅚: 1 ⑩: 10 𐤛: 3 𢦘: 3 𒐙: 5 ⅲ: 3 𒑠: 1/4 𐅏: 5 ㊂: 3 𒐚: 6 ↀ: 1000 𠀁: 7 肆: 4 Ⅶ: 7 ↈ: 100000 ㉍: 60 拾: 10 𐄘: 90 𐹲: 100 ⅰ: 1 ⓱: 17 𒐪: 8 𠁤: 4 ୴: 3/4 𐹺: 900 ⅸ: 9 壹: 1 ౾: 3 ፲: 10 𠫽: 3 𐅪: 100 𐅠: 10 𒐱: 5 𝍤: 5 ፷: 60 𐹪: 20 𒐥: 3 𐅨: 50 𒐁: 3 ⑮: 15 𐅃: 5 𝍬: 40 ꛭ: 8 ㉒: 22 仟: 1000 𐅐: 10 ㉚: 30 𐅮: 500 𐅘: 1 𒐵: 2 𒑞: 2/3 𐭜: 10 ⓯: 15 𒑝: 1/3 ౽: 2 ⒁: 14 𒑆: 9 卄: 20 𐏒: 2 𐅥: 30 𐅈: 5 𒑎: 6 卌: 40 𐅒: 100 𐄰: 60000 𒐹: 5 𒐶: 3 ㊵: 40 𒐨: 6 𐭼: 10 阡: 1000 𒐾: 4 𑁞: 40 ㊽: 48 ㈢: 3 𐄠: 800 𐏑: 1 𒐦: 4 𐅢: 10 𐅖: 50000 𐄨: 7000 𒐮: 3 ༬: 5/2 𒐇: 9 𒐤: 3 ㆓: 2 𐄐: 10 ⒑: 10 𒐖: 2 𐅴: 50 參: 3 𐤘: 20 ⒙: 18 𒐞: 1 𠦃: 30 ㉝: 33 〡: 1 Personally I'm not too sure that ㊱ and ㊱ and co. really deserve to be parsed...
On Fri, Jul 12, 2013 at 12:15 PM, Joshua Landau <joshua@landau.ws> wrote:
Additionally, core devs have rejected multiple "negative signs" despite the fact that there is an alternate standard "negative sign".
On 12 July 2013 18:27, Alexander Belopolsky <alexander.belopolsky@gmail.com> wrote:
On Fri, Jul 12, 2013 at 12:15 PM, Joshua Landau <joshua@landau.ws> wrote:
Additionally, core devs have rejected multiple "negative signs" despite the fact that there is an alternate standard "negative sign".
Did they?
Ah, thanks -- I'm actually glad to be corrected here.
On Sat, Jul 13, 2013 at 1:42 AM, Serhiy Storchaka <storchaka@gmail.com> wrote:
12.07.13 17:52, Chris Angelico написав(ла):
On Sat, Jul 13, 2013 at 12:43 AM, Gerald Britton <gerald.britton@gmail.com> wrote:
So, if Python doesn't recognize the symbol for pi, why should it recognize the one for infinity?
Considering that Python can't represent π in a float anyway, I wouldn't be too bothered.
However Python can represent ½ in a float. Shouldn't it recognize the symbol for ½?
That one would be more plausible, in the same way that many of the other Unicode digits are accepted. Not sure there's all that much of a use-case for it, though, and if it's going to complicate the code I wouldn't bother; for instance, it's fairly obvious that "3½" should be accepted, but what does "½3" mean? I'm -0 on it initially, but would change that to +0 if a suitable answer is found for that (even if it's "raise ValueError, same as float('1.1.1') does") that doesn't make the code horrendous. ChrisA
On Fri, Jul 12, 2013 at 5:51 PM, Chris Angelico <rosuav@gmail.com> wrote:
On Sat, Jul 13, 2013 at 1:42 AM, Serhiy Storchaka <storchaka@gmail.com> wrote:
12.07.13 17:52, Chris Angelico написав(ла):
On Sat, Jul 13, 2013 at 12:43 AM, Gerald Britton <gerald.britton@gmail.com> wrote:
So, if Python doesn't recognize the symbol for pi, why should it recognize the one for infinity?
Considering that Python can't represent π in a float anyway, I wouldn't be too bothered.
However Python can represent ½ in a float. Shouldn't it recognize the symbol for ½?
That one would be more plausible, in the same way that many of the other Unicode digits are accepted. Not sure there's all that much of a use-case for it, though, and if it's going to complicate the code I wouldn't bother; for instance, it's fairly obvious that "3½" should be accepted, but what does "½3" mean? I'm -0 on it initially, but would change that to +0 if a suitable answer is found for that (even if it's "raise ValueError, same as float('1.1.1') does") that doesn't make the code horrendous.
Umm, last time I checked, ³*½ = 1.5. Which brings us to yet another problem: will we implement magic so that '10²' becomes 100? And '√25' becomes 5? -- Kwpolska <http://kwpolska.tk> | GPG KEY: 5EAAEA16 stop html mail | always bottom-post http://asciiribbon.org | http://caliburn.nl/topposting.html
On Sat, Jul 13, 2013 at 2:08 AM, Chris “Kwpolska” Warrick <kwpolska@gmail.com> wrote:
On Fri, Jul 12, 2013 at 5:51 PM, Chris Angelico <rosuav@gmail.com> wrote:
... it's fairly obvious that "3½" should be accepted, but what does "½3" mean? I'm -0 on it initially, but would change that to +0 if a suitable answer is found for that (even if it's "raise ValueError, same as float('1.1.1') does") that doesn't make the code horrendous.
Umm, last time I checked, ³*½ = 1.5.
Not sure what you mean here. Yes, 3 times one half equals one and one half, but the abuttal of "3½" meant 3.5 - at least, it did in my school days. If float("½") == 0.5, then float("3½") should be 3.5. Anything else would be treating it as an expression, not a floating-point value. ChrisA
12.07.13 18:51, Chris Angelico написав(ла):
On Sat, Jul 13, 2013 at 1:42 AM, Serhiy Storchaka <storchaka@gmail.com> wrote:
12.07.13 17:52, Chris Angelico написав(ла):
On Sat, Jul 13, 2013 at 12:43 AM, Gerald Britton <gerald.britton@gmail.com> wrote:
So, if Python doesn't recognize the symbol for pi, why should it recognize the one for infinity?
Considering that Python can't represent π in a float anyway, I wouldn't be too bothered.
However Python can represent ½ in a float. Shouldn't it recognize the symbol for ½?
That one would be more plausible, in the same way that many of the other Unicode digits are accepted. Not sure there's all that much of a use-case for it, though, and if it's going to complicate the code I wouldn't bother; for instance, it's fairly obvious that "3½" should be accepted, but what does "½3" mean? I'm -0 on it initially, but would change that to +0 if a suitable answer is found for that (even if it's "raise ValueError, same as float('1.1.1') does") that doesn't make the code horrendous.
This will complicate the code is not more than recognizing ∞. I don't propose accepting ½. I just noticed that the accepting ∞ will open a wide gate for a lot of other cases.
On 12 July 2013 19:17, Serhiy Storchaka <storchaka@gmail.com> wrote:
This will complicate the code is not more than recognizing ∞. I don't propose accepting ½. I just noticed that the accepting ∞ will open a wide gate for a lot of other cases.
Whilst I disagreed, the usual hunger of Python-list to jump at bad ideas like piranhas means that you've effectively been proven right. This doesn't mean that ∞ is a bad thing to accept -- just that if we accept it we're going to have to be ready to push back against all the other people who want silly extensions. //justmyopinionlyyrs
On 12/07/2013 19:17, Serhiy Storchaka wrote:
12.07.13 18:51, Chris Angelico написав(ла):
On Sat, Jul 13, 2013 at 1:42 AM, Serhiy Storchaka <storchaka@gmail.com> wrote:
12.07.13 17:52, Chris Angelico написав(ла):
On Sat, Jul 13, 2013 at 12:43 AM, Gerald Britton <gerald.britton@gmail.com> wrote:
So, if Python doesn't recognize the symbol for pi, why should it recognize the one for infinity?
Considering that Python can't represent π in a float anyway, I wouldn't be too bothered.
However Python can represent ½ in a float. Shouldn't it recognize the symbol for ½?
That one would be more plausible, in the same way that many of the other Unicode digits are accepted. Not sure there's all that much of a use-case for it, though, and if it's going to complicate the code I wouldn't bother; for instance, it's fairly obvious that "3½" should be accepted, but what does "½3" mean? I'm -0 on it initially, but would change that to +0 if a suitable answer is found for that (even if it's "raise ValueError, same as float('1.1.1') does") that doesn't make the code horrendous.
This will complicate the code is not more than recognizing ∞. I don't propose accepting ½. I just noticed that the accepting ∞ will open a wide gate for a lot of other cases.
In other words, it would be the infinite end of the wedge. :-)
13.07.13 01:12, MRAB написав(ла):
On 12/07/2013 19:17, Serhiy Storchaka wrote:
This will complicate the code is not more than recognizing ∞. I don't propose accepting ½. I just noticed that the accepting ∞ will open a wide gate for a lot of other cases.
In other words, it would be the infinite end of the wedge. :-)
To reach the finish line, we must first run ½ of the way. Oh, we must first run ⅓ of the way. Oh…
there is no such thing as a “slippery slope”. ∞ is special. it’s a symbol for exactly one thing that happens to be the same one created using float('inf') in python. the same holds for the vulgar fractions, but they seem to be deprecated in unicode. π is a greek letter commonly used in math to represent a number, but it’s not its one responsibility to represent that number. you could define π to mean something else if you’re evil (i’ve even seen it done for some angle: let the angle between a and b be π), but you can’t redefine ∞. so don’t be silly everyone. the question is if float('∞') should work and i say “why the hell not”
On Sat, Jul 13, 2013 at 1:25 PM, Philipp A. <flying-sheep@web.de> wrote:
there is no such thing as a “slippery slope”. ∞ is special. it’s a symbol for exactly one thing that happens to be the same one created using float('inf') in python. the same holds for the vulgar fractions, but they seem to be deprecated in unicode.
π is a greek letter commonly used in math to represent a number, but it’s not its one responsibility to represent that number. you could define π to mean something else if you’re evil (i’ve even seen it done for some angle: let the angle between a and b be π), but you can’t redefine ∞.
so don’t be silly everyone. the question is if float('∞') should work and i say “why the hell not”
+1
On Sat, Jul 13, 2013 at 1:25 PM, Philipp A. <flying-sheep@web.de> wrote:
so don’t be silly everyone. the question is if float('∞') should work and i say “why the hell not”
Here is why: float(<unicode string>) remained mostly unchanged since unicode was added in Python 2.0. There were internal changes such as a better rounding algorithm and elimination of platform-dependencies when parsing special values (-0, inf, nan, etc.), but overall the design remained the same: replace unicode digits with ASCII equivalents and pass the result to a more or less equivalent of ISO C strtod. Note that even accepting non-ASCII digits is not free from criticism. Python rejected the ISO C's wcstod approach and did not make float() parsing locale-dependent. This was a good decision, but resulted in float() accepting strings with a mix of scripts that don't represent valid numbers in any system. We recently agreed that float() and int() should be changed to reject mixed scripts, but the best way to do that is still being discussed. If we decide that 3.4 is the release in which the way float() and int() parse unicode change, we should do it in a way that will last until Python 4.0 and hopefully beyond. This is what I've been trying to achieve in issue 10581 <http://bugs.python.org/issue10581>, but when it comes to reviewing actual code rather than posting expletives on python-ideas the pull of volunteers shrinks.
On 14/07/13 03:25, Philipp A. wrote:
so don’t be silly everyone. the question is if float('∞') should work and i say “why the hell not”
Firstly, let me say that I personally love the idea of float('∞') working. Or even having literal ∞ recognised as float('inf') (or perhaps that should be Decimal('inf')?). But I'm still voting -1 on this proposal. If the best argument in favour is "why the hell not?", then whatever benefit we might gain is truly tiny. So tiny that the benefit is probably smaller than the cost. And yes, there is a cost, there is always a cost. There are one-off costs: - somebody has to program this feature; - write tests for it; - write documentation; and on-going costs: - that's one more thing for every user to learn; - programmers will have to take this feature into account whenever they use float. Now, you might argue, and I will agree, that these costs are probably tiny costs. But the benefit is even tinier. Cost: tiny, but real; Benefit: "why the hell not?" Overall benefit: negative. Here is a simple implementation that supports ∞, +∞ and -∞. _float = float def float(arg): if isinstance(arg, str): arg = arg.replace('∞', 'inf') return _float(arg) Hands up anyone who already uses this, or something like it, in their code? Anyone? Given how trivial it is to build this functionality if you need it, if you haven't already done so, chances are that you don't need it, even if you think you want it. -- Steven
On 14 July 2013 02:24, Steven D'Aprano <steve@pearwood.info> wrote:
On 14/07/13 03:25, Philipp A. wrote:
so don’t be silly everyone. the question is if float('∞') should work and i say “why the hell not”
Firstly, let me say that I personally love the idea of float('∞') working. Or even having literal ∞ recognised as float('inf') (or perhaps that should be Decimal('inf')?).
But I'm still voting -1 on this proposal. If the best argument in favour is "why the hell not?", then whatever benefit we might gain is truly tiny. So tiny that the benefit is probably smaller than the cost. And yes, there is a cost, there is always a cost. There are one-off costs:
That wasn't the best reason. The best reason was given by the OP, who said that it was for data input. If you receive data that uses ∞, then it's useful.
- somebody has to program this feature; - write tests for it; - write documentation;
and on-going costs:
- that's one more thing for every user to learn;
Doesn't apply here.
- programmers will have to take this feature into account whenever they use float.
This isn't true -- most uses of float(...) don't care about the internationalisation aspect either. Only a minority of cases will need to account for this.
Now, you might argue, and I will agree, that these costs are probably tiny costs. But the benefit is even tinier.
Cost: tiny, but real; Benefit: "why the hell not?" Overall benefit: negative.
With these changes: Cost: People keep giving bad criticisms Benefit: Tiny Overall benefit: Still can't decide
Here is a simple implementation that supports ∞, +∞ and -∞.
_float = float
def float(arg): if isinstance(arg, str): arg = arg.replace('∞', 'inf') return _float(arg)
Hands up anyone who already uses this, or something like it, in their code? Anyone? Given how trivial it is to build this functionality if you need it, if you haven't already done so, chances are that you don't need it, even if you think you want it.
I'd hope not, because that's broken code. All the more reason to accept the proposal.
On Sun, Jul 14, 2013 at 11:39 AM, Joshua Landau <joshua@landau.ws> wrote:
On 14 July 2013 02:24, Steven D'Aprano <steve@pearwood.info> wrote:
and on-going costs:
- that's one more thing for every user to learn;
Doesn't apply here.
Yes, it does; what happens to someone who reads someone else's Python code? To write code, you need to understand one way of spelling something. To read code, you need to understand _every_ way of spelling that thing. That may not be a particularly great cost in this case, but it is a cost. ChrisA
On Sat, Jul 13, 2013 at 9:39 PM, Joshua Landau <joshua@landau.ws> wrote:
The best reason was given by the OP, who said that it was for data input. If you receive data that uses ∞, then it's useful.
Are you serious? Why would anyone use non-ASCII text format for numerical data? Note that
len('∞'.encode()) 3
so using '∞' does not even save space compared to 'inf'.
On 14/07/13 11:39, Joshua Landau wrote:
On 14 July 2013 02:24, Steven D'Aprano <steve@pearwood.info> wrote:
On 14/07/13 03:25, Philipp A. wrote:
so don’t be silly everyone. the question is if float('∞') should work and i say “why the hell not”
Firstly, let me say that I personally love the idea of float('∞') working. Or even having literal ∞ recognised as float('inf') (or perhaps that should be Decimal('inf')?).
But I'm still voting -1 on this proposal. If the best argument in favour is "why the hell not?", then whatever benefit we might gain is truly tiny. So tiny that the benefit is probably smaller than the cost. And yes, there is a cost, there is always a cost. There are one-off costs:
That wasn't the best reason. The best reason was given by the OP, who said that it was for data input. If you receive data that uses ∞, then it's useful.
Only if you are expecting to get float('inf') as the answer. Just because IEEE 754 floating point supports INFs and NANs doesn't mean that any particular application needs or wants to support them. My guess is that for every app that actively would benefit from this, there is another app that would actively have to counter-act this feature, and another 50 that simply don't care. For apps that actively do want to support INFs, doing a text transformation ∞ -> 'inf' before calling float is trivial.
- somebody has to program this feature; - write tests for it; - write documentation;
and on-going costs:
- that's one more thing for every user to learn;
Doesn't apply here.
Of course it does. Do you think that people are born knowing that float('∞') returns an IEEE 754 floating point INF? It's a feature that needs to be learned.
- programmers will have to take this feature into account whenever they use float.
This isn't true -- most uses of float(...) don't care about the internationalisation aspect either. Only a minority of cases will need to account for this.
Correct. And? Most users won't care. Of those that do care, some will be annoyed because previously they could rely on float('∞') raising an exception, and no longer can.
Here is a simple implementation that supports ∞, +∞ and -∞.
_float = float
def float(arg): if isinstance(arg, str): arg = arg.replace('∞', 'inf') return _float(arg)
Hands up anyone who already uses this, or something like it, in their code? Anyone? Given how trivial it is to build this functionality if you need it, if you haven't already done so, chances are that you don't need it, even if you think you want it.
I'd hope not, because that's broken code. All the more reason to accept the proposal.
How is it broken? True, it accepts '∞inity' as well as 'infinity', but that's a feature, not a bug. -- Steven
On 14 July 2013 03:07, Steven D'Aprano <steve@pearwood.info> wrote:
On 14/07/13 11:39, Joshua Landau wrote:
On 14 July 2013 02:24, Steven D'Aprano <steve@pearwood.info> wrote:
On 14/07/13 03:25, Philipp A. wrote:
so don’t be silly everyone. the question is if float('∞') should work and i say “why the hell not”
Firstly, let me say that I personally love the idea of float('∞') working. Or even having literal ∞ recognised as float('inf') (or perhaps that should be Decimal('inf')?).
But I'm still voting -1 on this proposal. If the best argument in favour is "why the hell not?", then whatever benefit we might gain is truly tiny. So tiny that the benefit is probably smaller than the cost. And yes, there is a cost, there is always a cost. There are one-off costs:
That wasn't the best reason. The best reason was given by the OP, who said that it was for data input. If you receive data that uses ∞, then it's useful.
Only if you are expecting to get float('inf') as the answer. Just because IEEE 754 floating point supports INFs and NANs doesn't mean that any particular application needs or wants to support them.
My guess is that for every app that actively would benefit from this, there is another app that would actively have to counter-act this feature, and another 50 that simply don't care. For apps that actively do want to support INFs, doing a text transformation ∞ -> 'inf' before calling float is trivial.
I think it's the best reason because "why not?" is a worse one. Hence it's the best reason. Also, name a single app where accepting unicode infinity is bad.
- somebody has to program this feature; - write tests for it; - write documentation;
and on-going costs:
- that's one more thing for every user to learn;
Doesn't apply here.
Of course it does. Do you think that people are born knowing that float('∞') returns an IEEE 754 floating point INF? It's a feature that needs to be learned.
No it's not. It needs to be learned if you use float on data that can return "∞", excluding data directly from humans (where you don't need to know about it much as most people don't need to know about internationalisation). This is not a burden that most people will feel.
- programmers will have to take this feature into account whenever they use float.
This isn't true -- most uses of float(...) don't care about the internationalisation aspect either. Only a minority of cases will need to account for this.
Correct. And? Most users won't care. Of those that do care, some will be annoyed because previously they could rely on float('∞') raising an exception, and no longer can.
Agreed. But that was a contradiction of the statement "programmers will have to take this feature into account whenever they use float" which it adequately contradicts.
Here is a simple implementation that supports ∞, +∞ and -∞.
_float = float
def float(arg): if isinstance(arg, str): arg = arg.replace('∞', 'inf') return _float(arg)
Hands up anyone who already uses this, or something like it, in their code? Anyone? Given how trivial it is to build this functionality if you need it, if you haven't already done so, chances are that you don't need it, even if you think you want it.
I'd hope not, because that's broken code. All the more reason to accept the proposal.
How is it broken? True, it accepts '∞inity' as well as 'infinity', but that's a feature, not a bug.
First I will admit that originally I misread the code so my tone was more pronounced than it should've been. I posted seconds before I realised, but decided that it wasn't worth changing. Secondly, I'm not convinced that accepting "∞inity" a feature. Thirdly, even assuming it was, the code was written as if it were a direct stand-in for the proposal, which it is not and thus the code is buggy. Of course, it would be as simple as replacing "∞" with "infinity" instead of "inf", AFAICT -- *assuming* that you don't mind that it "breaks" the returned exceptions.
On Sat, Jul 13, 2013 at 9:24 PM, Steven D'Aprano <steve@pearwood.info>wrote:
Or even having literal ∞ recognised as float('inf')
BTW, if having literal ∞ was considered as a language feature [1], I would support it: if x == ∞: ... would be an improvement over existing alternatives if x == float('inf'): ... or if math.isinf(x): ... But float('∞') still looks like line noise. [1] .. for some language other than Python. In that language empty set would be spelled ∅ and string catenation operator would be ⋈. :-)
On 14 July 2013 03:17, Alexander Belopolsky <alexander.belopolsky@gmail.com> wrote:
On Sat, Jul 13, 2013 at 9:24 PM, Steven D'Aprano <steve@pearwood.info> wrote:
Or even having literal ∞ recognised as float('inf')
BTW, if having literal ∞ was considered as a language feature [1], I would support it:
if x == ∞: ...
would be an improvement over existing alternatives
if x == float('inf'): ...
or
if math.isinf(x): ...
But float('∞') still looks like line noise.
I disagree. Personally, code in which copy-paste is the best way to write single-character identifiers is a hassle. I know because I wrote: from itertools import count as æ, permutations as Æ, starmap as ð [globals().setdefault("%c"%sum(ø.encode()),ß)for ø,ß in vars(__builtins__).items()if ø!="vars"] sorted = lambda ħ:ƿ(ƞ for ı in φ(ƴ(lambda:ħ,æ),ń(0,ń(ħ)**(len(ħ)*2-1)*len(ħ)))for ƞ in Æ(ħ)if ǂ(()).__eq__((ŕ(ð(ǂ(Ƽ(ƞ).pop()).__rpow__,φ(ŕ(œ(ƞ,ƴ(lambda:0,ħ)),()),1))),ħ),ı))[::-1] And that was a *nightmare* to edit.
On 14/07/13 16:40, Joshua Landau wrote:
Personally, code in which copy-paste is the best way to write single-character identifiers is a hassle. I know because I wrote:
Copy-pasting is never the best way to write single-character identifiers, however it may be the least-worst way when dealing with unfamiliar characters or those not supported by your input system. It works, even in Notepad. But nobody suggests Notepad is the best way to edit code. Professionals use a more powerful editor with lots of powerful shortcuts. Professionals who need to support non-ASCII characters should likewise choose an editor that provides them with powerful character entry methods that are faster than copy-and-pasting. Looking at the example you give below:
from itertools import count as æ, permutations as Æ, starmap as ð [globals().setdefault("%c"%sum(ø.encode()),ß)for ø,ß in vars(__builtins__).items()if ø!="vars"] sorted = lambda ħ:ƿ(ƞ for ı in φ(ƴ(lambda:ħ,æ),ń(0,ń(ħ)**(len(ħ)*2-1)*len(ħ)))for ƞ in Æ(ħ)if ǂ(()).__eq__((ŕ(ð(ǂ(Ƽ(ƞ).pop()).__rpow__,φ(ŕ(œ(ƞ,ƴ(lambda:0,ħ)),()),1))),ħ),ı))[::-1]
And that was a *nightmare* to edit.
Of course it is, because you have just arbitrarily chosen identifiers that don't mean anything, and obfuscated your algorithm as well. I could generate obfuscated ASCII-only code just as horrible to edit using equally awful identifiers like O00OOllII1, O0O0OlIlIl and so forth. But to a mathematician, identifiers like μ σ and ß are no more obfuscated than len, encode or count. Back in the 1980s, I used a Mac which made entering non-ASCII characters a dream, at least for the limited 8-bit charset that Macs supported. Making allowances for that, the above could be simple, if you know key sequence to get the symbols you want, or if your editor provides an input interface that you are happy to use. We have developers here who have seemingly memorized seemingly vast numbers of Emacs and Vim key sequences to perform the most obscure functions, and yet are apparently utterly terrified of the idea that some time in the future they may have to memorize a key sequence like option-p to get π, or option-u o to get ö. (See, I still remember them, 15+ years since I last used a Mac extensively. Well-thought out mnemonic key sequences for the win.) Editor support for non-ASCII characters ranges from mediocre to absolutely atrocious, depending on the characters and the editor. I don't deny this. A softly, softly approach to non-ASCII identifiers is still wise. I'm still unconvinced that Python 3.4 should accept ∞ in the language, and I am probably one of the minority who would actually made use of such a feature. But let's please put aside the concept that writing code in anything other than a subset of American English characters is by definition an insane thing to do. -- Steven
On 14 July 2013 10:17, Steven D'Aprano <steve@pearwood.info> wrote:
On 14/07/13 16:40, Joshua Landau wrote:
Personally, code in which copy-paste is the best way to write single-character identifiers is a hassle. I know because I wrote:
Copy-pasting is never the best way to write single-character identifiers, however it may be the least-worst way when dealing with unfamiliar characters or those not supported by your input system. It works, even in Notepad. But nobody suggests Notepad is the best way to edit code. Professionals use a more powerful editor with lots of powerful shortcuts. Professionals who need to support non-ASCII characters should likewise choose an editor that provides them with powerful character entry methods that are faster than copy-and-pasting.
How do you input unicode then? I don't count typing escape sequences better, because I don't want to memorise pseudorandom numbers. That said, you have inspired me to find a new plugin for my editor which makes unicode input much easier (\forall for example), so thanks.
We have developers here who have seemingly memorized seemingly vast numbers of Emacs and Vim key sequences to perform the most obscure functions, and yet are apparently utterly terrified of the idea that some time in the future they may have to memorize a key sequence like option-p to get π, or option-u o to get ö. (See, I still remember them, 15+ years since I last used a Mac extensively. Well-thought out mnemonic key sequences for the win.)
The ones I added manually to that were actually single-key shortcuts (ALT-GR <key>); the others were much harder in that they weren't. There's no simple way to usefully fit so many thousands of possibilities into such a small keyboard, in my opinion without reverting to character codes.
Editor support for non-ASCII characters ranges from mediocre to absolutely atrocious, depending on the characters and the editor. I don't deny this. A softly, softly approach to non-ASCII identifiers is still wise. I'm still unconvinced that Python 3.4 should accept ∞ in the language, and I am probably one of the minority who would actually made use of such a feature. But let's please put aside the concept that writing code in anything other than a subset of American English characters is by definition an insane thing to do.
I didn't say it was insane. But I do dislike it. Code should be quick for the majority of people (of the same language) to edit; unicode symbols ruin that barrier. This includes Notepad users. Should I be French, "á" would be completely acceptable -- if you cannot type that as a French human, you're doing something wrong. But expecting typical read-writers of your program to have better access to unicode infinity (which I wrote like that because copy-paste is a hassle) than copy-paste is presumptuous and silly. There is a *lot* of unicode, and it is hard to get at its reaches.
2013/7/14 Joshua Landau <joshua@landau.ws>
I didn't say it was insane. But I do dislike it. Code should be quick for the majority of people (of the same language) to edit; unicode symbols ruin that barrier.
when applied to the oly way to do something: yes. in this case: not in the slightest. float('inf') still works, so if your keyboard layout/compose key doesn’t support ∞, you just use the ascii variant. comparing it to naming a variable á or µ or something isn’t valid at all.
On 14 July 2013 12:07, Philipp A. <flying-sheep@web.de> wrote:
2013/7/14 Joshua Landau <joshua@landau.ws>
I didn't say it was insane. But I do dislike it. Code should be quick for the majority of people (of the same language) to edit; unicode symbols ruin that barrier.
when applied to the oly way to do something: yes. in this case: not in the slightest.
float('inf') still works, so if your keyboard layout/compose key doesn’t support ∞, you just use the ascii variant.
That would make the code inconsistent.
On 14/07/13 21:18, Joshua Landau wrote:
On 14 July 2013 12:07, Philipp A. <flying-sheep@web.de> wrote:
float('inf') still works, so if your keyboard layout/compose key doesn’t support ∞, you just use the ascii variant.
That would make the code inconsistent.
Who cares if in one function you say float('∞') and in another function you say float('inf') and in a third you say float("inf") [note quotation marks] and in a fourth float("INF")? What possible difference does it make? If you really care, then refactor all of those calls out to a single constant declared in one place only: INF = float(random.choice([ 'inf', "inf", "INFINITY", '∞', '+∞', r"""∞""", '\N{INFINITY}', "\U0000221e", "\u221E", # etc. ])) and now you can satisfy everybody's preferred way of writing ∞, no matter what. And no, I am not serious about calling random.choice. But I am serious about refactoring multiple calls to float(whatever) to a module level constant. -- Steven
On 15 July 2013 00:43, Steven D'Aprano <steve@pearwood.info> wrote:
On 14/07/13 21:18, Joshua Landau wrote:
On 14 July 2013 12:07, Philipp A. <flying-sheep@web.de> wrote:
float('inf') still works, so if your keyboard layout/compose key doesn’t support ∞, you just use the ascii variant.
That would make the code inconsistent.
Who cares if in one function you say float('∞') and in another function you say float('inf') and in a third you say float("inf") [note quotation marks] and in a fourth float("INF")? What possible difference does it make?
No, I was saying using "∞" here and "float('inf')" there is inconsistent. If you really want a pretty global-ish constant, you should just write "Infinity = float('inf')"¹² and forget these troubling unicode urges. I even tend to use "thing is Ellipses" instead of "thing is ..." because it reads better -- "thing == ∞" just goes back to that. Can you really prefer it that much to "thing == Infinity"²? ¹ You might wonder what I'm doing with capitalisation, but Ellipsis is capitalised and its class is lower-case, so I feel this is warranted. ² Or your name of choice
2013/7/15 Joshua Landau <joshua@landau.ws>
I even tend to use "thing is Ellipses" instead of "thing is ..." because it reads better -- "thing == ∞" just goes back to that.
At least “...” is correct, while “Ellips*e*s” isn’t. it’s “Ellips*i*s”. but as said: ∞ can be in data, and other than e.g. π, it unambiguously and always means the same as “infinity”. there is a reason why float accepts “inf(inity)” and “NaN”, but no other prose. float() imho should accept all literals for values it can represent, and ∞ is just a symbol and therefore synonym for “infinity”. if there would be a symbol for NaN, i’d propose to include it as well.
On 15 July 2013 13:17, Philipp A. <flying-sheep@web.de> wrote:
2013/7/15 Joshua Landau <joshua@landau.ws>
I even tend to use "thing is Ellipses" instead of "thing is ..." because it reads better -- "thing == ∞" just goes back to that.
At least “...” is correct, while “Ellipses” isn’t. it’s “Ellipsis”.
;). That's why I use autocomplete.
but as said: ∞ can be in data, and other than e.g. π, it unambiguously and always means the same as “infinity”. there is a reason why float accepts “inf(inity)” and “NaN”, but no other prose. float() imho should accept all literals for values it can represent, and ∞ is just a symbol and therefore synonym for “infinity”. if there would be a symbol for NaN, i’d propose to include it as well.
Joshua Landau writes:
How do you input unicode then?
I don't. He probably doesn't, either. On Mac OS, there's a generic way to input characters you only know by sight: a clickable table. Kinda painful, but then, that works for functions in Excel so 99% of the computer-using world can handle it, I suppose. However, in general I don't input Unicode, I input characters I know. I bet Steven does too. On touchpads, I write them by hand (takes memorizing pseudo-random sequences, though, because Chinese characters are recognized dynamically by the shape of strokes, and order matters, not by the shape of the resulting glyph). ATK, I use phonetic input. For math characters, at least Emacs provides "LaTeX entry". Ie, if you type "\pi" you get the Greek letter, if you type "\int" you get an integral sign character. To get the leminscate, you type "\infty". If you know the Unicode name of the character you can use that for input in Python and Emacs. Emacs is pretty smart about completion: I don't use that feature but it would be easily arranged that completion work on the list of Unicode names, if it doesn't work already. (Of limited utility for Han characters though because the Unicode code point is the significant part of the name for them.)
future they may have to memorize a key sequence like option-p to get π, or option-u o to get ö. (See, I still remember them, 15+ years since I last used a Mac extensively. Well-thought out mnemonic key sequences for the win.)
Not for Han characters or Hangul or Hieroglyphics though. Phonetic input is the way to go for those. Siri actually works pretty good for spoken input, too.
Chris Angelico writes:
That one would be more plausible, in the same way that many of the other Unicode digits are accepted.
The analogy doesn't hold. Unicode *digit* and Unicode *numeric* are separate properties. Digits are intended to form numerals according to a positional rule, so parsing a string of digits in logical order always means the same thing, regardless of the character set (or Unicode block, if you prefer). Numeric characters are characters that have a numeric interpretation. So in Japanese "1x1" can mean 11, 101, 1001, 10001, 100000001, and a few others depending on the numeric character used for x (which is the multiplier for the "1" on its left), or it might be a parse error (conventions for writing checks often use powers of 10000 as separators rather than multipliers, so you're missing three digits on the right side). It's possible the same conventions apply to Chinese. Anyway, in Japanese many numeric characters make no sense in positional notation, and require localized parsing methods. Personally, I think it was a mistake to allow non-ASCII digits to be parsed directly by int() and float(). Not even language nationalists like the French, Russians, and Japanese publish statistics using non-ASCII digits. OTOH, people who need to read numbers out of text or whatever probably should be using localization facilities anyway (there are a few cases of "confusables" among the digits where digits whose glyphs are similar have different values as digits). But that ship has sailed, apparently.
participants (13)
-
Alexander Belopolsky -
Chris Angelico -
Chris “Kwpolska” Warrick -
Gerald Britton -
Joshua Landau -
Laurens Van Houtven -
MRAB -
Nathan Schneider -
Oscar Benjamin -
Philipp A. -
Serhiy Storchaka -
Stephen J. Turnbull -
Steven D'Aprano