8 ms·

Nice course. Looks like good, practical material for people who want to dive in. Side note, this example made me pause and be grateful that I'm no longer profe

Nice course. Looks like good, practical material for people who want to dive in. Side note, this example made me pause and be grateful that I'm no longer professionally writing in python as much as I used to be: @shares.setter def shares(self, value): if not isinstance(value, int): raise TypeError('Expected int') self._shares = value I programmed python for about 6 years. Now I've switched to Java and Go and really don't miss having to type-check things manually. Static-typed languages have too many benefits right off the bat. You can (mostly) avoid all of these types of checks. I still use python if I'm doing prototyping, exploring APIs or ideas, etc. But I try not to roll it into production unless it's an inconsequential program.

xthetrfd 6y ago
I believe that some recent Python version has added (optional) type annotation support. I haven't ever used it though.
- scubbo 6y ago
  It's super-easy to use! More flexible than Java, but (so far as I can tell) just as powerful in terms of catching errors.
  - willcipriano 6y ago
    You can even benefit from it without bothering with the type annotations (though they make it more effective). https://google.github.io/pytype/ https://google.github.io/pytype/
  - ed25519FUUU 6y ago
    Maybe your IDE experience is different than mine, but a typed function will gladly accepted an untyped var without complaining, and during runtime could care less.
    - j88439h84 6y ago
      That's a mypy setting
    - anentropic 6y ago
      There is type inference in all of the Python type checkers, it's not necessarily an "untyped" var because it lacks an annotation. Running a type checker in Python is a way to avoid runtime type errors, just like in compiled languages, but without a performance benefit.
    - ghostwriter 6y ago
      > but a typed function will gladly accepted an untyped var without complaining this can be made prohibited by MyPy's --strict flag [1], and enforced with a mypy git pre-commit hook locally, and with a MyPy CI job. [1] https://mypy.readthedocs.io/en/stable/command_line.html#cmdoption-mypy-strict https://mypy.readthedocs.io/en/stable/command_line.html#cmdo...
- ed25519FUUU 6y ago
  It’s not enforced at all, and only serves to provide development feedback.
  - dragonwriter 6y ago
    The annotations are a language syntax feature than the runtime doesn't enforce. There are a number of separate static typecheckers, such as mypy, that do allow AOT static verification (which is, after all, all languages like Haskell have; runtime enforcement of types that have been statically verified in advance isn't super common or necessary.)
