7 ms·

> There is also an example with types, but this becomes very awkward to show in Python. With the book having been published in 2014, and type hints [1] being i

> There is also an example with types, but this becomes very awkward to show in Python. With the book having been published in 2014, and type hints [1] being introduced with Python 3.5 released in 2015 [2], without knowing how the book did it I guess this is one part of the book that could have been made better in 2018. [1]: https://docs.python.org/3/library/typing.html https://docs.python.org/3/library/typing.html [2]: https://www.python.org/downloads/release/python-350/ https://www.python.org/downloads/release/python-350/

tom_mellior 9y ago
As as understand it, those hints are only hints to human readers. There is no standard tooling that actually does any type checking, either statically or dynamically (although such tooling can be built using Python's reflective capabilities). So while adding the hints may be valuable documentation, it wouldn't solve the problem of "showing how types protect against errors in the Adversity section".
- gtklocker 9y ago
  There's mypy.
  - tom_mellior 9y ago
    Sorry, by "no standard tooling" I meant "no standard tooling" in the sense of no tooling in the standard Python distribution.
    - nullp0tr 9y ago
      Seeing that mypy is under github.com/python/, you can easily argue that it is in fact the standard tool for type-checking python code.
      - milliams 9y ago
        And also that the second highest contributor is Guido van Rossum (https://github.com/python/mypy/graphs/contributors https://github.com/python/mypy/graphs/contributors).
        tom_mellior 9y ago
        Fair enough, those are reasonable arguments the grandparents could (and should) have made.
- bringtheaction 9y ago
  Like the other commenter said, check out mypy. http://mypy-lang.org/ http://mypy-lang.org/
faitswulff 9y ago
I am planning on adding this book to my wishlist, but I agree with the reviewer's note at the end: > My only criticism of the book is the naming of the styles...In many cases, there are already establish names for the styles, but instead of using them, the author came up with her own. For example: Trinity instead of MVC, Things instead of Objects, Hollywood instead of Callbacks, Bulletin Board instead of Pub/Sub and Kick Forward instead of Continuation-passing. Those names are OK, but it is much better to stick to the industry standard ones. I'd definitely include this change in a 2018 edition, too.
- kerkeslager 9y ago
  MVC = Model View Presenter? Objects = Structs or Workers? Callbacks = Continuations? Pub/Sub = Observer pattern? Depending on what programming language background you come from, you may not use the "established" names either.
  - barrkel 9y ago
    Generally speaking, solution to a terminology problem isn't to create terminology n+1.
    - kerkeslager 9y ago
      That depends what the terminology problem is. If the problem is that you're going to be criticized by a bunch of pedantic linguistic prescriptivists who want you to use their terms in the way they want, creating new terms avoids that criticism.
      - abiox 9y ago
        > avoids that criticism is that really important to avoid? and one is just gaining new criticisms in trade, no? and of course, going bespoke and inventing everything yet again has it's perks. maybe you'll get to be the person who "invented" a term, should it catch on. great for the resume. :)
    - 9y ago
gabriel 9y ago
I believe the premise of the book is to expose the reader to an element of style that bridges different programming environments. Thus, "style" here is meant more in the terms of a restrictive technique to allow an exposure of these techniques, not writing in idiomatic, or latest-and-greatest Python. I'd suggest this book even to experienced engineers to focus on different types or a style of programming that he/she may not be familiar. And when you recognize some of the styles it'll be a re-enforcement technique that you were doing something that is seen over and over again (much like a pattern language). I recall going over styles that are seen more in systems programming (like C). The book will contribute to an understanding of code architecture styles across different languages. For the new engineer, I'd also highly suggest this book as you may begin to see a variety of ways to solve a problem. And I would not concern myself with idiomatic Pythonic styles as that will come with time.

tom_mellior 9y ago

As as understand it, those hints are only hints to human readers. There is no standard tooling that actually does any type checking, either statically or dynamically (although such tooling can be built using Python's reflective capabilities). So while adding the hints may be valuable documentation, it wouldn't solve the problem of "showing how types protect against errors in the Adversity section".

gtklocker 9y ago
There's mypy.
- tom_mellior 9y ago
  Sorry, by "no standard tooling" I meant "no standard tooling" in the sense of no tooling in the standard Python distribution.
  - nullp0tr 9y ago
    Seeing that mypy is under github.com/python/, you can easily argue that it is in fact the standard tool for type-checking python code.
    - milliams 9y ago
      And also that the second highest contributor is Guido van Rossum (https://github.com/python/mypy/graphs/contributors https://github.com/python/mypy/graphs/contributors).
      - tom_mellior 9y ago
        Fair enough, those are reasonable arguments the grandparents could (and should) have made.
bringtheaction 9y ago
Like the other commenter said, check out mypy. http://mypy-lang.org/ http://mypy-lang.org/

faitswulff 9y ago

I am planning on adding this book to my wishlist, but I agree with the reviewer's note at the end: > My only criticism of the book is the naming of the styles...In many cases, there are already establish names for the styles, but instead of using them, the author came up with her own. For example: Trinity instead of MVC, Things instead of Objects, Hollywood instead of Callbacks, Bulletin Board instead of Pub/Sub and Kick Forward instead of Continuation-passing. Those names are OK, but it is much better to stick to the industry standard ones. I'd definitely include this change in a 2018 edition, too.

kerkeslager 9y ago
MVC = Model View Presenter? Objects = Structs or Workers? Callbacks = Continuations? Pub/Sub = Observer pattern? Depending on what programming language background you come from, you may not use the "established" names either.
- barrkel 9y ago
  Generally speaking, solution to a terminology problem isn't to create terminology n+1.
  - kerkeslager 9y ago
    That depends what the terminology problem is. If the problem is that you're going to be criticized by a bunch of pedantic linguistic prescriptivists who want you to use their terms in the way they want, creating new terms avoids that criticism.
    - abiox 9y ago
      > avoids that criticism is that really important to avoid? and one is just gaining new criticisms in trade, no? and of course, going bespoke and inventing everything yet again has it's perks. maybe you'll get to be the person who "invented" a term, should it catch on. great for the resume. :)
  - 9y ago

gabriel 9y ago

I believe the premise of the book is to expose the reader to an element of style that bridges different programming environments. Thus, "style" here is meant more in the terms of a restrictive technique to allow an exposure of these techniques, not writing in idiomatic, or latest-and-greatest Python. I'd suggest this book even to experienced engineers to focus on different types or a style of programming that he/she may not be familiar. And when you recognize some of the styles it'll be a re-enforcement technique that you were doing something that is seen over and over again (much like a pattern language). I recall going over styles that are seen more in systems programming (like C). The book will contribute to an understanding of code architecture styles across different languages. For the new engineer, I'd also highly suggest this book as you may begin to see a variety of ways to solve a problem. And I would not concern myself with idiomatic Pythonic styles as that will come with time.