PyCon US 2021 Recordings are Available • Hacker News Board

Re: PyCon US 2021 Recordings are Available

#61

Post by takeda » Sat, Jun 05, 2021, 7:08 AM UTC

neolog wrote: post #57

takeda wrote: post #34

Earlier quoted context omitted.

I believe GP means that they are not checked at runtime. But I don't think that matters much in case of finding bugs, because you run mypy and it will scream that you are assigning wrong type. I use it whenever I can and it helped me find many bugs in the code (especially not checking if value is None through the Optional). It also makes refactoring your code in IDEs that understand types (like PyCharm) much much eas…

> I believe GP means that they are not checked at runtime. Haskell types aren't checked at runtime either, so that can't be it. Python has runtime type checks that do happen at runtime, so maybe it's Haskell that doesn't have types.

What Haskell does and other statically compiled languages is figuring the type before program runs. Once it does it is impossible to have a different type in the code.

Python is dynamically typed. That means everything including things like string or integer is stored as a structure with a type. The checking of the type happens at runtime. This is major reason why languages like Python are so much slower than statically typed languages.

The annotated type in Python is providing mechanism of figuring out types before code is run, this helps finding bugs, but these types are not used during normal operation[1], but that doesn't stop them from being useful for finding bugs in the code or helping with refactoring.

[1] There are some packages that implement some runtime checks, but they IMO are waste of time. Basically they are ensuring that type problems that tool like mypy would detect also will cause your code to crash. It also add performance penalty as well.

There's also mypyc, code that compiles python code that using types increasing its performance. It is currently used to compile mypy increasing its performance by a factor of 4 I believe. It also makes some python features unavailable if you want to use it (https://mypyc.readthedocs.io/en/latest/differences_from_pyth...)

Re: PyCon US 2021 Recordings are Available

#62

Post by hathym » Sat, Jun 05, 2021, 7:11 AM UTC

jshen wrote: post #27

I hate it when YouTube channels put the subject of the video at the end of the title. It gets cropped and I can’t tell which videos are of interest to me without clicking on each one to see what it’s about.

https://www.youtube.com/playlist?list=PL2Uw4_HvXqvYk1Y5P8kry...

Re: PyCon US 2021 Recordings are Available

#63

Post by kqr » Sat, Jun 05, 2021, 7:26 AM UTC

void_mint wrote: post #60

scrapcode wrote: post #47

As a young ambitious man I always knew programming was going to be my passion, but life had different plans and I have ended up in less technical IT related roles. I used to think that this ever-revolving door of advancement in tech would create an interesting career but now that I realize that programming is not my career path, I now feel that in my mid 30s with a family it could become extremely cumbersome to those…

1. Learn something, be really good at it. Have demonstrable experience in that thing. 2. Learn a handful of things a little bit less well. Diversify your learnings. Some database stuff, some devops stuff, maybe some game stuff, network stuff, whatever. Try to have demonstrable experience in this stuff well. 3. In 3-5 years, repeat step 1 and 2. Do this over and over and you'll be competitive in tech indefinitely. It…

> In general, don't worry about things like project management.

I agree with most of what you say but this sounds like terrible advice. Fixing bugs in software is cheaper the earlier they are fixed. Cheaper in testing than in prod, cheaper in design than in testing, and so on.

The cheapest place to fix them are in the processes that lead to the design.

Fixing things in the project management process is a hugely levered activity.

Re: PyCon US 2021 Recordings are Available

#64

Post by cuddlybacon » Sat, Jun 05, 2021, 7:35 AM UTC

wonton53 wrote: post #15

yuy910616 wrote: post #14

After watching this 2018 talk on typing: https://www.youtube.com/watch?v=hWV8t494N88 and this one last year: https://www.youtube.com/watch?v=ST33zDM9vOE&t=68s and finally this one in 2021: https://www.youtube.com/watch?v=Lj_9TyT3V98 I think I'll finally start using type checking - it really seems to just eliminate a whole class of potential bugs; a class that is often not tested at that.

Great! I am so glad more people see types as a useful tool. Personally I see it as essential, so I struggle to understand the mind set of people who do not want to use them. I understand that people think it feels like a lot of work, but that is like nothing compared to the 90% of time people who dont use types spend on reading logs and fixng the same issues every day. I assume people have some sort of amnesia and th…

> I struggle to understand the mind set of people who do not want to use them.

I've posted a few reasons before. I think I've refined the list slightly since last time:

* People's first exposure to programming often came from using C++ or Java. An old version with really crappy type errors. Schools are often conservative about updating their tech stacks.

* Types are most useful when reading or changing code. New learners are mostly writing new code.

* Writing `Person person = new Person()` seems highly redundant. In the kinds of small programs you are writing as a newbie, you are likely to write a lot of this.

The reasons so far make types seem like overhead: you are having to do more work and getting little in return for doing so. The next two get a bit deeper.

* In the small codebases you'll have as a newbie[0] at disproportionate amount of the codebase is interacting with the outside world. The outside world is untyped. In both typed or dynamic languages, you have to shuttle this untyped data into your language's type system. But when there is a type error in this process, I find it is generally easier to debug in a dynamic language. That makes sense to me: they need to have good workflows for dealing with runtime type errors.

* Classes tend not to teach technique[1]. Students are expected to invent it on their own as they learn programming. As professionals, we often don't teach technique to each other either. If you invent techniques that leverage the strengths of types, then the appeal of types will seem pretty obvious. If you don't you may go years without before you are exposed to these techniques. If you invent techniques where static types get in the way, then you may find static types to be a severe hindrance to getting things done.

