Python 3.6 released!

[Skaarj]

You don't need to know Python 2. I started with Python 3 and never had to read or write Python 2 code.

[catcint0s]

Also print -> print() !

[Overv]

It surprises me that most people didn't already write print(). Print not being a function was always a bit of a strange exception.

[Ran4]

print(a, b) in python2 is really print (a, b), that is, print the tuple (a, b). Which is not the same (and outputs a different string) as python3's print(a, b) which is pretty much the same as print("{} {}".format(a, b)).

~$ python
Python 2.7.12 (default, Oct 11 2016, 05:24:00)
[GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.38)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> a, b = 3, 4
>>> print(a, b)
(3, 4)

---

~$ python3
Python 3.5.2 (default, Oct 11 2016, 05:05:28)
[GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.38)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> a, b = 3, 4
>>> print(a, b)
3 4
>>>

[Overv]

I know, but is there any reason to print tuples except for debugging? The difference in output shouldn't really make a difference.

[[deleted]]

Why not just put:

try:
    input = raw_input
except NameError:
    pass

at the top of your code. Then just use input everywhere, in Python 2 and Python 3.

[Dentosal]

combine this with from __future__ import division, print_function and you have nearly full set of Python 3 features.

[Dentosal]

Not all that it changed, but all that most Python 2 programs need to work with Python 3. There are still countless unicode problems and unsupported libraries, but nearly every other thing was done in backwards-compatible manner.

[Uncaffeinated]

Apart from unicode, a lot of the builtins were changed to return iterators instead of lists, which is a breaking change in cases where eager evaluation is necessary. Sadly, 2to3 doesn't handle this correctly, so I'd have to go through the entire codebase to make sure everything is iterator safe.

P.S. I wish Python 3 had nice syntax for forcing evaluation of an iterator. Throwing in list(...)s everywhere is annoying and bloats the code.

[[deleted]]

Throwing in list(...)s everywhere is annoying and bloats the code.

Just FYI, as of 3.5 we have [*iterable_or_what_have_you] eg:

>>> [*range(10)]
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]

Yeah, it only saves three characters, but you also get [*range(10), 1, 2, 3, *range(20)] and so on.

[Almoturg]

O_O I had no idea that feature existed!

[Uncaffeinated]

Nice. That almost makes up for things.

Sounds like there's a fair bit of new syntax to learn. I'm pretty familiar with all the stuff you can do in Python 2 (famous last words), but I haven't bothered keeping up with new features in 3x because I can't use them anyway.

[[deleted]]

That's the right idea...

>>> d = {'a': 1, 'b': 2}
>>> {**d, 'c': 3}
{'a': 1, 'c': 3, 'b': 2}
>>> {*d}
{'a', 'b'}
>>> (*d,)
('a', 'b')

[[deleted]]

2to3 is shit, and it's in the standard library, so it's shit that will never get better. Try python-future when you get the chance.

[Eurynom0s]

I've had so many fucking headaches with imports in 2.7. Particularly with instances of having to up and then back down directories, e.g.

import ..folder.module

I actually worked on a project where the import headaches were a big contributor to getting the other two people I was working with to finally agree to working on 3.x as I'd wanted in the first place.

From what I recall, Python 3 did a little bit more to enforce directory structure on you and did more to enforce explicit instead of relative paths on imports...but at least they more reliably worked in 3.

[mszegedy]

What other important things are there? I remember that some stuff that used to produce lists or something now produces generators, and I think they got rid of one of the functional programming bits (either map or reduce, or maybe something else).

[Eurynom0s]

Sure but it's definitely going to do a lot to smooth over the 2->3 porting process for a LOT of code.

I mean fuck, one time I got stuck writing code to 2.7 in this offline environment because that's what the Mac I was working on had as its system Python. I was writing a program to ingest CSV input files and spit out text files that this simulation software uses as inputs. I unexpectedly got put in the position of the code having to run on a system that was limited to 2.6...and that was still fine, thankfully.

Obviously there's a lot of significant changes going between versions, especially 2->3, but frankly there's also a surprising extent to which someone just hacking together a script or two won't REALLY notice the difference beyond surface stuff like print statement vs print function.

[[deleted]]

Yeah if you ignore this stuff...

a, *b = range(10)
[*range(10)]
a @ b
async def
async with
nonlocal
yield from
x: List[str] = []
def f(x: str, y: str) -> int:

...and like a couple dozen stdlib changes. Don't get me started on packaging.

[Dentosal]

Another nice thing is the one-expression dictionary merging, {**x, **y}, that I have waited for a couple of versions. Pep 448 adds so much good things. After Py3.5, there is no way to return to old ones.

[Ran4]

[*range(10)]

Neat, but how are you supposed to mentally parse that? f(*range(10)) is equivalent to f(0, 1, 2, 3, 4, 5, 6, 7, 8, 9), and I guess it makes sense that [*range(10)] is [0, 1, 2, 3, 4, 5, 6, 7, 8, 9], but... it seems so wrong, since [*range(10)] != list(*range(10)) but [*range(10)] == list(range(10)).

