Live data from Hacker News

PyCon US 2021 Recordings are Available

pycon.blogspot.com

91–100 of 107 posts

Re: PyCon US 2021 Recordings are Available

#91
post #56

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?

pythons type system, just like typescripts, is completely unsound. Haskell is also unsound because of unsafeCoerce. But that makes it very clear that what you are doing is unsafe. In python you very often write unsound code that passes the type checker. This means you cannot trust the type checker to catch type errors.

Re: PyCon US 2021 Recordings are Available

#93
post #63

Earlier quoted context omitted.

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

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

Respectfully, you're absolutely right, but at many many employers dev's opinions on project management doesn't matter and is totally ignored. That's why I say don't worry about it. The devs I've been around that get upset and dogmatic about project management principles just get burnt out faster because employers don't care/won't change. "Don't care" didn't mean "Don't know about", but moreso "Don't get worked up about" or "Don't be strongly opinionated". Of all the hills that exist in software to die on, project management is pretty much the worst one.

Re: PyCon US 2021 Recordings are Available

#94
post #71

Earlier quoted context omitted.

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.

Still not necessarily true.

The academic usage holds that the distinction between the true type systems and the pretenders is that the first are sound: a well-typed program either evaluates to a normal form (value) or fails to terminate, but can never get stuck (segfault, terminate with an uncaught exception, however your environment implements that).

Of course, a gradual system like Mypy can never both be sound in this sense and remain gradual (which is a major selling point for Mypy), so for them the rule is usually amended with “provided the program is fully annotated” (and it should be obvious whether any given program is fully annotated or not, otherwise the system is just user-hostile regardless of how sound it is; at the very least it must be decidable). That is still obviously not satisfied for Mypy, because it doesn’t track exceptions (and including uncaught exceptions in normal forms would be useless because then no Python programs would ever get stuck). The actual guarantee Mypy is supposed to provide sounds kind of wimpy, like “never gets a TypeError that is not explicitly raised in user code”, but would still be useful regardless... Except that soundness is usually a pretty non-trivial theorem, and the lack of a readable specification for Mypy’s type system precludes it from being proven.

While well-typed Haskell (or SML) programs can in fact crash from the user’s perspective, the possible sources of crashes are rare and avoidable enough (for Haskell, only non-exhaustive patterns and explicit use of undefined, error, or throw) that you can call them additional normal forms without making the whole thing trivial. Every other way an untyped program could get stuck is disallowed by the type system, and there is a proof (SML) or at least a proof sketch (Haskell) of that (although of course not every untyped program that can’t get stuck is allowed by the type system, that is impossible by Turing—Gödel). Even the horrendously complicated systems that GHC implements nowadays still have papers that prove their soundness for a good enough toy example that one walks away convinced that the real thing works just as well.

So yes, there is a sense in which Mypy’s system is less “true” than SML’s or Haskell’s, and it is directly caused by (though not completely reducible to) the lack of a complete human-readable spec for both Mypy and Python itself. (I love Python to bits, but its object model is surreal and its only complete description is Objects/object.c together with Objects/typeobject.c.) If a wizard waved his wand and made every copy of the Haskell Report disappear, its type system would technically remain sound, but illegibly so to human mathematicians, thus it would in fact become less “true” in this sense than previously. Multiple implementations help, but I expect that without a prose spec it wouldn’t be easy to tell that GHC, UHC and Hugs implement the same system, the same way I have no idea if Mypy and Pytype do.

Re: PyCon US 2021 Recordings are Available

#95
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?

Python types are unprovable, since the type of a variable can change at runtime. It's the Halting problem. All you can do is enforce types on static function boundaries - but that doesn't prove you won't send a different type through the boundary at runtime. GHC types are mathematically provable. Types are guaranteed to stay within your defnitions, so you can analyze the type graph without ever having to run the prog…

> since the type of a variable can change at runtime.

Can you give an example of that? Mypy catches this:

    def addsome(val: int) -> int:
        val += 1.1 #  tmp.py:2: error: Incompatible types in assignment (expression has type "float", variable has type "int")
        return val

I'm sure there are cases where it doesn't notice, but afaik those are considered bugs. Doesn't Haskell have bugs?

Re: PyCon US 2021 Recordings are Available

#96
post #73
post #61

Earlier quoted context omitted.

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

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

I don't know Haskell so can't answer that, but typically a statically typed language doesn't need that.

Sometimes languages still provide runtime check, typically happens when their type system is lacking. For example in Go, if you use interface{} type, the type checking happens at runtime. That's why it is discouraged to use, because could be reason that slows down your code.

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

I'm also not familiar with Julia, but from what I read is that for numerical types, Julia uses native types instead of using objects like Python.

It looks like well written Julia code can enable the interpreter to infer types and then JIT can use that to optimize the code. Python doesn't have that functionality at least not yet.

Re: PyCon US 2021 Recordings are Available

#97
post #71

Earlier quoted context omitted.

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.

Still not necessarily true. The academic usage holds that the distinction between the true type systems and the pretenders is that the first are sound : a well-typed program either evaluates to a normal form (value) or fails to terminate, but can never get stuck (segfault, terminate with an uncaught exception, however your environment implements that). Of course, a gradual system like Mypy can never both be sound in…

Thanks, that makes sense to me.

It's hard to find people who are knowledgeable enough about both static and dynamic systems and able to explain in layman's terms. Is there somewhere (online?) I can go to talk with people like you?

Re: PyCon US 2021 Recordings are Available

#98
post #31

Been waiting for these! There's a lightning talk from day 1 about the new Flask that explained some of the performance improvements, which actually answers a question I've had since its release. Also really enjoyed the talk on the new profiler Scalene, I would love to try it out ASAP. Looking forward to the rest.

where is that lightning talk link?

Phil Jones - What’s new in Flask (starts at 44:48): https://youtu.be/5zEn3Jta2Dg?t=2688

Re: PyCon US 2021 Recordings are Available

#99

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…

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

That makes a lot of sense. And I think the lack of teaching technique has to do with the broad variety of programming tasks. Techiques are way too specific to the domain and we won’t see more of it in school until «computer science» is split into more and more fine grained studies or get a bigger part of existing studies like math is now. e.g now I feel embedded, backend and frontend are distinct «directions». In the future I expect it to be further branched into for example finance, healthcare, chemical processing, public infrastructure. This is gradually happening all the time though and «true» computer engineering will always exist, but I think it will be more and more niche just like embedded and OS level programming is more niche now but was the only option before. Anyway I think types are key to making programming safe enough to bring it to this kind of broader workforce (in some distant future, with good IDE support).

Re: PyCon US 2021 Recordings are Available

#100
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…

I can absolutely see that there are many cases where the code is not run many times or the dataset is dirty and that types actually get in the way. As a example, I cannot stand using stuff like VSCode with lsp because it is unbearably slow for both linting and code completion. I feel pycharm is faster (actual typing is slow, but code completion makes me rarely type more than 3 characters before completing which makes it feel faster). I’m mentioning this because I would never dream of typing out a data structure, which is probably because my work is so different from an analysis job. For me code for data structures should be either generated or be simple enough to type out in a few minutes and there should be as few as possible of them. In sharp contrast to data engineering type of work where data just is dirty because it is so much of it from everywhere. Anyway, in both cases I dont want to type a full variable name without some completion, ever, much less 100 times which it seems some people are completely fine with. I’m showing my inexperience with python here, but I would love if there existed something like the F# type providers so I do not have to type so damn much:D
Post reply on HN