This is drives home some of the things I really like about scheme. Scheme is built on a few selected primitives and much of the language comes together on top of that.
Since learning that I have started disliking all the things that I just have to accept in other languages. I can accept the c++ variant of "because this and that comes together like this. Because speed", but the pythonesque "because because" drives me insane.
No way. Scheme is hobbyist language at this point.
Simply put difference between a 'hobbyist' and professional language for me is the strength and depth of the packaging ecosystem.
So as soon as you need to do things like open and parse PDF, implement TLS/SSL, create a dashboard,... you will be in trouble pretty quick in scheme. Probably simple stuff like handling unicode would be shaky.
Nope. I am not a programmer, except for that time I got paid to write common lisp. The only thing except that I have done for money is some data processing using python.
Wow. Can't believe a couple of these are in my production. Esp with the mixture of py2 and py3. And people who are not well versed in python are just not aware of these gotchas.
Good repo, I learnt quite a few more... wtfs. :)
I have a strong belief that unless type hints, testing, tooling is leveraged properly, python does not qualify as a good candidate for long term projects. Go handles all of this automatically and I'm having good results with it as an alternative to Python for small to medium scale projects.
Consider not holding strong beliefs without empirical evidence. There are both plenty of long term python projects that have held up, and no strong evidence one way or the other on type safety.
The only evidence I've seen in this respect suggests typing is not the leading cause of bugs in Python. I wish I could find the talk but essentially the guy looked at a load of GitHub issues and analysed the cause and only like 1% or so were type related.
I like putting in types just to help my IDE with autocomplete, though. I have also caught a few errors with mypy that could have caused a crash in very unlikely cases. I'm not convinced it's worth rigourously typing a project. It seems like mostly a nerd snipe because I've noticed there is a satisfaction with getting in right despite not making any difference to the user.
There are both merits and demerits to python. Unfortunately not everyone has the opportunity or the luxury to work with projects that are properly maintained. Even messy python projects in legacy companies hold up but that does not mean quality and maintenance costs are good. My beliefs stem from my experience with the jobs available in my area and country. I'm not the expert on type safety but my understanding from various sources and my own experience is that type safety is superior. Go has been the best candidate as the alternative for the projects I have undertaken. YMMV.
For most of these type hints or static typing do not at all help. I haven’t went through all of them, but in the first quarter or so almost all of them were due to leaky compiler weirdness in CPython.
I haven't tested out the repo with type hints so I can't comment on that. What I did mean to say was outside of this repo, type hints are a huge boon saver. There are enough legacy projects written by non python experts which would benefit from whatever I said above.
One python library WTF I came across recently is the autojunk parameter of the difflib SequenceMatcher class. Despite passing constructing the class with
difflib.SequenceMatcher(isjunk=None, ...
The matcher will start classifying characters as junk once the b parameter is more than 200 characters long. So unless you read the docs carefully, your matcher will start not matching anything longer than a few characters once the input gets longer than a few sentences. The trick is to also set autojunk=False in the constructor.
Its like the original writer of this component wrote the matcher for a specific application (DNA matching?) and left in the heuristic even though it isn't applicable to general use. At some point they added the autojunk parameter to gate this behaviour, but it still defaults to true, to keep backwards compat, and to confuse people.
Python's "int" optimization of pre-allocating objects for values between -5 and 256 can be a great source of fun when writing extensions, too.
Same mechanism, overwriting the value stored in the allocated object; but when the extension is in loose C code which is casting pointers with abandon... things can go wrong.
Honestly, I never understood why Python gained such a good reputation given the scale of its warts and don't get me started on its crippled lambda implementation.
Use it for a while and you'll understand why. It's a joy to use. That is successful despite its warts just goes to show how nice it is compared to other languages.
I had forgotten about the walrus operator. I’m curious what the rationale is for not just allowing the regular assignment operator within expressions for that feature. Would it confuse the interpreter or something?
Depending on what you do on the lhs of = you can actually overwrite this operator.
It could be setattr or setitem instead of bind-to-name. Because you can overwrite = only in certain cases that are defined, by the syntax, you can't easily elevate = to an expression and be done with it.
Readit News
* https://news.ycombinator.com/item?id=31566031 (460 points | May 31, 2022 | 139 comments)
* https://news.ycombinator.com/item?id=26097732 (359 points | Feb 11, 2021 | 162 comments)
* https://news.ycombinator.com/item?id=21862073 (396 points | Dec 23, 2019 | 185 comments)
Since learning that I have started disliking all the things that I just have to accept in other languages. I can accept the c++ variant of "because this and that comes together like this. Because speed", but the pythonesque "because because" drives me insane.
Simply put difference between a 'hobbyist' and professional language for me is the strength and depth of the packaging ecosystem.
So as soon as you need to do things like open and parse PDF, implement TLS/SSL, create a dashboard,... you will be in trouble pretty quick in scheme. Probably simple stuff like handling unicode would be shaky.
Good repo, I learnt quite a few more... wtfs. :)
I have a strong belief that unless type hints, testing, tooling is leveraged properly, python does not qualify as a good candidate for long term projects. Go handles all of this automatically and I'm having good results with it as an alternative to Python for small to medium scale projects.
I like putting in types just to help my IDE with autocomplete, though. I have also caught a few errors with mypy that could have caused a crash in very unlikely cases. I'm not convinced it's worth rigourously typing a project. It seems like mostly a nerd snipe because I've noticed there is a satisfaction with getting in right despite not making any difference to the user.
Its like the original writer of this component wrote the matcher for a specific application (DNA matching?) and left in the heuristic even though it isn't applicable to general use. At some point they added the autojunk parameter to gate this behaviour, but it still defaults to true, to keep backwards compat, and to confuse people.
https://docs.python.org/3/library/difflib.html#difflib.Seque...
Same mechanism, overwriting the value stored in the allocated object; but when the extension is in loose C code which is casting pointers with abandon... things can go wrong.
Deleted Comment
It could be setattr or setitem instead of bind-to-name. Because you can overwrite = only in certain cases that are defined, by the syntax, you can't easily elevate = to an expression and be done with it.