101–110 of 118 posts
As with package managers, there seem to be half a dozen different, competing type checkers for Python now...
Yeah and even worse they disagree about type errors! We really need a modern Python alternative. I don't know of any that don't give up the REPL / single file script features which are pretty huge advantages of Python to be honest.
Earlier quoted context omitted.
How is it nothing like Python? 1-based indexing is definitely not a flaw. And version 1.6 massively decreased package import and precompilation time.
> 1-based indexing is definitely not a flaw. It really is. We've known it for literally decades: https://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/E...
My own preference is random indexing, it's so much more exciting to be surprised https://www.juliabloggers.com/random-based-indexing-for-arra...
Earlier quoted context omitted.
It's starting to look like the huge embarrassment that is python packaging and environment management. I work with the language every day, and I still have no idea what am I supposed to use between conda, pip, setuptools/setup.py, pyproject, meta.yml, poetry, pipenv, etc... Conda is so slow that I sometimes wonder if we are being trolled by some cruel God of programming. Pip is faster, but version resolution is iffy.…
Just use setup.py and __version__, ignore fashion until a winner emerges. Hasn’t failed me in ~twenty years.
Earlier quoted context omitted.
The org I'm in regularly publishes peer reviewed papers on engineering productivity (including on this particular subject!). It's far less anecdotal than a random talk by a random dude.
Could you kindly link to one of those papers?
I've also written about this publicly before, e.g. https://mail.python.org/archives/list/typing-sig@python.org/..., where I found a number of errors by tweaking pytype in a way to make it stronger. It's difficult to quantify what percentage of bugs would have been found anyway, but pretty much any time the type systems I work with improve, it uncovers new bugs.
Anyone considering using type hints should listen to this talk: https://www.infoq.com/presentations/dynamic-static-typing/ I personally think it's mostly a waste of time to do type hinting for the purpose of catching errors in a strongly typed language like Python. Type errors just aren't practically a problem in dynamic languages. Doing types for performance is a great reason to do it, though.
I agree with you that the benefits of static typing are sometimes greatly exaggerated. But I also think that using type hints and type checkers in Python isn't quite the same thing as static typing. For starters, type checking can't actually guarantee you won't have type errors at run time. Because, unlike in a statically typed language, in Python, anyone can always choose to just not use type hinting. Whenever that…
Earlier quoted context omitted.
Just use setup.py and __version__, ignore fashion until a winner emerges. Hasn’t failed me in ~twenty years.
This doesn't allow you to create conda packages, so you have to install things via pip. This can then cause headaches as you now have two mechanisms by which package versions are managed. Or you give up conda entirely and the scientific python ecosystem that comes with it.
Earlier quoted context omitted.
I've been on teams at multiple companies that have used type annotations for Python. Developers have generally loved adopting type annotations because it (1) makes the code easier to understand (2) makes the code easier to refactor (3) improves integration with IDEs and (4) catches real bugs. I disagree that type errors "aren't practically a problem". NoneType errors and AttributeErrors turn up all the time in Python…
Clearly didn't watch the talk then. He found that about 1-2% of errors in real world projects were type-related errors.
I'm not a fan of this kind of methodology, because there are so many different use cases for github issue tracker (including feature requests, documentation requests, etc.) that I think the denominator here is overestimated. I'd rather have a study that looked at 1000 issues in depth with a rigorous rubric than one that grepped through millions of issues.
Also, looking only at the issues doesn't count the ones that were caught in development or testing. I like the notion of "moving your bugs to the left"[1] and would much rather find these type errors at build time than later.
Finally as I said in my other comment, avoiding type errors is not the only benefit of type checking. Making code easier to understand and refactor (including programmatic refactoring) are other benefits that are not captured only by counting bugs.
Earlier quoted context omitted.
I agree with you that the benefits of static typing are sometimes greatly exaggerated. But I also think that using type hints and type checkers in Python isn't quite the same thing as static typing. For starters, type checking can't actually guarantee you won't have type errors at run time. Because, unlike in a statically typed language, in Python, anyone can always choose to just not use type hinting. Whenever that…
I don't like the term "type hints" because typecheckers like mypy are genuinely proving type correctness. Yes, if you don't annotate part of your program then you can get a type error in that part of the program, likewise, if you pass a value of the wrong type, you can get a type error. But if you are using a typechecker, you are guaranteed that if your inputs are well-typed, then you won't have a type error, which i…
Typecheckers like mypy are (1) optional, and (2) are only as good as the type hints themselves. Unlike with a language that's actually statically typed, the relation of the type annotations to the actual types of the data operates largely on the honor system, so the type checking is more a validation of internal consistency than full-on static type safety. Which is fine, and well within Python's "We're all adults here" ethos. It's just that it's still not anywhere near the level of rigor you get out of the type checker in a language like OCaml.
Earlier quoted context omitted.
GNU Guile is a weird Lisp variant. Nobody is switching from Python to that; be realistic. I do agree in some applications like data science / machine learning you could never get people to switch from Python because everyone uses it. But Python is also used for loads of other things, e.g. hacky build systems, web scraping, etc. that could easily switch.
It is actually more precisely a Scheme dialect. I used Racket for some time and then moved to Guile. I do not find it weird, having used other lispy languages before. Guile has many useful tools, like OS level threads and also a fibers library, community projects, a good manual, albeit sometimes lacking a few examples, an active community and mailing list and more. Since it is a Scheme, it adheres to a Scheme standar…
That's what's weird.