On Aug 27, 2019, at 08:36, Steven D'Aprano <st...@pearwood.info> wrote:
>
> I don't wish to say that parsing strings to extract information is
> always an anti-pattern:
>
> http://cyrille.martraire.com/2010/01/the-string-obsession-anti-pattern/
>
> after all we often need to process data coming from config files or
> other user-input, where we have no choice but to accept a string.
>
> But parsing string *literals* usually is an anti-pattern, especially
> when there is a trivial transformation from the string to the
> constructor arguments, e.g. 123/4567 --> Fraction(123, 4567).
But there are plenty of cases where parsing string literals is the current
usual practice. Decimal is obvious, as well as most other non-native numeric
types. Path objects even more so. Pandas users seem to always build their
datetime objects out of YYYYMMDDTHHMMSS strings. And so on.
So the status quo doesn’t mean nobody parses string literals, it means people
_explicitly_ parse string literals. And the proposed change doesn’t mean more
string literal parsing, it means making some of the existing, uneliminable uses
less visually prominent and more readable. (And, relevant to the blog you
linked, it seems to make it _less_ likely, not more, that you’d bind the string
rather than the value to a name, or pass it around and parse it repeatedly, or
the other bar practices they were talking about.)
I’ll admit there are some cases where I might sacrifice performance for
convenience if we had this feature. For example, F1/3 (or 1/3F with suffixes)
would have to mean at least Fraction(1) / 3, if not Fraction('1') / 3, or even
that plus an extra LOAD_ATTR. That is clearly going to be more expensive than
F(1, 3) meaning Fraction(1, 3), but I’d still do it at the REPL, and likely in
real code as well. But I don’t think that choice would make my code worse
(because when setup costs matter, I _wouldn’t_ make that choice), so I don’t
see that as a problem.
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/YQMFAPYI6TU3APEYWROQN5GFMVG2I3TF/
Code of Conduct: http://python.org/psf/codeofconduct/
