I am strongly opposed to any such syntax sugar.  In all the posts in this thread, I have not seen anything that would do anything other than save 4 keystrokes.  The thing that expresses transformations on string literals are known as *functions* already.  And while functions need a set of parentheses and perhaps an 'r' to make sure raw strings are passed in, this is exactly the same thing as the "registry of evaluated string types".

I.e. if you want:

  mydecimal = D"123.45"

Just settle for the perfectly good (and far less confusing and error-prone):

  mydecimal = D(r"123.45")

And likewise, this is fine:

  sql = S(r"SELECT * FROM foo WHERE field='value'")
  funny_string_type = f(r"Gets interpreted [in some] <odd way>")




On Thu, May 30, 2013 at 1:15 PM, Göktuğ Kayaalp <goktug.kayaalp@gmail.com> wrote:
> 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@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



--
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.