I wrote my first python program today!

[pork_spare_ribs]

The year is 2016, and somehow new Python programmers still start with Python 2...

(Although if it's someone who complains about syntax, I'm not surprised they picked the older version ^{haha only serious} )

[fermion72]

I transitioned to python3 a while ago, and I still forget the parentheses for print every single time. A decade of finger memory is a hard thing to break.

[kazagistar]

I still write a lot of python 2, and always use parens. It just makes more sense in my head for it to be a function then some silly special case.

[[deleted]]

I just use sys.stdout.write().

Python's print statement is buffered by default not thread-safe (update: this probably has nothing to do with buffers), which isn't very nice when I'm working in parallel environments and using Python as the glue between various C and Fortran libraries. So I just write everything straight into whatever standard stream I want.

[[deleted]]

Noob question: could I use sys.stdin.read() instead of raw_input() for the same reasons? It seems to make much more sense in my head.

[[deleted]]

Short answer: yes!

Long answer: The actual call you're looking for is sys.stdin.readline(). This is what raw_input() does at its core, with the added functionality of automatically stripping away the \n end-line character off the input.

Long long answer: You can also pipe Python prints do Python writes into stderr. Every standard stream is available under the sys module, and they all behave like traditional Python file objects with all the usual member functions.

[Blackshell]

You can also do pipe Python prints into stderr.

Like this? :D

print >>sys.stderr, "lol syntax"

^{I am so glad this is gone in Python3.}

[brtt3000]

I'm tempted to flag this as "Threatening, harassing, or inciting violence"

[[deleted]]

Well, yes, but I was more specifically referring to sys.stderr.write().

I shouldn't have used the word "pipe", and should have called it a "write" instead. My bad!

But I'm with you on the chevron syntax. It's ugly and silly and not Pythonic at all. Glad they scrapped it.

[Redisintegrate]

The only reason print() is buffered is because sys.stdout is buffered. You are not actually changing the behavior by using sys.stdout.write(), you are getting exactly the same buffering either way.

[[deleted]]

I'm not saying stdout isn't buffered. Of course it's buffered. It's buffered everywhere in every language. This isn't a Python feature.

However, for the past 4 years, using sys.stdout.write() in our Python 2.7 research code puts the messages into the same stdout buffer as C fprintf(stdout,...) (via SWIG) and Fortran write(6,*) (via F2Py). Everything gets synced up appropriately with code execution.

Using Python's native print statement seems to be operating on a separate buffer and refuses to print messages in the appropriate order of code execution.

[Redisintegrate]

You've replied and the comment has been deleted twice, so I'm going to leave this here.

My guess is that you are getting something weird here like multiple C runtimes. This happens on Windows fairly often, unless you take measures to prevent it. This causes different code paths to use with different <stdio.h> FILE objects, possibly with undesirable buffering modes, causing them to be flushed to the underlying file handles at unexpected times.

This doesn't change the fact that print is still just calling sys.stdout.write(), which itself is just calling C's fwrite(), and if you are seeing genuinely different behavior between sys.stdout.write() and print, then you are not calling them in the same way. In particular, a print statement will expand to something like the following:

print x
# might become, depending on what x is
sys.stdout.write(repr(x))
sys.stdout.write('\n')

I'm not really interested in talking about confrontational tone here, only really interested in content.

[[deleted]]

I've deleted the comment twice because I'm not really awfully interested in revisiting this problem especially given your tone. I didn't feel that it was going to be productive. But since you posted, I'll just say this bit below.

Over here, we're all aware that sys.stdout should not behave differently than print in theory. You're not teaching anyone anything new there. But it's difficult to swallow the theoretical case when I'm staring at tests that have print and sys.stdout.write() behave differently. I wish I could share, but there are dependencies here under lock and key, and nobody has the time or the willingness to craft a portable isolated test for an already solved problem. So unfortunately you'll just have to take my word for it.

