> all of which hugely outweighs the gain of being able to avoid a pair
> of parentheses.
Thank you for summarizing the main objections so succinctly,
otherwise it becomes too easy to get lost in the discussion. Let me
try to answer them as best as I can:
> you have something that looks like a kind of string czt'...'
> but is really a function call that might return absolutely
> anything at all;
This is kinda the whole point. I understand, of course, how the
idea of a string-that-is-not-a-string may sound blasphemous,
however I invite you to look at this from a different perspective.
Today's date is 2019-08-28. The date is a moment in time, or
perhaps a point in the calendar, but it is certainly not a string.
How do we write this date in Python? As
`datetime("2019-08-28")`. We are forced to put the date into
a string and pass that string into a function to create an actual
datetime object.
With this proposal the code would look something like
`dt"2019-08-28"`. You're right, it's not a string anymore. But
it *should not* have been a string to begin with, we only used
a string there because Python didn't offer us any other way.
Now with prefixed strings the justice is finally done: we are
able to express the notion of <a specific date> directly.
And the fact that it may still use strings under the hood to
achieve the desired result is really an implementation detail,
that may even change at some point in the future.
> you have a redundant special case for calling functions that
> take a single argument, but only if that argument is a string
> literal;
There are many things in python that are in fact function calls
in disguise. Decorators? function calls. Imports? function calls.
Class definition? function call. Getters/setters? function calls.
Attribute access? function calls. Even a function call is a
function call via `__call__()`. I may be oversimplifying a bit, but
the point is that just because something can be written as a
function call doesn't mean it's the most natural way of doing it.
Besides, there are use cases (such as `sql'...'`) where people
do actually want to have a function that is constrained to string
literals only.
Having said that, prefixed (suffixed) strings (numbers) are not
*exactly* equivalent to function calls. The points of difference
are:
- prefixes/suffixes are namespaced separately from regular
variable names.
- their results can be automatically memoized, bringing them
closer to builtin literals.
> you encourage people to write cryptic single-character
> functions, like v(), x(), instead of meaningful expressions
> like Version() and re.compile();
Which is why I suggested to put them in a separate
namespace. You're right that function `v()` is cryptic and
should be avoided. But a prefix `v"..."` is neither a function
nor a variable, it's ok for it to be short. The existing string
prefixes are all short after all.
> you encourage people to defer parsing that could be efficiently
> done in your head at edit time into slow and likely inefficient
> string parsing done at runtime;
I don't encourage such thing, it's just that most often there is no
other way. For example, consider regular expression `[0-9]+`.
I can "parse it in my head" to understand that it means a
sequence of digits, but how exactly am I supposed to convey
this understanding to Python?
Or perhaps I can parse "2019-08-28" in my head, and write in
Python `datetime(year=2019, month=8, day=28)`. However, such
form would greatly reduce readability of the code from humans'
perspective. And human readability matters more than computer
readability, for now.
In fact, purely from the efficiency perspective, the prefixed strings
can potentially have better performance because they are
auto-memoized, while `datetime("2019-08-28")` needs to re-parse
its input string every time (or add its own internal memoization,
but even that would be less efficient because it doesn't know the
input is a literal string).
> the OP still hasn't responded to my question about the ambiguity
> of the proposal (is czt'...' a one three-letter prefix, or three
> one-letter prefixes?)
Sorry, I thought this part was obvious. It's a single three-letter prefix.
_______________________________________________
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/XU6XI4NIHKQGZ7IKSBNSJ6SRYMDVYLZD/
Code of Conduct: http://python.org/psf/codeofconduct/
