4 ms·

> Usually, a dev writing a Python 2.7 library will not discriminate between bytes-like buffers and ASCII strings (since the language doesn’t either) which means

> Usually, a dev writing a Python 2.7 library will not discriminate between bytes-like buffers and ASCII strings (since the language doesn’t either) which means to have to code review everything str operations and ask yourself if there is a bytes operation implied or is it really a string one. And...that's exactly why you want static typing. Code review to catch stuff like this is poorly and primitively doing a job a computer can do for you perfectly. Dynamic typing is fine for small projects but when you're wanting to port over all Python 2 code that's ever been written to Python 3 types would have made the task much less daunting.

syrrim 9y ago
You're thinking strong typing, not static typing. With stronger types, there would be a difference between a bytes string and unicode string, and the programmer would have to explicitly choose between them. With dynamic typing, this difference can still exists, and it is still obvious from the code. The only difference is that it isn't checked by the compiler at compile time. Look at c. It has static typing, but fairly weak types. Strings are represented as a series of bytes (char *). The exact same work would be required to port c code to semantic c++.
- seanwilson 9y ago
  Whatever terminology you want to use, I mean at compile time you would get an error because the types are wrong for that specific example. Python is generally referred to as strongly dynamically typed, that's why I only wrote "static".
tyingq 9y ago
In this case, a new type was introduced...bytes didn't exist. So I don't know that static typing would have helped much, at least for dealing with existing code. You still have to decide what migrates from type1 to type2. The "bytes" that was put into 2.6 was just an alias to str as hinting for the 2to3 utility.
- seanwilson 9y ago
  If Python had static typing though, wouldn't that have introduced a compile time error instead of a runtime error? At the least it would alert you to all the places you had to make the decision instead of waiting for a runtime crash.
  - tyingq 9y ago
    Introducing a new type to a statically typed language still requires that decision point. The compiler can't know what was string and now should be byte. So there wouldn't be errors, other than maybe for types you're passing into 3rd party libraries that changed themselves from 2 to 3. Yes, it would help after that decision. And as mentioned, the byte "backported (sort of)" to 2.x acts and works differently than the byte in 3.x. So there actually 3 types in play, plus bytearray too.
    - seanwilson 9y ago
      Yeah, I'm not saying static typing would make the decision for you but it would let you know every line in your code where the decision had to be made instead of having to rely on runtime crashes or debugging weird behaviour. The latter is really horrible as well as it's hard to pinpoint where the problem originates from and you sometimes have to delve into the innards of libraries you're using to understand what's going on. I just think it's a good example of how strong static typing makes refactoring large projects significantly easier compared to strong dynamic typing. Getting everyone to move from Python 2 to 3 is basically a massive refactoring task.
ubernostrum 9y ago
Statically-typed Python 2 would not have solved this, since the problem was a single type permitting both string-like and bytes-like operations. A static type checker would simply say "yup, that type supports that". The solution -- introducing a new type which explicitly is not to be used in string-like fashion and does not expose the same interface as 'str' -- was implemented in Python 3, and does not require static typing. Also, I've been involved in porting very large codebases and have never felt a need for static typing to assist. The "dynamic typing is only for tiny puny baby child's toy programs" meme does not reveal your sagacity; it reveals your ignorance.
- seanwilson 9y ago
  > Statically-typed Python 2 would not have solved this, since the problem was a single type permitting both string-like and bytes-like operations. A static type checker would simply say "yup, that type supports that". You'd have to change type definitions then...if you define the type to allow those operations then obviously a static type checker isn't going to help. From the article they have this Python 2 -> 3 example which seems like static typing would catch: self.streams = zip(sizes, page_lists) and # zip return a generator on Py3 self.streams = list(zip(sizes, page_lists)) > Also, I've been involved in porting very large codebases and have never felt a need for static typing to assist. The "dynamic typing is only for tiny puny baby child's toy programs" meme does not reveal your sagacity; it reveals your ignorance. Why would you not want assistance from the computer to automatically check things for you given the choice? Why would you not want ways to automatically refactor your code? Those are good reasons, not memes or ignorance... Basic refactorings like changing an ID field between being a number and a string type are just horrible with languages that have dynamic types and implicit conversions for example.
  - ubernostrum 9y ago
    Did you know that automated refactoring was first invented and implemented in a dynamically-typed language?
    - seanwilson 9y ago
Rotareti 9y ago
I never ported something from 2 to 3, but whenever I read about it I wonder, wouldn't the new typing [0] module be enough to cope with this? It let's you annotate types like 'str', 'bytes', 'bytearray', etc. My IDE shows me right away, whenever I have the types wrong and with all the annotations visible I find it pretty easy to reason about types. [0] https://docs.python.org/3/library/typing.html https://docs.python.org/3/library/typing.html
- seanwilson 9y ago
  Sounds like it would help but it sounds like the same 2 to 3 issue that everyone has to start migrating to it. > My IDE shows me right away, whenever I have the types wrong and with all the annotations visible I find it pretty easy to reason about types. Do you find it makes you more productive? Honestly not trying to troll but my feeling is people that defend strong dynamic typing just haven't used strong statically type languages enough because the benefits are painfully obvious to me when you switch between them.
  - Rotareti 9y ago
    > it sounds like the same 2 to 3 issue that everyone has to start migrating to it. If you don't like to have it in your code base, then you could use it for the migration phase and remove it afterwards, or just leave it in the parts of the project, where it was helpful. It's totally optional, meaning, you can use it just on some parts of your code without affecting the rest. > Do you find it makes you more productive? It makes me a lot more productive. Especially when I touch code that I haven't seen in a while. I use it everywhere. Actually my IDE highlights items that I forgot to annotate. > Honestly not trying to troll but my feeling is people that defend strong dynamic typing just haven't used strong statically type languages enough because the benefits are painfully obvious to me when you switch between them. I'm not defending strong dynamic typing. I just think that the typing module makes Python a better language. I use the typing module for the same reason I switched from JavaScript to TypeScript and the experience I have working in both, Python+typing and TypeScript, is very similar, even though TypeScript is strong statically typed.