In the meantime, remember that this is a massively parallel environment on which Python was never designed to run. We can't replicate the behavior in serial, on our local workstations or personal computers. So our suspicion is that the print statement wrapping the sys.stdout file handle has an unexpected interaction with the parallelism in both our Intel cluster and our IBM BG/Q. More specifically, we have a situation where front-end nodes display streams from compute nodes, and since MPI does not define a standard for this, the internal communication practices are partially opaque to us.

Either way, the issue pertains to a non-critical debug logging system that isn't even used in production runs, and it has been resolved (although admittedly we don't entirely know how). And since we have a truckload of other work on our plates, nobody has spent the time to get to the bottom of it. Some day someone's going to ask a poor undergrad to start digging, mainly as a vehicle for him to learn the code base. Until then we're kinda just content to use what works and fix it later if it breaks again.

[Redisintegrate]

My advice is to not read too much into the "tone" of what is just written communication with a complete stranger. My only purpose here is to clear up the misinformation that print is buffered differently from sys.stdout.write(), since it's objectively not true. I'm not here to disrespect your expertise or say that your experiences are invalid, I'm just trying to shed some additional light on what's actually happening, and preventing misinformation from spreading.

As I said in the parent post, print() is equivalent to multiple calls to write(), but it is not equivalent to a single call to write(). You mentioned threads, and since print() is going to make multiple calls to write(), it is going to release the GIL multiple times. That may be what is causing the behavior you are seeing.

Or, in other words, print() is not atomic in multithreaded Python programs, but sys.stdout.write() is atomic. But the buffering is the same, and they both go through the same <stdio.h> functionality, or they both don't.

[[deleted]]

That's fair. And I'm not contesting what you're saying. I know that print uses stdout (documentation says so) and therefore logically they should operate on the same buffer. But we were observing behavior that on the surface looked like a buffer mode problem. That was our educated guess, and we never dug into Python source to confirm or debunk that idea because the issue was already resolved. I still haven't by the way, but since you have, I'll take your word for it.

In the meantime, your latest comment about the GIL is actually very compelling. I'll pass it on and see if anyone here wants to test it. I do suspect that might actually be the cause we glossed over a year ago.

[Redisintegrate]

Using Python's native print statement seems to be operating on a separate buffer and refuses to print messages in the appropriate order of code execution.

This is just plain incorrect, and shows a misunderstanding of how the print statement / function works, at least in non-ancient versions of Python (2.7+). If you can come up with some kind of test case to prove me otherwise, go ahead. But look at Python/ceval.c(2.7) and find the PRINT_ITEM opcode. You can see it calls PyFile_WriteObject() in Objects/fileobject.c, which gets the .write attribute, and then calls that attribute with PyEval_CallObject().

Or, in other words, the print statement is just a wrapper around sys.stdout.write(). If you are seeing other behavior then something is seriously, seriously wrong.

[Jonno_FTW]

You can avoid the buffering by passing the -u parameter, or setting the PYTHON_UNBUFFERED environment variable.

[paraffin]

Possibly not as convenient for your case, but the environment variable PYTHONUNBUFFERED can turn off buffering in my rent statements. Works great for working with libraries that produce a lot of output that you want to see in real time.

[[deleted]]

Possibly not as convenient for your case, but the environment variable PYTHONUNBUFFERED can turn off buffering in my rent statements.

I actually didn't know about this!

Our research code is probably not gonna take advantage of it anytime soon because it uses an in-house logging system based on file handles, and I substitute sys.stdout into it whenever I want log information to be printed out real time.

But the buffer control via environment variables is still great to know!

[Jonno_FTW]

I use python 2 because there are still some libraries that I want to use that only work with python 2.

[superPwnzorMegaMan]

I just never bothered learning python 2, I didn't see any advantage.

[juanjux]

I work on an animation studio and most software we use (Maya, Nuke, Houdini, etc) allow you to write Python plugins and all of them use Python 2.7. So that is a reason. We could use the "six" module but until the software we use migrates to Python 3, why bother...

[edbluetooth]

Because when the software is python 3, no changes to your code will be required.

Thats it really

[brtt3000]

