61–70 of 172 posts
That was a long time ago when Python's userbase was much smaller. I wonder if Python be in better shape today had they merged stackless back then.
Earlier quoted context omitted.
There has actually been a lot of focus on making migration less painful, including restoring some removed features, e.g. Python 3.3 has added back the unicode literals. This is limited to things that are actually painful to migrate though not trivial non-issues like the print statement.
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…
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 port and drop 2. Tell people who want 3.x support before then to port and maintain it themselves. Enough complaining.
Earlier quoted context omitted.
It's challenging. On the one hand, you don't want to break what is working (Python 2.x), so you'd like to support it so that community can continue to be productive. On the other hand, you don't want your braintrust split across two different versions, and you don't want the confusion that comes from having two major versions. For example, the (Epic) Learning Python 5th Edition by Mark Lutz, had to be written for two…
There are a lot of Windows users who are happy with XP too. I remember trying to explain to people 20 years ago why HDTV was better than what they had. Most people were happy with 480 lines of resolution, or thought they were. It's human nature. By being accommodating, you've made the problem harder. Apple is the only company that says screw legacy. Of course users complain but they just grumble and know to accept it…
The nice thing about Windows XP, is that by and large, a Windows XP user could use Windows 7 with next to zero training. Or, in fact, zero training.
This is why the first version of Windows 8 pissed so many people off - removing the Start Button all of a sudden made the Operating System unusable to a huge portion of the Windows user base.
I understand they've brought back the start button.
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,…
Removing the print statement is, to me, an extremely frustrating breaking change to make. If nothing else, I feel that backward compatibility should be given toward's a language's canonical "hello world" example.
> Windows has the CreateFiber() API that creates "fibers", which act like threads, but use "cooperative multitasking". For POSIX, using a combination of setjmp(), longjmp(), sigaltstack(), and some signal (e.g. SIGUSR2) will provide coroutine support though it is "pretty awful". While it is "horrible", it does actually work. I do this, and it works perfectly well. Here's a full implementation demonstrating this appro…
The way to make Python 3 more attractive is to backport the best bits to Python 2.8...
This is Python 2.7, but is based on PyPy (so it's waaay faster), and has requests + gevent + lxml built-in, and adds some small niceties from 3.x (yield from, a, b* = foo()).
If the Perl6 rewrite is validated by it having a larger user base than Python 3 in 5 years' time, part of me that has died will be reborn. Unlikely, though.
What Perl6 rewrite? Perl6 is a specification. Are you referring to various compilers that have been implemented over the years as rewrites?
The rewrite of the language.
It was decided that if you need to break backwards compatibility anyway, you might as well do so in a big way. In contrast, Python3 breaks backwards compatibility as well, but only offers moderate improvements.
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…
> 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…