Live data from Hacker News

PyCon US 2021 Recordings are Available

pycon.blogspot.com

51–60 of 107 posts

Re: PyCon US 2021 Recordings are Available

#51

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?

Re: PyCon US 2021 Recordings are Available

#52

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…

I don't think it's cumbersome. After doing stuff long enough you get to the point when you realize you can't know everything, you are not perfect, and more importantly, NO ONE IS.

Also if you go back and read the software engineering conferences proceedings from 1968 and 1969, David Parnas' classic 1970s papers, and other instances of this foundational material, you realise that except that we have faster computers, higher-level languages, and version control, software engineering really hasn't changed since then.

We're still struggling with team organisation, verifying features with users before building them, choosing proper abstractions, testing for reliability and understanding, resource management, documentation, modeling the domain clearly, prototyping the right way, and so on.

All the actually difficult things today are just the same as they were 40--50 years ago.

While on the surface things look like they move quickly, what makes one a good software engineer is the same as it's always been.

Good software engineering is not about today's favourite technology. It's about building things that work and which people actually need. That is a hard-earned skill and you don't get it by chasing shiny things.

Re: PyCon US 2021 Recordings are Available

#53

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.

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…

> There’s also two type checker implementations.

Four: Mypy, Pyre, Pyright and Pytype.

Re: PyCon US 2021 Recordings are Available

#54
post #26

Earlier quoted context omitted.

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…

A lot of it depends on the work you do, and what other kinds of tools you use. If you’re working with simpler code and use something like flake8 or have a reasonably fast test cycle, you can be pretty productive either way. If you work with harder-to-type data structures (e.g. nested JSON or XML), you’ll see less wins from typing then validation (this is why Django apps tend to have fewer issues this way because the…

One of the pycon type talks was about type checking json. TypedDict or pydantic can both be used to deal with that fairly well now. For a complex json sure the type might be long but write it once and used the typeddict name after that. It feels similar to needing to write protobut def/thrift def. Some of the json I even work with is given a spec with protobuf and loaded that way which gives you type support. protobuf can generate python type stubs with mypy-protobuf. One practical annoyance is many libraries that use protobuf generated code don't currently include type stubs with them. I currently just make the stubs myself, but that is something most people would probably get stuck on and just needs more libraries to update the build scripts to include them in wheels.

XML could have a similar approach although I'm not sure if anyone has done it already.

Second talk (30 minute mark) of this video, https://www.youtube.com/watch?v=ld9rwCvGdhc

Re: PyCon US 2021 Recordings are Available

#55
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.

This sounds like something that "increases engagement metrics" ...

Re: PyCon US 2021 Recordings are Available

#56

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.

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?

Re: PyCon US 2021 Recordings are Available

#57
post #34

Earlier quoted context omitted.

> 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. Could you elaborate. When can you pass in wrong values? The type checkers aren't always precisely the same (some do inference, mypy doesn't), but the cases where they disagree are usually because one…

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.

Re: PyCon US 2021 Recordings are Available

#59

Earlier quoted context omitted.

That might be where it usually comes from, but that hasn't been my experience. My Python subcommunity groupthink was against type annotations for years, despite the groupthink also saying that statically typed are better all things equal and most of the loudest folks having worked for some FAANG company. Thinking that typing is good and buying that a pasted-on-after-the-fact typing system is good are different matter…

In my experience, it was quite jarring to see a python function with a bunch of : -> Union[int,str], Optional, Any, etc. Change is always hard.

I actually don't understand Optional in that mix. "Optional" basically means the value can be "None". You typically use it like this "Optional[str]" which means the value is a string or "None".

Re: PyCon US 2021 Recordings are Available

#60

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 doesn't really matter what you pick to be good at or care about, something current (but not bleeding edge), and then dabble in a bunch of other current technologies and tools.

In general, don't worry about things like project management. Every company bastardizes any written practice, and every company is very different. Just do what your employer does, and then if you find a new employer, do what they do. Maybe have some opinions and reflect on what you liked and didn't like, because employers might pretend to care what you think about processes and improvements, but it's really all just buzzword nonsense. Regardless of what you pretend, it's all going to go how it's going to go.

r.e. "metas" - Play around with stuff. Spend some time reading about TDD, maybe give it a shot every now and then. Understand why it's good and understand why it's bad. Stay away from "never"s and "always"s.

As I write this, I realize you're already doing half of what I'm suggesting, which is just to pay attention to the industry and the comings and goings of tech/tools. The other half is to learn and get interested in various pieces of tech. If it feels "cumbersome", it might just not be the right career path for you. That's totally okay - the work you're doing now is totally fine! Do what you like. Don't force stuff you don't like. Most of the successful programmers I know think that toying with a new language or tool is fun/interesting. It doesn't feel cumbersome because it's both a job and a hobby.

Post reply on HN