On Wed, Aug 28, 2019 at 10:52 AM Andrew Barnert <abarn...@yahoo.com> wrote: > > On Aug 27, 2019, at 14:41, Chris Angelico <ros...@gmail.com> wrote: > > All the examples about Windows paths fall into one of two problematic boxes: > > > > 1) Proposals that allow an arbitrary prefix to redefine the entire > > parser - basically impossible for anything sane > > > > 2) Proposals that do not allow the prefix to redefine the parser, and > > are utterly useless, because the rest of the string still has to be > > valid. > > 3) Proposals that do not allow the prefix to redefine the parser for the > entire program, but do allow it to manually parse anything the tokenizer can > recognize as a single (literal) token. > > As I said, I haven’t tried to implement this example as I have with the other > examples, so I can’t promise that it’s doable (with the current tokenizer, or > with a reasonable change to it). But if it is doable, it’s neither insane nor > useless. (And evenif it’s not doable, that’s just two examples that affixes > can’t solve—Windows paths and general “super-raw strings”. They still solve > all of the other examples.) >
So what is the definition of "a single literal token" when you're creating a path-string? You want this to be valid: x = path"C:\" For this to work, the path prefix has to redefine the way the parser finds the end of the token, does it not? Otherwise, you still have the same problems you already do - backslashes have to be escaped. That's why I say that, without being able to redefine the parser, this is completely useless, as a "path string" might as well just be a "string". Which way is it? > > That line of argument is valid for anything that is specifically > > defined by the language. > > Yes, and? “Literal token” is specifically defined by the language. “Literal > token with attached tag” will also be specifically defined by the language. > The only thing open to customization is what that token gets compiled to. > I don't understand. Are you saying that the prefix is not going to be able to change how backslashes are handled, or that it is? If you keep the tokenizer exactly the same and just add a token in front of it, then things like path"C:\" will be considered to be incomplete and will continue to consume source code until the next quote (or throw SyntaxError for EOL inside string literal). Or is your idea of "literal token" something other than that? If a "literal token" is simply a string literal, then how is this actually helping anything? What do you achieve? > Look at the plethora of suffixes C has for number and character literals. > Look at how many things people still can’t do with them that they want to. I don't know how many there are. The only ones I can think of are "f" for single-precision float, and the long and unsigned suffixes on integers. Python doesn't have these because very few programs need to care about whether a float is single-precision or double-precision, or how large an int is. > Look at the way user literals work in C++. While technically you can argue > that they are “syntax customization”, in practice the customization is highly > constrained. Is it _impossible_ to use that feature to write code that can’t > be parsed by a human reader? I don’t know if I could prove that it’s > impossible. However, I do know that it’s not easy. And that none of the > examples, or real-life uses, that I’ve seen have done so. > I also have not yet seen any good examples of user literals in C++. > Do you think Python users are incapable of the kind of restraint and taste > shown by C++ users, and therefore we can’t trust Python users with a tool > that might possibly (but we aren’t sure) if abused badly enough make code > harder to visually parse? > People can be trusted with powerful features that can introduce complexity. There's just not a lot of point introducing a low-value feature that adds a lot of complexity. 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/THQWD6GA4ESFXE6GRO3BJKSRBQWLAP2X/ Code of Conduct: http://python.org/psf/codeofconduct/
