On Monday 12 February 2007 18:38, Neil Toronto wrote: > Anthony Baxter wrote: > > I have to say that I'm not that impressed by either the 1-arg > > or 2-arg versions. Someone coming across this syntax for the > > first time will not have any hints as to what it means - and > > worse, it looks like a syntax error to me. -1 from me. > > I'm not sure the "looks like a syntax error" argument holds much > weight, because any new syntax is likely to be a syntax error > until the syntax is changed. :) Yes and no. My point is that it's extremely similar to existing syntax. (Worse yet, it looks the same but for what's possibly the smallest and hardest-to-see character in any character set) "foo(baz)" vs "foo.(baz)" is... not good. > "No hints" is a decent argument > against it, though. Parenthesis are already used for tuples, > function calls, precedence, and generator comprehensions. The > more something gets overloaded, the more ambiguous it looks. How > about > > obj.*str_expression > > instead? "*" is pretty common in the C family of languages as a > dereferencing operator. I don't know. This all still smacks of magic line noise to me :-) Although I should also add that after thinking about it a bit, I'm still not convinced this is something that needs shorthand syntax - particularly not one that's so line-noisy... Hey, we could always use backticks in Python 3.0! <wink> Anthony
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