321–330 of 355 posts
Earlier quoted context omitted.
And yet Python is eating the world: http://pypl.github.io/PYPL.html Not that I'm implying that 'popularity' is a good measure of anything.
Then what are you implying?
Earlier quoted context omitted.
Well, first thing is that most new code in scientific research is developed in PhD projects which last some three or maybe four years. The people who develop this do not have resources and time to maintain this code. Projects don't have a budget for that. There are projects which are very long-running (think CERN or ESO's VLT) but even there the true duration of the code usage is seldomly planned (AFAIK, ESO VLT has…
"ESO VLT has just started to transition from Tk/Tcl to Python" - they might regret this, new Tcl releases tend to take backward compatibility much more seriously than Python :-)
Earlier quoted context omitted.
Agree totally. I had to climb the painful learning curve of psql because none of the front ends worked the way I wanted for some reason or another. Of course, having learned psql, I'm now scathing of anyone wanting a front end... hmm... maybe that's why ;)
I was actually thinking about the lack of SQL alternatives using the postgres engine; for example, why is datalog not simply available as an extension? Or MySQL syntax? PG implements a wide array of alternatives to PL/pgSQL (including standard programming languages eg python), but for whatever reason these SQL-alts never seem to consider being layered on top of the postgres engine. However, the lack of GUI frontends…
Earlier quoted context omitted.
I’ve seen a lot of people taking issue with the self argument. Am I crazy to actually love it as a feature? I pulled out a lot of my hairs when I first started OOP (Java) trying to gork `this`, and I remember myself thinking “why didn’t everybody just do this” when I saw how Python declare methods. And I still think that’s a good idea now. So much easier to keep my sanity than using JavaScript’s bind.
What's weird is that it's half baked def foo(self): instead of a more logical: def self.foo(): to match the calling syntax.
thing_instance.foo(bar, baz)
Thing.foo(thing_instance, bar, baz)
Earlier quoted context omitted.
Behold the tremendous amount of effort for Mercurial: https://www.mercurial-scm.org/repo/hg/log?rev=py3&revcount=2... They've been porting hg into Python 3 for the last 10 years and are only now nearing completion. I've written a bit more about this in Lobsters: https://lobste.rs/s/3vkmm8/why_i_can_t_remove_python_2_from_...
Honest question, how can it possibly take 10 years to port hg to Python 3? If I am to believe the Wikipedia source for the first release of Mercurial[0], it would've been only 4 years old at the start of the 10 year porting process. How on earth does it take 10 years to port 4 year old software? Even taking into account the fact that new features were still being added and not all focus was on porting, this doesn't r…
Earlier quoted context omitted.
> In python 3 it always blows up when you mix bytes with text so you can catch the issue early on. This is definitely the case. I've been wrestling with bytes and strings all the time during the port of a Django application to Python 3 for a costumer. I can see myself encoding and decoding response bodies and JSON for the time being. For reasons I didn't investigate I don't have to do that with projects in Ruby and E…
you don't have to do these things in python 3 either, your problem was that you had python 2 code that was already broken and you are started adding encode/decode to fix it, typically making the problem worse. If you write code in python 3 from the start you rarely need to use encode() and decode(). Typically what you always want is a text not bytes. Exception to it might be places where you want to serialize like IO…
Example, I just had to write this
return urllib.request
.urlopen(url, timeout=60)
.read()
.decode("utf-8", errors="backslashreplace")
This is the only language where I have to explicitly deal with encodings at such low level. I don't feel like I want to use it for my pet projects.
Earlier quoted context omitted.
It's not so much that it's "hard", but that it's time consuming when you have hundreds or even thousands of python scripts to port -- and since those scripts already work and you probably weren't going to have to touch them at all, you're not really gaining anything for all of that porting effort.
Maybe whomever should have stopped writing new ones by 2009 a decade ago. Then you wouldn't have much to port.
Earlier quoted context omitted.
Because of the amount of work involved in porting my existing Python code. Python 3 doesn't offer any advantages that matter to me, so that's a lot of effort for little gain.
OK, thanks. Good luck with the bug fixing ;)
Earlier quoted context omitted.
OK, thanks. Good luck with the bug fixing ;)
I'm not really worried about bugs, because the code I have works well, and I doubt I'm going to do any serious new Python 2 development.
Earlier quoted context omitted.
I'm not really worried about bugs, because the code I have works well, and I doubt I'm going to do any serious new Python 2 development.
I meant the bugs in your dependencies that you'll have to backport fixes to. But hey, if you're writing bug-free code that'll be easy ;)
I wasn't commenting on how buggy my own code is. Which version of a language I'm using doesn't really affect that variable.