In Python strings are allowed to have a number of special prefixes:
b'', r'', u'', f''
+ their combinations.
The proposal is to allow arbitrary (or letter-only) user-defined prefixes as
well.
Essentially, a string prefix would serve as a decorator for a string, allowing
the
user to imp
Thanks, Andrew, for your feedback. I didn't even think about string
**suffixes**, but
clearly they can be implemented together with the prefixes for additional
flexibility.
And your idea that ` ` is conceptually no different than
` ` is absolutely insightful.
Speaking of string suffixes, flags o
Thank you, Steven, for taking the time to write such an elaborate rebuttal.
If I understand the heart of your argument correctly, you're concerned that
the prefixed strings may add confusion to the code. That nobody knows
what `l'abc'` or `czt'xxx'` could possibly mean, while at the same time
`v'1.
> Unless there is some significant difference between the two, what does
> this proposal give us?
The difference between `x'...'` and `x('...')`, other than visual noise, is the
following:
- The first "x" is in its own namespace of string prefixes. The second "x"
exists in the global namespace
> But you haven't made the case for generic string prefixes or any sort
> of "arbitrary literal" that would let you import something that
> registers something to make your float32 literals.
The case can be made as follows: different people use different parts
of the Python language. Andrew would
Thanks, Andrew, you're able to explain this much better than I do.
Just wanted to add that Python *already* has ways to grossly abuse
its syntax and create unreadable code. For example, I can write
>>> о = 3
>>> o = 5
>>> ο = 6
>>> (о, o, ο)
(3, 5, 6)
But just because some fea
> 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 i
> In addition, there is the question of how user-defined literals would
> get turned into constants within the code.
So, I'm just brainstorming here, but how about the following
approach:
- Whenever a compiler sees `abc"def"`, it creates a constant of
the type `ud_literal` with fields `.prefix=
> A really good example here is the p"C:\" question. Is the
> proposal that the "string part" of the literal is just a normal
> string? If so, then how do you address this genuine issue
> that not all paths are valid? What about backslash-escapes
> (p"C:\temp")? Is the string a raw string or no
> all of which hugely outweighs the gain of being able to avoid a pair
> of parentheses.
Thank you for summarizing the main objections so succinctly,
otherwise it becomes too easy to get lost in the discussion. Let me
try to answer them as best as I can:
> you have something that looks like a
10 matches
Mail list logo
