171–180 of 181 posts
menuFont = wx.Font(12, wx.DEFAULT, wx.NORMAL, wx.NORMAL) # 12pt font
Will be flagged as an error by ty, wx.DEFAULT and wx.NORMAL being some kind of wxPython place holder that wxPython can interpret into a value later on, not a value just yet. Can you get past that kind of late binding?
Python programmers are crying out for types it seems. It’s a shame the Python foundation haven’t blessed a spec. Better to get everyone working on a single slightly imperfect standard than a morass or differing ideas.
Speaking as a Python programmer, no. Using types in a prototyping language is madness. The point is you drop things such as types to enable rapid iteration which enables you to converge to the unknownable business requirements faster. If you want slow development with types, why not Java?
Serious question, Do we need another type checker in Python? I've never really felt the existing options were lacking for our use case. Completely fair game if this was just a passion project, but at this point at best this feels like noise, at worst some overzealous developer is going to implement this in my teams pipeline and waste time. Waste his time because the existing type checker did the job and there was not…
If it was going from 3s -> 1s then you'd probably be right, but on my work codebase pyright (which is the faster one!) takes 15 seconds (ty takes 0.8s) and takes a bit for errors to appear in the IDE. This is now fast enough for us (mypy was taking >30s, which was not fast enough), but if the project grew another order of magnitude (which it might) then it would probably be too slow.
It's the same reason ruff is great, linting the codebase is so so fast.
Earlier quoted context omitted.
The guy behind Zuban should've put his project out the in open way earlier. I'd love to see both projects succeed, but in reality it should become one.
Zuban maybe doesn't succeed in terms of the amount of users, but it's nearly finished, supports the full Python type system (I'm in the process of completing the conformance tests), has support for Django and LSP support is also pretty much complete. So in a technical way it did already succeed. It might not be used as much, but to be honest I think that's fine. I'm not a big VC-funded company and just hope to be abl…
How conformant is this, compared to e.g. mypy?
https://htmlpreview.github.io/?https://github.com/SimonSchic...
Earlier quoted context omitted.
You're not wrong, but a) most of the badness happened after the founders checked out and b) it's hard to find examples of developer tool companies doing better.
You however, are. Hashimoto didn't leave until December 2023, Hashicorp announced the license change August 10, 2023. Also way back in September 2021 they started having staffing issues and stopped accepting community contributions, and also made the questionable choice of going public that same year. You might be on to something with point B, hard to find good examples of developer tool companies that don't eventual…
https://www.hashicorp.com/en/blog/mitchell-s-new-role-at-has...
So I've decided to give it a try. Open installation instructions and went thru "easy install with uvx" / "get and run our sgell script" until get "pip install ty". I do not want use other tools so I started it in pet project directory as "ty check". Is shows me progressbar and "98/99 files" then hang. I restarted it and it hung on "68/99" and started using 100% of cpu core. I waited for 15 min and killed it. Try to g…
(And as an aside, there _is_ a verbose mode: if you add `-vv` you'll get DEBUG-level log messages printing out the name of each file as we start to check it, and you can set TY_MAX_PARALLELISM=1 in your env to make it very clear which file is causing the hang. That's how we debug these kinds of issues when they're reported to us.)
[1] https://github.com/astral-sh/ty/issues/1968
Earlier quoted context omitted.
Zuban maybe doesn't succeed in terms of the amount of users, but it's nearly finished, supports the full Python type system (I'm in the process of completing the conformance tests), has support for Django and LSP support is also pretty much complete. So in a technical way it did already succeed. It might not be used as much, but to be honest I think that's fine. I'm not a big VC-funded company and just hope to be abl…
Zuban continues to have "not great" diagnostics like the rest of the python type checkers, where ty has "rust inspired" diagnostics that are extremely helpful. It's a shame to hear that the current state is considered "nearly finished".
Earlier quoted context omitted.
Speaking as a Python programmer, no. Using types in a prototyping language is madness. The point is you drop things such as types to enable rapid iteration which enables you to converge to the unknownable business requirements faster. If you want slow development with types, why not Java?
because i want fast development with types.
This goes all the way back to Lisp vs C in the 1980s with C programs having triple the development time as Lisp programs.
To modern day with Turborepo taking 3 months to write in structually typed Go vs 14 months in statically typed Rust.
Earlier quoted context omitted.
Speaking as a Python programmer, no. Using types in a prototyping language is madness. The point is you drop things such as types to enable rapid iteration which enables you to converge to the unknownable business requirements faster. If you want slow development with types, why not Java?
If you can’t do fast prototypes with types, you need to get better at using types. It’s very fast to throw stuff together in TypeScript.
Having worked in both dynamically typed and statically typed software development shops, the statically typed programmers are considerably slower in general. Usually they only have 1/3 of the output as programmers who use dynamically typing. Statically typed programmers also tend to be much less ambitious in their projects in general.
They still think they are "fast programmers" but it's complete fiction.