On Aug 27, 2019, at 08:52, Steven D'Aprano <st...@pearwood.info> wrote:
> 
>> On Tue, Aug 27, 2019 at 05:24:19AM -0700, Andrew Barnert via Python-ideas 
>> wrote:
>> 
>> There is a possibility in between the two extremes of “useless” and 
>> “complete monster”: the prefix accepts exactly one token, but can 
>> parse that token however it wants.
> 
> How is that different from passing a string argument to a function or 
> class constructor that can parse that token however it wants?
> 
>    x'...'
> 
>    x('...')
> 
> Unless there is some significant difference between the two, what does 
> this proposal give us?

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

The fact that they look the same as the same values in other contexts like a 
C++ program or a GLSL shader is a pretty large added bonus. But I don’t think 
that’s essential to the value here. If you forced me to use prefixes instead of 
suffixes (I don’t think there’s any good reason for that, but who knows how the 
winds of bikeshedding may blow), I’d still prefer f2.3 to f('2.3'), because it 
still looks like a number, as it should.

I know this is doable, because I’ve written an import hook that does it, plus I 
have a decade of experience with another popular language (C++) that has 
essentially the same feature.

What about the performance cost of these values not being constants? A 
decorator that finds np.float32 calls on constants and promoted them to 
constants by hacking the bytecode is pretty trivial to write, or you can load 
the whole array in one go from a bytes constant and put the readable version in 
a comment, or whatever. But anything that’s slow enough to be worth optimizing 
is doing a huge matmul or pushing zillions of values back and forth to the GPU 
or something else that swamps the setup cost, even if the setup cost involves a 
few dozen string parses, so it never matters. At least not for me.

—-

For a completely different example—but one that I’ve also already given earlier 
in this thread, so I won’t belabor it too much:

    path'C:\'

    bs"this\ space won’t have a backslash before it, also \e[22; is an escape 
sequence and of course \a is still a bell because I’m using the rules from 
C/JS/etc."

    bs37"this\ space has a backslash before it without raising a warning or an 
error even in Python 3.15 because I’ve implemented the 3.7 rules”

… and so on.

Some of these _could_ be done with a raw string and a (maybe slightly more 
complicated) function call, but at least the first one is impossible to do that 
way.

Unlike the numeric suffixes, this one I haven’t actually implemented a hacky 
version of, and I don’t know of any other languages that have an identical 
feature, so I can’t promise it’s feasible, but it seems like it should be.
_______________________________________________
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/RKGU2ZQUQDBSIFQOBXQPO4UVSYIF4NEF/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to