On 30 August 2016 at 04:19, Ken Kundert <python-id...@shalmirane.com> wrote: > Do you think there is no value to be able to naturally read and write numbers > with SI scale factors from Python? Or is your issue with something about my > proposal?
Ken, Answering these questions from my perspective (and thanks for taking note of the comments and toning down your delivery, by the way) I have an issue with the way your proposal is vague about the relationship between SI scales and units - it's been mentioned a couple of times, but never adequately addressed, that scales are tightly linked to units (we routinely talk about kilometers and milligrams, but almost never about kilos or millis). There have been some strong (and justified, IMO) objections to adding units without giving them proper semantic meaning, and your response to that seems to be to talk for a while about scale factors in isolation, but then go straight back to examples using scaled units. It's hard to understand exactly what you're proposing when your examples don't match your suggestions. If we assume you *are* simply talking about pure scales (k=1000, M=1000000 etc), then you haven't addressed the many suggestions of alternatives, with anything more substantive than "well, I (and colleagues I know) prefer scale factors", plus some examples with scaled *units* again. Your comparisons tend to show your preferred approach in the best light, while using the least attractive alternative options. And there's almost no proper discussions of pros and cons. In short, you offer almost nothing in the way of objective arguments for your proposals. You mention "reading and writing numbers with scale factors from Python". It's easy enough to do external IO with scale factors, you just read strings and parse them as you wish. A language syntax only affects internal constants - and it's not clear to me that the benefit is significant even then, as I'd expect (as a matter of good style) that any constant needing this type of syntax should be named anyway. Again, this isn't something you address. You've offered no examples of real-world code in existing public projects that would be improved by your proposal. While that's not always necessary to a successful proposal, it certainly makes it more compelling, and helps to confirm that a proposal isn't limited to "niche" areas. So to summarise, I don't think you've made objective arguments for your proposal (your *subjective* enthusiasm for the proposal has never been in doubt), or addressed many of the comments that have already been made. To be honest, I don't think there's much chance of your proposal being accepted at this point in time. As Steven noted, Python tends not to be a leader in matters like this, and so the lack of mainstream prior art is probably sufficient to kill this proposal. But for your own benefit (and the benefit of any future proposals you may make in this or other areas - please don't feel put off by the fact that this specific proposal has met with a lot of resistance) you might want to review the thread and consider what a PEP might look like for this discussion, and how you would have incorporated and responded to the objections raised here - https://www.python.org/dev/peps/pep-0001/#what-belongs-in-a-successful-pep is a good summary of the sort of things you should be looking at. There's no need to actually complete a PEP or post it, the proposal here hasn't reached a stage where a PEP is useful, but thinking about the PEP structure might help you understand the context a bit better. I hope this helps, Paul _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
