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.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
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