> Of course the OP wasn't even worried about that; he just wanted toI haven't used the decimal library for anything other than the example
> save a few keystrokes making decimals.
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 <abarnert@yahoo.com> writes:
> On May 30, 2013, at 3:42, Haoyi Li <haoyi.sg@gmail.com> 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 <goktug.kayaalp@gmail.com>
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
http://mail.python.org/mailman/listinfo/python-ideas