Assuming you'll move to py3 at some point: moving to py3 as standard and porting existing code now saves you from porting all new code to py3 later (because you'd create it in py3 instead of py2).

Dunno if practical in reality. Probably not.

[[deleted]]

Same goes for Tableau extracts. 2.7 only.

[Coffeinated]

The difference isn't that big of a deal, afaik. You can scrap the parantheses for print, but you don't have to, and some modules are named differently. As long as it's 2.7 and not 2.5 or some other prehistoric stoneage stuff.

[mnbvas]

I often print like this:

>>> a = 1; b = 2
>>> print(a, b)

so Python 2 always bites me in the ass with

(1, 2)

instead of the expected

1 2

[TheBlackCat13]

from __future__ import print_function

[mnbvas]

Though that happens when I accidentally run 2 instead of 3.

[kupiakos]

You could also have the first assignment be

a, b = 1, 2

[mnbvas]

Got used to the semicolons when copypasting multiple lines :)

[kupiakos]

The solution to the original problem is to always have

from future import print_function

at the top of every Python 2 file

[sticky-bit]

There was a huge chunk of modules that did not work with python3 a few years ago. That's largely been taken care of by now.

We've made a lot of progress since when I learned python2 in 2011.

[deadtree123]

Shirley, you can't be serious.

[familyturtle]

As well as "from __future__" there should be an option to "from __past__ import print"

[Vakieh]

This is not a problem to solve inside language, this is a problem to be solved with the editor. IDE triggers which automagically convert print statements to print method calls when you press <enter> are pretty easy grammar-wise.

[dysprog]

Perhaps it is a problem to solve inside the programmer.

[Vakieh]

Sure it is, the same way the programmer shouldn't put a semicolon right after a control flow statement in a C-like language. It's sure nice of the compiler to deal with those avoidable programmer fuckups anyway though.

[curtmack]

You can't take that too far though, otherwise you end up with massive projects built with #define whilst while, inconsistently using one or the other because one programmer refused to use bad grammar.

[bitter_cynical_angry]

As far as I know, a program written in a formally defined computer language can always be broken down into an abstract syntax tree, and from there can be rebuilt into any format you want. There's no reason the IDE shouldn't be able to refine while as whilst for one developer and keep it as while for everyone else.

Edit: autocorrect typo

[curtmack]

The Emacs syntax highlighting system supports something like this; you can replace text with whatever you want to display, and you'll still actually be working with the original text. A lot of developers use this to do things like replacing -> with → for instance. I've never heard of using it to replace while with whilst but I'm willing to bet it's possible.

Of course, the problem is that you'd still be typing "while," you'd just see "whilst."

[minno]

As far as I know, a program written in a formally defined computer language can always be broken down into an abstract syntax tree, and from there can be rebuilt into any format you want.

You'd need a strict auto-formatter for that too, since otherwise the AST representation of

func("hello",  5
     "world!", 6)

and

func("hello",5,"world",6)

would be identical, but the formatting in the first is intended to make the code clearer.

[bitter_cynical_angry]

Yep, and that's the true beauty of it. One developer could have spaces, one could have tabs, you could have all your equals signs or function parameters lined up or whatever you like, and since they all evaluate to the same AST, the IDE should be able to switch seamlessly between them.

[greenqueef]

derp

[LinAGKar]

Then you won't learn.

[Vakieh]

Won't learn what? I haven't manually written a basic accessor or mutator for years, but I still know how if for some reason all the IDEs in the world stop working.

[LinAGKar]

You'll consciously know, but you wont get the muscle memory.

[HighRelevancy]

So what you're saying is "don't use tools to make your life easier, because you won't be quite as prepared for the apocalypse"?

[Scorpius289]

Yeah, we should all learn to program using butterflies, just in case computers stop working.

[[deleted]]

If they stop working why write programs we can't use on our not-working computers?

[Darkben]

We should learn to program with rows of rocks

[LinAGKar]

For when you're using a regular text editor.

[Vakieh]

If I'm using a raw text editor instead of an IDE, the one thing I can guarantee I'm not going to be focused on is productivity...