syrrim 9y ago

You're thinking strong typing, not static typing. With stronger types, there would be a difference between a bytes string and unicode string, and the programmer would have to explicitly choose between them. With dynamic typing, this difference can still exists, and it is still obvious from the code. The only difference is that it isn't checked by the compiler at compile time. Look at c. It has static typing, but fairly weak types. Strings are represented as a series of bytes (char *). The exact same work would be required to port c code to semantic c++.

seanwilson 9y ago
Whatever terminology you want to use, I mean at compile time you would get an error because the types are wrong for that specific example. Python is generally referred to as strongly dynamically typed, that's why I only wrote "static".

tyingq 9y ago

In this case, a new type was introduced...bytes didn't exist. So I don't know that static typing would have helped much, at least for dealing with existing code. You still have to decide what migrates from type1 to type2. The "bytes" that was put into 2.6 was just an alias to str as hinting for the 2to3 utility.

seanwilson 9y ago
If Python had static typing though, wouldn't that have introduced a compile time error instead of a runtime error? At the least it would alert you to all the places you had to make the decision instead of waiting for a runtime crash.
- tyingq 9y ago
  Introducing a new type to a statically typed language still requires that decision point. The compiler can't know what was string and now should be byte. So there wouldn't be errors, other than maybe for types you're passing into 3rd party libraries that changed themselves from 2 to 3. Yes, it would help after that decision. And as mentioned, the byte "backported (sort of)" to 2.x acts and works differently than the byte in 3.x. So there actually 3 types in play, plus bytearray too.
  - seanwilson 9y ago
    Yeah, I'm not saying static typing would make the decision for you but it would let you know every line in your code where the decision had to be made instead of having to rely on runtime crashes or debugging weird behaviour. The latter is really horrible as well as it's hard to pinpoint where the problem originates from and you sometimes have to delve into the innards of libraries you're using to understand what's going on. I just think it's a good example of how strong static typing makes refactoring large projects significantly easier compared to strong dynamic typing. Getting everyone to move from Python 2 to 3 is basically a massive refactoring task.

ubernostrum 9y ago

Statically-typed Python 2 would not have solved this, since the problem was a single type permitting both string-like and bytes-like operations. A static type checker would simply say "yup, that type supports that". The solution -- introducing a new type which explicitly is not to be used in string-like fashion and does not expose the same interface as 'str' -- was implemented in Python 3, and does not require static typing. Also, I've been involved in porting very large codebases and have never felt a need for static typing to assist. The "dynamic typing is only for tiny puny baby child's toy programs" meme does not reveal your sagacity; it reveals your ignorance.

seanwilson 9y ago
> Statically-typed Python 2 would not have solved this, since the problem was a single type permitting both string-like and bytes-like operations. A static type checker would simply say "yup, that type supports that". You'd have to change type definitions then...if you define the type to allow those operations then obviously a static type checker isn't going to help. From the article they have this Python 2 -> 3 example which seems like static typing would catch: self.streams = zip(sizes, page_lists) and # zip return a generator on Py3 self.streams = list(zip(sizes, page_lists)) > Also, I've been involved in porting very large codebases and have never felt a need for static typing to assist. The "dynamic typing is only for tiny puny baby child's toy programs" meme does not reveal your sagacity; it reveals your ignorance. Why would you not want assistance from the computer to automatically check things for you given the choice? Why would you not want ways to automatically refactor your code? Those are good reasons, not memes or ignorance... Basic refactorings like changing an ID field between being a number and a string type are just horrible with languages that have dynamic types and implicit conversions for example.
- ubernostrum 9y ago
  Did you know that automated refactoring was first invented and implemented in a dynamically-typed language?
  - seanwilson 9y ago

Rotareti 9y ago

I never ported something from 2 to 3, but whenever I read about it I wonder, wouldn't the new typing [0] module be enough to cope with this? It let's you annotate types like 'str', 'bytes', 'bytearray', etc. My IDE shows me right away, whenever I have the types wrong and with all the annotations visible I find it pretty easy to reason about types. [0] https://docs.python.org/3/library/typing.html https://docs.python.org/3/library/typing.html

seanwilson 9y ago
Sounds like it would help but it sounds like the same 2 to 3 issue that everyone has to start migrating to it. > My IDE shows me right away, whenever I have the types wrong and with all the annotations visible I find it pretty easy to reason about types. Do you find it makes you more productive? Honestly not trying to troll but my feeling is people that defend strong dynamic typing just haven't used strong statically type languages enough because the benefits are painfully obvious to me when you switch between them.
- Rotareti 9y ago
  > it sounds like the same 2 to 3 issue that everyone has to start migrating to it. If you don't like to have it in your code base, then you could use it for the migration phase and remove it afterwards, or just leave it in the parts of the project, where it was helpful. It's totally optional, meaning, you can use it just on some parts of your code without affecting the rest. > Do you find it makes you more productive? It makes me a lot more productive. Especially when I touch code that I haven't seen in a while. I use it everywhere. Actually my IDE highlights items that I forgot to annotate. > Honestly not trying to troll but my feeling is people that defend strong dynamic typing just haven't used strong statically type languages enough because the benefits are painfully obvious to me when you switch between them. I'm not defending strong dynamic typing. I just think that the typing module makes Python a better language. I use the typing module for the same reason I switched from JavaScript to TypeScript and the experience I have working in both, Python+typing and TypeScript, is very similar, even though TypeScript is strong statically typed.