<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2017-01-12 13:13 GMT+01:00 Stephan Houben <span dir="ltr"><<a href="mailto:stephanh42@gmail.com" target="_blank">stephanh42@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Something like:<div><br></div><div>from __syntax__ import decimal_literal</div><div><br></div><div>which would feed the rest of the file through the "decimal_literal" transpiler.</div><div>(and not influence anything in other files). </div><div><br></div><div>Not sure if you would want to support multiple transpilers per file.</div><div><br></div><div>Note that Racket has something similar with their initial "#lang ..." directive.</div><div>That only allows a single "language". Possibly wisely so.</div><div><br></div><div>Stephan</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-01-12 12:59 GMT+01:00 אלעזר <span dir="ltr"><<a href="mailto:elazarg@gmail.com" target="_blank">elazarg@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><p dir="ltr">I think such proposals are special cases of a general theme: a compiler pragma, similar to "from __future__", to make Python support domain-specific syntax in the current file. Whether it's decimal literals or matrix/vector literals etc. </p>
<p dir="ltr">I think it will be nice to make some tool, external to Python, that will allow defining such "sibling languages" (transpiled into Python) easily and uniformly.</p>
<p dir="ltr">Elazar </p>
<br><div class="gmail_quote"><div dir="ltr">בתאריך יום ה׳, 12 בינו' 2017, 13:21, מאת Paul Moore <<a href="mailto:p.f.moore@gmail.com" target="_blank">p.f.moore@gmail.com</a>>:<br></div><div><div class="gmail-m_-3647297922728463638h5"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 12 January 2017 at 10:28, Victor Stinner <<a href="mailto:victor.stinner@gmail.com" class="gmail-m_-3647297922728463638m_-9153359223763791002gmail_msg" target="_blank">victor.stinner@gmail.com</a>> wrote:<br class="gmail-m_-3647297922728463638m_-9153359223763791002gmail_msg">
> George requested this feature on the bug tracker:<br class="gmail-m_-3647297922728463638m_-9153359223763791002gmail_msg">
> <a href="http://bugs.python.org/issue29223" rel="noreferrer" class="gmail-m_-3647297922728463638m_-9153359223763791002gmail_msg" target="_blank">http://bugs.python.org/issue29<wbr>223</a><br class="gmail-m_-3647297922728463638m_-9153359223763791002gmail_msg">
><br class="gmail-m_-3647297922728463638m_-9153359223763791002gmail_msg">
> George was asked to start a discusson on this list. I posted the<br class="gmail-m_-3647297922728463638m_-9153359223763791002gmail_msg">
> following comment before closing the issue:<br class="gmail-m_-3647297922728463638m_-9153359223763791002gmail_msg">
><br class="gmail-m_-3647297922728463638m_-9153359223763791002gmail_msg">
> You are not the first one to propose the idea.<br class="gmail-m_-3647297922728463638m_-9153359223763791002gmail_msg">
<br class="gmail-m_-3647297922728463638m_-9153359223763791002gmail_msg">
OK, but without additional detail (for example, how would the proposed<br class="gmail-m_-3647297922728463638m_-9153359223763791002gmail_msg">
flag work, if the main module imports module A, then would float<br class="gmail-m_-3647297922728463638m_-9153359223763791002gmail_msg">
literals in A be decimal or binary? Both could be what the user wants)<br class="gmail-m_-3647297922728463638m_-9153359223763791002gmail_msg">
it's hard to comment. And as you say, most of this has been discussed<br class="gmail-m_-3647297922728463638m_-9153359223763791002gmail_msg">
before, so I'd like to see references back to the previous discussions<br class="gmail-m_-3647297922728463638m_-9153359223763791002gmail_msg">
in any proposal, with explanations of how the new proposal addresses<br class="gmail-m_-3647297922728463638m_-9153359223763791002gmail_msg">
the objections raised previously.<br class="gmail-m_-3647297922728463638m_-9153359223763791002gmail_msg">
<br class="gmail-m_-3647297922728463638m_-9153359223763791002gmail_msg">
Paul</blockquote></div></div></div></blockquote></div></div></blockquote><div> </div><div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Most of the time one of my students talks to me about decimal vs<br>
binary, they're thinking that a decimal literal (or converting the<br>
default non-integer literal to be decimal) is a panacea to the "0.1 +<br>
0.2 != 0.3" problem. Perhaps the real solution is a written-up<br>
explanation of why binary floating point is actually a good thing, and<br>
not just a backward-compatibility requirement?<br>
<br>
ChrisA</blockquote><div><br><br></div><div><br></div><div>from __future__ import use_decimal_instead_of_float<br></div><div>or any other import would be very good. <br></div><div>The most important thing in my point of view is that I do not want to convert every variable every time to decimal.<br></div><div>Accuracy is important for me (yes, 0.1 + 0.2 should equal to 0.3 , no more, no less ;-) )<br><br></div><div>And if it is mentioned, I would like to ask why binary floating point is "better". It is faster, I agree, but why "better"?<br><br></div><div>Actually I create test automation (I am a senior QA eng), the fastest test case runs for about 1-2 minutes. I do not know the exact time difference between binary and decimal arithmetic, but I do not care with this. My test would run some microseconds faster. It does not matter at a minute range.<br><br></div><div>In the tests I calculate with numbers with 4 decimal digits, and I need exact match. ;-)<br></div><div><br></div><div>Actually I have a new colleague, they did image analysis, and the calculated much calculations, and they used a library (not python) that is accurate as well. Becasue accuracy was more important for them as well.<br><br></div><div>BR<br></div><div>George<br></div></div></div></div></div>