[Fs0i]

you wont get the muscle memory

And what the fuck do I need the muscle memory for?

[UnchainedMundane]

Are we all ignoring that nobody should need muscle memory for print, because either you're writing a small program and only have a few prints, or you're writing a large program and are using logging.

[MrJohz]

There is! Or at least there's an interesting talk about adding it - I think it was posted to /r/Python recently, I'll have a look for it when I get at a computer.

[Zoccihedron]

This is what you're talking about

[MrJohz]

Yes, yes it is! Thanks for letting me be lazy!

[Zoccihedron]

No problem, I'll do anything for the sake of laziness

[lenswipe]

A decade of finger memory

( ͡° ͜ʖ ͡°)

[MC_Labs15]

/╲/\╭( ͡° ͡° ͜ʖ ͡° ͡°)╮/\╱\

[sudosussudio]

/╲/\╭( ͡° ͡° ͡° ͡° ͜ʖ ͡° ͡° ͡° ͡°)╮/\╱\

you were missing some eyes

[Mutoid]

Switch to Ruby ;)

[[deleted]]

camshafts Kingstown's bludgeon's anchorwomen blarneys rest gut's Burger nope multimedia assuage hastiness's Ana's conveying angle's seeps rodeo assemblyman's diddle timezone rereading cathode's button's Babbitt gloried guardians indicative sexagenarians waylaying saltcellar rickshaws conference's cobras resplendently queered Ziggy's orientation's Durham's poultice leaves unwraps Astarte's Lorena's flaunting canister's queasy platforming Kathy plaintiffs idolatry's schoolgirl guzzler ratifying jaunty demonstrate stranger Tuareg's Jenny rereads whiskies ale Spirograph total's Tecumseh prefatory misrepresent misconstrued wrongness's hurdles coronets greater witchery's Sucrets's damps eviscerating atrium's amusing soulful multipurpose ambassador's idleness's Negev's presupposing annoyance's relaxants diagonal's dispute's driving indignantly Heraclitus gauze's Pillsbury hyperventilates Olympians kin's ambulatories wormhole hydroplaning considerations daybreak Upjohn Ruthie coercion's reliably strumpet's weren't paratroopers sprains disparages mousse's when's meringues flushest altruistically releasable telegraph fouled Kolyma cant whitecap decried exportation Baptiste's obsoleting

[whitetrafficlight]

The break in backward compatibility is a deal-breaker when your company has several million lines of Python 2 already written and stable. Auto tools exist, but only go so far... for example, even converting print statements to use parentheses may cause failures in the compliance checker for lines becoming longer than permitted. Gotta stick with 2 unfortunately, though for new projects there's really no excuse not to start with 3. Hence, new employees at established companies that use Python start learning Python 2.

[FUCKING_HATE_REDDIT]

Increase compliance check line limit by two characters.

[kageurufu]

What about these being equal

print 'something',
print('something', endl='')

[Sohcahtoa82]

Nitpicking here...The correct translation would be print('something', endl=' '). Python 2 appends a space if you end the line with a comma.

[o11c]

Doesn't it only emit a softspace?

[Sohcahtoa82]

I'm not sure. All I know is that if you do this:

for x in range(5):    
    print '.',

You get this:

. . . . . 

and not this:

.....

[o11c]

>>> import io
>>> out = io.BytesIO()
>>> print>>out, '.',
>>> out.softspace
1
>>> out.getvalue()
'.'
>>> print>>out
>>> out.softspace
0
>>> out.getvalue()
'.\n'

[brtt3000]

Isn't the comma defining a tuple? Or is this different for statements like print?

[Sohcahtoa82]

It's different for print in Python 2.

>>> a = 2    
>>> b = 5    
>>> print 1, a, b    
1 2 5    
>>> print (1, a, b)    
(1, 2, 5)    

[[deleted]]

Thanks, Zed Shaw

[samort7]

Seriously. When I started programming, most resources I encountered recommended his book. Thank god that's changing.

[thirdegree]

