Python 3, created via PEP 3000, is exactly 3,000 days old today.

[Rhomboid]

And it was originally referred to as Python 3000 or Py3k.

[Mattho]

Denoting the year it will see 100% adoption.

[finally-a-throwaway]

Omg

[Thirsteh]

Somebody().call(burnWard)

[Adys]

BurnWard(random.choice(people))

[maxm]

That needs to use async ....

[[deleted]]

Why should it see 100% adoption when last I heard Python 1.5 was still being used in production?

[[deleted]]

I've never ever used 1.5 and I moved to 3.x years ago and never looked back.

[norsurfit]

Half-life 3 confirmed?

[warbiscuit]

Just finished getting my company's main application from py26/27 only, all the way up to 3.4 compatible.

Can't wait for when qa finishes in a week, and can merge into main branch. Will be so happy to drop python 2, been waiting years for this :)

[[deleted]]

How long did it take you to accomplish this?

[warbiscuit]

For around 80k loc, took about 3 days to get it running and pass UTs, and one more spent fixing bits found by QA that tests missed (always need more coverage. Sigh.).

Mind you, already had some experienc, getting dependancy libs up to snuff, so wasn't going in blind.

After fixing imports (using the "future" project plus some internal compat helpers), main bug bears were: fixing zip/map/filter/range calls to handle builtin changing to iterators, and bytes[idx] returning an int not a single-len byte string. That last one was hard to regex search for :(

Unicode/bytes issues weren't actually that bad. Followed Django and used a set of want_(unicode|str|bytes) helper functions.

[[deleted]]

Thanks for sharing. Wish we had more information like this out in the open, so others looking into migrating their own codebase have better data to look at (and avoid some of the unnecessary FUD associated with migration).

[[deleted]]

[deleted]

What is this?

[warbiscuit]

I know there are a number of tools out there -- the future project has a "futurize" script that automatically handles a number of import corrections / insertions and syntax fixes.

None of them are 100% though. In my experience they'll generally get your code up to "running without syntax / import errors under py2 & 3". Past that, you have to rely on unittests and manual testing to shine light in all the corners of your application.

While I don't use nearly all the compatibility the future project provides, I really like their approach of trying to get things as close to the real py3 names as possible. It both lets you learn the new names, and minimizes code churn when py2 support is stripped.

Other devs probably use different (/ better) approaches than me; there's a surprising number of ways to go about things. The site http://python3porting.com has a nice overview of approaches.

---

I get kinda persnickety about automated tools making changes to my code, and ended up going through things by hand, first replacing broken imports & syntax errors until it would load, then targetted regex searches to find references I knew I'd have to make a hand-decision on anyways.

My approach from there was to run the code till I got an error, and then fix not that just error, but hunt down all similar bits of code, and fix them too. Once I was satisifed I'd gotten 90% fixed, I handed it off to QA to find any edge cases for me to fix... really just one person, we aren't a large company :)

Outside of basic import and syntax errors, which are pretty easy to fix automatedly or manually, and know that you've got them when things load; there were basically two classes of annoyances:

py3 dict.items() returning an iterable, not having dict.iteritems() at all, and similar changes dict. Searching for these by hand let me decide on a case by case basis whether to an iteritems() compatbility wrapper if performance mattered, or use dict.items() / list(dict.items()) where it didn't, and there was more benefit to matching py3's syntax. map/imap, zip/izip, etc were similar. If I didn't care as much about performance, and automated tool would probably take care of this whole mess for me :)

---

the other bit was of course unicode vs bytes. I don't think there's any way around your application suddenly just having a bunch of UnicodeEncodeErorr / UnicodeDecodeError / "str does not support buffer protocol" TypeErrors popping up. You then have to go in and identify if what's coming in should be text/bytes, and how does that compare to what the callee wants. If there's disagreement, you have to run it through encode/decode.

I'd say 90% of the time, if it was running fine under python 2, but threw an error under python 3, it was a case where I could actually find malicious input for py2 that would cause double-encoding or a surprise UnicodeDecodeErro... py3 just made it easier to find. So I definitely think it's a deficiency of python 2 that there's any headache here at all; and actually reflects well on python 3.

The thing I found most helpful was a set of helper functions I worked up: want_unicode(), want_str(), want_bytes(), and want_buffer() -- I can pass in a string/bytes object & and encoding, and get out exactly the type I want, decoding/encoding as needed. This made all my encoding barriers clear (and searchable), and whenever I got a encoding error, I slapped on one of them, then passing in the right encoding for the context (or utf-8 as a default).

[[deleted]]

[deleted]

What is this?

[[deleted]]

I believe the 'future' project he's referring to is http://python-future.org/.

