On Mon, Aug 29, 2016 at 1:29 PM, Ken Kundert <python-id...@shalmirane.com> wrote: > Because by focusing on the implementation details, we miss the big picture. > We > have already done that, and we ended up going down countless ratholes.
They're important ratholes though. Without digging into those questions, all you have is an emotive argument of "but we NEEEEEEED to support SI prefixes as integer suffixes!". >> > Don't Python's users in the scientific and engineering communities deserve >> > the same treatment? These are, after all, core communities for Python. >> >> Yes. That's why we have things like the @ matrix multiplication >> operator (because the numeric computational community asked for it), >> and %-formatting for bytes strings (because the networking, mainly >> HTTP serving, community asked for it). Python *does* have a history of >> supporting things that are needed by specific sub-communities of >> Python coders. But there first needs to be a demonstrable need. How >> much are people currently struggling due to the need to transform >> "gigapascal" into "e+9"? Can you show convoluted real-world code that >> would be made dramatically cleaner by language support? > > Can you show code that would have been convoluted if Python had used a library > rather than built-in support for hexadecimal numbers? See my other email, with examples of bit flags. It's not too bad if you only ever work with a single bit at a time, but bit masks combine beautifully in binary, fairly cleanly in hex, and really badly in decimal. Hex is a great trade-off between clean bit handling and compact representation. (Octal is roughly the same trade-off, and in days of yore was the one obvious choice, but hex has overtaken it.) > So, in summary, you are suggesting that we tell the scientific and engineering > communities that we refuse to provide native support for their preferred way > of > writing numbers because: > 1. our way is better, Is more general, yes. If all you have is SI prefixes, you're badly scuppered. If all you have is exponential notation, you can do everything. > 2. their way is bad because some uneducated person might see the numbers and > not > understand them, Is, again, less general. It's a way of writing numbers that makes sense only in a VERY narrow area. > 3. we already have way of representing numbers that we came up with in the > '60s > and we simply cannot do another, False. > 4. well we could do it, but we have decided that if you would only adapt to > this > new way of doing things that we just came up with, then we would not have > to > do any work, and that is better for us. Oh and this this new way of writing > numbers, it only works in the program itself. Your out of luck when it > comes > to IO. I'm not sure what you mean by "IO" here, but if you're writing a program that accepts text strings and prints text strings, it's free to do whatever it wants. > These do not seem like good reasons for not doing this. Not worded the way you have them, no, because you've aimed for an extremely emotional argument instead of answering concrete questions like "where's the code that this would improve". Find some real-world code that would truly benefit from this. Show us how it's better. Something that I don't think you've acknowledged is that the SI scaling markers are *prefixes to units*, not *suffixes to numbers*. That is to say, you don't have "132G" of a thing called a "pascal", you have "132" of a thing called a "gigapascal". Outside of a unit-based system, SI prefixes don't really have meaning. I don't remember ever, in a scientific context, seeing a coefficient of friction listed as "30 milli-something"; it's always "0.03". So if unitless values are simply numbers, and Python's ints and floats are unitless, they won't see much benefit from prefixes-on-nothing. 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/
