Guido van Rossum wrote:
> I understand that '&' here stands for "any arbitrary combination", but
> what about searches? Given that asciistr's base class is str, won't it
> still blow up if you try to use it as an argument to e.g.
> bytes.startswith()? Equality tests also sound problematic; is b'x' ==
> asciistr('x') == 'x' ???
I'm wondering whether asciistr shouldn't be a *type*
at all, but just a function that constructs a string
with the same type as another string.
All of these problems then go away. Instead of
foo.startswith(asciistr("prefix"))
you would write
foo.startswith(asciistr("prefix", foo))
There's also no chance of an asciistr escaping into
the wild, because there's no such thing.
We probably want a more compact way of writing it,
though. Ideally it would support currying. If we
have a number of string literals in our function,
we'd like to be able to write something like this
at the top:
def myfunc(a):
s = stringtype(a)
...
and then use s('foo') to construct all our string
literals inside the function.
We could go further. If the function has more than
one string argument, they're probably constrained
to be of the same type, so in the interests of
symmetry it would be nice if we could write
def myfunc(a, b):
s = stringtype(a, b)
...
and have it raise a TypeError if a and b are not
of the same string type.
--
Greg
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4