On Tue, Aug 27, 2019 at 6:25 PM
You're correct that, devoid of context, `v"smth..."` is not very meaningful. The "v" suffix could mean "version", or "verbose", or "volatile", or "vectorized", or "velociraptor", or whatever. Luckily, the code is almost always exists within a specific context. It solves a particular problem, and works within a particular domain, and makes perfect sense for people working within that domain.
This isn't much different than, say, `np.` suffix, which means "numpy" in the domain of numerical computations, NP-completeness for some mathematicians, and "no problem" for regular users.
Syntactically, the "np." prefix (not suffix fwiw) actually means "look up the np object, then locate an attribute called <whatever comes next>". That's true of every prefix you could ever get, and they're always looked up at run time; the attribute name always follows the exact same syntactic rules no matter what the prefix is. Literals, on the other hand, are part of syntax - a different string type prefix can change the way the entire file gets parsed. Will these "custom prefixes" be able to define anything syntactically? If not, why not just use a function call? And if they can, then you have created an absolute monster, where a v-string in one context can have completely different syntactic influence on what follows it than a v-string in another context. At least with attribute lookups, you can parse a file without knowing what "np" actually means, and even examine things at run-time. ChrisA