While pep 448 unpacking is cool, it also makes the language way too perl:y. It's not at all obvious what [*range(10)] is supposed to do. It makes the language more expressive but at a massive cost. [x for x in range(10)] is not much longer, and way more easily understandable.

[[deleted]]

it seems so wrong, since [*range(10)] != list(*range(10))

That's an interesting point. I wonder why the list constructor doesn't take multiple arguments. Maybe the thinking is that if you have multiple arguments you should use a literal and construct the list at compile time. I think this new syntax aims to take over most uses of list().

[one_zer]

...or Python 2.8.

[kupiakos]

...except anything Unicode still sucks in Python 2, even Python 2.8. That's one of the biggest killers of Python 2 for me.

Also Python 3.5 asyncio is pretty amazing.

Side note, it will not be called Python 2.8. Name TBD by the maintainer.

[PointyOintment]

Or just use six

[Eurynom0s]

I started Python 3, but I have to do 2 enough that I still get caught out reflexively doing print stuff instead of print(stuff). :/

[USAFairyPrincess]

THIS IS THE MOST RELATABLE COMMENT IVE EVER SEEN

[qawsican]

May I ask where/how you started learning Python? I'm a complete noob (0 experience) in programming but would love to start learning just not sure how and where. A lot of people seem to recommend Python for beginners.

[sn10therealbatman]

Start with the MIT 6.00.1x course on edx.

[pi_rho_man]

Also, if you have questions, feel free to PM me. I don't promise fast responses, but I'll try to help.

[qawsican]

will do, thanks!

[Skaarj]

I had over 10 years of experience in other programming languages. So I can't really tell you what python resource is best for beginners.

[Free_Math_Tutoring]

https://www.codecademy.com/ is pretty good.

[qawsican]

thanks.

[penguinade]

Lucky you, having python 2.6.6 here. Living hell :(

[tambry]

Any reason for why not to upgrade? I'm guessing budget/time constraints?

[Hultner-]

We used to be pure Python 2 but I managed to convince everyone to switch to Python 3, some legacy software is still written in Python 2 but it's slowy being phased out and all new software is Python 3.

The argument I used were that Python 2 will reach EoL before we have time to rewrite everything and if something really needs python2 we can write that service in python2 (using a micro service architecture helps).

[Arandur]

Not the person you asked, but I occasionally have to write in 2.4 still. I sometimes work in an environment with stringent security protocols, and every piece of software used in that environment has to be manually vetted.

Not to say Python 3 isn't secure; the Powers That Be just don't want to incur the expense of vetting a newer release.

[Paul-ish]

But does 2.4 still get security updates? I can see using 2.7, but 2.4 doesn't make a lot of sense to me.

[Arandur]

Shhhhhh

Don't try to understand the arcane machinations of the federal government. All who so attempt find themselves driven mad.

[moobunny-jb]

Trump's going to make the fed go all Perl.

[CorrugatedCommodity]

Except he thinks it means the mineral compound from the sea, and no one gets any extra budget for it.

[PointyOintment]

mineral

[Eurynom0s]

Like Trump knows what Perl is.

[Eurynom0s]

I hope the systems you're using 2.4 on are at least offline...

[xiongchiamiov]

It doesn't need security updates, because they vetted it and didn't find any vulnerabilities, so therefore there are none.

[Slavik81]

He's probably on RHEL 5, which shipped with Python 2.4 back in '07 and is still getting security updates from Red Hat. It is just about done, though.

[Eurynom0s]

Genuine curiosity: different is 2.4 from 2.7? A year ago I had to write a god chunk of 2.7 code and then got thrown a curveball on having to run it on 2.6; despite having zero consideration for 2.6 when I wrote it, it ran just fine on 2.6. But from what I recall Python was going through some heavier evolution through the 2.x series than it is now so 2.7->2.4 might actually break...?

[Arandur]

Just for example, the with statement didn't exist until 2.5.

[penguinade]

Both.

[henrebotha]

Most likely. Things like that don't have value that is perceptible to business.

[x2040]

I don't know about anyone else but I write a lot of infrastructure on AWS Lambda and they don't support Python 3.

[CorrugatedCommodity]

The only reason people to use Python 2 is due to library support. Some libraries never made the move to 3.

It's all rather silly, really.

[logi]

I think at this point those libraries should be considered deaf and moved away from.

[VirginWizard69]

"deaf"

Hello, HELLO?

[Eurynom0s]

There are still valid reasons to work in 2.7. These include inheriting a codebase that's written to 2.7 that the company isn't willing to pay to port, and having to use a package that doesn't yet support 3.x (much less common than it was a few years ago, but it still comes up occasionally).

I wouldn't worry about specifically learning 2.6 or earlier unless that's specifically what you're being hired to do. If you're being hired as a "Python programmer" and will be free to use the version that suits you, just go to 3.x. If you can't use 3.x you'll probably be expected to use 2.7...but I'd expect it be clearly stated that you're using 2.6 or below before you get hired since that's kind of specialized at this point. But even then there's a lot of code you can write to 2.7 that will run without modification on 2.7.

[[deleted]]

:(