[Brett]
> That is coming down to a question of convenience compared to
> explicitness. Do we want "Give me $1,000,000 now!" to raise ValueError,
> or do we want to let it pass through?
>
> "Explicit is better than implicit" is good since it will cut down on
> errors (which is what Tim is arguing for along with "Special cases
> aren't special enough to break the rules").
>
> But Raymond is pushing for "practicality beats purity" which is more or
> less true,
It's far less true for non-Americans. I know it took me several
decades to learn that "$ means currency" isn't an international
standard enforced by the death penalty -- although it should be
<wink>.
> but I am starting to agree with Tim that dollar amounts in an
> interpolated string probably won't hapeen that often. If anything the
> number will be what is interpolated in.
And that's where "handy shortcuts" bite too. "OK, I want to
interpolate the value of variable 'dollars'. A $ sign on its own
means a $ sign, and to interpolate the value of 'dollars' I do
$dollars, so putting them those together I must need
"Total: $$dollars"
". Which doesn't do what they want, although
"Total: $ $dollars"
might be close enough. A *consistent* (if you want $ in the output,
you must have $$ in the input) rule may be surprising at first, but it
doesn't remain surprising.
> So going for a more explicit version is seeming to be the better solution.
> Perk of the current implementation is that if someone wants a looser definition
> they can just change the regex themselves (you guys could even go as far as to
> break up the regex into individual class attributes and just have a
> property that does a '|'.join on them as a read method so it is even
> easier to just change the one group).
We could indeed make this so complicated nobody will understand it
<wink>. The use of named (as opposed to the current numbered)
capturing groups could make it a lot less dependent on details of how
the regexp happens to be written, though.
> So I guess it's your call, Mr PEP Champion, on whether you want all
> individual, non-interpolating $ signs to lead to an error or just random
> orphaned ones at the end of the line.
I still don't grasp why the end of the line is somehow special here.
The real thrust of what I'm after is catching what will *certainly* be
common typos, like
$(barry)
${barry)
$[barry]
$(barry}
${barry{
${barry
The specific gimmick I suggested flags those as errors, and flags an
odd number of trailing $;s too, but the latter isn't a kind of typo I
expect occurs in real life.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4