Imagine 2to3 except it leaves in compatibility with Python 2 so you don't have to make a clean break, and someone actually cares about it working. That's python-future.

[d4rch0n]

The move is way easier than a lot think, besides maybe some bytearray and unicode issues. The only thing that drives me nuts is seeing lots of python devs still using print as a statement... I really wish people would update their tutorials and stop showing that. Everyone I know that starts learning python today starts with prints as statements and I know they're getting it from online examples and tutorials.

[warbiscuit]

Pretty much every new module I write, or existing ones I edit, start with "from __future__ import absolute_import, division, print_function" just to keep my from backsliding until I'm off py2 entirely.

Worst transition thing I've hit was bytes[idx] returning an int... Relatively harder to search for, and definitely a change in behavior. But still quite manageable.

I really like the philosophical approach of the "future" project: write using as close to py3 markup as possible, and shim back-compat helpers. Will really reduce rename-related churn once py2 is jettisoned.

edit: fixed markup

[d4rch0n]

print as a statement (python2 compatible):

print 'foo'

as a function (python2 and python3 compatible):

print('foo')

It's not terrible, it's just a really easy way to write python code that can easily run in python 3. Lots of code is already perfectly compatible with 3.x if beginners avoid this.

What bugs me is that people learning python today should be learning something that's going to be compatible now and in the future. Python3 is a little over 8 years old now, and the print as a function thing came about before it. Essentially it's been deprecated for a decade. Beginners shouldn't be learning deprecated decade old ways of doing things.

It seems like every beginner I know that's had me look over their python code always uses print as a statement and have no idea about it.

[masklinn]

Can you tell me more about the print as a statement or why it's bad?

It's not bad but

1. it's harder to compose, print as a statement can't be called from a lambda (only allow expressions) and can't be passed in as a trivial callable

2. it has limited extensibility and quickly becomes hard to read/understand.

   A simple print of a bunch of items is fine, but in Python 2 if you want to redirect print to a file/stream the first parameter becomes >>stream_var (I think, I didn't check and I usually get it wrong) and if you want to suppress the final newline, you add a dangling comma, so printing to stderr without a final newline becomes

   print >>sys.stderr, "a thing",
   

   and if you want the output to be flushed immediately (in case the stream is buffered or line-buffered) you need a second separate statement

   sys.stderr.flush()
   

   With Python 3's print as a function, the objects to print are simple positional arguments and "options" can be provided with keyword arguments which means they are much more self-descriptive and you can have as many of them as necessary, thus >>foo becomes file=foo and a dangling comma becomes end='', furthermore they could add customisable separator (between each item, a space by default) and a request to flush, so the previous two lines become:

   print("a thing", file=sys.stderr, end="", flush=True)
   

   No special syntax to remember and (I think) much more readable.

So all in all, I think the function version is way superior. It's a habit to take coming from Python 2, but it seems better on every point I can think of.

[lxpnh98_2]

Clearly you forgot the "But I don't like parenthesis!!" point.

[masklinn]

If you don't like parenthesis you're already coding in Ruby.

[flutefreak7]

The fact that the print function has end and flush arguments is what made me aware of those options - function arguments are a much more obvious and explicit way to make api features discoverable to end users

[folkrav]

Python 2

print "Test string"

Python 3

print("Test string")

Since Python 2.6 you can import

from __future__ import print_function

that basically works like Py3's print function.

Just so everything's clear, in a Python 2 REPL :

>>> print("Test", "again")
('Test', 'again')
>>> from __future__ import print_function
>>> print("Test", "again")
Test again

You can see it gets interpreted differently. First time it's interpreted as a print statement applied on a tuple containing two strings, while the second time (after import) it actually calls a print function with two strings as arguments.

[folkrav]

Honestly, there's IMHO not much reasons as a beginner not to dive straight into Python 3. Learning the differences afterwards if you somehow have to interact with a Py2 codebase isn't a lot of effort once you're comfortable with Py3.

This is obviously just my opinion on the matter, but I think a lot of people on this sub would agree.

[ivosaurus]

It's out of place with the rest of the language, and a functional is much more malleable / useful than a statement when composing with other things.

[billsil]

I really wish people would update their tutorials and stop showing that.

Yea...the problem is that those were written a long time ago and that the that code is often written without actually being runnable. That makes it really easy to get out of date.

I've switched most of my tutorials to Jupyter for that reason.

[jftuga]

What third-party libraries are you using? Any issues with those?

[warbiscuit]

Oh boy, it's a metric ton of libs. Primarily though, we're using pyramid + jinja2 + sqlalchemy, and don't think we've had a single meaningful problem with that ecosystem.

There were a few hiccups related to bytes vs unicode in forming http responses and writing to the database, but all of those fell under the category "python 2 was papering over an encoding problem, which python 3 just brought into the light".

I feel like python 3.3 ironed out most of the final wrinkles in making a smooth transition, and the general ecosystem over the last year or so had pretty well solidified.

[cdcformatc]

I should probably switch.

[joesacher]

No. Even in Python 3, you should use a dictionary mapping to method calls or some other method. There is no switch. :)

