Using a typing approach sounds like a fantastic idea. Moreover, as Stephen
showed, it's easy to make Emacs utilize that, and as I showed, it's easy to
make vim follow that. I've only written one tiny VS Code extension, but it
wouldn't be hard there either. I'm not sure how one adds stuff to PyCharm
and other editors, but I have to believe it's possible.
So I see two obvious approaches, both of which 100% fulfill Emil's hope
without new syntax:
#1
from typing import NewType
html = NewType("html", str)
css = NewType("css", str)
a: html = html("<h1>Hello world</h1>")
b: css = css("h1 { color: #999999; }")
def combine(h: html, c: css):
print(f"Combined page elements: {h} | {c}")
combine(a, b) # <- good
combine(b, a) # <- bad
However, if you want to allow these types to possibly *do* something with
the strings inside (validate them, canonicalize them, do a security check,
etc), I think I like the other way:
#2
class html(str): pass
class css(str): pass
a: html = html("<h1>Hello world</h1>")
b: css = css("h1 { color: #999999; }")
def combine(h: html, c: css):
print(f"Combined page elements: {h} | {c}")
combine(a, b)
combine(b, a)
The type annotations in the assignment lines are optional, but if you're
doing something other than just creating an instance of the (pseudo-)type,
they might add something. They might also be what your text editor decides
to use as its marker.
For either version, type analysis will find a problem. If I hadn't matched
the types in the assignment, it would detect extra problems:
(py3.11) 1310-scratch % mypy tagged_types1.py
tagged_types1.py:13: error: Argument 1 to "combine" has incompatible type
"css"; expected "html" [arg-type]
tagged_types1.py:13: error: Argument 2 to "combine" has incompatible type
"html"; expected "css" [arg-type]
Found 2 errors in 1 file (checked 1 source file)
Using typing.Annotated can also be used, but it solves a slightly different
problem.
On Sun, Dec 18, 2022 at 5:24 PM Paul Moore <p.f.mo...@gmail.com> wrote:
> On Sun, 18 Dec 2022 at 21:42, Christopher Barker <python...@gmail.com>
> wrote:
>
>> On Sun, Dec 18, 2022 at 9:48 AM David Mertz, Ph.D. <david.me...@gmail.com>
>> wrote:
>>
>>> In general, I find any proposal to change Python "because then my text
>>> editor would need to
>>> change to accommodate the language" to be unconvincing.
>>>
>>
>> Personally, I’m skeptical of any proposal to change Python to make it
>> easier for IDEs.
>>
>> But there *may* be other good reasons to do something like this. I’m not
>> a static typing guy, but it segg do me that it could be useful to subtype
>> strings:
>>
>> This function expects an SQL string.
>>
>> This function returns an SQL string.
>>
>> Maybe not worth the overhead, but worth more than giving IDEs hints SATO
>> what to do.
>>
>
> I believe typing has annotated types that could do this.
> Paul
>
--
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons. Intellectual property is
to the 21st century what the slave trade was to the 16th.
_______________________________________________
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/XCACWMITDR5YNBICCNONLUGZUYC3NFRV/
Code of Conduct: http://python.org/psf/codeofconduct/
