Hello! Is it good idea to allow float('∞') to be float('inf') in python? -- С уважением, Шибзухов З.М.
On Fri, Jul 12, 2013 at 2:54 PM, Joshua Landau <joshua@landau.ws> wrote:
On 12 July 2013 13:36, Zaur Shibzukhov <szport@gmail.com> wrote:
Hello!
Is it good idea to allow float('∞') to be float('inf') in python?
Why?
Because it obviously means infinity -- much more so than "inf" does :) cheers lvh
int ('100%') = 1? float('1%') = 0.01? -1
12.07.13 15:36, Zaur Shibzukhov написав(ла):
Is it good idea to allow float('∞') to be float('inf') in python?
float('½') == 0.5? float('3.(142857)') == 22/7? int('Ⅶ') == 7? int('✌') == 2?
AIM - Gesellschaft für angewandte Informatik und Mikroelektronik m.b.H Registered Office: Freiburg District Court of Freiburg HRB 3520 Managing Directors: Hansjörg Frey, Joachim Schuler This E-mail and any attachment(s) to it are for the addressee's use only. It is strictly confidential and may contain legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you are not the intended addressee, then please delete it from your system and notify the sender immediately. You are hereby notified that any use, disclosure, copying or any action taken in reliance on it is strictly prohibited and may be unlawful. - Thank you.
On 12 July 2013 14:31, Andreas Hagmüller <hagmueller@aim-online.com> wrote:
int ('100%') = 1? float('1%') = 0.01? -1
12.07.13 15:36, Zaur Shibzukhov написав(ла):
Is it good idea to allow float('∞') to be float('inf') in python?
float('½') == 0.5? float('3.(142857)') == 22/7? int('Ⅶ') == 7? int('✌') == 2?
No-one has implied that int or float should parse mathematical *expressions*, but just that unicode infinity should be one more way to write "infinity". Consider that: int(1) == int(١) == int(۱) == int(߁) == int(१) == int(১) == int(੧) == int(૧) == int(୧) == int(௧) == int(౧) == int(೧) == int(൧) == int(๑) == int(໑) == int(༡) == int(၁) == int(႑) == int(១) == int(᠑) == int(᥇) == int(᧑) == int(᪁) == int(᪑) == int(᭑) == int(᮱) == int(᱁) == int(᱑) == int(꘡) == int(꣑) == int(꤁) == int(꧑) == int(꩑) == int(꯱) == int(１) == int(𐒡) == int(𑁧) == int(𑃱) == int(𑄷) == int(𑇑) == int(𑛁) == int(𝟏) == int(𝟙) == int(𝟣) == int(𝟭) == int(𝟷) and that float("inf") == float("infinity") == float("INF") == float("INFINITY") == float("Inf") == float("Infinity") int and float are obviously meant to handle abstract inputs (not expressions) and unicode infinity is an extension of this. Your "analogies" are inapt.
12.07.13 17:10, Joshua Landau написав(ла):
int and float are obviously meant to handle abstract inputs (not expressions) and unicode infinity is an extension of this. Your "analogies" are inapt.
Why you think ½ (this is only one symbol!) and 3.(142857) (this is a decimal notation of the 22/7 fraction) are expressions, but ∞ or even -1 are not?
On 12 July 2013 16:26, Serhiy Storchaka <storchaka@gmail.com> wrote:
12.07.13 17:10, Joshua Landau написав(ла):
int and float are obviously meant to handle abstract inputs (not expressions) and unicode infinity is an extension of this. Your "analogies" are inapt.
Why you think ½ (this is only one symbol!) and 3.(142857) (this is a decimal notation of the 22/7 fraction) are expressions, but ∞ or even -1 are not?
For the same reason that 0.5 and [0, 1, 2, 3, 4] are literals but 1/2 and range(5) are not.
12.07.13 18:50, Joshua Landau написав(ла):
On 12 July 2013 16:26, Serhiy Storchaka <storchaka@gmail.com> wrote:
12.07.13 17:10, Joshua Landau написав(ла):
int and float are obviously meant to handle abstract inputs (not expressions) and unicode infinity is an extension of this. Your "analogies" are inapt.
Why you think ½ (this is only one symbol!) and 3.(142857) (this is a decimal notation of the 22/7 fraction) are expressions, but ∞ or even -1 are not?
For the same reason that 0.5 and [0, 1, 2, 3, 4] are literals but 1/2 and range(5) are not.
∞ is not a literal.
On 12 July 2013 18:12, Serhiy Storchaka <storchaka@gmail.com> wrote:
12.07.13 18:50, Joshua Landau написав(ла):
On 12 July 2013 16:26, Serhiy Storchaka <storchaka@gmail.com> wrote:
12.07.13 17:10, Joshua Landau написав(ла):
int and float are obviously meant to handle abstract inputs (not expressions) and unicode infinity is an extension of this. Your "analogies" are inapt.
Why you think ½ (this is only one symbol!) and 3.(142857) (this is a decimal notation of the 22/7 fraction) are expressions, but ∞ or even -1 are not?
For the same reason that 0.5 and [0, 1, 2, 3, 4] are literals but 1/2 and range(5) are not.
∞ is not a literal.
So? float("[1, 2, 3, 4]") isn't valid -- I never claimed there was 1:1 mapping between literals and things that float should except. I said that float shouldn't parse expressions.
12.07.13 20:18, Joshua Landau написав(ла):
On 12 July 2013 18:12, Serhiy Storchaka <storchaka@gmail.com> wrote:
12.07.13 18:50, Joshua Landau написав(ла):
On 12 July 2013 16:26, Serhiy Storchaka <storchaka@gmail.com> wrote:
12.07.13 17:10, Joshua Landau написав(ла):
int and float are obviously meant to handle abstract inputs (not expressions) and unicode infinity is an extension of this. Your "analogies" are inapt.
Why you think ½ (this is only one symbol!) and 3.(142857) (this is a decimal notation of the 22/7 fraction) are expressions, but ∞ or even -1 are not?
For the same reason that 0.5 and [0, 1, 2, 3, 4] are literals but 1/2 and range(5) are not.
∞ is not a literal.
So? float("[1, 2, 3, 4]") isn't valid -- I never claimed there was 1:1 mapping between literals and things that float should except. I said that float shouldn't parse expressions.
I agree. But how is it related to ½ and 3.(142857)?
On 12 July 2013 18:58, Serhiy Storchaka <storchaka@gmail.com> wrote:
12.07.13 20:18, Joshua Landau написав(ла):
On 12 July 2013 18:12, Serhiy Storchaka <storchaka@gmail.com> wrote:
12.07.13 18:50, Joshua Landau написав(ла):
On 12 July 2013 16:26, Serhiy Storchaka <storchaka@gmail.com> wrote:
12.07.13 17:10, Joshua Landau написав(ла):
int and float are obviously meant to handle abstract inputs (not expressions) and unicode infinity is an extension of this. Your "analogies" are inapt.
Why you think ½ (this is only one symbol!) and 3.(142857) (this is a decimal notation of the 22/7 fraction) are expressions, but ∞ or even -1 are not?
For the same reason that 0.5 and [0, 1, 2, 3, 4] are literals but 1/2 and range(5) are not.
∞ is not a literal.
So? float("[1, 2, 3, 4]") isn't valid -- I never claimed there was 1:1 mapping between literals and things that float should except. I said that float shouldn't parse expressions.
I agree. But how is it related to ½ and 3.(142857)?
½ === 1/2; thus is an expression 3.(142857) is more ambiguous, because there's not actually any mathematical operator in place. But it is too much parsing for no benefit, AFAICT; you would complicate something simple to solve almost no use-cases, and then when they are used it's harder for people to work out what is meant. The informal definition for "expression" with regards to int and float I'm using is basically the measure of how much more parsing code would need to be implemented.
On 07/12/2013 02:27 PM, Joshua Landau wrote:
On 12 July 2013 18:58, Serhiy Storchaka <storchaka@gmail.com <mailto:storchaka@gmail.com>> wrote:
I agree. But how is it related to ½ and 3.(142857)?
½ === 1/2; thus is an expression
That's ridiculous. ½ is no more an expression than "0.5" is. -- ~Ethan~
On 12 July 2013 22:41, Ethan Furman <ethan@stoneleaf.us> wrote:
On 07/12/2013 02:27 PM, Joshua Landau wrote:
On 12 July 2013 18:58, Serhiy Storchaka <storchaka@gmail.com <mailto:
storchaka@gmail.com>> wrote:
I agree. But how is it related to ½ and 3.(142857)?
½ === 1/2; thus is an expression
That's ridiculous. ½ is no more an expression than "0.5" is.
When you are talking in context of float(...), I have to disagree.
13.07.13 00:27, Joshua Landau написав(ла):
On 12 July 2013 18:58, Serhiy Storchaka <storchaka@gmail.com <mailto:storchaka@gmail.com>> wrote: I agree. But how is it related to ½ and 3.(142857)? ½ === 1/2; thus is an expression
0.5 === 5/10. Isn't it an expression?
3.(142857) is more ambiguous, because there's not actually any mathematical operator in place. But it is too much parsing for no benefit, AFAICT; you would complicate something simple to solve almost no use-cases, and then when they are used it's harder for people to work out what is meant.
AFAIK children teach 3.(142857) before ∞. I'm sure people use fractions and recurring decimals more often than infinity.
The informal definition for "expression" with regards to int and float I'm using is basically the measure of how much more parsing code would need to be implemented.
½ requires no more parsing code then ∞.
On 12 juil. 2013, at 21:46, Serhiy Storchaka <storchaka@gmail.com> wrote:
13.07.13 00:27, Joshua Landau написав(ла):
On 12 July 2013 18:58, Serhiy Storchaka <storchaka@gmail.com <mailto:storchaka@gmail.com>> wrote: I agree. But how is it related to ½ and 3.(142857)? ½ === 1/2; thus is an expression
0.5 === 5/10. Isn't it an expression?
In the context of making a difference between literal values and other expressions in python, yes 5/10 is an expression, no 0.5 is not one.
13.07.13 00:52, Masklinn написав(ла):
On 12 juil. 2013, at 21:46, Serhiy Storchaka <storchaka@gmail.com> wrote:
13.07.13 00:27, Joshua Landau написав(ла):
On 12 July 2013 18:58, Serhiy Storchaka <storchaka@gmail.com <mailto:storchaka@gmail.com>> wrote: I agree. But how is it related to ½ and 3.(142857)? ½ === 1/2; thus is an expression
0.5 === 5/10. Isn't it an expression?
In the context of making a difference between literal values and other expressions in python, yes 5/10 is an expression, no 0.5 is not one.
In this context both ∞ and ½ are not literal values and not expressions.
On 12 July 2013 22:46, Serhiy Storchaka <storchaka@gmail.com> wrote:
13.07.13 00:27, Joshua Landau написав(ла):
On 12 July 2013 18:58, Serhiy Storchaka <storchaka@gmail.com <mailto:storchaka@gmail.com>> wrote: I agree. But how is it related to ½ and 3.(142857)? ½ === 1/2; thus is an expression
0.5 === 5/10. Isn't it an expression?
No. That's like saying "1 === 2/2". There is a much more obvious equivalence between two ways of writing "1/2" than between two ways of displaying the result of "1/2".
3.(142857) is more ambiguous, because there's not actually any
mathematical operator in place. But it is too much parsing for no benefit, AFAICT; you would complicate something simple to solve almost no use-cases, and then when they are used it's harder for people to work out what is meant.
AFAIK children teach 3.(142857) before ∞. I'm sure people use fractions and recurring decimals more often than infinity.
In my experience (I'll take a good wager I'm younger than you) people learn first about infinity, then are taught recurrence using the floating-dot syntax. The bracket form for recurrence was not taught once during high-school for me, and although "infinity" was hardly covered either it's not niche knowledge. Plus, why on earth would you use recurrence for floats? Give me a use case. There's a good reason for float infinity. Note that I'm British.
The informal definition for "expression" with regards
to int and float I'm using is basically the measure of how much more parsing code would need to be implemented.
½ requires no more parsing code then ∞.
Au contraire, if you accept ½ you are bound by law to accept all of the other fractions -- that's much more code than just allowing ∞.
On Fri, Jul 12, 2013 at 5:55 PM, Joshua Landau <joshua@landau.ws> wrote:
Au contraire, if you accept ½ you are bound by law to accept all of the other fractions -- that's much more code than just allowing ∞.
Let's see: def float(x): if x == '\u221e': return builtins.float('inf') return builtins.float(x) def float(x): if len(x) == 1: return unicodedata.numeric(x) return builtins.float(x) Where is "much more code "? And if you accept '∞', aren't you "bound by law to accept '+∞' and '-∞' as well?
On 12 July 2013 23:20, Alexander Belopolsky <alexander.belopolsky@gmail.com>wrote:
On Fri, Jul 12, 2013 at 5:55 PM, Joshua Landau <joshua@landau.ws> wrote:
Au contraire, if you accept ½ you are bound by law to accept all of the other fractions -- that's much more code than just allowing ∞.
Let's see:
def float(x): if x == '\u221e': return builtins.float('inf') return builtins.float(x)
def float(x): if len(x) == 1: return unicodedata.numeric(x) return builtins.float(x)
Where is "much more code "?
Sorry, I didn't equate you on this thread with you on the other, where you said you wanted to special-case characters, I thought you were on about solely fractions. I don't like that idea, because then you could have stuff like ➉, ㊹, Ⅶ and so on, leading people to assume that "𐌢Ⅴ" or somesuch is valid. Additionally, accepting "ⅿ" is confusing, "⑽" is ridiculous and ↂ is just silly. And why would int("𐌣") equal 50? Additionally, your change would affect both int and float, and require an extra check to see whether the return is an integer for int. I see no advantage in a blatant explosion of acceptable characters, and several disadvantages from having characters special-cased. And if you accept '∞', aren't you "bound by law to accept '+∞' and '-∞' as
well?
Yes. On the basis that we except "-inf", there's really no question. The "-" is undoubtedly dealt with semi-separately, though, so it shouldn't change the amount we have to write.
13.07.13 00:55, Joshua Landau написав(ла):
On 12 July 2013 22:46, Serhiy Storchaka <storchaka@gmail.com <mailto:storchaka@gmail.com>> wrote:
13.07.13 00:27, Joshua Landau написав(ла):
On 12 July 2013 18:58, Serhiy Storchaka <storchaka@gmail.com <mailto:storchaka@gmail.com> <mailto:storchaka@gmail.com <mailto:storchaka@gmail.com>>> wrote: I agree. But how is it related to ½ and 3.(142857)? ½ === 1/2; thus is an expression
0.5 === 5/10. Isn't it an expression?
No. That's like saying "1 === 2/2". There is a much more obvious equivalence between two ways of writing "1/2" than between two ways of displaying the result of "1/2".
0.5 is 5/10 by definition. The result of 1/2 is a fraction ½.
3.(142857) is more ambiguous, because there's not actually any mathematical operator in place. But it is too much parsing for no benefit, AFAICT; you would complicate something simple to solve almost no use-cases, and then when they are used it's harder for people to work out what is meant.
AFAIK children teach 3.(142857) before ∞. I'm sure people use fractions and recurring decimals more often than infinity.
In my experience (I'll take a good wager I'm younger than you) people learn first about infinity, then are taught recurrence using the floating-dot syntax. The bracket form for recurrence was not taught once during high-school for me, and although "infinity" was hardly covered either it's not niche knowledge.
Well, maybe it's a cultural difference. I learned recurring decimals in primary school (if memory serves me).
Plus, why on earth would you use recurrence for floats? Give me a use case. There's a good reason for float infinity.
This is only a way to spell a general fraction in decimal. On other hand, ∞ is even not a real number.
Note that I'm British.
The informal definition for "expression" with regards to int and float I'm using is basically the measure of how much more parsing code would need to be implemented.
½ requires no more parsing code then ∞.
Au contraire, if you accept ½ you are bound by law to accept all of the other fractions -- that's much more code than just allowing ∞.
If you accept ∞ you are bound by law to accept ½ and all of the other fractions — and that's much more code than just allowing ∞.
On 14 July 2013 09:40, Serhiy Storchaka <storchaka@gmail.com> wrote:
13.07.13 00:55, Joshua Landau wrote:
On 12 July 2013 22:46, Serhiy Storchaka wrote:
13.07.13 00:27, Joshua Landau wrote:
½ === 1/2; thus is an expression
0.5 === 5/10. Isn't it an expression?
No. That's like saying "1 === 2/2". There is a much more obvious equivalence between two ways of writing "1/2" than between two ways of displaying the result of "1/2".
0.5 is 5/10 by definition. The result of 1/2 is a fraction ½.
I don't understand. What are you trying to say?
Plus, why on earth would you use recurrence for floats? Give me a use case. There's a good reason for float infinity.
This is only a way to spell a general fraction in decimal. On other hand, ∞ is even not a real number.
That's not a use-case.
The informal definition for "expression" with regards to int and float I'm using is basically the measure of how much more parsing code would need to be implemented.
½ requires no more parsing code then ∞.
Au contraire, if you accept ½ you are bound by law to accept all of the other fractions -- that's much more code than just allowing ∞.
If you accept ∞ you are bound by law to accept ½ and all of the other fractions — and that's much more code than just allowing ∞.
I was afraid that people would go and take this too literally. But either way, if you accept ½ and reject ¾, you have made a really bad design decision. If you accept ∞ and reject ½, the atrocity of that decision is much less. I would say it's a good choice, you may say it is bad. But if you say those are equivalently bad decisions you're simply wrong and there's not much more I can say.
14.07.13 11:56, Joshua Landau написав(ла):
On 14 July 2013 09:40, Serhiy Storchaka <storchaka@gmail.com> wrote:
13.07.13 00:55, Joshua Landau wrote:
On 12 July 2013 22:46, Serhiy Storchaka wrote:
13.07.13 00:27, Joshua Landau wrote:
½ === 1/2; thus is an expression
0.5 === 5/10. Isn't it an expression?
No. That's like saying "1 === 2/2". There is a much more obvious equivalence between two ways of writing "1/2" than between two ways of displaying the result of "1/2".
0.5 is 5/10 by definition. The result of 1/2 is a fraction ½.
I don't understand. What are you trying to say?
0.5 is a spelling of 5⁄10 which is a result of expression 5/10. ½ is a spelling of 1⁄2 which is a result of expression 1/2. I don't understand why you think 1⁄2 is expression while 5⁄10 is not.
Plus, why on earth would you use recurrence for floats? Give me a use case. There's a good reason for float infinity.
This is only a way to spell a general fraction in decimal. On other hand, ∞ is even not a real number.
That's not a use-case.
∞ is not a use-case.
If you accept ∞ you are bound by law to accept ½ and all of the other fractions — and that's much more code than just allowing ∞.
I was afraid that people would go and take this too literally. But either way, if you accept ½ and reject ¾, you have made a really bad design decision. If you accept ∞ and reject ½, the atrocity of that decision is much less. I would say it's a good choice, you may say it is bad. But if you say those are equivalently bad decisions you're simply wrong and there's not much more I can say.
The difference between this two bad choices is far less than the difference between good and bad. Why should we choose between two bad designs?
On 7/14/2013 7:08 AM, Philipp A. wrote:
2013/7/14 Serhiy Storchaka <storchaka@gmail.com <mailto:storchaka@gmail.com>>
∞ is not a use-case.
it is. OP has it in his/her data.
Looking back through the many emails about this so far, I didn't see where the OP explained why he wanted this to work. Zaur Shibzukhov never said he had it in his data, he said, "Is it good idea to allow float('∞') to be float('inf') in python?" and, "Because infinity is special case of numbers. Unicode standard have regular infinity symbol and it's natural to represent inifinity as ∞." As near as I can tell, we don't have an actual use case yet. --Ned.
_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
воскресенье, 14 июля 2013 г., 16:55:46 UTC+4 пользователь Ned Batchelder написал:
On 7/14/2013 7:08 AM, Philipp A. wrote: Looking back through the many emails about this so far, I didn't see where the OP explained why he wanted this to work. Zaur Shibzukhov never said he had it in his data, he said, "Is it good idea to allow float('∞') to be float('inf') in python?" and, "Because infinity is special case of numbers. Unicode standard have regular infinity symbol and it's natural to represent inifinity as ∞."
As near as I can tell, we don't have an actual use case yet.
I think that actual use cases are rather belongs to numeric area. For example, one could use infinity symbol when output infinity numerical results of calculations to the text file and another one input them. Usually float numbers in python world are converted from string using float(...). So any code that use float to convert from string could benefit.This is not a real use case though, but rather some scenario...
_______________________________________________ Python-ideas mailing listPython...@python.org <javascript:>http://mail.python.org/mailman/listinfo/python-ideas
14.07.13 16:53, Zaur Shibzukhov написав(ла):
I think that actual use cases are rather belongs to numeric area. For example, one could use infinity symbol when output infinity numerical results of calculations to the text file and another one input them. Usually float numbers in python world are converted from string using float(...). So any code that use float to convert from string could benefit.This is not a real use case though, but rather some scenario...
If one use custom code to output an infinity float as '∞' (or '+∞', or '-', or '\\infty', or 'бесконечность', or '>9000'), then another one should use custom code to input them.
воскресенье, 14 июля 2013 г., 18:49:13 UTC+4 пользователь Serhiy Storchaka написал:
14.07.13 16:53, Zaur Shibzukhov написав(ла):
I think that actual use cases are rather belongs to numeric area. For example, one could use infinity symbol when output infinity numerical results of calculations to the text file and another one input them. Usually float numbers in python world are converted from string using float(...). So any code that use float to convert from string could benefit.This is not a real use case though, but rather some scenario...
If one use custom code to output an infinity float as '∞' (or '+∞', or '-', or '\\infty', or 'бесконечность', or '>9000'), then another one should use custom code to input them.
Yes of caurse. But I mean only the case when the output is float ('inf') or float ('-inf') - the actual infinity values.
Because infinity is special case of numbers. Unicode standard have regular infinity symbol and it's natural to represent inifinity as ∞. пятница, 12 июля 2013 г., 17:12:09 UTC+4 пользователь Serhiy Storchaka написал:
12.07.13 15:36, Zaur Shibzukhov написав(ла):
Is it good idea to allow float('∞') to be float('inf') in python?
float('½') == 0.5? float('3.(142857)') == 22/7? int('Ⅶ') == 7? int('✌') == 2?
_______________________________________________ Python-ideas mailing list Python...@python.org <javascript:> http://mail.python.org/mailman/listinfo/python-ideas
On 12 July 2013 13:36, Zaur Shibzukhov <szport@gmail.com> wrote:
Is it good idea to allow float('∞') to be float('inf') in python?
I don't think so as my preference is for Python to stick to IEEE 754 as closely as possible. Section 5.12.1 of IEEE 754-2008 says ''' Conversion of an infinity in a supported format to an external character sequence shall produce a language defined one of “inf” or “infinity” or a sequence that is equivalent except for case (e.g., “Infinity” or “INF”), with a preceding minus sign if the input is negative. Whether the conversion produces a preceding plus sign if the input is positive is language-defined. Conversion of external character sequences “inf” and “infinity” (regardless of case) with an optional preceding sign, to a supported floating-point format shall produce an infinity (with the same sign as the input). ''' This does not seem to prohibit accepting other strings for infinity but it does explicitly define a set of textual representations for infinity. I don't think Python's float <-> str conversions should accept (or emit) any other strings for infinity. Since I was looking at the standard I was also interested to see what is says about non-ascii decimal digits (as accepted by Python 3). Immediately above this in section 5.12 it says ''' Issues of character codes (ASCII, Unicode, etc.) are not defined by this standard. ''' My interpretation of that is that Python's current behaviour is conforming but that it would also be conforming if it didn't accept non-ascii decimal digits. Oscar
понедельник, 15 июля 2013 г., 14:26:43 UTC+4 пользователь Oscar Benjamin написал:
On 12 July 2013 13:36, Zaur Shibzukhov <szp...@gmail.com <javascript:>> wrote:
Is it good idea to allow float('∞') to be float('inf') in python?
I don't think so as my preference is for Python to stick to IEEE 754 as closely as possible.
Section 5.12.1 of IEEE 754-2008 says ''' Conversion of an infinity in a supported format to an external character sequence shall produce a language defined one of “inf” or “infinity” or a sequence that is equivalent except for case (e.g., “Infinity” or “INF”), with a preceding minus sign if the input is negative. Whether the conversion produces a preceding plus sign if the input is positive is language-defined.
Conversion of external character sequences “inf” and “infinity” (regardless of case) with an optional preceding sign, to a supported floating-point format shall produce an infinity (with the same sign as the input). '''
This does not seem to prohibit accepting other strings for infinity but it does explicitly define a set of textual representations for infinity. I don't think Python's float <-> str conversions should accept (or emit) any other strings for infinity.
Since I was looking at the standard I was also interested to see what is says about non-ascii decimal digits (as accepted by Python 3). Immediately above this in section 5.12 it says ''' Issues of character codes (ASCII, Unicode, etc.) are not defined by this standard. '''
My interpretation of that is that Python's current behaviour is conforming but that it would also be conforming if it didn't accept non-ascii decimal digits.
With this we could agree if python completely drop support for non-ascii input.
As for IEEE-754-2008, it not fully defined presentation of infinity because we now could have several strings that could identified as "infinity" (inf, Inf, INF, infinity, Infinity, INFINITY). So if IEEE committee will decide to designate one single textual view of infinity that could be ok.
participants (11)
-
Alexander Belopolsky -
Andreas Hagmüller -
Ethan Furman -
Joshua Landau -
Laurens Van Houtven -
Masklinn -
Ned Batchelder -
Oscar Benjamin -
Philipp A. -
Serhiy Storchaka -
Zaur Shibzukhov