Python 2.8 Un-release Schedule - <AUTHOR> http://www.python.org/dev/peps/pep-0404/

<comment><USER2> I'm kind of surprised people are surprised that upgrading to 3.x has gone slowly. You can't upgrade a major installed base overnight unless there's incentive. Windows Vista, for example?

Additionally, it has stumbling blocks towards achieving the upgrade. Packages you're using aren't upgraded, you have a lot of code dealing with strings, and so on. I worked on a project that tried to use Python 3.x and it was a nightmare in both regards.

In my view, Python 3 doesn't offer any major reasons to upgrade other than we've been told to. Someone tell me: what is it that's so compelling about Python 3? For instance, when you click on "What's new in Python 3" on this page, the first thing in the list is "print is a function". Seriously? The FIRST thing in the list is something that breaks code and has very little impact. Unicode has a lot more impact, breaks a lot more stuff, and is doable in 2.x anyway, yet is the 5th or 6th thing in the list.

So I'm not really sure what the devs were thinking with Python 3.x. It broke a lot of stuff but didn't break enough to make Python notably better. I was around and a heavy Python user for the 1.x -> 2.x upgrade. That was far easier, had some features I could really use, and there was a much smaller installed base. This time around, I just don't see the reason I should upgrade. Eventually, I imagine I will when support is so far gone that there's no choice, or there's some amazing feature that requires it.

For those of you who will respond: "So don't upgrade, or switch off Python". One of those is mission accomplished. The other one remains to be seen, though if Tiobe is at all believed, Python is declining sharply in interest.

<comment><USER3> _though if Tiobe is at all believed, Python is declining sharply in interest._

