Elements of AnyStr
are difficult to handle
#1446
Replies: 1 comment 2 replies
-
I don't think there's a very compelling case for I don't think it's too big of an ask having to write the latter, sure it's less readable and it's not as type safe for the internals, but there's a way to get most of the way back to the first example by adding a The more general case of |
Beta Was this translation helpful? Give feedback.
-
Consider the following code (which assumes a symbol called
AnyStrElem
is available):(Even using this hypothetical facility (
AnyStrElem
), there's some awkwardness: I'm aware of no interface tostr
andbytes
which can be used to construct anAnyStr
from a sequence ofAnyStrElem
s; handling this accounts for about half the length ofencode_value()
.)Of course, we don't have
AnyStrElem
, so instead we're forced to write something like this:The latter is far less readable, quite a bit less safe (more
cast
s,type: ignore
s, etc.), and almost twice as long by character count.1 (We could have skippedvalue_to_digit()
anddigit_to_value()
in the first version, referencingself._fwd
andself._rev
directly, making the contrast in length even greater.)Proposal One:
AnyStrElem
The simplest fix would be to add
AnyStrElem
as a special case, as used in the first example above.Proposal Two:
TypeOf
Introduce an operator which sets a
TypeAlias
to the type of some expression.This would read something like this:
This would be more legible (and less polluting of the namespace) with a corresponding
ValueOfType
operator:Discussion
Thanks for taking the time to consider this problem!
Footnotes
about 65% longer after stripping imports, comments, docstrings, common indentation, and converting spaces to tabs ↩
Beta Was this translation helpful? Give feedback.
All reactions