3 ms·

But Python is a duck-typed language. And most of the time, a bytearray's quack and a chararray's quack sound similar, if not the same [0]. Java can afford to di

by tremon 6y ago

But Python is a duck-typed language. And most of the time, a bytearray's quack and a chararray's quack sound similar, if not the same [0]. Java can afford to distinguish between bytes and characters because it is strongly typed throughout the language. In Python, whether 2 or 3, as a developer you do not have the luxury of informed reasoning whether something is bytes or a string, because your functions' input parameters can be either. In hindsight, I think the proper decision would have been to ensure every string has an accompanying encoding attribute, and refuse operations on two strings of different encodings (or even perform on-the-fly encoding changes). At least that wouldn't have created a source-incompatible language. [0] Here's some of the operations that should absolutely be invalid on a byte array, but aren't because Python3's bytes object isn't actually bytes, it's 8-bit ASCII: lower(), title(), upper(), isalpha(), isdigit(), isprintable(), splitlines()

heavyset_go 6y ago
> Java can afford to distinguish between bytes and characters because it is strongly typed throughout the language. In Python, whether 2 or 3, as a developer you do not have the luxury of informed reasoning whether something is bytes or a string, because your functions' input parameters can be either. Python is a strongly typed language, and you can check a function's argument types at runtime with isinstance(), and inspect those types' class hierarchies with issubclass().
- takeda 6y ago
  The parent meant statically typed. Meaning it shows the errors at compile time. Yes, you can check at runtime, the problem though is that especially on Python 2. Those checks don't happen very often. Python 3 though will crash if you try to use bytes as text or vice versa. The python 2 though it will do an implicit casting and execute code, which will run and look like it runs correctly until you get an unicode characters, then it will crash. Java won't even let you compile such program. You could get somewhat similar protection if you annotate types and use mypy to check them.
joshuamorton 6y ago
While I agree with you about some of those, `isprintable` only makes sense in a byte object, it doesn't make sense on text which is printable by definition. Perhaps it should be called isasciipritnable, but yeah. > In hindsight, I think the proper decision would have been to ensure every string has an accompanying encoding attribute This wouldn't have made things any more source compatible. Adding more types doesnt address the issue that python2 string was multiple things masquerading as one.
dehrmann 6y ago
> In Python, whether 2 or 3, as a developer you do not have the luxury of informed reasoning whether something is bytes or a string, because your functions' input parameters can be either. I guess they can be, but the code might also work on an int tuple, even though the operation doesn't make any sense. Here's a case where duck typing does something, but it doesn't make sense. import functools def sum2(vals): return functools.reduce(lambda a, b: a + b, vals) Python's built-in sum won't work on strings or lists of strings (so much for saying the language is duck typed), but this will. It's also weird because addition is associative, but not with strings, so changing a+b to b+a changes the behavior and gives you a very cute answer to the "reverse a string" algorithm: reverse = sum2 In practice, every legitimate use I've seen for duck typing might as well use what would be an interface in Java. I see duck typing as interfaces without the formality of declaring them. If you violate the implicit contract, funny things happen, and this is why Typescript got so popular and Python added type annotations.

by tremon 6y ago

heavyset_go 6y ago

> Java can afford to distinguish between bytes and characters because it is strongly typed throughout the language. In Python, whether 2 or 3, as a developer you do not have the luxury of informed reasoning whether something is bytes or a string, because your functions' input parameters can be either. Python is a strongly typed language, and you can check a function's argument types at runtime with isinstance(), and inspect those types' class hierarchies with issubclass().

takeda 6y ago
The parent meant statically typed. Meaning it shows the errors at compile time. Yes, you can check at runtime, the problem though is that especially on Python 2. Those checks don't happen very often. Python 3 though will crash if you try to use bytes as text or vice versa. The python 2 though it will do an implicit casting and execute code, which will run and look like it runs correctly until you get an unicode characters, then it will crash. Java won't even let you compile such program. You could get somewhat similar protection if you annotate types and use mypy to check them.

joshuamorton 6y ago

While I agree with you about some of those, `isprintable` only makes sense in a byte object, it doesn't make sense on text which is printable by definition. Perhaps it should be called isasciipritnable, but yeah. > In hindsight, I think the proper decision would have been to ensure every string has an accompanying encoding attribute This wouldn't have made things any more source compatible. Adding more types doesnt address the issue that python2 string was multiple things masquerading as one.

dehrmann 6y ago

> In Python, whether 2 or 3, as a developer you do not have the luxury of informed reasoning whether something is bytes or a string, because your functions' input parameters can be either. I guess they can be, but the code might also work on an int tuple, even though the operation doesn't make any sense. Here's a case where duck typing does something, but it doesn't make sense. import functools def sum2(vals): return functools.reduce(lambda a, b: a + b, vals) Python's built-in sum won't work on strings or lists of strings (so much for saying the language is duck typed), but this will. It's also weird because addition is associative, but not with strings, so changing a+b to b+a changes the behavior and gives you a very cute answer to the "reverse a string" algorithm: reverse = sum2 In practice, every legitimate use I've seen for duck typing might as well use what would be an interface in Java. I see duck typing as interfaces without the formality of declaring them. If you violate the implicit contract, funny things happen, and this is why Typescript got so popular and Python added type annotations.