Jim Baker's draft PEP gives runtime behavior to tagged strings. I agree
it would all be pointless if it's just hints to an editor. Sorry, I
again don't have a handy link to his PEP. But it's similar in spirit to
PEP 501.
Eric
On 12/22/2022 2:36 PM, Joao S. O. Bueno wrote:
I am not enthusiastic about this idea at all: as I perceive it it is
an IDE problem, external to the language, and
should be resolved there - maybe with a recommendation PEP.
But on the other hand, I had seem tens of e-mails discussing
string-subclassing, so that
annotations could suffice as a hint to inner-string highlighting - and
then: subclassing is not
really needed at all:
Maybe we can allow string tagging in annotations by using
`str['html']`, "str['css']" and so on.
(the typing module even could take no-op names such as "html", "css",
etc... to mean those
without any other signs, so stuff could be annotated like `template:
html = "xxxx"` which the
the same typing machinery that makes things like `TypedDict`.
`Required`, etc...
work would present these as plain "str" to the runtime, while
allowing any
tooling to perceive it as a specialized class.
In other words, one could then either write:
mytemplate: str['html'] = "<html> ....</html>"
Or
from typing import html
mytemplate: html = ...
(the former way could be used for arbitrary tagging as proposed by the
O.P. , and it would be trivial to add a "register" function to
declaratively create
new tags at static-analysis time.
This syntax has the benefits that static type checkers can take
full-beneffit of
the string subtypes, correctly pointing out when a "CSS" string is
passed as
an argument that should contain "HTML", with no drawbacks, no syntax
changes,
and no backwards compatibility breaks.
On Thu, Dec 22, 2022 at 1:42 AM Christopher Barker
<python...@gmail.com> wrote:
On Wed, Dec 21, 2022 at 9:35 AM Chris Angelico <ros...@gmail.com>
wrote:
>From the look of things, PyUnicode_Join (the internal
function that
handles str.join()) uses a lot of "reaching into the data
structure"
operations for efficiency. It uses PyUnicode_Check (aka
"isinstance(x,
str)") rather than PyUnicode_CheckExact (aka "type(x) is str") and
then proceeds to cast the pointer and directly inspect its
members.
As such, I don't think UserString can ever truly be a str,
I had figured subclasses of str wouldn’t be full players in the C
code — but join() us pretty fundamental:-(
-CHB
--
Christopher Barker, PhD (Chris)
Python Language Consulting
- Teaching
- Scientific Software Development
- Desktop GUI and Web Development
- wxPython, numpy, scipy, Cython
_______________________________________________
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/C2HG3QJOU5SLU536CGOJ26VKXVEBZYBH/
Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________
Python-ideas mailing list --python-ideas@python.org
To unsubscribe send an email topython-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived
athttps://mail.python.org/archives/list/python-ideas@python.org/message/LFWSTEFW46ATMCTRRM6FZYCYX7WQBWSG/
Code of Conduct:http://python.org/psf/codeofconduct/
_______________________________________________
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/52ERBBVWPRGXKNSVXUQCNC33DYEHTSER/
Code of Conduct: http://python.org/psf/codeofconduct/