- pansa2 6y ago
  Type annotations aren’t equivalent to this check, though, because they’re not enforced at runtime.
  - h8hawk 6y ago
    Why should type annotation be enforced at run time? In statically typed languages there is no type checking at run time, your type system already proved the type of variable.
    - pansa2 6y ago
      Because Python’s type annotations don’t prove anything. That’s why, for example, they can’t be used to increase the performance of the interpreter.
      - ghostwriter 6y ago
        > That’s why, for example, they can’t be used to increase the performance of the interpreter. They can (as in - there's API for that, the rest is up to a community effort) improve performance of a final program, if type-annotated code is passed through Cython with ``annotation_typing=True`` flag: http://docs.cython.org/en/latest/src/tutorial/pure.html#static-typing http://docs.cython.org/en/latest/src/tutorial/pure.html#stat... https://github.com/cython/cython/issues/1672#issuecomment-295281642 https://github.com/cython/cython/issues/1672#issuecomment-29...
- dragonwriter 6y ago
  > I believe that some recent Python version has added (optional) type annotation support. Annotation support was added in 3.0, which isn't really a recent version of Python, having been released about 11.5 years ago. Also, mypy, while it can use Python 3.x annotations, also supports static checking of Python 2.x code using type comments.
  - pansa2 6y ago
    > Annotation support was added in 3.0 However, support for type annotations, specifically, wasn’t added until Python 3.5 (via PEP 484).
    - dragonwriter 6y ago
      What PEP 484 was standardize the use of annotations as type annotations and provide ancillary out-of-the-box support for type hinting via annotations, particularly the typing module. Mypy was actually using python 3.x annotation for type annotations before PEP 484 standardized them brought the stdlib typing module, but with PEP 484 there was a common, language-defined standard baseline for mypy and other efforts.
j88439h84 6y ago
That's not idiomatic python, just use the type annotation system.
- pansa2 6y ago
  I’d argue the opposite - that `isinstance` checks are idiomatic, whereas type annotations have not been widely adopted.
  - j88439h84 6y ago
    I dont think you'll find a long time pythonista who thinks isinstance is good python style.
    - pansa2 6y ago
      I agree that, in general, duck-typing is preferable. However in cases like this, where you really want to ensure the count of shares is a whole number, I can see an argument for `isinstance`. What I can’t understand is the argument that occasional use of `isinstance` is bad, but also that pervasive nominal type-checking via annotations is good.
      - 4ec0755f5522 6y ago
        It usually means there is a better way to do what you are doing. If it's user input you should sanitize there. In Python this is often easy because you can usually cast as the type you need e.g. with int() and then raise exception if it cannot. If it's your code, then you should make sure you are passing in an int if that's what is required. If you type hint the input as int, and somewhere in your code you pass in a string, you will get a warning in the IDE. I would argue that's a very different time and place than checking for instanceof in the running code and that's why isinstance is bad and type-checking is good. There are always exceptions but it's bad to write them in examples when teaching code.
        pansa2 6y ago
jakear 6y ago
I’m in the midst of a python project right now - I’m fairly familiar with python but I haven’t used in a while, preferring TS. I’m currently majorly kicking myself for not starting out with mypy. Unfortunately even with mypy, soundness guarantees are nowhere near as powerful as TS, and the typing ecosystem is lacking (no definitely-typed equivalent i know of), so working with libraries is pretty much just guesswork. I really have no clue why people love this language so much.
- pansa2 6y ago
  In my experience, the people who love Python are those who are happy with dynamic typing - usually because they only use the language for small projects. When starting a large project, it would be better to skip Python altogether and use a proper statically-typed language. Type hints only make sense when you’re working on an existing large Python project - just as Guido was doing at Dropbox when he added them to the language. This is because type annotations are the worst-of-both-worlds - they require the verbosity of static typing and provide few of its benefits. > This is not a course for software engineers on how to write or maintain a one-million line Python application. I don't write programs like that, nor do most companies who use Python, and neither should you.
  - ramraj07 6y ago
    If you already know your project is going to be as big as Dropbox's entire codebase, salut don Corleone! But otherwise, I feel like trying to choose the language that scales to a million lines sounds like dooming in the beginning itself by over-engineering. I attempted that myself but kept coming back to python because it's fast to code, it's forgiving as hell and its customizable. Once you're used to it's quirks you can breeze through it fast. I'm sure ruby and js have the same as well, and with ts you get better typing, but with the typing you can do with 3.8, I'll argue that python gives the _best_ of both worlds if it's especially mixed with a good IDE like pycharm. If you really want, you can also incorporate pytype or something from the get-go. If my Greenfield project's biggest problem is that python doesn't scale, then I'm a very happy man.
    - 6y ago
dragonwriter 6y ago
> Static-typed languages have too many benefits right off the bat. You can (mostly) avoid all of these types of checks. Python’s major typecheckers, which add features faster than the type systems of most major statically-typed languages, already support a more robust type system than many industrially-popular statically-typed languages. It's not Haskell, or even Scala, but then neither is Go or Java. Now, obviously, you don't get the performance benefits of type-informed static compilation with Python, but performance isn't the issue most people seem to be discussing here.
- iso8859-1 6y ago
  A large majority of projects out there are not using type hints. You'd have to roll your own type hints. And sometimes, the type hints are impossible to upstream: For example, let's say you use Mongoengine. Now, you can query a collection by using MyObject.objects.get(...) and it will return a MyObject. You might be able to make that work in Mypy. Now, you use some fancy aggregation feature, passing a dict into Mongoengine and it changes the type of the result you get back. How will you typehint that? I think the only way would be to special case it for all your queries. Dynamic languages have 'reflection' all over the place. Type systems are to terminate quickly, and if they don't, you are hacking them and they perform terrible (game of life in C++ templates and such). So even if performance is not the goal, you can't even get the correctness property right. In Haskell, there are libraries that will generate code from schemas, including migrations. They are typed to various degrees. There also shallow embeddings of the PostgreSQL query language (with types for the returned type, unlike the Mongoengine example before!). I just want to demonstrate that in Haskell, typing is not all-or-nothing either, but it is a spectrum, where a Haskell lib will typically end up being more typed than a Python lib. You could 'simplify' their type signatures (get dynamic typing) with GHC.Generic and you'd get something like what is common practice with Python. But it is pretty much impossible to go the other way.
  - kqr 6y ago
    > For example, let's say you use Mongoengine. Now, you can query a collection by using MyObject.objects.get(...) and it will return a MyObject. You might be able to make that work in Mypy. Now, you use some fancy aggregation feature, passing a dict into Mongoengine and it changes the type of the result you get back. How will you typehint that? I think the only way would be to special case it for all your queries. Isnt this the case any time you use a DSL to query external data? Only sometimes someone else have type-hinted the things for you. I work in a strongly typed language (F#) that interops with JS, and one of our principles is to do the type checking on the F#--JS boundary and then not have to worry about it again.

xthetrfd 6y ago

I believe that some recent Python version has added (optional) type annotation support. I haven't ever used it though.

scubbo 6y ago
It's super-easy to use! More flexible than Java, but (so far as I can tell) just as powerful in terms of catching errors.
- willcipriano 6y ago
  You can even benefit from it without bothering with the type annotations (though they make it more effective). https://google.github.io/pytype/ https://google.github.io/pytype/
- ed25519FUUU 6y ago
  Maybe your IDE experience is different than mine, but a typed function will gladly accepted an untyped var without complaining, and during runtime could care less.
  - j88439h84 6y ago
    That's a mypy setting
  - anentropic 6y ago
    There is type inference in all of the Python type checkers, it's not necessarily an "untyped" var because it lacks an annotation. Running a type checker in Python is a way to avoid runtime type errors, just like in compiled languages, but without a performance benefit.
  - ghostwriter 6y ago
    > but a typed function will gladly accepted an untyped var without complaining this can be made prohibited by MyPy's --strict flag [1], and enforced with a mypy git pre-commit hook locally, and with a MyPy CI job. [1] https://mypy.readthedocs.io/en/stable/command_line.html#cmdoption-mypy-strict https://mypy.readthedocs.io/en/stable/command_line.html#cmdo...
ed25519FUUU 6y ago
It’s not enforced at all, and only serves to provide development feedback.
- dragonwriter 6y ago
  The annotations are a language syntax feature than the runtime doesn't enforce. There are a number of separate static typecheckers, such as mypy, that do allow AOT static verification (which is, after all, all languages like Haskell have; runtime enforcement of types that have been statically verified in advance isn't super common or necessary.)
