Live data from Hacker News

PyCon US 2021 Recordings are Available

pycon.blogspot.com

71–80 of 107 posts

Re: PyCon US 2021 Recordings are Available

#71
post #56

Earlier quoted context omitted.

> 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 exte…

Sure, I'm just saying that Mypy is a real type checker. The distinction is one of degree, not of kind. Writing a spec for Mypy wouldn't make its types more "true", just as deleting Haskell's spec wouldn't make its types less true types.

Re: PyCon US 2021 Recordings are Available

#72

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…

If you don’t have really flexible type system, strong typing makes certain things complicated.

Think for example a library like Pandas. Building something like that with a not-very-flexible type system would result in much more cumbersome user experience. In many cases you would likely feel the types just getting on your way while working interactively.

Microsoft has done great things with C# on this frontier, but it has also taken many years and probably a lot of brainpower.

Re: PyCon US 2021 Recordings are Available

#73
post #61
post #57

Earlier quoted context omitted.

> 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 statica…

> The checking of the type happens at runtime.

Mypy checks the type before runtime, just like GHC does.

Python also checks during runtime, but Haskell doesn't have that feature. Right?

> This is major reason why languages like Python are so much slower than statically typed languages.

Julia's dynamic typing, and hence its ability to do specialization using runtime information, is part of why it can (sometimes) beat Fortran in numerical performance.

Re: PyCon US 2021 Recordings are Available

#74

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.

I've never had problems that strong typing would have prevented and see no use for them in languages that originally didn't provide them. They add noise to the code and require more effort in reading around them.

Re: PyCon US 2021 Recordings are Available

#75
For those that care about performance while using Python,

"From 3 to 300 fps: NES Emulation in Python and Cython"

https://www.youtube.com/watch?v=3of9pY2vovA

"Restarting Pyjion, a general purpose JIT for Python- is it worth it?"

https://www.youtube.com/watch?v=YFeUUdKBrJ8

"Python Performance at Scale - Making Python Faster at Instagram"

https://www.youtube.com/watch?v=xGY45EmhwrE

and for some hardware fun,

"More Fun With Hardware and CircuitPython - IoT, Wearables, and more!"

https://www.youtube.com/watch?v=GnteZjiHVdA

Re: PyCon US 2021 Recordings are Available

#76

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…

It's horrible and I wish I'd kept programming as a hobby. The continual 'evolution' is ridiculous, as we build and rebuild the same things with newer tools. Often project management is more important than building things and build tools became an obsession as more layers started to come between writing code and seeing results. Agile, TDD, Testing, Design Patterns are all topics that muddied the waters. And with people on both sides of the fence with these practices, it gets very tiring and you just want to find refuge outside of it all. A place where the tools don't change each year and a half, or where the best practices can easily be agreed upon.

Yes, it gets old and I can't wait to retire.

Re: PyCon US 2021 Recordings are Available

#77
post #65
post #56

Earlier quoted context omitted.

> 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.)

Could you explain the significance of the distinction you're making?

Re: PyCon US 2021 Recordings are Available

#78
post #77
post #65

Earlier quoted context omitted.

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.)

Could you explain the significance of the distinction you're making?

You first!

Re: PyCon US 2021 Recordings are Available

#79

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.

I started a new project in Python in late 2019. Coming from a C++/Java background I elected from the start to use type checking and data classes heavily.

The project has now scaled to multiple developers and many thousands of lines of code. If I compare my experiences this time around with past experiences in Python, I feel those early choices are paying big dividends in terms of code readability and correctness.

In particular:

The ergonomics of data classes is great (IMO). They avoid a lot of boiler plate, integrate well with type checking and auto completion, and provide clear context to anyone reading the code.

I’ve found Mypy a bit flaky (sometimes it misses errors it seemingly should catch) and some things that cannot be expressed in the type system to be pain points but overall having type annotations present and enforced helps document code, works well with IDE auto completion, and occasionally picks up errors that would have been otherwise missed.

In particular I’ve found it’s picked up a lot of errors around missing None checks (nullability). These seem to be particularly easy to miss in unit tests.

I’ve also found that PyCharm’s built in code code checking has often been able to pick up and highlight problems which it would have otherwise missed thanks to having type annotations. Having early feedback on problems is nice productivity boost.

One hint if you do use Mypy make sure to enable check-untuned-defs. You’ll get much better coverage.

Re: PyCon US 2021 Recordings are Available

#80
post #11

What's the TL;DWWWW? (Too Long; Didn't Waste a Whole Week Watching)

I watched several talks on 2x speed. It's not comfortable, but some speakers speak so slow, that 2x sounds almost normal, also, I can skip that way long introductions and slow down where the interesting part starts.
Post reply on HN