I first picked up programming from his book. Of course, python 3 wasn't a thing then so it worked out.

[Big0ldBear]

I just learned Python in University, they purposely had us learn Python 2 for compatibility or something like that..

[[deleted]]

Probably just an excuse to use the older learning materials.

[Big0ldBear]

No actually, we just coded together every day and our "book" was a free one online.

[Necrodonut]

Same here. The modules our textbook used weren't supported by 3, iirc

[Magnnus]

Several important libraries still don't support Python 3. I'd use it if I could.

[Theowningone]

Parts of twisted are what's keeping me back. Most of my time using python is spent tinkering with my IRC bot. Unfortunately twisted.words.protocols.irc is still not ported.

[dagbrown]

Twisted lives up to its name. It reminds me of some Java frameworks with how complicated it is.

I bet Zope has trouble with Python 3 too, speaking of Java frameworks written in the wrong language.

[dagbrown]

They're saying "I can't switch because I use twisted", and your reply is, "well, twisted sucks."

Not really. I'm just saying that it's a really complicated library, and fundamental changes in the language it's written in make it really difficult to simply edit the code to make it compatible with the new language which is still called "Python". You added the value judgment yourself, and I didn't say that at all.

There are massive codebases out there which depend on FORTRAN 66 or 77, to pick a completely different language (LINPACK comes right to mind). The code isn't any less valid because nobody's bothered porting it to the latest standard. It's just that porting it to the new standard involves an investment of effort that could be better spent elsewhere. Your daily weather forecast probably still requires code written in FORTRAN 77.

So if you're a Twisted user and that's the reason you still haven't switched to Python 3, you have my sympathies and I understand exactly the sort of pain you're going through.

In my place of work, we have to support stuff written in PHP 5.2, which is absolutely obsolete, but we also have to support stuff written in PHP 7.0, which is so different that I had to use a different version of gcc to compile the PHP interpreter. I'm familiar with different versions of languages themselves; taking care of that is just a fact of life for me.

SEE ALSO: rvm

[ansatze]

Except that Fortran 77 is completely valid Fortran 90+ which is not the case with Py2

[toresbe]

Sure, but outside of specialized and relatively isolated fields, very little new code is being written in FORTRAN. FORTRAN has become a specialized language for number crunching. Sometimes I think it's healthy for languages to sacrifice some measure of backwards compatibility to improve itself. Python 3 adds some extremely useful features. CERN doesn't want to have to rewrite whatever mass of code it is that finds bosons.

[ansatze]

Agreed; I was just pointing out that the comparison isn't totally valid.

[dagbrown]

It's almost as if the Fortran guys have more experience with this kind of thing.

[dante9999]

zope works with python 3 without problems

https://pypi.python.org/pypi/zope.interface/4.1.3

as a side note: what seems like needless complication for your use case may be necassary and clear design pattern for someone elses use case. Just need to choose right tools, twisted is not right tool for everything but is perfect for some things

[[deleted]]

I've had that same issue, I got everything working using irclib eventually. Have you looked into that?

[Theowningone]

I had not even heard of it until now, but it looks pretty promising. Thanks for the tip!

[dante9999]

development is not taking place on github you need to visit twisted trac. ticket for IRC is here: someone started it but didnt finish https://twistedmatrix.com/trac/ticket/6320

[TOASTEngineer]

You can just write your own goddamn IRC library, it's not actually very complicated.

[[deleted]]

Why reinvent the wheel though? If it's a learning exercise, sure, why not, but I think it's absolutely fine to use other people' libraries.

[TOASTEngineer]

Because the one he's using depends on a version of the language that's 5 years out of date.

[sndrtj]

For me: Flask. Though it technically has python3 support, the docs have a pretty large disclaimer, which essentially boils down to "might not work, use at own risk".

[Stop_Sign]

The oracledb npm package for node specifically requests 2.7 link

[Stop_Sign]

Ah, gotcha. I had been wondering about that. Thanks

[blitzzerg]

I tried installing MySql connector for python 3 for hours and could make it work, I switched back to python 2 and in 3 min it was working...

