On Tue, Aug 27, 2019 at 6:25 PM <stpa...@gmail.com> wrote: > 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 _______________________________________________ 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/ZDKVSRIASJQFORKF7FPARBYFELGUDBM2/ Code of Conduct: http://python.org/psf/codeofconduct/
