Nothing in that article matters to me and I use Python every single day. I guess if you know too much about a thing it's easy to lose sight of what "normal" users care about. So here's my list: 1. Speed 2. Language warts (e.g. del, __init__, import *, while: else:) 3. Lack of a modern UI toolkit 4. No native support in Android, iOS, or Browsers worth mentioning. Right now Python is the perfect prototyping, glue, and…
what's wrong with qt as a modern ui toolkit? python seems to be one the best supported languages as far as qt bindings go.
Making python 3 more attractive is not the solution, it's part of the problem. I can't use just python 3 because python 2 is still widely used. I can write code that works on both but now I'm using the worst of both worlds, and even worse I now have to test on both. And that'll last until python 2 goes away completely which, - when has a language ever gone away quickly? These aren't fun problems. Improving python 3,…
`print` statement is not a big deal for me. But one thing that especially annoys me is the functions in the module `itertools`. In Python 2, I use `itertools.izip` or `itertools.imap` a lot, because I'd like to avoid creating a large list only to iterate over once. When I tried migrating to Python 3, I found out that these functions are gone, and I was supposed to use plain `zip` and `map` instead. I was furious. How easy it is to let `itertools` contain these functions as aliases to the builtin? And I felt that I was punished for writing efficient code, while people who code carelessly get rewarded. I switched back instantly.
Nothing in that article matters to me and I use Python every single day. I guess if you know too much about a thing it's easy to lose sight of what "normal" users care about. So here's my list: 1. Speed 2. Language warts (e.g. del, __init__, import *, while: else:) 3. Lack of a modern UI toolkit 4. No native support in Android, iOS, or Browsers worth mentioning. Right now Python is the perfect prototyping, glue, and…
what's wrong with qt as a modern ui toolkit? python seems to be one the best supported languages as far as qt bindings go.
Nothing per se. However the situation with two competing python bindings and no official out of the box support or blessing of either makes it non-obvious as to what the 'correct' way to write and ship GUI apps in python is.
If I just want to wrap a simple GUI around some functions then going down the qt route is currently far to 'heavy'.
Reasons I am excited about Python 3: * "yield from" * Unicode support (I'm German and the clear distinction between bytes and unicode really makes my life easier) * function annotations (PyCharm interprets them and uses them for static type checking) * cleaned up stdlib (not only names, but also features) * asyncio Library support is very good nowadays, pretty much all of the important libraries are either ported to…
Most of this stuff is great and I'm actually looking forward to moving to py3k. But I've been looking forward for a few years now, though, and it seems like that will continue to for a while longer. The main problem for me remains dependencies. Python makes it so easy to integrate stuff via pip/easy_install, but that's a double edged sword in this case: Since there's such a huge abundance of great libraries for anyth…
Do you have a list of dependencies that are causing you the issues? When I did my migration (about 9 months ago) I found that there were a few dependencies that had been superseded by much better libraries. At the time there were a couple where I had to use a py3 branch, but no longer.
It's not really migration though, it's supporting both python 2 and 3. If you write modules that people depend on you're in a really, really painful spot with the 2 and 3 transition. You can have two completely separate code bases and deal with all the duplication and problems that come with it, or you can try to write code that works with both python 2 and 3 and deal with the huge amount of warts and pain that come…
I'm a library consumer not a maintainer, but with info like this- https://twitter.com/mitsuhiko/status/586294700430254080 If you look at the date on the calender, the fact this is still being discussed with virtually no progress like it's still 2008 when 3.0 got released tells me that this is over. As an end user, I say drop 3.x support in your libraries. The gig is up. If 3 ever takes over, do a 1 time wholesale por…
> I say drop 3.x support in your libraries. The gig is up. If 3 ever takes over
People dropping 3.x support until 3.x becomes the most used version basically guarantees that it won't take over.
Is this a code equivalent to the bystander effect?
Honestly I thought that we where done with 2 vs. 3. Every new project we start is Python 3 and I don't hear anyone in the office preferring Python 2. Dealing with Scandinavian languages having the Python 3 Unicode support is the killer feature in Python 3, it just make everything so much easier. In terms of performance it's fine and library support is no longer an issue (for us at least), everything we use just works…
Yeah, perhaps your experience in your office is not generally representative? In PIP, Python 3 has like 5% uptake...
What do you mean with "In PIP"? Are only 5% of the pip downloads from Python 3? That would make sense seeing as pip is included in Python 3.4, so there no need to download it.
If you mean that only 5% of the packages on pypi.python.org is Python 3, I would say that sound a bit low. Also unimportant for most, if it's just the correct 5%. There's also a ton of old cruft on pypi.python.org that would count against Python 3, but not really be important to anyone.
Yeah, I don't like the busywork that Pep8 makes me do it, and it's a lot, and some of it is stupid, but it has to be done You certainly don't have to do it if you don't want Python 3 and 2to3 makes it a lot easier
> Yeah, I don't like the busywork that Pep8 makes me do it, and it's a lot, and some of it is stupid, but it has to be done Actually no, it hasn't. PEP8 is just a formatting standard, your code will work with your own standard too.
> The Unicode support that comes with Python 3 is "kind of like eating your vegetables", he said. It is good for you, but it doesn't really excite developers Saddly I agree with that. There needs to be either a big stick (Python 2 being really bad, but it is actually pretty good) or a large carrot ("Oh look 3x performance improvement!"). Something like a carrot was presented during Pycon and that was gradual types (o…
Firefox added Python support in the past and there was no uptake. Brendan Eich has a hnews comment on it. I think 2x-3x perf improvement /is/ possible. I mean we have the example of javascript that went from terrible perf to almost native parity. Of course Mozilla & Google each dedicated an entire team to get there. We already have the example of PyPy too which /today/ averages a >5x ( http://speed.pypy.org/ ) speed…
> I mean we have the example of javascript that went from terrible perf to almost native parity.
It didn't have the ecosystem of C extensibility and mature extensions Python has, which drive much of its adoption in e.g. scientific computing (a big factor for Pypy having trouble making inroads).
Making python 3 more attractive is not the solution, it's part of the problem. I can't use just python 3 because python 2 is still widely used. I can write code that works on both but now I'm using the worst of both worlds, and even worse I now have to test on both. And that'll last until python 2 goes away completely which, - when has a language ever gone away quickly? These aren't fun problems. Improving python 3,…
Migration is a critical issue for python 3 adoption. I think python 3 should have done something similar to Protocol Buffers v3 (proto3) by introducing syntax = "python3" statement and let runtime support both v2 and v3. This allows people migrate one file at a time. In any large scale production environment, this is pretty much the only practical way for migration. Another critical mistake python 3 made was unicode…
A runtime that can support both v2 and v3 files is a nice idea and has been proposed before, but is virtually impossible because of the unicode changes.
I don't understand where you see the mistake in Python 3 with unicode. What encoding Python internally uses to store strings doesn't really matter. What's important is that it is always known what encoding is used. This was unclear in Python 2 and Python 3 fixed this.