31–40 of 355 posts
It _is_ happening, but moaning about it won't make it happen any more quickly.
Python, unlike a C executable, could hypothetically stop working tomorrow. Researchers who have code that works/businesses don't give a shit about the esoteric differences between py2 and py3, they just want their stuff to keep working. This is similar to the banks still running Cobal backends, I don't know why everyone cares, I guarantee multiple servers out there are running executables that couldn't be rebuilt, bu…
Because software that isn't protected by walls of legislation value features and the end user UX. i.e. "evergreen". Your Nokia N900 running Meego may be sufficient for certain subsets of HN readers but your average user wants Material Design and cannot care less about ideological purity or "if it ain't broke don't fix it".
EDIT: Personally for me while I find for example older windows interfaces ugly they were very consistent and functional. In modern designs I sometimes could hardly find what is clickable/actionable. It is not interface working for me but the other way around
Because there's been not enough carrot and too much stick. The only real killer feature of Python3 is the async programming model. Unfortunately, the standard library version is numbingly complex. (Curio is far easier to follow, but doesn't appear to have a future.) On the down side, switching to Unicode strings is a major hurdle. It mostly "just works", but when it doesn't, it can be difficult to see what's going on…
Earlier quoted context omitted.
Python 3 seems like a bit of a missed opportunity. Since they were introducing breaking changes in the first place, why didn't they go bigger? E.g. make the OOP seem less tacked on, immutable data structures, clean up inconsistencies in the standard library?
Can you describe how OOP feels tacked on? One of the major changes in Python 3 is that new-style classes are the only style of classes.
Because there's been not enough carrot and too much stick. The only real killer feature of Python3 is the async programming model. Unfortunately, the standard library version is numbingly complex. (Curio is far easier to follow, but doesn't appear to have a future.) On the down side, switching to Unicode strings is a major hurdle. It mostly "just works", but when it doesn't, it can be difficult to see what's going on…
I wonder how many people feel that migrating to Python3 would have been worth doing in the absence of being forced to do so. Dropbox invested three years of work, actually hired Python's creator, and are still not done. What are they getting out of it that they wouldn't have gotten if Python2 simply had been maintained?
Who wants to break old SQL? Nobody.
Earlier quoted context omitted.
Python 3 seems like a bit of a missed opportunity. Since they were introducing breaking changes in the first place, why didn't they go bigger? E.g. make the OOP seem less tacked on, immutable data structures, clean up inconsistencies in the standard library?
Can you describe how OOP feels tacked on? One of the major changes in Python 3 is that new-style classes are the only style of classes.
About some of the design decisions in Guido's own words: http://python-history.blogspot.com/2009/02/adding-support-fo...
Earlier quoted context omitted.
Can you describe how OOP feels tacked on? One of the major changes in Python 3 is that new-style classes are the only style of classes.
I myself, speaking for my self and only my self find that, in regards to myself, the redundant self keyword, in my self's opinion, is somewhat selfish and easy for my self to accidentally omit. Self.
Earlier quoted context omitted.
Can you describe how OOP feels tacked on? One of the major changes in Python 3 is that new-style classes are the only style of classes.
I myself, speaking for my self and only my self find that, in regards to myself, the redundant self keyword, in my self's opinion, is somewhat selfish and easy for my self to accidentally omit. Self.
Rust does the same thing - with self, it's an instance method, without, it's a static method.
[copying comment from an older HN thread, not speaking on behalf of any employer, opinions my own] I think many people underestimate the challenge that the 2 to 3 migration presents for large enterprises. The core issue is that even though the migration for any given module is normally really easy, the total effort required to migrate is still essentially O(n) in module count/file count, because even with current too…
As a member of a team hopefully nearing the end of the python3 migration, this is exactly correct. The unicode switch is a nightmare in terms of having to go through and double/triple check everything and still get it wrong half the time. Particularly when it comes to moving data over the network. The big selling point for Python3 finally came with the built-in async support, but we've been using Twisted for a decade…
Because there's been not enough carrot and too much stick. The only real killer feature of Python3 is the async programming model. Unfortunately, the standard library version is numbingly complex. (Curio is far easier to follow, but doesn't appear to have a future.) On the down side, switching to Unicode strings is a major hurdle. It mostly "just works", but when it doesn't, it can be difficult to see what's going on…
With respect to async, I'm partial to trio [0], which is a spiritual successor to curio [1]. The model is similar to Golang in many ways, e.g. communication using channels [2] and cancellation [3] reminiscent of context.WithTimeout, except that in Golang you need to reify the context passing. The author has written some insightful commentary on designing async runtimes [4] and is actively developing the library, so I…
The link to support requests (which is a great piece of software) is here:
https://cash.app/$KennethReitz
Note: This is NOT a charitable donation, it is a gift to an individual. These are not tax deductible under US law.
Njs has a long attacking blog post saying this needs to go through PSF (huh?) and that they should be getting most of this money not the person the funds were directed towards (it's not clear how much they've actually contributed to requests over time). This supposedly also may trigger folks who have also suffered from "gaslighting".
Supporting the developer of a piece of software does not, as far as I know, require that they sign up to handle it on a charitable basis. A big todo is made about the "large" amount raised. The amounts is 33K. To be frank, this is almost zero in tech land at least in the bay area and requests is a very highly used project. I was literally expecting something like 300K or even $1M - silly kickstarter projects raise for more and deliver nothing. Requests has already delivered a lot of utility.
Just a bit of perspective from someone who wasn't familiar with this "fiasco".