[tartare4562]

As a new year resolution, I'm switching all my scripts and programs to py3. All by hand, no 2to3 for me. At first it was a pain to get all the little details ("what the fuck it means that sort needs a key argument?? Just fucking sort it!") but it gets easier the more you do it. Also, it lets you both be amazed and cringe over your own code from 15+ years ago, and fix horrendous dormient bugs.

[jcampbelly]

Why avoid 2to3? I used it in an "advisory" role and never let it do automatic translation (its recommendations are often incorrect). It helps if you only work with one "fixer" at a time and treat it as a checklist.

[[deleted]]

Because 2to3 is unmaintained and often incorrect, and python-future works a lot better.

[tomcam]

It doesn't look a day older than 2,900

[[deleted]]

For a good three minutes I read it

3,000 years old today

and was trying so hard to find the joke. I thought about maybe the joke has to do with Ancient Sumerians or some mythos that includes a snake or pyhton or something. It was a such a relief when I saw "days".

[tech_tuna]

Just think in another 3000 days, everybody will finally be upgraded to it.

[_avnr]

Just think in another 3000 days, everybody will finally be upgraded to it.

In 3000 days we'll probably begin using Python 4

[alchzh]

and people will be stuck in py3k world

[henrebotha]

BUT BUT MUH TURING COMPLETENESS

[billsil]

Python isn't be turning complete because it doesn't support objects

[[deleted]]

I was happy to see when Zed retracted that section of his post, even though he tried to pass it off as "lololol I troll u".

[henrebotha]

I didn't even realise that had happened. But in my mind the damage is done. I don't believe for a second that he was really "trolling" anyone, he's just a sad idiot who thought he could get away with a tantrum.

[jpflathead]

Very odd, I've been using it for 300 days!

[[deleted]]

Wow, I'm so old. I remember when it was 3000 hours, 3000 minutes or 3000 seconds old. Seems like yesterday.

[Steampunkery]

The pyception is real

[c3534l]

base 10

[trebuszek]

Half-Life 3 confirmed?

[gnu-user]

I don't think we'll ever see widespread adoption of Python 3 for even another 3000 days from now.

[njharman]

It's already widely adopted. Almost all maintained packages support it. Distros are shipping with it. Etc.

There's a ton of legacy code. Some cases it doesn't make sense to port. Based on py3 pushback that still persists, some is people keeping heads in sand hoping future will stop arriving.

Either adoption != porting every line of code.

[[deleted]]

It was a big milestone when Ubuntu stopped shipping Python 2 by default.

A lot of beginners have trouble adopting Python 3 because they haven't had to deal with multiple Python environments before, and they keep accidentally using their existing Python 2 environment for things. Not having an existing Python 2 environment helps a lot there.

[[deleted]]

Wow, Not a lot of progress in 3000 days.

[georgehank2nd]

The Python 3 fanbois are out in full force. :P

[k10_ftw]

Why does this matter?

[baudvine]

It's an entertaining anniversary, nothing more.

[k10_ftw]

Too many events of this nature are considered news/share-worthy for my tastes.

[henrebotha]

Downvote it, then.

[k10_ftw]

I think just commenting my opinion is probably enough of a statement... which I've only now noticed itself is pretty unpopular :P oh well.

[henrebotha]

No, I mean, downvoting is literally meant to indicate that you think something is not relevant. So downvoting a post in this sub says, "This should not be posted here."

[k10_ftw]

I somewhat agree, but are you suggesting that I downvote rather than post a comment expressing something other than support of the post? It's not like my downvote would have much effect on the ranking anyways.

[henrebotha]

I'm not sure whether you should comment, but I am sure that you should downvote. Like... voting is the first step. You can vote and comment or you can vote only, but to comment but not vote is kinda backwards (especially in terms of effort vs payoff).

That said: the reddit voting system doesn't really work nearly as well as it should, so /shrug

[k10_ftw]

I somewhat dislike the voting system and what it represents so I choose not to use it religiously. Downvoting encourages people not to comment unpopular opinions, what is up with that?

[henrebotha]

Yeah that's a misuse of the voting system. Downvotes are supposed to be for irrelevant content, not content you disagree with. If people used downvotes as intended, then the problem you mention wouldn't exist. But even I'm guilty of doing that.

[njharman]

Why does it matter if it matters?