[Python-ideas] Custom string prefixes

[Göktuğ Kayaalp]

> 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 <abarnert at yahoo.com> writes:

> On May 30, 2013, at 3:42, Haoyi Li <haoyi.sg at 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 at python.org
> http://mail.python.org/mailman/listinfo/python-ideas

-- 
Göktuğ Kayaalp <goktug.kayaalp at gmail.com>