On Sat, Dec 22, 2012 at 10:05 PM, Steven D'Aprano
<steve+comp.lang.pyt...@pearwood.info> wrote:
> On Sat, 22 Dec 2012 20:08:25 +1100, Chris Angelico wrote:
>
>> I don't see "string % tuple" as a good syntax; I prefer to spell it
>> sprintf("format",arg,arg,arg).
>
> Very possibly one of the worst names ever from a language that excels at
> bad names. "Sprint f"? WTF?
>
> Certainly not appropriate for Python, where a sprintf equivalent would
> return a new string, rather than automatically print the result. Oh
> wait... C's sprintf doesn't automatically print either.
>
> *wink*Sure, it's not ideal, but it's the string-returning form of printf, which prints formatted text, so it's not completely inappropriate. But my point stands: it's an easy thing to search for. >> When it >> comes to operators on strings, what I'd prefer to see is something that >> does more-or-less what the operator does with integers - for instance: >> >> "This is a string" / " " ==> ["This","is","a","string"] > > I don't see the connection between the above and numeric division. If it > were this: > > "This is a string" / 3 ==> ["This ", "is a ", "strin", "g"] > > (and presumably // 3 would be the same except the "g" would be dropped) > then I could see the connection. But there's no relationship between > numeric division, which divides a number up into N equal-sized parts, and > string splitting as you show above. Sure, but it's still dividing. It's a different form of division, but it still makes sense. "Oh, you're dividing that string by a delimiter. I'd prefer to call it 'on' a delimiter, but 'by' works." Your description makes perfectly good sense too, though; however, if: "This is a string" / 3 ==> ["This ", "is a ", "strin", "g"] and "This is a string" // 3 ==> ["This ", "is a ", "strin"] then "This is a string" % 3 ==> ["g"] or possibly "g" which is incompatible with current usage. But that's a meaning that makes reasonable sense as "modulo". >> Taking a string modulo a tuple doesn't make any sense in itself, > > Taking an integer cross an integer doesn't make any sense if you haven't > learned the meaning of the + operator. Why insist that only string > operators must make inherent sense to somebody who doesn't know what the > operator means? If we're allowed to learn the meaning of + * and &, why > not % as well? Sure, but + and * have meaning in mathematics, not just programming, and it's a similar meaning. Even the much-maligned = assignment, which has quite a different meaning to = equality, which itself isn't the same as the = equality in mathematics, is sufficiently close that it's grokkable. But someone coming from a mathematical background has no particular advantage in figuring out that % means formatting, or that <= means add child. That doesn't mean they shouldn't be done, just that the justification hump is that bit higher. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
