PyCon US 2021 Recordings are Available • Hacker News Board

Re: PyCon US 2021 Recordings are Available

#81

Post by [deleted] » Sat, Jun 05, 2021, 10:38 AM UTC

Mehdi2277 wrote: post #36

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…

You can have strict lint checks enforced with pre-commit hooks/ci checks. My current team I've been adding type checker tests (mypy + pyright) and for now as we're missing types I have type checkers on a nice rule of any prs you make must decrease the number of type errors (by 5, but up to you how harsh you want to be) in master to be merged forcing people to add more types. Once the type hints eventually hit 0 on ou…

[deleted]

Re: PyCon US 2021 Recordings are Available

#82

Post by MillenialMan » Sat, Jun 05, 2021, 10:41 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?

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

Re: PyCon US 2021 Recordings are Available

#83

Post by ptx » Sat, Jun 05, 2021, 10:43 AM UTC

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.

Scheme, which was an inspiration for JavaScript, works the same way Python does in this case. See page 57 of the spec: http://dspace.mit.edu/bitstream/handle/1721.1/5600/AIM-848.p...

That was written in 1985. If you're thinking of this as a mistake and waiting for it to be corrected, you're going to be waiting a long time.

Edit: Although it would be awesome if Python had extension functions like Kotlin, which would make this super easy to fix (either in your own code or the standard library). But that would require static typing to be more baked into the core language.

Re: PyCon US 2021 Recordings are Available

#84

Post by [deleted] » Sat, Jun 05, 2021, 10:48 AM UTC

neolog wrote: post #73

takeda wrote: 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…

[deleted]

Re: PyCon US 2021 Recordings are Available

#85

Post by kzrdude » Sat, Jun 05, 2021, 10:54 AM UTC

pjmlp wrote: post #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…

Pyjion has some excellent documentation that makes the whole thing seem approachable/introspectable. (See the talk.)

See optimizations breakdown here https://pyjion.readthedocs.io/en/latest/optimizations.html

Re: PyCon US 2021 Recordings are Available

#86

Post by kzrdude » Sat, Jun 05, 2021, 10:56 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.

Inline code completion/IDE integration can have it show the parameter names or docstring inline in the editor. That helps me with map, specifically. :)

With that configured, a window pops up in Vim and says we have:

    map(func: Callable[[_T1], _S], iter1: Iterable[_T1], /) -> Iterator[_S]                                               
     ——————————————————————————————————————————————————————————————————————————————                                        
    map(func, *iterables) --> map object                                                                                  
                                                                                                                          
    Make an iterator that computes the function using arguments from                                                      
    each of the iterables.  Stops when the shortest iterable is exhausted.                                                
                                                                                                                          
    ——————————————————————————————————————————————————————————————————————————————

There are things to criticize here. Note that the type hinting (this is Python 3.8 btw) doesn't agree with the full generality of the stated function interface (the multiple iterables part).

Re: PyCon US 2021 Recordings are Available

#87

Post by BiteCode_dev » Sat, Jun 05, 2021, 11:54 AM UTC

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.

Above all, it's much more usable now, especially with 3.10 around the corner:

- you can use list[] instead of typing.List[]. Same for dicts or sets.

- you will be able to use bool | str instead of typing.Union[bool, str]

- mypy has saner default, is better supported by IDE and is way faster

- a lot of edge cases are now covered, including protocols for duck typing, vartype, etc.

- fantastic libs such as pydantic, fastapi and typer make using them a ton of fun

Re: PyCon US 2021 Recordings are Available

#88

Post by rajasimon » Sat, Jun 05, 2021, 12:09 PM UTC

memco wrote: 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?

Re: PyCon US 2021 Recordings are Available

#89

Post by goodoldneon » Sat, Jun 05, 2021, 12:38 PM UTC

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.

We added mypy last year and it’s been a huge benefit. It catches a lot of bugs and makes onboarding easier.

However, mypy is woefully limited when compared to TypeScript. Granted, TypeScript is maintained by a trillion dollar company while mypy is a community project.

Re: PyCon US 2021 Recordings are Available

#90

Post by acdha » Sat, Jun 05, 2021, 12:45 PM UTC

Mehdi2277 wrote: post #54

acdha wrote: post #26

Earlier quoted context omitted.

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

Yes, I use pydantic for that and it’s quite helpful - one of my favorite libraries in recent years. I do think your last point is key: this seems to be a community maturity point because a fair fraction of people will bounce off of a bad first experience and say it’s not worth the cost.