On Wed, Aug 28, 2019 at 3:10 AM Andrew Barnert via Python-ideas
<python-ideas@python.org> wrote:
> Before I get into this, let me ask you a question. What does the j suffix
> give us? You can write complex numbers without it just fine:
>
> c = complex
> c(1, 2)
>
> And you can even write a j function trivially:
>
> def j(x): return complex(0, x)
> 1 + j(2)
>
> But would anyone ever write that when they can write it like this:
>
> 1 + 2j
>
> I don’t think so. What does the j suffix give us? The two extra keystrokes
> are trivial. The visual noise of the parens is a bigger deal. The real issue
> is that this matches the way we conceptually think of complex numbers, and
> the way we write them in other contexts. (Well, the way electrical engineers
> write them; most of the rest of us use i rather than j… but still, having to
> use j instead of i is less of an impediment to reading 1+2j than having to
> use function syntax like 1+i(2).
>
> And the exact same thing is true in 3D or CUDA code that uses a lot of
> float32 values. Or code that uses a lot of Decimal values. In those cases, I
> actually have to go through a string for implementation reasons (because
> otherwise Python would force me to go through a float64 and distort the
> values), but conceptually; there are no strings involved when I write this:
>
> array([f('0.2'), f('0.3'), f('0.1')])
>
> … and it would be a lot more readable if I could write it the same way I do
> in other programming languages:
>
> array([0.2f, 0.3f, 0.1f])
>
> Again, it’s not about saving 4 keystrokes per number, and the visual noise of
> the parens is an issue but not the main one (and quotes are barely any noise
> by comparison); it’s the fact that these numeric values look like numeric
> values instead of looking like strings
>
If your conclusion here were "and that's why Python needs a proper
syntax for Decimal literals", then I would be inclined to agree with
you - a Decimal literal would be lossless (as it can entirely encode
whatever was in the source file), and you could then create the
float32 values from those.
But you haven't made the case for generic string prefixes or any sort
of "arbitrary literal" that would let you import something that
registers something to make your float32 literals.
ChrisA
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/57CA2ZAIFXUZMF2ISNBS4UTESPX2ZA4G/
Code of Conduct: http://python.org/psf/codeofconduct/
