> Ouch! That's adding a lot of additional complexity to the language.
> ...
> This proposal adds a completely separate, parallel set of scoping rules
> for these string prefixes. How many layers in this parallel scope?
Right, having a parallel set of scopes sounds like WAY too much work.
Which is why I didn't want to start my proposal with a particular
implementation -- I simply don't have enough experience for that.
Still, we can brainstorm possible approaches, and come up with
something that is feasible.
For example, how about this: prefixes/suffixes "live" in the same local
scope as normal variables, however, in order to separate them from
the normal variables, their names get mangled into something that is
not a valid variable name. Thus,
re'a|b|c' --becomes--> (locals()["re~"])("a|b|c")
2.3f --becomes--> (locals()["~f"])("2.3")
Assuming that most people don't create variable names that start
or end with `~`, the impact on existing code should be minimal (we
could use an even more rare character there, say `\0`).
The current string prefixes would be special-cased by the compiler to
behave exactly as they behave right now.
Also, a prefix such as `czt""` is always just a single prefix, there is no
need to treat it as 3 single-char prefixes.
> One of the weaknesses of string prefixes is that it's hard to get help
> for them. ...
> What's the difference between r-strings and u-strings? help() is no help
Well, it's just another problem to overcome. I know in Python one can get
help on keywords and even operators by saying `help('class')` or `help('+')`.
We could extend this to allow `help('foo""')` to give the help for the
prefix "foo".
Specifically, if the argument to `help` is a string, and that string is not a
registered topic, then check whether the string is of the form `<id>""`
or `<id>''` or `""<id>` or `''<id>`, and invoke the help for the corresponding
prefix / suffix.
This will even solve the problem with the help for existing affixes `b""`,
`f""`, `0j`, etc.
> you probably won't want to do that, since Version will probably be
> useful for those who want to create Version objects from expressions or
> variables, not just string literals.
For the Version class you're right. But use cases vary. In the thread from
2013 where this issue was discussed, many people wanted `sql"..."`
literal to be available as literal and nothing else. Presumably, if you wanted
to construct a query dynamically there could be a separate function
`sql_unsafe()` taking a simple string as an argument.
> So the "pollution" isn't really pollution at all, at least not if you
> use reasonable names, and the main justification for parallel namespaces
> seems much weaker.
The pollution argument is that, on one hand, we want to use short names
such as "v" for prefixes/suffixes, while on the other hand we don't want
them to be "regular" variable names because of the possibilities of name
clashes. It's perfectly fine to have a short character for a prefix and at the
same time a longer name for a function. It's like we have the `unicode()`
function and `u"..."` prefix. It's like most command line utilities offer short
single-character options and longer full-name options.
> That's an interesting position for the proponent of a new feature to
> take. "Don't worry about this being confusing, because hardly anyone
> will use it."
I'm sorry if I expressed myself ambiguously. What I meant to say is that
the set of different prefixes within a single program will likely be small.
> We can't extrapolate from four built-in prefixes being manageable to
> concluding that dozens of clashing user-defined prefixes will be too.
That's a valid point. Though we can't extrapolate that they will be
unmanageable either. There's just not enough data. But we could look
at other languages who have more suffixes. Say, C or C++.
Ultimately, this can be a self-regulating feature: if having too many
suffixes/prefixes makes one's code unreadable, then simply stop using
them and go back to regular function calls.
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/OCPR77XVTKWZJUSIBNJAF75FITRPE7AP/
Code of Conduct: http://python.org/psf/codeofconduct/
