Of course the OP wasn't even worried about that; he just wanted to save a few keystrokes making decimals.
I haven't used the decimal library for anything other than the example
I've given in the first post of this thread. What I wanted was a more
convenient way to express transformations on string literals that are
usually expressed via functions and classes and what I proposed was a
method to achieve this utilizing syntactic sugar and runtime evaluation
of string literals. Reducing my *worries* to an *effort of mutating the
language to save some keystrokes* is rude.
Göktuğ.
Andrew Barnert
On May 30, 2013, at 3:42, Haoyi Li
wrote: > But still, it's amazing how C++11-ish this discussion is getting. Which may be a good hint that (as you suggest) this feature isn't a good fit for Python.
I don't agree with this; while C++ is huge and terrible, C++11 actually has some pretty good stuff (e.g. real lambdas, with real closures and real lexical scoping! u"unicode" and r"raw" strings!). Dismissing something as bad just because it's something C++11 has is a terrible idea and immediately shuts out a whole range of interesting possibilities.
C++11 is a set of very clever, and often very nice, improvements, but nearly all of the improvements are solutions to problems unique to C++90.
And if you step back, the problem most people are trying to solve here is that they don't want to do string processing inline within a function because they're worried about performance. (Of course the OP wasn't even worried about that; he just wanted to save a few keystrokes making decimals. But most of the follow ups haven't been about that.) I'd guess that 90% of the time those performance worries are misguided, and the remaining 10% can already be solved by moving the strings to module level, caching the results, etc. So, we're looking for syntactic sugar for a way to accomplish one of those solutions more nicely. That's a very different problem than making strings (and other types) accessible to a compile-time metalanguage that's radically different from the runtime language, which is what C++ was solving.
(PS, you misattributed most of your quotes to me instead of Eric Snow. But I'm sure he'll still see then.) _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
--
Göktuğ Kayaalp