pansa2 6y ago
Type annotations aren’t equivalent to this check, though, because they’re not enforced at runtime.
- h8hawk 6y ago
  Why should type annotation be enforced at run time? In statically typed languages there is no type checking at run time, your type system already proved the type of variable.
  - pansa2 6y ago
    Because Python’s type annotations don’t prove anything. That’s why, for example, they can’t be used to increase the performance of the interpreter.
    - ghostwriter 6y ago
      > That’s why, for example, they can’t be used to increase the performance of the interpreter. They can (as in - there's API for that, the rest is up to a community effort) improve performance of a final program, if type-annotated code is passed through Cython with ``annotation_typing=True`` flag: http://docs.cython.org/en/latest/src/tutorial/pure.html#static-typing http://docs.cython.org/en/latest/src/tutorial/pure.html#stat... https://github.com/cython/cython/issues/1672#issuecomment-295281642 https://github.com/cython/cython/issues/1672#issuecomment-29...
dragonwriter 6y ago
> I believe that some recent Python version has added (optional) type annotation support. Annotation support was added in 3.0, which isn't really a recent version of Python, having been released about 11.5 years ago. Also, mypy, while it can use Python 3.x annotations, also supports static checking of Python 2.x code using type comments.
- pansa2 6y ago
  > Annotation support was added in 3.0 However, support for type annotations, specifically, wasn’t added until Python 3.5 (via PEP 484).
  - dragonwriter 6y ago
    What PEP 484 was standardize the use of annotations as type annotations and provide ancillary out-of-the-box support for type hinting via annotations, particularly the typing module. Mypy was actually using python 3.x annotation for type annotations before PEP 484 standardized them brought the stdlib typing module, but with PEP 484 there was a common, language-defined standard baseline for mypy and other efforts.

j88439h84 6y ago

That's not idiomatic python, just use the type annotation system.

pansa2 6y ago
I’d argue the opposite - that `isinstance` checks are idiomatic, whereas type annotations have not been widely adopted.
- j88439h84 6y ago
  I dont think you'll find a long time pythonista who thinks isinstance is good python style.
  - pansa2 6y ago
    I agree that, in general, duck-typing is preferable. However in cases like this, where you really want to ensure the count of shares is a whole number, I can see an argument for `isinstance`. What I can’t understand is the argument that occasional use of `isinstance` is bad, but also that pervasive nominal type-checking via annotations is good.
    - 4ec0755f5522 6y ago
      It usually means there is a better way to do what you are doing. If it's user input you should sanitize there. In Python this is often easy because you can usually cast as the type you need e.g. with int() and then raise exception if it cannot. If it's your code, then you should make sure you are passing in an int if that's what is required. If you type hint the input as int, and somewhere in your code you pass in a string, you will get a warning in the IDE. I would argue that's a very different time and place than checking for instanceof in the running code and that's why isinstance is bad and type-checking is good. There are always exceptions but it's bad to write them in examples when teaching code.
      - pansa2 6y ago

jakear 6y ago

I’m in the midst of a python project right now - I’m fairly familiar with python but I haven’t used in a while, preferring TS. I’m currently majorly kicking myself for not starting out with mypy. Unfortunately even with mypy, soundness guarantees are nowhere near as powerful as TS, and the typing ecosystem is lacking (no definitely-typed equivalent i know of), so working with libraries is pretty much just guesswork. I really have no clue why people love this language so much.

pansa2 6y ago
In my experience, the people who love Python are those who are happy with dynamic typing - usually because they only use the language for small projects. When starting a large project, it would be better to skip Python altogether and use a proper statically-typed language. Type hints only make sense when you’re working on an existing large Python project - just as Guido was doing at Dropbox when he added them to the language. This is because type annotations are the worst-of-both-worlds - they require the verbosity of static typing and provide few of its benefits. > This is not a course for software engineers on how to write or maintain a one-million line Python application. I don't write programs like that, nor do most companies who use Python, and neither should you.
- ramraj07 6y ago
  If you already know your project is going to be as big as Dropbox's entire codebase, salut don Corleone! But otherwise, I feel like trying to choose the language that scales to a million lines sounds like dooming in the beginning itself by over-engineering. I attempted that myself but kept coming back to python because it's fast to code, it's forgiving as hell and its customizable. Once you're used to it's quirks you can breeze through it fast. I'm sure ruby and js have the same as well, and with ts you get better typing, but with the typing you can do with 3.8, I'll argue that python gives the _best_ of both worlds if it's especially mixed with a good IDE like pycharm. If you really want, you can also incorporate pytype or something from the get-go. If my Greenfield project's biggest problem is that python doesn't scale, then I'm a very happy man.
  - 6y ago

dragonwriter 6y ago

> Static-typed languages have too many benefits right off the bat. You can (mostly) avoid all of these types of checks. Python’s major typecheckers, which add features faster than the type systems of most major statically-typed languages, already support a more robust type system than many industrially-popular statically-typed languages. It's not Haskell, or even Scala, but then neither is Go or Java. Now, obviously, you don't get the performance benefits of type-informed static compilation with Python, but performance isn't the issue most people seem to be discussing here.

iso8859-1 6y ago
A large majority of projects out there are not using type hints. You'd have to roll your own type hints. And sometimes, the type hints are impossible to upstream: For example, let's say you use Mongoengine. Now, you can query a collection by using MyObject.objects.get(...) and it will return a MyObject. You might be able to make that work in Mypy. Now, you use some fancy aggregation feature, passing a dict into Mongoengine and it changes the type of the result you get back. How will you typehint that? I think the only way would be to special case it for all your queries. Dynamic languages have 'reflection' all over the place. Type systems are to terminate quickly, and if they don't, you are hacking them and they perform terrible (game of life in C++ templates and such). So even if performance is not the goal, you can't even get the correctness property right. In Haskell, there are libraries that will generate code from schemas, including migrations. They are typed to various degrees. There also shallow embeddings of the PostgreSQL query language (with types for the returned type, unlike the Mongoengine example before!). I just want to demonstrate that in Haskell, typing is not all-or-nothing either, but it is a spectrum, where a Haskell lib will typically end up being more typed than a Python lib. You could 'simplify' their type signatures (get dynamic typing) with GHC.Generic and you'd get something like what is common practice with Python. But it is pretty much impossible to go the other way.
- kqr 6y ago
  > For example, let's say you use Mongoengine. Now, you can query a collection by using MyObject.objects.get(...) and it will return a MyObject. You might be able to make that work in Mypy. Now, you use some fancy aggregation feature, passing a dict into Mongoengine and it changes the type of the result you get back. How will you typehint that? I think the only way would be to special case it for all your queries. Isnt this the case any time you use a DSL to query external data? Only sometimes someone else have type-hinted the things for you. I work in a strongly typed language (F#) that interops with JS, and one of our principles is to do the type checking on the F#--JS boundary and then not have to worry about it again.