On Sun, Aug 9, 2015 at 3:25 PM Brett Cannon <br...@python.org> wrote:
>
> On Sun, Aug 9, 2015, 13:51 Peter Ludemann via Python-Dev <
> python-dev@python.org> wrote:
>
> Most of my outputs are log messages, so this proposal won't help me
> because (I presume) it does eager evaluation of the format string and the
> logging methods are designed to do lazy evaluation. Python doesn't have
> anything like Lisp's "special forms", so there doesn't seem to be a way to
> implicitly put a lambda on the string to delay evaluation.
>
> It would be nice to be able to mark the formatting as lazy ... maybe
> another string prefix character to indicate that? (And would the 2nd
> expression in an assert statement be lazy or eager?)
>
>
> That would require a lazy string type which is beyond the scope of this
> PEP as proposed since it would require its own design choices, how much
> code would not like the different type, etc.
>
> -Brett
>
Agreed that doesn't belong in PEP 498 or 501 itself... But it is a real
need.
We left logging behind when we added str.format() and adding yet another
_third_ way to do string formatting without addressing the needs of
deferred-formatting for things like logging is annoying.
brainstorm: Imagine a deferred interpolation string with a d'' prefix..
di'foo ${bar}' would be a new type with a __str__ method that also retains
a runtime reference to the necessary values from the scope within which it
was created that will be used for substitutions when iff/when it is
__str__()ed. I still wouldn't enjoy reminding people to use di''
inlogging.info(di'thing happened: ${result}') all the time any more than I
like reminding people to undo their use of % and just pass the values as
additional args to the logging call... But I think people would find it
friendlier and thus be more likely to get it right on their own. logging's
manually deferred % is an idiom i'd like to see wither away.
There's also a performance aspect to any new formatter, % is oddly pretty
fast, str.format isn't. So long as you can do stuff at compile time rather
than runtime I think these PEPs could be even faster. Constant string
pep-498 or pep-501 formatting could be broken down at compile time and
composed into the optimal set of operations to build the resulting string /
call the formatter.
So far looking over both peps, I lean towards pep-501 rather than 498:
I really prefer the ${} syntax.
I don't like arbitrary logical expressions within strings.
I dislike str only things without a similar concept for bytes.
but neither quite suits me yet.
501's __interpolate*__ builtins are good and bad at the same time. doing
this at the module level does seem right, i like the i18n use aspect of
that, but you could also imagine these being methods so that subclasses
could override the behavior on a per-type basis. but that probably only
makes sense if a deferred type is created due to when and how interpolates
would be called. also, adding builtins, even __ones__ annoys me for some
reason I can't quite put my finger on.
(jumping into the threads way late)
-gps
>
> PS: As to Brett's comment about the history of string interpolation ... my
> recollection/understanding is that it started with Unix shells and the
> "$variable" notation, with the "$variable" being evaluated within "..." and
> not within '...'. Perl, PHP, Make (and others) picked this up. There seems
> to be a trend to avoid the bare "$variable" form and instead use
> "${variable}" everywhere, mainly because "${...}" is sometimes required to
> avoid ambiguities (e.g. "There were $NUMBER ${THING}s.")
>
> PPS: For anyone wishing to improve the existing format options, Common
> Lisp's FORMAT <http://www.gigamonkeys.com/book/a-few-format-recipes.html>
> and Prolog's format/2
> <https://quintus.sics.se/isl/quintus/html/quintus/mpg-ref-format.html>
> have some capabilities that I miss from time to time in Python.
>
> On 9 August 2015 at 11:22, Eric V. Smith <e...@trueblade.com> wrote:
>
> On 8/9/2015 1:38 PM, Brett Cannon wrote:
> >
> >
> > On Sun, 9 Aug 2015 at 01:07 Stefan Behnel <stefan...@behnel.de
>
> > <mailto:stefan...@behnel.de>> wrote:
> >
> > Eric V. Smith schrieb am 08.08.2015 um 03:39:
> > > Following a long discussion on python-ideas, I've posted my draft
> of
> > > PEP-498. It describes the "f-string" approach that was the subject
> of
> > > the "Briefer string format" thread. I'm open to a better title than
> > > "Literal String Formatting".
> > >
> > > I need to add some text to the discussion section, but I think
> it's in
> > > reasonable shape. I have a fully working implementation that I'll
> get
> > > around to posting somewhere this weekend.
> > >
> > > >>> def how_awesome(): return 'very'
> > > ...
> > > >>> f'f-strings are {how_awesome()} awesome!'
> > > 'f-strings are very awesome!'
> > >
> > > I'm open to any suggestions to improve the PEP. Thanks for your
> > feedback.
> >
> > [copying my comment from python-ideas here]
> >
> > How common is this use case, really? Almost all of the string
> formatting
> > that I've used lately is either for logging (no help from this
> proposal
> > here) or requires some kind of translation/i18n *before* the
> formatting,
> > which is not helped by this proposal either. Meaning, in almost all
> > cases,
> > the formatting will use some more or less simple variant of this
> > pattern:
> >
> > result = process("string with {a} and {b}").format(a=1, b=2)
> >
> > which commonly collapses into
> >
> > result = translate("string with {a} and {b}", a=1, b=2)
> >
> > by wrapping the concrete use cases in appropriate helper functions.
> >
> > I've seen Nick Coghlan's proposal for an implementation backed by a
> > global
> > function, which would at least catch some of these use cases. But it
> > otherwise seems to me that this is a huge sledge hammer solution for
> a
> > niche problem.
> >
> >
> > So in my case the vast majority of calls to str.format could be replaced
> > with an f-string. I would also like to believe that other languages that
> > have adopted this approach to string interpolation did so with knowledge
> > that it would be worth it (but then again I don't really know how other
> > languages are developed so this might just be a hope that other
> > languages fret as much as we do about stuff).
>
> I think it has to do with the nature of the programs that people write.
> I write software for internal use in a large company. In the last 13
> years there, I've written literally hundreds of individual programs,
> large and small. I just checked: literally 100% of my calls to
> %-formatting (older code) or str.format (in newer code) could be
> replaced with f-strings. And I think every such use would be an
> improvement.
>
> I firmly believe that the majority of software written in Python does
> not show up on PyPi, but is used internally in corporations. It's not
> internationalized or localized: it just exists to get a job done
> quickly. This is the code that would benefit from f-strings.
>
> This isn't to say that there's not plenty of code where f-strings would
> not help. But I think it's as big a mistake to generalize from my
> experience as it is from Stefan's.
>
> Eric.
>
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
>
>
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/pludemann%40google.com
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
>
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/greg%40krypto.org
>
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