[0] I think this also applies a lot of the time when starting a new project.

[1] By technique I mean the steps you do to produce working code. This doesn't just include generating new code, but understanding existing code and debugging code.

Re: PyCon US 2021 Recordings are Available

#65

Post by tome » Sat, Jun 05, 2021, 7:36 AM UTC

neolog wrote: post #56

tiew9Vii wrote: post #29

Earlier quoted context omitted.

The thing with Python types is that they are “type hints” and not true types, hints is the keyword. There’s also two type checker implementations. As they are hints it means you can still pass in wrong values in some situations and what types check on one implementation may not type check with the other implementation. So the types are superficial only in Python. The paper “Python 3 types in the wild” at https://news…

> The thing with Python types is that they are “type hints” and not true types Python has several type checkers, as does Haskell, each with different soundness properties. What makes GHC's type checking more "true" than Mypy's or Pytype's or Pyright's?

Haskell doesn't have "several type checkers". It has several compilers, and if you use a particular compiler then you use its type checker and not the type checker of another compiler.

(There is also Liquid Haskell, but it doesn't check Haskell types, it checks Liquid Haskell types.)

Re: PyCon US 2021 Recordings are Available

#66

Post by revskill » Sat, Jun 05, 2021, 7:40 AM UTC

ivanivanovich wrote: post #38

revskill wrote: post #33

Too many conference recordings without a touch on refactoring the broken mapped function ? Wish i could have a real `array.map` just like in javascript.

why is it broken?

In common sense, u just need to put a function into map, right ?

x.map(fn)

In python, mapped takes some arguments that makes me confused in order and types of arguments.

Secondly, it broke my thinking process.

Re: PyCon US 2021 Recordings are Available

#67

Post by revskill » Sat, Jun 05, 2021, 7:44 AM UTC

rbonvall wrote: post #42

revskill wrote: post #33

Too many conference recordings without a touch on refactoring the broken mapped function ? Wish i could have a real `array.map` just like in javascript.

Is this what you wish? ['10', '10', '10'].map(parseInt) === [10, NaN, 2]

What's your point here ?

Re: PyCon US 2021 Recordings are Available

#68

Post by whymauri » Sat, Jun 05, 2021, 7:45 AM UTC

revskill wrote: post #66

ivanivanovich wrote: post #38

Earlier quoted context omitted.

why is it broken?

In common sense, u just need to put a function into map, right ? x.map(fn) In python, mapped takes some arguments that makes me confused in order and types of arguments. Secondly, it broke my thinking process.

Having a different interface doesn't mean its broken...

Re: PyCon US 2021 Recordings are Available

#69

Post by mananaysiempre » Sat, Jun 05, 2021, 8:08 AM UTC

neolog wrote: post #56

tiew9Vii wrote: post #29

Earlier quoted context omitted.

The thing with Python types is that they are “type hints” and not true types, hints is the keyword. There’s also two type checker implementations. As they are hints it means you can still pass in wrong values in some situations and what types check on one implementation may not type check with the other implementation. So the types are superficial only in Python. The paper “Python 3 types in the wild” at https://news…

> The thing with Python types is that they are “type hints” and not true types Python has several type checkers, as does Haskell, each with different soundness properties. What makes GHC's type checking more "true" than Mypy's or Pytype's or Pyright's?

Every correct Haskell ’98 or Haskell 2010 implementation (not that a lot of them are still alive) accepts exactly the same set of programs, because that set is described in the Report. Every correct Standard ML implementation (of which there are still a few, surprisingly) with extensions turned off accepts exactly the same set of programs, because that set is described in the Definition.

GHC with its innumerable extensions and impenetrable (if well-defined) typing rules is and was always intended to be a testbed for wild type system ideas; that whatever it accepts became the received superset of standard Haskell (of which it is the only implementation) is in my opinion a failure of the Haskell community and the very thing that turned me away from Haskell after several years.

On the other hand, the only real description of what Mypy accepts is the source code of Mypy, and while many interesting programs that fall into that set also happen to be accepted by Pytype or whatever else, it’s not in any useful sense a bug if some are not. There’s also no practical way to tell if an arbitrary program is accepted except to try throwing it into the typechecker, because there is no human-adapted description of what constitutes being accepted.

None of which is to say that Mypy is not useful. It is useful, tremendously so. But as far as maturity of type systems in Haskell or SML goes, it’s not even in the same league. (So that this is not taken as academic elitism, neither are Scala, OCaml, or Typed Racket.)

Re: PyCon US 2021 Recordings are Available

#70

Post by aix1 » Sat, Jun 05, 2021, 8:20 AM UTC

fulafel wrote: post #51

yuy910616 wrote: post #14

After watching this 2018 talk on typing: https://www.youtube.com/watch?v=hWV8t494N88 and this one last year: https://www.youtube.com/watch?v=ST33zDM9vOE&t=68s and finally this one in 2021: https://www.youtube.com/watch?v=Lj_9TyT3V98 I think I'll finally start using type checking - it really seems to just eliminate a whole class of potential bugs; a class that is often not tested at that.

Is this eliminated class of bugs just generally the ones that aren't caught by tests but could be caught by static type annotations, or was there a discussion of the kinds of bugs that had some convincing details?

I think there's considerable overlap between classes of bugs that could be caught by static type checking and those that could be caught by unit tests. That said, I view the two as complementary and use both extensively.

One particularly interesting (though in my experience, rare) class of bugs are typing errors _in unit tests_. For example, an API under test expects one thing and a unit test supplies something else. If the test passes, it's hard to spot the problem without static type checking.