[Python-ideas] str.startswith taking any iterator instead of just tuple
Devin Jeanpierre
jeanpierreda at gmail.com
Mon Jan 6 09:19:44 CET 2014
On Mon, Jan 6, 2014 at 12:09 AM, Devin Jeanpierre
<jeanpierreda at gmail.com> wrote:
> On Sun, Jan 5, 2014 at 9:08 PM, Terry Reedy <tjreedy at udel.edu> wrote:
>> On 1/5/2014 12:48 PM, Andrew Barnert wrote:
>>>
>>> On Jan 5, 2014, at 3:09, David Townshend
>>> <aquavitae69 at gmail.com> wrote:
>>>
>>>> Reading this thread made me start to think about why a string is a
>>>> sequence,
>>
>>
>> Because a string is defined in math/language theory as a sequence of symbols
>> from an alphabet. If you want to invent or define something else, such as an
>> atomic symbol type, please use a different term. For example:
>
> And sequences in math / CS are functions from the natural
> numbers to elements of the sequence. Since isinstance(str,
> types.FunctionType) isn't True, it must mean that Python strings
> aren't strings.
>
> But seriously, Python functions aren't functions, the set of Python
> complex numbers is not the set of complex numbers, Python types aren't
> types, and Python addition is not addition; mathematical terminology
> in programming is evocative and
> not actually literally true. Arguments based on trying to literally
> copy math to the letter are flawed, probably irretrievably so.
>
> The important feature of strings in math is not that they are
> literally a sequence of characters, but that they correspond to a
> sequence of characters isomorphically. You can represent them any way
> you like, as long as you maintain that isomorphism, and the operations
> with the right names do the right thing, etc. As evidence, observe
> that not every programming language has its string type obey the
> equivalent of Python's sequence interface or math's notion of
> "sequence" per se (mapping naturals to elements). For example, Haskell
> strings are linked lists; Rust strings are arrays behind the scenes
> but don't expose it within the str type; etc.
>
> It's not just strings, either, There are a multitude of ways of
> defining the natural numbers -- maybe a natural number is a set of a
> given structure (and which structure?), maybe it is a pair of integers
> where the second integer is 1, maybe it is an infinite sequence of
> rationals whose limit is a rational with denominator 1, maybe it is a
> bitstring of arbitrary finite length. The usual construction in math
> is the first, but Python uses the last one. To say Python doesn't
> actually have natural numbers but does have strings, is absurd, but it
> is what your logic points towards. If two things are equivalent,
> everything said about one can be said about the other, and math is
> about saying things about stuff, not about precise definitions of
> structure -- those are chosen for convenience.
Apologies, I wasn't thinking much and bungled that last argument
(should've talked about integers instead of naturals; and even did,
for half of it...). Fixed:
[...] There are a multitude of ways of defining the integers -- maybe
an integer is an equivalence class over the pairs of naturals, maybe
it is rational number with denominator 1, maybe it is an infinite
sequence of rationals whose limit is a rational with denominator 1,
maybe it is a two's complement bitstring of arbitrary length. The
usual construction in math is the first (or the second to last), but
Python uses the last one. To say that Python doesn't actually have
integers, but does have strings, is absurd, but [...]
-- Devin
More information about the Python-ideas
mailing list