[http://www.tiobe.com/index.php/content/paperinfo/tpci/index....](http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html)

Java script seems to be going strong. Python has fallen by 3 places and has the maximum drop in ratings among top 20 languages.

Python is right next to Perl.

Since according to many Pythonistas and the references they used to point to in the past when they talked of Perl, Perl was dead for the same metrics which Python has now.

        1. A major revision whose ecosystem isn't ready.
        2. Current stable widely deployed version is going to go away soon.
        3. Fall in ratings.
        4. Fall in usage.
        5. Rise of new languages like clojure.

And since now Python has the same metrics and is next to Perl.

Can we say Python is dead? It must be since TIOBE says so!

<comment><USER3> To everybody who is downvoting this, this is heights of hypocrisy and fanboy'ism.

I am just applying the same principles to Python what used to be applied to Perl.

And more importantly there is data to back up everything that I said.

<comment><USER4> I'd guess the downvotes are thanks to sloppy and/or biased dataanalysis rather than fanboyism. For one thing Perl has been dropping almost steadily for the last 7 years, Python just one.

</comment></comment></comment></comment><comment><USER5> Three shall be the version of the Python, and the version of the Python shall be three. Version four shalt thou not use, nor shalt thou use version two, excepting that thou then upgrade to three.

Perl 5 is right out.

</comment><comment><USER6> I've been using Python2 now for 4 years but have been dragging my feet upgrading to Python3.

Finally, I started learning it just a month ago and now I don't know what ever stopped me before. In fact, the most annoying thing I've found about Python3 is that my searches for documentation on DDG or Google all go to the Python2 docs.

<comment><USER7> My impression is that the slowness to adopt python3 is mostly about fashion than anything else, not that there aren't solid, technical reasons to stay with python2. The main thing for me is availability of numpy/scipy packages for python 3.

<comment><USER8> s/fashion/fear/ with a small pinch of missing libraries, as you said (btw i hear numpy is getting there.)

<comment><USER9> numpy/scipy/matplotlib have been there for about a year, according to [http://pythonsprints.com/2011/04/8/matplotlib- python-3-thank...](http://pythonsprints.com/2011/04/8/matplotlib- python-3-thanks-cape-town-group/)

(I am dragging my feet on this, too.)

</comment></comment></comment></comment><comment><USER10> THis isn't surprising. Python 3 was advertised, back in the time, as "mainstream, please don't bother yet, we'll do a few more 2.x releases while letting the community catch up with jumping through the hoops of Python 3".

That is, at the same time when they removed some tried and true language constructs people liked and didn't add more of any powerful features that everyone was hoping for.

I bet Python 2.x will dominate for a long time, possibly with PyPy w/ LLVM becoming the de facto implementation instead of the discontinued CPython. Also, another party will at some point continue developing the 2.x line further.

</comment><comment><USER11> There really should be an effort to get people to write new code in python3 and use 3to2 to backport (rather than writing in python2 and using 2to3 to convert).

<comment><USER12> The biggest obstacle there is the lack of setuptools/distribute integration. It's easy to run 2to3 at install time when your source distribution is python2, but there's no support for going in the other direction.

</comment></comment><comment><USER13> _In addition, integer division now produces floating point numbers for non- integer results._

Grr.

<comment><USER14> Well, that makes sense, doesn't it? Not in relation to prehistoric programming languages, but in relation to humans. I'd imagine it's hard to think about programming language without comparing it to others... but try it. Why would 5/2 be 2 and not 2.5? That being said, you can (still) use //.

<comment><USER13> Because int/float conversions are not free! It is hidden, hard-to-reason-about computation that now, you have to explicitly look for.

<comment><USER15> If my work's performance requirements were so tight as to make that an issue, I would use C. Or numpy. CPython is _slow_. CPython is so mind-numbingly slow, for many many reasons, that each numeric variable could be a bigfloat and it would not matter the slightest.

Now, let's talk semantics. Not converting to floating point is precisely the kind of hidden computation that should be avoided, at all costs, in a language. Haskell is efficient and rigorous, and its division operator does floating point conversion. So, no excuses.

<comment><USER16> Haskell's division operator (/) does _not_ do floating point conversion. It may seem that way to you since evaluating 3/4 gives 0.75, for example. What actually happens is that every integer literal get the function fromInteger applied to it automatically, this function converts integers to whatever other type is necessary. So if you evaluate 3/4 at the REPL you're really computing (fromInteger 3) / (fromInteger 4), giving, by default[^1] a floating point number.

The key point in this is that only integer _literals_ get fromInteger applied automatically, so for example

          let n=6 :: Integer in n/3

gives a type error since n is not a literal and thus not automatically coerced. (Of course, doing this without the type declaration,

          let n=6 in n/3

does give 2.0 as result, but it declares n to be a Fractional number, not an Integer.)

[^1]: only by default, if you load the rational number library, you can ask for / to compute rational numbers by simply saying the type of result you want: 3/4 :: Ratio Int evaluates to the rational number 3 % 4 (% is Haskell's odd choice of notation for rationals).

</comment></comment></comment></comment></comment><comment><USER17> Heh, PEP 404. Nice.

</comment><comment><USER3> I've tried to push Python for many projects at our shop. But it always get shot down by _We don't want to write in 2.x series as its going to go away, and 3.x ecosystem isn't ready yet_.

The more this continues, the more some technology is going to eat Python's lunch.

If Python wanted to break backwards compatibility they should have done so with some big major changes. That would have been justifiable. Right now no one sees a reason to break backwards compatibility to go to a no-so-ready ecosystem at the expense little gains. At the same time no wants to write 2.x either.

At least people planning to maintain their code base for years aren't going to write in a major version that's going to go away.

</comment><comment><USER18> For some reason, adoption has been really slow so far; it is disappointing to see so many beginners pick Python 2 over 3. I believe that even MIT and Coursera teach Python 2.

<comment><USER19> One of the issues is that almost every Linux distro is still shipping 2.7+ (and with good reason, there's a lot of code that won't run in 3.0 still).

I think now that 2.7 is the last we will start to see a bit more migrate.

Edit: I didn't mean they aren't shipping 3.0, but that the default is still 2.7.x

<comment><USER20> That's simply not true, unless perhaps you actually mean "almost every Linux distro" (i.e. including the bulk of distros that have a whole of five users and release once in a blue moon).

The fact is that almost every _major_ distro is shipping Python 3, and often has been for several releases/years: Fedora, Ubuntu, openSUSE, Debian, Gentoo, ArchLinux ... and many of these also have anywhere from dozens to hundreds of Python 3 libraries packaged.

If you mean that /usr/bin/python still points to Python 2 on most of these (in fact all of them except for ArchLinux): True, and that is unlikely to change, possibly never. It's my understanding that this is in keeping with upstream's wishes (from discussions on python-devel and python-porting): bin/python is to remain Python 2 with python3 being the right way to run the Python 3 interpreter.

<comment><USER19> Sorry, you are right, I did mean that /usr/bin/python is usually 2.7.

For someone just starting out with python (on linux anyways) that means they are probably going to fire up that interpreter first.

I was wondering myself actually if any of the distros would switch to 3.0. I think a lot of packages would break if that were to happen.

As you've said, Arch has already switched but their package release isn't really typical for most distros.

<comment><USER20> Ubuntu's Python maintainer Barry Warsaw recently announced their goal to have no Python 2 in the "main" part of the repositories by their April 2014 release: <http://lwn.net/Articles/469939/>

I think that's probably a too aggressive schedule to actually keep, but here's hoping.

</comment></comment></comment></comment></comment><comment><USER21> Great reasons to upgrade.

But they should also mention they are taking away our beloved print and quick string formatting.

<comment><USER22> To be precise, print is now a function instead of a statement. It has not been taken away. Just add parenthesis.

The string formatting syntax did indeed change, but the new syntax is just as "quick" as the old one, just different (see [http://stackoverflow.com/questions/517355/string- formatting-...](http://stackoverflow.com/questions/517355/string-formatting- in-python)).

</comment></comment><comment><USER23> As a Perl guy waiting for Perl 6, I never understood why Python devs were waiting. I'd talk to Python guys and they'd say some library or another was missing. Then I would explain how exciting it was to have a breaking version that fixed defects and warts, and in general making the language better. Of course, I'm still waiting for Perl 6 plus another 5 before adoption. Oh well, I'm glad someone is finally moving ahead.

<comment><USER24> As a non-Perl guy, I thought it was supposedly clear that Perl 6 is a completely different language than Perl 5 and isn't meant to replace it? So I don't think Perl 5 : Perl 6 :: Python 2 : Python 3 is really that analogous...

<comment><USER23> Perl 6 will have a Perl 5 compatibility mode. Yes, it's a more ambitious effort and it's a loose analogy. However, I don't think there's a need to have both Perl 5 and 6. It's meant as an evolution to solve the same kinds of problems. Perl 5 came back to life after it became clear Perl 6 was going to take even longer, and it's adding some of the improvements from Perl 6.

Anyway, the observation is to note how long it takes to get people "upgrade" when "breaking" changes are made to languages.

</comment></comment></comment><comment><USER25> Love that it is 404 :)</comment>


Redbox is leaving Canada - <AUTHOR> http://www.redbox.ca/

<comment><AUTHOR> I didn't care when Target decide to leave ; it was too much like Zellers. But I love RedBox and its convenient locations. I will miss it badly!</comment>


Show HN: Software Documentation Using GitHub - <AUTHOR> https://salty-falls-27943.herokuapp.com/ <comment><AUTHOR> Hi everyone,

I have been involved in a project that uses confluence to keep a software documentation. As the project develops in each version, keeping and viewing the documentation has become a hassle to a point that we append the date to the title to know which documentation is the latest one. So that got me thinking that maybe we can use Git to solve the versioning issue.

Eventhough Github and other version control website can already render markdown pages, but I need something that 1\. Can render UML diagram 2\. Can handle version link.

After a few weeks of hacking this is the result. A website that can convert a Github repo into a software documentation website. It still in it's early stages but you can try out the demo :D</comment>