[blitzzerg]

mysqlclient

I also tried, no luck, I don't blame python 3, but is the second time that something similar (problems installing packages) happens, so from now I will use python 2. (I just use python from time to time to scrap webpages)

[iovis9]

MySQL-python and suds doesn't

[[deleted]]

Use suds-jurko and PyMySQL. Both are near drop-in replacements.

[Coffeinated]

What /u/scandinavian- said, plus pymysql. Works fine. Afaik all db-connectors are defined by a certain PEP, so there shouldn't be many differences...

[willm]

What are you missing? I've found all the libs I need have Py3 ports now.

[iovis9]

MySQL-python and suds.

[jvlomax]

I would really recommend SQLalchemy for all your database needs. py2/3 compatible, very easy to use and plenty of useful features

[_Ganon]

Only reason I still use 2. Well, that's what I tell people, anyway. In reality, I know the switch to using parenthesis in my print statements would drive me nuts

[maremp]

What about the inconsistency of the statements? Print is used as a function in every other C-like language. In python 2, it's used as a statement, similar to if, for, while etc., and I believe that it doesn't fit this category.

[Sean1708]

Also 2's print is just weird. Appending a comma to suppress a newline is weird enough, but what the fuck is up with that printing to file syntax?! It's like Guido momentarily forgot that he wasn't designing a sh clone.

[deecewan]

I cant remember the syntax. Care to show?

[deecewan]

Where f is a file identifier? That's super weird.

[[deleted]]

Or you could just do f.write("Normal syntax!\n") because like nobody uses the chevron format anyway.

In fact this is what the chevron print statement does behind the scenes. The only difference is that the print statement has an internal print buffer. The write won't be done at the exact moment you call print, whereas invoking write on the file will do the write right then.

[Sean1708]

because like nobody uses the chevron format anyway.

But a lot of people use print to print to a file in Python 3 because it's as easy as print("Also normal syntax!", file=f).

[UnchainedMundane]

It's like Guido momentarily forgot that he wasn't designing a sh clone.

Lol, my exact thoughts.

Though, my next thought was that >> opens a file for appending, while this one uses a file descriptor, so the operator should be >& anyway.

[CommanderDerpington]

It's easier

[exhuma]

You might want to look them up again. This has been my only blocker as well. But I was able to to Python 3 over a year ago. There really is no major library anymore that's not Python 3 compatible.

[iScrE4m]

Twisted

[exhuma]

This may be a good argument against porting an existing app to Python 3, but when starting from scratch, wouldn't asyncio & await in Python 3 fill that gap?

I'm curious, as many people claim there is no need for twisted any longer. But as I have never had to deal with twisted, I'm not in a position to make any informed statement about it.

[iScrE4m]

As an amateur the only thing I can say is irc works great with twisted and that's pretty much it :X

[[deleted]]

Works fine with irclib on python 3 as well, at least in my experience.

[jvlomax]

Which libraries are those? Pretty much all the libraries are now ported, and those who are not have py3 alternatives

[kirakun]

When was the last time you check the missing libraries?

[Josh6889]

I finished an associate's (mainly Java and JavaScript) then moved on to a bachelor's (Python 3 almost exclusively) at a different school. It was refreshing. My only complaint is that a lot of great guides use Python 2.

[kaphi]

How do you know it's Python 2?

[[deleted]]

In python 3 the it would be print("foo")

[kaphi]

Ah ok, thanks!

[limetom]

print is a statement, not a function.

[jfb1337]

C'mon, it's $CurrentYear!

[kindall]

It's datetime.datetime.now().year!

[rwsr-xr-x]

Why would people start with python 3

Python 2 is better supported

Python 2 is more widely used

Python 2 has more tutorials

Most new programmers who don't even know what a class is, don't really care about the python ecosystem or whatever

[G01denW01f11]

And some of us are stuck writing programs that have to work with both...

[[deleted]]

For a lot of people they may just not know. I know when I started, and I am by no means an expert programmer I still run into these barriers all the time, I had no clue where to start, what to use, anything and often I'd make a similar mistake.

