Okay, so I talked to Guido about this, and all he was trying to convey is that there is an extremely high bar that must be reached before he will consider changing the base language, which of course is both prudent and expected.
I'd like to continue the discussion because I believe there is some chance that we could reach that bar even though Guido is clearly skeptical. At this point I'd like to suggest that there be two more constraints we consider: 1. whatever form we choose to be used when outputting numbers should the same form we use when inputting numbers (so %r should produce valid python input, as does all the other format codes), 2. and whatever form we choose to be used when outputting numbers should look natural to end users. So ideas like using 2.4*G, 2.4*GHz, or 0s2.4G wouldn't really work because we would not want to output numbers to end users in this form. Even 2.4_GHz, while better, would still look somewhat unnatural to end users. One more thing to consider is that we already have a precedent here. Python already accepts a suffix on real numbers: j signifies an imaginary number. In this case the above constraints are satisfied. For example, 2j is a natural form to show any end user that understands imaginary numbers, and 2j is acceptable input to the language. To be consistent with that, it seems like 2G or 2GHz should be preferred over 2_G or 2_GHz. Of course, this brings up another issue, how to we handle imaginary numbers with scale factors. The possibilities include: 1. you don't get them, you can either specify j or a scale factor, but not both 2. you do get them, but if we allow units, then j should be first 3. you do get them, but we don't allow units and j could be first or second I like choice 2 myself. Also, to be consistent with j, and because I think it is simpler overall, I think 2G should be a real number, not an integer. Similarly, I think 2Gi, if we accept it, should also be a real number, simply for consistency. One last thing, we can accept 273K as input for 273,000, but when we output it we must use k to avoid confusion with Kelvin (and because that is the standard). Also, we can use μ for for inputting or outputting 1e-6, but we must always accept u as valid input. -Ken On Fri, Aug 26, 2016 at 07:42:00AM -0700, Guido van Rossum wrote: > On Fri, Aug 26, 2016 at 5:47 AM, Steven D'Aprano <[email protected]> > wrote: > > > Ken has made what I consider a very reasonable suggestion, to introduce > > SI prefixes to Python syntax for numbers. For example, typing 1K will be > > equivalent to 1000. > > > > However, there are some complexities that have been glossed over. > > [...] > > > > Please curb your enthusiasm. This is not going to happen. > > -- > --Guido van Rossum (python.org/~guido) > _______________________________________________ > Python-ideas mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ _______________________________________________ Python-ideas mailing list [email protected] https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
