I was surprised to recently notice a yellow banner on the website of the very popular Requests library, which urges users to switch to Python 3. That's when I first thought switching may become inevitable. I guess this is being orchestrated behind the scenes now.
Still, I have no plans to switch. The only useful feature in Python 3 to me is more liberal use of unpacking. Unfortunately it comes at the cost of removed tuple parameter unpacking, which I use often, but most users apparently never do. I don't know what's difficult about Unicode in Python 2 either, once you understand the difference between Unicode and UTF-8.
It's unfortunate it ever had to come to this. Makes you wonder what Python would be like today without Py3K. (It's an open question.)
> The only useful feature in Python 3 to me is more liberal use of unpacking.
Unfortunately, this ignores composing software. Your user may use things you don’t. The result: your software won’t get used as a library. That may be fine! More power to you. Just don’t drag anyone else down to 2 with you. :)
Personally, python 2’s print keyword/statement is infuriatingly inconsistent with the rest of the language; the network modules are a mess, organizationally; there’s no async support; the unicode support makes me want to stab my eyes out. I don’t mean to convince you (I’m not very convincing...) just to give an opportunity to hedge your statement with empathy for everyone who did decide to move on. Surely you must have any commentary that doesn’t reduce to “I don’t like change”, right?
Python without py3k is just old software that is end of lifing soon, after all :)
> I don't know what's difficult about Unicode in Python 2 either, once you understand the difference between Unicode and UTF-8.
"once you understand the difference between Unicode and UTF-8" is what's difficult about Unicode in Python 2. I understand it, you might understand it, but I have to interop w/ and work w/ code written by people who do not. I'm not fool-proof either, so I greatly appreciate that the language makes a hard distinction now; doing the right thing by default is the point.
I still use Python 2.7 and all I need with strings is UTF-8 byte string nowadays in Japan.
If you read Japanese, read the following blog to know the current circumstances:
And note that Golang is getting popular in Japan, which uses UTF-8 byte strings solely.
Python 2.7 with byte strings as default has a good chance to evolve into a more elegant language :-)
It has been "orchestrated" ever since PSF announced an official end-of-life date for Python 2.7.
This is just the way things work: support eventually runs out, and if people didn't switch before then for other reasons, that's usually motivation enough to finally do so.
Actually not related. The case in the article is about late-binding methods to object instances (creating a new object on each access) - whereas in python 2 the "unbound method" was a lazy creation on access, and in python 3 an unbound method is just a reference to a bare function in the class' name space. The lazy evaluation is from the descriptor protocol in python (see the links in TLA).
The case you point out is because the python bytecode compiler will intern raw values for some items - e.g. string literals, some integer values, and so on. More on interning: https://en.wikipedia.org/wiki/String_interning
The `is` operator is the same amount of strict in all examples here and in the article: it compares the identities (in CPython, this is essentially the memory address) of two objects.
The reason, in your example, that `is` returns different results is that small integers are "interned"; i.e., the literal 100 always references the exact same integer object, whereas 1000 will cause an integer to be allocated. (So a and b, while both represented 1000, are stored twice in memory.)
That's from almost 3 years ago. Have you ran the attached patch to check the benchmarks with a more current release? I don't know if that's been fixed, but it probably wouldn't take much time to test out.
I notice App Engine isn't mentioned in their stack. I'm a bit worried that Google abandons it once Snapchat moves off it. It has already been in maintenance mode for some years now (save for Managed VMs). The writing was on the wall when Guido left the team. Apparently Google still uses it internally (as the recent switch to Monorail made evident), so perhaps it's safe for a few more years.
True that Google stills uses it internally, but external usage exists way beyond Snapchat (although they are a fun customer). App Engine hasn't been in maintenance mode, although we have set aside engineering cycles to improve the reliability and stability of the service in order to ensure the highest level of support for production-grade customers. In tandem, we've some large features such Go, PHP, full-text search, and Cloud Storage support. We've added integration with the Cloud Console as well as Cloud SDK to allow developers to build hybrid solutions that span, for example, App Engine and Compute Engine. And, yes, we've invested in the App Engine Managed VM environment with a host of new runtimes including Java 8, Python 3, Go, PHP, and Node.js. We have more coming there over the next 2-3 months. Guido leaving was tough, I used to share an office with him. That said, I'm not sure that his exit was the writing on the wall.
Disclaimer: I'm the lead for the App Engine product team.
I'm a Product Manager on App Engine and wanted to reach out and say that 100% we are invested in app engine and are working to make it your favorite platform. For example, we heard that GAE documentation needs enhancements and we've kicked off a large project to do just this. It's an ongoing effort as you can imagine, but please take a look at the new landing page and managed VM content as well as the left-hand nav reorg we did. Here is the link. More to come of course.
Please give the new set of docs a try and please give us feedback when you see errors or generally when the content is not up to par with what you expect. There is a feedback tool on the top right hand side of every page.
Do you have any plans to launch a data center in India? AWS is launching one this year, and I imagine this will be a huge boon to the startup industry here.
While Google could potentially abandon App Engine, it's much more likely it will simply remain unchanged for a number of years (as indeed it has roughly been for the past few years, save for Managed VMs).
GCP is now offering an increasingly larger percentage of what App Engine used to offer, so really the future may look a lot more like just build your apps on GCE + PubSub + Cloud Datastore and don't even mess with App Engine at all.
To your first point though, streaming services typically are more focused on storage and egress (network) optimizations. App Engine has integration points with each, but its core workloads fall more in the dynamic web app and mobile backend realm. Within Spotify's architecture, there are places where App Engine makes sense (e.g. hosting their frontend APIs). That said, this is small relative to the rest of their architecture and understandably isn't the first area of focus when you're making a move to a new vendor.
If ffplay supported hardware decoding, it'd be the perfect player. You could not make a more minimal player. It does not, and it doesn't seem to be high on the priority list, rather in last position perhaps.
I had two monitors that were x1200 but sadly they both stopped working for mysterious reasons. It was great for online poker as it allowed a perfect number of tables at a decent size (Stars, FTP). In the end I played only 4 on each as that was my sweetspot for paying attention to all details but for massgrinding 12 on each was doable (iirc, I could never play more than 8x2 without going insane).
Standard x1080 didn't work well at all especially back in the day when the tables weren't resizable :D
https://docs.python-requests.org
Still, I have no plans to switch. The only useful feature in Python 3 to me is more liberal use of unpacking. Unfortunately it comes at the cost of removed tuple parameter unpacking, which I use often, but most users apparently never do. I don't know what's difficult about Unicode in Python 2 either, once you understand the difference between Unicode and UTF-8.
It's unfortunate it ever had to come to this. Makes you wonder what Python would be like today without Py3K. (It's an open question.)