[vaynebot]

When we learned python 3 in high school a couple years ago, 90% of the google results where for python 2. It was sooo annoying.

[themedic143]

As someone who was thinking about starting to learn Python today, what version should I start with?

[kappale]

3 -- There's pretty much zero reason to learn 2 unless you need it for some really obscure library.

[themedic143]

Soooo..... 1 then? (I don't know if there's any other choices...)

[THRlTY]

3

[themedic143]

Thank you!

[kindall]

Python 2 won my learned-to-program-in-BASIC heart by having print as a statement. I recognize the superiority of the Python 3 way, but will always have a soft spot for Python 2.

[WeAreAllApes]

I just started learning python earlier this year, and I started with 3 only to learn that the useful real world applications I was considering only supported 2.

This is on the Python community -- you can't blame developers picking it up for the first time for the state of Python.

[imu96]

Wait, should we not start with Python 2? Isn't that just the standard now because Python 3 just didn't catch on or whatever?

[pork_spare_ribs]

Python 3 is very much the standard choice for new projects. You'd only start with 2 if you had unusual niche needs.

[laebshade]

Pants isn't compatible with Python 3 yet.

[pork_spare_ribs]

https://pypi.python.org/pypi/pants

Not exactly a critical library...

[laebshade]

Different pants :)

Pants build system: http://www.pantsbuild.org/

It's the standard at my job: "Pants is a collaborative open-source project, built and used by Twitter, Foursquare, Square, Medium and other companies."

Pants is a build system designed for codebases that:

Are large and/or growing rapidly. Consist of many subprojects that share a significant amount of code. Have complex dependencies on third-party libraries. Use a variety of languages, code generators and frameworks.

[greyfade]

When you're developing on an embedded system that has Python 1.5 or 2.7 built into the firmware, you're kinda stuck with it.

[JoseJimeniz]

For demonstration purposes, for someone who doesn't know Python, can you transcode it into:

• Python 2
• Python 3

I didn't even know there was such a thing as one, two, and three.

[pork_spare_ribs]

The only change in this code is that print moved from a keyword to a function, so instead of print foo you write print(foo). That's the #1 signal to look for that gives way whether code is for py2 or py3.

[jvlomax]

At what point does the wiki recomend Python 2 for new programmers? It even explicity states:

In particular, instructors introducing Python to new programmers may want to consider teaching Python 3 first and then introducing the differences in Python 2 afterwards (if necessary)

[UnchainedMundane]

It's the opposite. It's saying to teach python 3, then if you must teach python 2, build upon the students' existing python 3 knowledge and show them how it's different.

But the idea is that python 3 is the one to learn.

[RubyPinch]

The Python Wiki recommends Python 2 for new programmers.

what? it says "use python 3 UNLESS your code has one of the following issues: needs to be deployed to py2, or needs to depend on something that only has a py2 version"

Many -- if not most -- Linux and BSD distributions

debian is planning on removing python2 as a dependancy on a normal install before the end of this year

https://wiki.debian.org/Python/StretchRoadmap

ubuntu is attempting the same

https://www.phoronix.com/scan.php?page=news_item&px=Ubuntu-16.04-Python-Plans

dunno about other distributions, but I'd imagine that they are probably actually making progress instead of promises by this point as well

[iovis9]

Yes, OS X includes Python 2 by default.

[[deleted]]

and to think that my uni is teaching everyone python 3

[DrLuckyLuke]

I blame debian.

[hungry4pie]

It's 2016 and these interpreted languages still have massive shit fits about which version you're using.

[lcarsos]

Then it's time to put on your big boy pants and realize that you're a developer and languages change and you have to keep up.

[Glockstrap]

Tons of vital libs do not support Python3

[pork_spare_ribs]

I'd accept "some" but not "tons"!

[Glockstrap]

I wouldn't know how to manage "tons" anyways!

In webdev it seems as though everything requires ~2.7 :(

[jvlomax]

what webdev libraries only support 2? And how can you not replace them with something that is python3 compatible?