On 28/08/2019 23:01, stpa...@gmail.com wrote:
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.
I don't think it's blasphemous. I think it's misleading, and that's far
worse.
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.
Pace Stephen's point that this is not in fact how datetime works, this
has the major advantage of being readable. My thought processes on
coming across that in code would go something like; "OK, we have a
function call. Judging from the name its something to do with dates and
times, so the result is going to be some date/time thing. Oh, I
remember seeing "from datetime import datetime" at the top, so I know
where to look it up if it becomes important. Fine. Moving on."
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.
Here my thoughts would be more like; "OK, this is some kind of special
string. I wonder what "dt" means. I wonder where I look it up. The
string looks kind of like a date in ISO order, bear that in mind. Maybe
"dt" is "date/time"." Followed a few lines later by "wait, why are we
calling methods on that string that don't look like string methods?
WTF? Maybe "dt" means "delirium tremens". Abort! Abort!"
Obviously I've played this up a bit, but the point remains that even if
I do work out that "dt" is actually a secret function call, I have to go
back and fix my understanding of the code that I've already read. This
significantly increases the chance that my understanding will be wrong.
This is a Bad Thing.
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.
If all that dt"string" gives us is a run-time call to dt("string"), it's
a complete non-starter as far as I'm concerned. It's adding confusion
for no real gain. However, it sounds like what you really want is
something I've often really wanted to -- a way to get the compiler to
pre-create "constant" objects for me. The trouble is that after
thinking about it for a bit, it almost always turns out that I don't
want that after all.
Suppose that we did have some funky mechanism to get the compiler to
create objects at compile time so we don't have the run-time creation
cost to contend with. For the sake of argument, let's make it
start_date = $datetime(2019,8,28)
(I know this syntax would be laughed out of court, but like I said, for
the sake of argument...)
So we use "start_date" somewhere, and mutate it because the start date
for some purpose was different. Then we use it somewhere else, and it's
not the start date we thought it was. This is essentially the mutable
default argument gotcha, just writ globally.
The obvious cure for that would be to have our compile-time created
objects be immutable. Leaving aside questions like how we do that, and
whether contained containers are immutable, and so on, we still have the
problem that we don't actually want an immutable object most of the
time. I find that almost invariably I need to use the constant as a
starting point, but tweak it somehow. Perhaps like in the example
above, the start date is different for a particular purpose. In that
case I need to copy the immutable object to a mutable version, so I have
all the object creation shenanigans to go through anyway, and that
saving I thought I had has gone away.
I'm afraid these custom string prefixes won't achieve what I think you
want to achieve, and they will make code less readable in the process.
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.
So how do you distinguish the custom prefix "br" from a raw byte string?
Existing syntax allows prefixes to stack, so there's inherent
ambiguity in multi-character prefixes.
--
Rhodri James *-* Kynesim Ltd
_______________________________________________
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/L7TX46MKZW35V2CYYMX5IIPKBJXRJLHA/
Code of Conduct: http://python.org/psf/codeofconduct/
