On Thursday 20 June 2002 01:52 pm, Christian Tismer wrote: ...
I'd like to express my opinion at this place (which is as good as any other place in such a much-too-fast growing thread):
Ditto (particularly since Christian's opinions strike me as quite sensible here).
The following statements are ordered by increasing hate. 1 - I do hate the idea of introducing a "$" sign at all.
In my case, I detest the idea of using '$' for something that is similar but subtly different from the job of '%'. It reeks of "more than one way to do it". I can just picture myself once more having to teach/explain "this, dear bright Python beginner, is the % way of formatting, with which you can do tasks X, Y, Z. However, for tasks Y, most of Z, and a good deal of T, there is also the $ way. It's close enough to the % way that you're sure to confuse their syntactic details when you try to learn both, but don't worry, those differences are arbitrary and bereft of any mnemonic value, so your eventual confusion is totally inevitable and you may as well give up. Cheer up, though -- if you're well-learned in C (not Java, C#, or C++, but the Real McCoy) *AND* sh (or bash or perl, and able to keep in mind exactly what subset of their interpolation syntax is implemented here), then you can toss a coin each and every time you want to format/interpolate, given the wide but not total overlap of tasks best accomplished each way.
There, aren't you happy you've chosen to learn a language so powerful, simple, regular, and uniform, based on the self evident principle that there should be one way, and ideally just one way, to perform each task?"
2 - giving "$" special meaning in strings via a module 3 - doing it as a builtin function
I agree that having it as a builtin (or string method) would be even worse than having it as a module. A module I can more easily try to "sweep under the carpet" as a side-show aberration. Built-in functions, operators, and methods of built-in object types, are far harder to explain away.
4 - allowing it to address local/global variables
Yeah, I can see this smells, too, but IMHO not quite as bad as the $-formatting - vs - %-formatting task overlap.
Version 4 as worst comes visually quite close to languages like Perl. In another post, Guido answered such objection with "grow up". While my emotional reaction would be to reply with "wake up!", I have some rationale reasons why I don't like this:
I have to read and sometimes write lots of Perl code. The massive use of "$" gives me true headache. I don't want Python to remind me of headaches.
I don't get this specific point. As punctuation goes, $ or % are much of a muchness from my POV (I admit to not having a very high visual orientation, so I may be missing some subtle point of graphical rendition?). A massive use of one OR the other would be just as bad. Am I misreading you or just missing something important?
One argument was that "$" and the unembraced usage in "$name" is so common and therefore easy to sell to Python newbies.
Newbies who come from Windows and have never knowingly used a Unix-ish box (probably more numerous today, despite Linux's renaissance -- newbies do tend to grow on Microsoft operating systems, that's what comes bundled with typical PCs today) might of course be familiar with %name and not $name (%name is what Microsoft's pitifully weak .BAT "language" uses). It seems to me that this "familiariry" argument doesn't cut much ice either way.
Were we designing from scratch, and having to choose one punctuation character for this purpose, I'd be pretty neutral on ground of looks and familiarity. A slight bias against $ because on some terminals or printers it can come out as some OTHER currency symbol, depending on various settings, but that's pretty marginal.
But I'd much rather not have both $ and % used in slightly different contexts for somewhat-similar, overlapping tasks...
Fine, but no reason to adopt this overly abused character. Instead, I'm happy that exactly "$" is nowhere used in formatting.
Me, I'm happy (so far) that not BOTH $ and % are used for this, but just one of them.
I don't want to make Python similar to something, but to keep it different in this aspect. Like the triple quotes, the percent formatting exists rather seldom in other languages, and I love to use templates for makefiles, scripts and whatsoever, where I don't have to care too much about escaping the escapes.
Good point -- sometimes being different than most others has pluses:-). Of course, if you were templating to MS .BAT files it would be the other way 'round, but one doesn't do that much:-).
With an upcoming "$" feature, I fear that "%" might get abandoned in some future, and I loose this benefit.
This sounds to me like a FUD/"slippery slope" argument, even though I'm in broad agreement with you. I've neither heard nor suspected anything about plans to introduce the huge code breakage that abandoning % would entail.
Rather, my fear is exactly that we'll get BOTH approaches to formatting, in an acute if localized outbreak of morethanonewayitis.
I agree with any sensible extension/refinement of the "%" sign.
Sure. The current %-formatting rules aren't perfect, far from it, and while we must of course keep compatibility when the % _operator_ is used, it WOULD be nice to have a function or method that does something simpler and sensible with the template string when called instead of the % operator.
I disagree on using "$" for anything frequent in Python.
I'd have no inherent objection to using $ (or @ or ? -- I think those are the three currently unused ASCII printing characters) for other tasks that didn't overlap with %'s.
I don't want to see variable names as placeholder inside of strings. Placeholders should be dictionary string keys, but this dictionary must be obtained explicitly.
Yes, I see your point. It's definitely a valid one.
I do like the allvars() proposal.
Me too BUT. How would allvars deal with free variables? eval is currently unable to deal with them very well:
... a=1; b=2; c=3 ... def g(x): ... z = b ... try: return eval(x) ... except: return '%s unknown'%x ... return g ...
K=f() for Z in 'abc': print K(Z)
... a unknown 2 c unknown
'b' is OK because the compiler has seen it used elsewhere in nested function g, but 'a' and 'c' aren't. If 'allvars' can't deal with this problem, then it should not be named 'allvars' but 'somevarsbutmaybenotalldepending'.