[Python-ideas] Custom string prefixes

[David Mertz]

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 at 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 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>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130530/a1feed9d/attachment.html>