Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An Update on Pytype

github.com

Post reply on HN
Print view View original

61–70 of 70 posts

Re: An Update on Pytype

#61

Post by librasteve »

zem wrote: post #43
librasteve wrote: post #42

Earlier quoted context omitted.

why not just go with a language that has gradual typing built in - eg raku

because there is a ton of existing python code that people find a lot of value in, and that no one wants to abandon. the return on investment for making python better is insanely higher than that on porting hundreds of millions of lines of code to another language.

that’s why raku has modules like

  Inline::Python 
  Inline::Perl5
and strong FFI (Foreign Function Interface) chops

certainly I see the economic sense in continuing with Python, but for some folks there’s a limit to how much lipstick you want on your pig

Re: An Update on Pytype

#62

Post by jpfr »

almostgotcaught wrote: post #32
zem wrote: post #28

ex-pytype dev here - we knew this was coming and it's definitely the right thing to do, but it's still a little sad to see the end of an era. in particular, pytype's ability to do flow-based analysis across function boundaries (type checking calls to unannotated functions by symbolically executing the function body with the types of the call arguments) has not been implemented by any of the other checkers (again for…

> while I agree that bytecode-based analysis has its drawbacks abstract interpretation of the bytecode like y'all were doing is the only way to robustly do type inference in python. > https://github.com/google/pycnite there's also https://github.com/MatthieuDartiailh/bytecode which is a good collection

MOPSA does abstract interpretation for both C and Python. It even works across language boundaries.

https://mopsa.lip6.fr/#features

It also has more abstraction domains than „just“ the type of objects.

Re: An Update on Pytype

#63

Post by marcyb5st »

sito42 wrote: post #25
RS-232 wrote: post #16

Earlier quoted context omitted.

Is ty more mature than pyright or mypy? I'm currently using pyright, but I'm going to migrate once ty and its vscode extension are given the "production ready" greenlight.

at this stage I get very few false positives and it's so much easier to configure and use than pyright

Personal experience: if you use injector[1] with NewType so that you can give your primitive types a meaning and add them to your injection stack it completely fails. For example:

```python

ModelName = NewType("ModelName", str)

# You bind your string within a module: binder.bind(ModelName, to=ModelName(parsed_args.model_name))

# When you need it: model_name = injector.get(ModelName) # Here it fails, saying that you need "concrete" types or something similar

```

So while it is great already it definitely still has many rough edges still. But it is to be expected from alpha releases

[1] https://pypi.org/project/injector/

Re: An Update on Pytype

#64

Post by ivanjermakov »

instig007 wrote: post #31

Scala 3: exists, https://docs.scala-lang.org/scala3/book/scala-features.html Developers: mypy, pyright, pyrefly, ty, pypy, nogil, faster-python, sub-interpreters, free-threading, asyncio, ...

Both python language and its ecosystem are such a mess. Imagine the amount of human hours spent on tooling development trying to fix fundamental flaws in a language design.

Re: An Update on Pytype

#65

Post by numice »

kingkilr wrote: post #53
xenophonf wrote: post #45

Earlier quoted context omitted.

> I have recently jumped onto the "write python tooling in rust" bandwagon I know Go and Rust are the belles du jour, but this kind of thing really hampers integrators' ability to support platforms other than x86-64 and armv8. In my particular case, it results in me being unable to build software that depends on pyca/cryptography on platforms like s390x, which makes me sad. It also makes development environment manag…

(pyca/cryptography dev here) As Steve notes, Rust does support s390x. Even prior to shipping Rust code, we never tested or claimed to support s390x. If there's genuine interest in more people supporting s390x in the open source world, folks will need to do the work to make it possible to build, test, and run CI on it. IBM recently contributed official PPC64le support to pyca/cryptography (by way of Github Actions run…

If you don't mind, how did you get into cryptography development? I have heard many say that don't do this unless you're experienced but I wonder how one becomes more experienced if you don't do it by yourself.

Re: An Update on Pytype

#66

Post by samwgoldman »

denis- wrote: post #34
jolux wrote: post #12

Earlier quoted context omitted.

I believe Pyrefly is stricter, so it may be a better choice for new projects but harder to integrate into existing ones without type-checking.

I have a medium-sized codebase that is all green when running mypy with the strictest configuration possible. Pyrefly spits put around 200 errors for the same codebase. Most errors are related to SQLAlchemy.

(Pyrefly dev here) Thanks for trying it out! If you have any feedback or bug reports, please don't hesitate to file issues on GitHub or find us on Discord. We have some open issues for SQLAlchemy (like [1]). I'm definitely curious to hear if there are any gaps from your perspective, having an already strictly-typed codebase.

1. https://github.com/facebook/pyrefly/issues/954

Re: An Update on Pytype

#67

Post by samwgoldman »

rhaps0dy wrote: post #11
underdeserver wrote: post #3

I think this is for the best. I used Pytype at Google years ago and while it's well written and the team was responsive, ultimately Python is not well suited for type checking Python. It's compute intensive. I think the Ty people at Astral have the correct idea, and hope it'll work out. https://docs.astral.sh/ty/

I've heard of `ty` too but recently I learned about Pyrefly, which is not in pre-production alpha, and is also Rust: https://pyrefly.org/ Is there a good reason to avoid using Pyrefly?

(Pyrefly dev here) As another commenter mentioned, Pyrefly is still in alpha. Sorry we don't make that more clear!

While we are in alpha, and there are plenty of open issues we are still working through, I think Pyrefly is actually pretty usable already, especially for code navigation.

Re: An Update on Pytype

#68

Post by lostmsu »

zem wrote: post #28

ex-pytype dev here - we knew this was coming and it's definitely the right thing to do, but it's still a little sad to see the end of an era. in particular, pytype's ability to do flow-based analysis across function boundaries (type checking calls to unannotated functions by symbolically executing the function body with the types of the call arguments) has not been implemented by any of the other checkers (again for…

I worked on https://github.com/Microsoft/PTVS (not being in MSFT) around 2019 so I know they did type check calls across function boundaries.

Re: An Update on Pytype

#69

Post by zem »

lostmsu wrote: post #68
zem wrote: post #28

ex-pytype dev here - we knew this was coming and it's definitely the right thing to do, but it's still a little sad to see the end of an era. in particular, pytype's ability to do flow-based analysis across function boundaries (type checking calls to unannotated functions by symbolically executing the function body with the types of the call arguments) has not been implemented by any of the other checkers (again for…

I worked on https://github.com/Microsoft/PTVS (not being in MSFT) around 2019 so I know they did type check calls across function boundaries.

neat. did they also do it by symbolically executing the function body?

Re: An Update on Pytype

#70

Post by lostmsu »

zem wrote: post #69
lostmsu wrote: post #68

Earlier quoted context omitted.

I worked on https://github.com/Microsoft/PTVS (not being in MSFT) around 2019 so I know they did type check calls across function boundaries.

neat. did they also do it by symbolically executing the function body?

In a nutshell it would build a dependency graph first using simplified algorithm that only looked at imports. Then it would pick a function, eval types statement by statement (I think that's what you call symbolic execution), and if any named value as result would expand the list of possible types it could have, all the functions that use that value (global var, passed as argument, etc) would be queued for reevaluation. Until either the set of possible types for all values is steady or some reevaluation limit is reached.
Post reply on HN