Comment by zem

Comment by zem 4 days ago

18 replies

View on Hacker News

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 good reasons; it's a performance hit and the world is moving towards annotations over pure inference anyway, but I still think it's a nice feature to have and makes for more powerful checking).

as an aside, while I agree that bytecode-based analysis has its drawbacks, I think it's a tool worth having in the overall python toolbox. I spun off pycnite from pytype in the hope that anyone else who wanted to experiment with it would have an easier time getting started - https://github.com/google/pycnite

I have recently jumped onto the "write python tooling in rust" bandwagon and might look into a rust reimplementation of pycnite at some point, because I still feel that bytecode analysis lets you reuse a lot of work the compiler has already done for you.

almostgotcaught 4 days ago

> 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

Reply View 2 replies
  • jpfr 3 days ago

    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.

    Reply View 0 replies
  • zem 4 days ago

    yeah, that's a really nice project too!

    Reply View 0 replies
xenophonf 4 days ago

> 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 management, including CI/CD pipeline maintenance, that much more complicated. It was already bad enough when I was trying to compile binary distributions on Windows, and that was just with the Visual C++ toolchain mess that is the Microsoft development experience.

Reply View 8 replies
  • kingkilr 4 days ago

    (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 runners so we could test and build in CI), and they've been responsive on weird platform issues we've hit (e.g., absl not support ppc64le on musl: https://github.com/pyca/infra/pull/710#issuecomment-31789057...). That level of commitment is what's really required to make a platform practical, treating "well, it's in C and every platform has a C compiler" as the sum total of support wasn't realistic.

    Reply View 1 reply
    • numice 3 days ago

      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.

      Reply View 0 replies
  • JoshTriplett 4 days ago

    Note that Python, in 2022, adopted a "target tier policy" based on the one I wrote for Rust in 2019. (See https://peps.python.org/pep-0011/ , history at https://peps.python.org/pep-0011/#discussions ; original Rust version at https://doc.rust-lang.org/nightly/rustc/target-tier-policy.h... .)

    It's important for projects to distinguish between "this might or might not work but it's nobody's job to support it" versus "people depend on this and will keep it working", so that people don't build on the former and think it's the latter. The latter requires active support and widespread user/developer interest, as well as comparable support from the upstream projects you build on (something shouldn't be tier 1 for you if it's tier 3 for one of your critical dependencies).

    See https://news.ycombinator.com/item?id=43673439 for a comment from last time this came up.

    s390x is currently supported by Rust, at tier 2, including host tools: https://doc.rust-lang.org/nightly/rustc/platform-support/s39... .

    Reply View 0 replies
  • endgame 4 days ago

    On top of all this, pretty much everything depends on Python (even glibc's build system depends on it now), and Rust is relatively hard to bootstrap. So bootstrapping a usable Python on glibc could one day involve bootstrapping all the way up to Rust on musl (including e.g. llvm) just to get Python just to build the final system's libc.

    That doesn't feel great to me.

    Reply View 1 reply
    • zem 4 days ago

      please note that I am not talking about introducing rust into the python interpreter (where, I agree, bootstrapping concerns would make the gain in code maintainability not really worth it), but in writing developer tools that work with python in rust or a mix of rust and python rather than in pure python. these are tools that run on the developer's machine or on test/ci servers, not in the target environment.

      Reply View 0 replies
  • zem 4 days ago

    I can sympathise with that, but to argue a bit for the other side, these tools are mainly intended to run on the developer's machine or in the CI pipeline. in both cases they overwhelmingly use architectures that rust supports, and in the case of CI surely it's easier to deploy a single rust binary than a python binary and all its library dependencies.

    I used to be very much in the "write your language tools in the language and the community will contribute" camp, but astral has really shown what a big difference pure speed can make, and I now have more of a "write tools in rust and ideally make sure they also expose libraries that you can call from python" mindset.

    Reply View 0 replies
  • pjmlp 3 days ago

    Visual C++ toolchain is rather easy to install, the issue is briging other OS expectations to Windows, likewise the other way around.

    However I fully agree with you, the tooling for a given language should be written in the language itself, and it is an ecosystem failure when it doesn't happen.

    I also feel that this trend, as usual, is people building their portfolio in the current trendy languages.

    Reply View 0 replies
lostmsu 3 days ago

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.

Reply View 2 replies
  • zem 2 days ago

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

    Reply View 1 reply
    • lostmsu 2 days ago

      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.

      Reply View 0 replies
librasteve 4 days ago

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

Reply View 2 replies
  • zem 4 days ago

    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.

    Reply View 1 reply
    • librasteve 3 days ago

      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

      Reply View 0 replies