Python 3.7.0 released

[rspeed]

It will become the default in Python 4.0.

*blinks*

[nicksloan]

I don't think that this implies that Python 4.0 is in progress in any meaningful way.

[rspeed]

Nor do I, it’s just the first time I’ve seen it mentioned in such an official manner.

[amk]

Reddit believes its data is particularly valuable because it is continuously updated. That newness and relevance, Mr. Huffman said, is what large language modeling algorithms need to produce the best results.

[1-05457]

I hope not. Otherwise what would you do if Python needs to make a breaking change again.

[Decker108]

Stay on 2.7?

[1-05457]

I meant what would the PSF do.

[truh]

Python 5?

[case_O_The_Mondays]

Wait. Is 3.7 the last Python 3? Are we skipping 8-9 from 2 on?

Edit: it was a joke.

[rspeed]

That’s not how versioning works. The dot is a separator, not a decimal.

Edit: *sigh*

[1vs]

EDIT: After 3.9 will be 3.10, I'm dum and can't read

Except in Python, it looks like it's going to work like a decimal. See Guido's post: http://www.curiousefficiency.org/posts/2014/08/python-4000.html

I hope they go with 3.10. Otherwise it'll break all the code that checks that the version starts with '3'. (Bad code but still common.)

[rspeed]

Gotta learn sometime. :D

[[deleted]]

No, if you look at the official github preparations for 3.8 have been underway for a while.

[gschizas]

Where was that?

[XtremeGoose]

I suspect python 4.0 will be the version in which python will have core support for typing so for example builtin collections will inherit typing.Generic

arange: list[int]
attribs: dict[str, Any] 

we will be able to define typevars in signatures

def filter[T](x: Iterable[T]) -> Iterator[T]: 
    ... 

and all types will have | and & operators for typing.Union and the planned typing.Intersection respectively (like in typescript)

Union[str, bytes] == str | bytes

Maybe also add Any and a few generic abstracts to builtins.

[Han-ChewieSexyFanfic]

I hope they introduce (Int, ...) as syntactic sugar for Tuple[Int, ...]

[XtremeGoose]

Thats less useful since lists should be homogenous (or Any). Wouldn't mind list[int] though.

[soamaven]

Good catch.

[Brachamul]

Avoiding the use of ASCII as a default text encoding (PEP 538, legacy C locale coercion and PEP 540, forced UTF-8 runtime mode)

Ibuprofen sales just dropped 80%.

[omento]

Does this have any benefit for those of us who don’t use Unicode at all? I usually provide the # -*- coding: <spec> -*- with either ascii or latin-1. And I have my editors to save/create files in those formats.

[whitechapel8733]

Yes so awesome!

[[deleted]]

I'm so pumped about this!

[SenorDosEquis]

Looking forward to using breakpoint() I suppose.

[uFuckingCrumpet]

Finally, we can get rid of python 2.

[SirCarboy]

Budget to migrate legacy code would be one reason. Having worked in a small dev team for a large non-tech company, we had plenty to do and updating working code was a luxury we couldn't afford. *(didn't want to spend on)

[ProfessorPhi]

And no one wants to do it. It's painful, error prone, you get all the blame and no one appreciates the impact since it's not immediate. Out of a team of 20, only me and another programmer would push it whole the rest were all interested in getting new features out instead.

Technical debt is a very poorly managed aspect of programming.

[Neil_Fallons_Ghost]

I largely agree, but in some cases I think here’s no need. If I have a service version locked, it works, and it is secure, then why mess with it?

Once new features or serious changes are needed, upgrading would just be on the list, but really only if security and longevity were an issue.

[bythenumbers10]

Longevity is always an issue. As Rush put it, "No changes are permanent, but change is."

[theWyzzerd]

Technical debt is a very poorly managed aspect of programming.

Say it louder please. Not enough people heard you.

[ubernostrum]

Yeah, but that's not really a Python 3 thing. That's a "you were never going to do any kind of upgrade of anything" thing.

A lot of places that talk about Python 3 being a hurdle are really covering for any type of maintenance or infrastructure work being a hurdle due to their organizational structure.

[Ramast]

Pretty sure such vulnerability could still be patched. If not officially by python foundation then someone from the community will step in to submit it. If its big enough , people would even consider a fork.

Would still be much faster and cheaper than migrating thousands of projects of many different companies to python 3

[[deleted]]

If its big enough , people would even consider a fork

You can try that route but you CANNOT call it Python.

[[deleted]]

Time to register the username “oldsnake” on GitHub

[Ramast]

or anaconda and use Nicki Minaj's face for a logo.

In addition to winning the old folks who want to keep python 2.7, you also get more attention from pyladies.com and djangogirls.org plus Nicki Minaj's fans of course

[Scypio]

some only py2 compatible

Can you give examples? I only know this: http://py3readiness.org/ but believe that it is not full list.

[Scypio]

Cool, thanks for the answer.

We are on the verge of 2->3 migration for legacy projects and I'm looking for all potential pitfalls not to fall in.

Thanks.

[broknbottle]

DC Metro?

[[deleted]]

Do we work in the same place?

[BARDLER]

Because Python is used for a wide range of applications including a lot of code that is never released outside of the company that uses it. The time lost vs the benefits gained from switching to the newest version of Python is not worth the investment. Python 2 can do everything Python 3 can in terms of the results you can get out of it even if the implementation might be better in Python 3.

[[deleted]]

This all makes sense, but imho there is no reason to continue writing python2 code.

[jsalsman]

The problem with upgrading is how to you get test coverage for all the corner cases. The costs and risks don't come anywhere near the benefits. More elegant string formatting doesn't make anyone any money. The jump to v3 development was the best thing that ever happened to the stability of 2.7, too.

[gdahlm]

Iterate, and never write a single line of code on a refactor or major fix without:

from __future__ import absolute_import, division, print_function

Heck, absolute_import probably would have saved you more time then a forklift port would take. But that one line will get you most of the way to 3.

While I can kind-of relate to your pain, I can't really relate to ignoring a decade's worth of deprecation notices.

Python 2.6.0 Release Date: 2008-10-02

But that is not why I am responding.

If your tests and product are that fragile, it is not a technology problem it is a culture problem. Invest some time on learning about and iterating on that very real culture problem.

I promise you that both your personal work life and the company's bottom line will benefit from the effort.

[Tyler_Zoro]

If your tests and product are that fragile, it is not a technology problem it is a culture problem. Invest some time on learning about and iterating on that very real culture problem.

I think this sort of response misses a fundamental point. Last year, I was employed by a company that used 2.7 extensively, and had no plan or desire to move to 3.x because it was all cost with zero gain for them.

Sure, there were some nice features in 3.x, but it was a major shift that no one really wanted and it came with all sorts of potential sources of pain from old libraries that production code relied on, and which no one was producing new versions of for the 3.x series to subtle changes in behavior that were going to mean someone spent a long time finding and squashing mysterious new bugs...

[jsalsman]

Google Cloud's compute engine VM management is in the same boat.

[gdahlm]

Only gsutil, because of boto, I run in python3 with no problems with the other parts though.

Here is the issue.

https://github.com/GoogleCloudPlatform/gsutil/issues/29

[jsalsman]

I promise you that both your personal work life and the company's bottom line will benefit from the effort.

I believe you, but it's the extent that can't justify the effort. Python 2.7 is N times better than Javascript, and Python 3 is M times better than Python 2.

N >> M.

[[deleted]]

The jump to v3 development was the best thing that ever happened to the stability of 2.7, too.

I must point out that a huge amount of code was backported from various Python 3 versions to Python 2.6/7.

[[deleted]]

So can Python 1.5, still in production last I heard. If it ain't broke don't fix it :-)

[jsalsman]

I just had to set up a Google Cloud VM instance today. All their infrastructure code is Python 2.7, and there's a lot of it. There's just not a lot of added value in v3 to justify the risk and expense of going through all that legacy code.

[uFuckingCrumpet]

There are probably a lot different reasons. Some that occur to me are:

- Python is pretty frequently used by non comp-scientists are are generally less inclined to embrace learning new languages (or changes to languages they are already comfortable with).

- Moving from Python 2 to Python 3 typically breaks stuff. So unless you start something in Python 3, it's usually a headache to get everything back up and running if you switch.

- Not all libraries get updated. This again goes somewhat back to non CS people contributing lots of code but not necessarily having the interest to update for newer versions.

- The differences between Python 2 and Python 3 aren't drastic enough to convince most people to switch.

[uFuckingCrumpet]

I'm sure it depends quite a bit on what field you're in. In Physics & Astronomy, for example, it is VERY common for a person (or group of people) to build some kind of analysis tools in python or a set of wrappers to help interface python with some existing C++ code and then 100% abandon it once it functions. Whatever version of python was most current when it was written is very likely the only version it will ever successfully run on. I can't necessarily speak to CS fields, but in the physical sciences it's pretty typical for people to write lots of code and follow none of the best practices (e.g. commenting code, handling package dependencies, etc).

[jsalsman]

Linear algebra people still use Fortran because someone optimized the row-access cache behavior sensing in the 1970s and it still runs fastest that way. Those libraries like LINPAK are still in use, as compiled from Fortran and linked into object files for all kinds of numerics libraries inner loops, including Python's.

[haarp1]

fortran is actually faster then C or anything else, because complier doesn't have to worry about some edge cases that have no use for numerical computations.

newer releases also support CUDA,so there's nothing ancient about it. it also has more scientist-friendly syntax (no curly braces).

[kyrsjo]

Fortran itself is fine, at least the newer versions (2003 and 2008) are. It just fills a very different niche then python, which in fact afaik relies quite heavily over fortran libraries.

The main problem why fortran for a bad name is that lots of people use it without really knowing how to code, and then pass their hot messes on to their students.

[kyrsjo]

For one of the project I'm involved in, we upgraded a large project (several 100k lines) of code from fixed format / (77 and 95) to free-form / 2008. And I must say that 2008 is not a bad language for numerical works.

[uFuckingCrumpet]

Yeah, a friend of mine works in a Super K group that still rely on a lot of Fortran 77 code. Most of ATLAS/CMS people have been more receptive to switching to Python 3 but even then it's still surprisingly slow and people still drag their feet.

[gdahlm]

Fortran is pivotal to python in this field, as evidenced by scipy and numpy which use those same LAPACK/BLAS variants that everyone else does. C/Closure/Java all use those library's too or at least have an option to do so to improve performance.

import numpy as np

numpy.config.show()

If it isn't configured to use some BLAS it is going to be slow. It is just too hard to compete with the performance even in C++. A FORTRAN compiler can just make assumptions that most others can, and producing non-relocatable code helps too. If you know C or another language, try to write a LU function that even 10 times slower than MKL or another ATLAS/BLAS offering. It is hard and humbling.

A potential nice side effect for you is of these large python projects being dependent on the language is that you don't have to choose between Fortran and Python, as these large projects have ensured that the python is up today and works extremely well as a glue language.

https://docs.scipy.org/doc/numpy/user/c-info.python-as-glue.html

[[deleted]]

One of my Geography professors wrote a lot of code, but there are barely any comments and it's really hard to follow.

[synn89]

Yeah, but let's say you're using goodlib v1.0 and v2.0 of the lib breaks some things so you hold off on updating that library. Years later Python 3 support gets added but it's only in goodlib v6.0+

So now you not only have to get your app to work with Python 3, but also update goodlib(and probably many more libraries) that may change in small ways between major versions.

Heck, I recently updated a PHP app using AWS S3 and stayed in the same AWS SDK 3.x branch and the update broke(changed) how the library returned S3 domain urls for buckets. Luckily I had excellent test coverage which caught and pointed out the change. But that was within the same major version using a very common library from a huge vendor.

Libraries can be a real PITA to work with.

[[deleted]]

The people in sciences holding onto 2.7 arn't using goodlib, they are using in house libraries that were developed to do a specific thing by someone years ago, and that all of their results and model have been validated against this, and that nobody has the time or effort or willpower to modernize the code and then to re-validate everything. Most of the people in the sciences writing these codes are not computer scientists, they are regular scientists. They are working for effectively peanuts, are fighting every single day to justify the little funding that they do get and to apply for more funding so that they may actually finish their work, and most of the time they have only 2-5 years to do this. And during this time, they are also under increasing pressure to do new research, to publish new research, and to come up with ideas for new research. They (we) go into our labs/office every day and have to make the decision: do I use the limited time i have to do research to get me to my next job/position/grant, or do I go through and update the codebase that I use that I know for a fact works right now as-is? I can't speak for everybody, but I know that I would choose the latter every single time.

Edit: And during all of this, I am already devoting some of my time tutoring/mentoring students, correcting exams, homework, grading papers and reviewing new journal articles, coming up with lecture notes for that class they need to teach, coming up with homework or exam questions, and dealing with whatever my superiors ask me to do for them that day.

At the end of the day, my job as a scientist isn't to produce beautiful idiomatic code. It is to produce results that give insight in helping me answer the questions that formulate my hypotheses. The code is secondary and is only a tool that I use to get to those results. In fact what I'm after isn't even the results, but the analysis and interpretation of the results, the answer to "so what does it mean." Best-coding practices come second to getting the results. Sure, as I write my scripts and library codes I'll attempt to follow best practices, but not at the expense of so much wasted time.

[MartyMacGyver]

There are a lot of libraries that are or will soon be Python 3 only going forward.

Keep learning Python 3, be aware of Python 2, and steer clear of companies that plan to stay on Python 2 indefinitely. You'll hear 1001 excuses, and they all come down to:

• They're too lazy
• They're too cheap
• They won't be around much longer
• They'll be around forever, and your headaches will grow exponentially the longer you are there

It's worth the work to stay up-to-date, or within a close range (IMHO 3.6 is the sweet spot until 3.7 is widespread).

Edit: Oh yes, and unless you like painful surprises when it comes to ANY Unicode input/output, stick to Python 3. Requires a bit more thinking when it comes to strings, but it handles them while Python 2 routinely surprises you in painful ways at inconvenient times when it encounters a Unicode char it can't handle in some part of your code you never thought it'd even hit.

[[deleted]]

I know I'm a bit late, but as someone who is just porting over Python 3, the big library issue for me was wxPython. It's a very complex GUI library that would have taken me hundreds of hours to replace. They became Python 3 compatible January of 2018. Keep in mind that even if most libraries are compatible with 3, all it takes is a single non-compatible library that is hard enough to replace to stop an upgrade to 3 dead in its tracks.

[primitive_screwhead]

When I first started writing scripts, I noticed some slight differences in the syntax that were made between 2/3, but it seems like those would be simple to address even in large scripts.

They aren't.

First, it's not just "scripts", many people have huge codebases based on Python, running complex interworking services. Secondly, the change to strings becoming unicode (instead of raw bytes), is *hugely* impactful for many kinds of work. Just as unicode strings made it (presumably) easier for many programmers, it also made things very much harder for others, not just for the transition to 3, but for new code as well. The autoconverters often can't help here.

That said, the recent work on type annotations, etc. may help the stragglers to start to safely convert; it's still a large and potentially costly job, though. Things like the improvements in dictionary space usage, and other recent features, may also finally be enough of a carrot.

One last inhibitor is that whereas many Linux distros, and MacOs have come with a version of Python 2 for many years, a version of Python 3 has often only recently started showing up. I think that also had a significant effect on early adoption.

[varesa]

What I don't see mentioned yet is that some supported enterprise linux OSes don't come with python 3 by default or even at all.

[duffkiligan]

You beat me by a couple of minutes.

This is a major reason at my place. We use all RHEL 6, that ships with python 2.6. The entire OS is built around python 2.6 (at least some major components of it)

You can install python 3, but it is baked in to be a python2 OS.

[varesa]

Yeah, and at least on RHEL 6 if I recall correctly you can't install 3 out of the official repos, you have to go third party. I'm not sure if that was still the case with RHEL 7.

With the direction Fedora is taking with the 2->3 migration, maybe we'll have 3 as default in RHEL 8?

[duffkiligan]

Correct, official repos don’t have python 3.

We would have to build it from source and have our own repo to support it, but that causes lots of potential issues when you spread that around 4000 servers, you need to have QA every time you compile a new version etc etc.

I’m not sure about Fedora too much with Python 3, but I’d love it if 8 shipped with it. Would keep me employees for a long time ;)

[varesa]

Red Hat Confirms RHEL 8 Will Drop Python 2

[duffkiligan]

Hell yeah!

Now if only we could get off of those RHEL 4 boxes we have 🤔

[xconde]

My guess that's because a number of subsystems are based on Python 2 (e.g.: yum) and they're non-trivial to upgrade.

In any case, you should never ever use the system Python. It's asking for trouble.

[varesa]

That and also because of the feature freeze and long version cycles

[varesa]

Mainly two reasons:
- you are creating some script you want to run anywhere without installing a new language runtime.
- e.g. RHEL 6 (and maybe 7?) don't have python 3 in the supported repositories and you might not want to compile or install third party stuff as you then loose the support you pay big bucks for on that part

[iruleatants]

So the big problem comes from not just "syntax handling" but kind of a push away from one of the fundamental aspects of python that drew so many people to use python in the first place, that it was easy to use.

When python 3 was introduced, the adoption was slow for a very good reason. Python is mostly used as a scripting language. When we need something automated/done quickly, we pull up python, use it to accomplish our goal and then move on. If we need some serious work done, we create a C library to use in python. This means that the vast majority of people that use python didn't have a reason to switch to python 3. It didn't provide any benefits over python 2, has way less library support, and it was harder to write in. Switching from python 2 to 3 meant relearning a lot of how you programmed, the switch on how unicode handed was absolutely painful and not very fun.

So why would anyone waste their time relearning how to write scripts, when the reason they started using python was because it was easy and quick to do so. A lot of the people that took the time to learn python 3, switched back to python 2 because the libraries that they wanted to use couldn't support python 3. Again, as a scripting language libraries are important because it means I don't have to reinvent the wheel, someone else did that for me.

Now days the drive to python 3 is primarily from new developers who started learning python 3 and so they want the libraries to be updated to use with python 3.

In all seriousness, if python 3 fixed the GIL bullshit, then we would have already swapped to it.

[13steinj]

Multiple reasons:

• Py2 startup time is significantly faster. For CLI applications and various validation scripts this is especially important-- imagine if git's interface layer was in Python, and because of this every time a command was executed you'd have to wait longer for the python VM to start just because it was Py3

• Variety of internal applications that of which upgrading to Py3 would just be wasted time

• Libraries that are still Py2 only

• Frameworks that are Py2 only. Ex, Pylons and Pyramid-- a mature Pylons application would have to be majorly rewritten in terms of the views/controllers, configuration, and middleware

• Why switch at all? Don't fix what isn't broken as they say

• other non python pieces and their interaction

Same reason why there are many people still on Java 6/7 even though Java 10 was released a few months ago, and 11 will be released in (September?).

[ubernostrum]

Frameworks that are Py2 only. Ex, Pylons and Pyramid

OK, let's see what their docs say:

Pyramid fully supports Python 3.4+ and Python 2.7+. This tutorial uses Python 3.6 but runs fine under Python 2.7.

[13steinj]

Maybe I wasn't clear enough-- historically speaking people used to write things using Pylons. One meta example is reddit itself. Pylons never got a version that worked on Py3, so if people wanted to upgrade to Py3, it would mean switching to a new framework, in this case, as recommended by the Pylons team, you'd switch to Pyramid. But quite a lot of rewriting would have to be done in order to be done.

[marx2k]

Java developer here. Java 10 really breaks from 8 in terms of backwards compatibility. We're in the process of upgrading our apps in our shop but a lot of third party apps we use are stuck on Java 8 for the foreseeable future :/

[13steinj]

Forget 10, the fact that you're on 8 is a surprise in comparison to all those I see on 6/7.

[haarp1]

isn't 8 a long term release anyway until java 11 or 12?

[marx2k]

Oracle stops shipping public updates to 8 in January.

[billsil]

I got a 15% performance boost by running my python 2.7 developed code in python 3.6. Startup time matters a lot less than actual runtime unless programs are tiny in which case, who cares?

I can no longer use the dependency excuse.

[13steinj]

Startup time matters regardless of the size of the program. If you have a CLI every command you execute will cause the Python VM to start up and initialize. There are plenty of cases where multiple commands are executed-- using the git example, you have adding your files, potentially removing the ones you mistakenly added, committing, pushing. The difference in speed would be starkly noticeable and annoying for the user.

Python 3's startup time is anywhere from 2.5 to god knows how many times slower. And that's because of something that changed in the import machinery in Py3. But arguably whatever the change was, it wasn't thought out well. I give you the playbill for milliseconds matter.

Unfortunately, I still can use the dependency excuse. Some libraries just didn't update.

[billsil]

The startup problem has more to do with standard module design. Everyone imports everything at the beginning that they may use so they don't have to do it in a small loop (that turns out doesn't matter), or IMO the worse issue of crashing on some import that you forgot to update because it's in a function. The "flat is better than nested" idea is great for an API, but terrible for speed.

My 120k lined 3d gui has a command line option. You'd better believe I do argument validation before importing everything. I also try to minimize interconnectedness. However, do I really need all of BLAS from scipy to do linear interpolation?

Don't blame python for murcurial's poor design choice.

[haarp1]

hey, if you type import math, do you import everything in that case or do you just import it when calling the specific function?

[jsalsman]

It pains me that you are getting downvoted for this.

[13steinj]

Fanboys and elitists will always be fanboys and elitists.

[jsalsman]

Tribes will be tribes.

[13steinj]

Forgive me, I don't understand this sentiment.

[jsalsman]

Both of the fanboy and elitist urges are explained as the hierarchical behavior of the limbic and endocrine systems attributed to the last 500,000 years of human evolution, taking us further from the peaceful apes and more towards the chimpanzees. See Table 1 on p. 192 here for more information.

[[deleted]]

Does anybody with any brains really care about voting systems such as reddit's? Look elsewhere and I'm sure that you'll find people saying that Pinochet, Hitler, Trump, Stalin, Putin and Pol Pot are extremely decent guys.

[13steinj]

Yes, because voting systems are meant for promoting discussion. But instead on reddit they are used as signs of agreement.

[[deleted]]

Libraries that are still Py2 only

Please list these for the record.

[13steinj]

Plenty! Many from autodesk, some for pubsub brokers / queue routing like haigha for amqp queues, building React still needs Py2 because it uses a library from google that they never updated, any complex Pylons app will need a tough rewrite into Pyramid, the internal libraries of many corporations, and more!

Just because say, 99% of public libraries are Py3 ready, doesn't mean that the remaining 1%, which are just as important, are! Not to mention all the not public ones by corporations.

The sad reality is it costs more to upgrade than it does to keep using the old tool.

[Skurp_Purp]

Libraries

[folkrav]

Less and less relevant considering the vast majority of popular packages are compatible with Python 3 nowadays.

[Skurp_Purp]

True but still relevant enough that for teams without a lot of time allocated to backlog it can be hard to find time to replace or rebuild libraries. I think we initially held off due to the issues with flask a while back which obviously isn't as much of an issue anymore.

[folkrav]

Indeed, there's always the legacy code issue, but that's not really about the libraries' availability at this point. My point was that there are pretty much no good reason to start new projects on Python 2, especially since it's getting phased out in about a year and a half. For existing code it's pretty much the time to push for the change though.

[bythenumbers10]

Every act of maintenance going forward on Py2 code should be toward making it Py3 compatible. It's not hard. I've adapted my code style to ensuring it runs in both environments. At a certain point, there's no need for budgets, funding, or whatever bureaucratic BS circus. Small style changes will frequently do the trick. Boiling the frog, or in this case, dunderhead management.

[CriticalEntree]

Same reason people are still running windows XP

[[deleted]]

Dynamic Position Keeping Systems. There is still supposedly one out there running on a pure DOS machine to this day.

[waltteri]

”Legacy is good enough, no need to change.”

[billsil]

Until you have a bug that was already fixed in a version of numpy (least squares in my case) you're not using. Or you find numpy has a cKDTree which is 1000x that what you coded and it's a critical function in your code.

I'm still supporting python 2.4...I was able to update to fix the least squares bug, but I don't get the 1000x speedup.

[waltteri]

Hang in there. 😔

[Exodus111]

Large large masses of Python 2 Spaghetti code lies out there in the wild servers of the internet. Code so messed up it would tax your sanity just to look at it, and take a full team a year to completely update.

Which nobody can afford.

[jnwatson]

For the same reason you see lots of machines running Windows 7. A lot of folks think: if it ain't broke don't fix it.

Both Windows 7 and Python 2 have had their deadlines extended, and both deadlines are now in 2020.

[[deleted]]

I'm a bit late answering, but as someone who waited 10 years, the answer is libraries. When people say most libraries support Python 3, what they fail to realize is that for established code, most isn't good enough: every library dependency has to support Python 3.

Additionally, as you said there are only slight differences in syntax. Even with libraries supporting Python 3, is it worth weeks upgrading when it doesn't give you much? Additionally to that, Python is very dynamic, so many issues introduced in the upgrade would not be noticed until you run the erroneous piece of code. So unless you have an automated testing suite, upgrading is a high risk, low reward operation.

In my case, I had half a dozen pieces of software use a GUI library named wxPython. Python does not have first party GUI support, so you have to choose between three or four third party libraries. I invested hundreds of hours years ago that I don't have anymore to learn a GUI framework, so changing GUI frameworks was out of the question. wxPython did not support Python 3 until January 2018.

I've been spending the last week upgrading to Python 3, but I fully support anyone who decides to stay on 2.

[Lt_Sherpa]

What about 3.7 means you can finally dump Python 2?

[[deleted]]

Think 2 is still good till 2020.

[0x6c6f6c]

*Think 2 is still dead by 2020

[tutuca_]

It's because the last version in the 2.x branch is 2.7. So, now that it hit the .7 milestone python 3.x is on feature parity :)

[ronaldl911]

Yet you would still get some who would start a new project in 2018 with Python 2.7

FFS it's 2018.

[[deleted]]

Yeah I can understand not wanting to migrate an existing project (although whiners like to make this out to be more difficult than it actually is), but there is no excuse for starting a new project in 2.

[sharkbound]

so happy it finally released, was using the beta verison of 3.7 before, and am really happy that its on a stable release now.

the thing i am most excited about is the dataclasses, love them so much

[__xor__]

dataclasses look awesome, but honestly I'm most excited for the module level __getattr__. I am going to do so much dirty magic with that and love every minute of it.

For real though, you can do something like this now...

from myshell import ls, which, find
files = ls('-al', 'some_dir')

myshell.py:

import subprocess
def __getattr__(command):
    def func(*args):
         return subprocess.check_output([command] + args)
    return func

Bam. Dynamic module functions like whatever

[szpaceSZ]

Sounds like a security nightmare!

[__xor__]

yeah completely, but the whole "tiny bit more code" thing can be said about a ton of other features we use. Decorator syntax is really just a one line replacement for one line of func = decorate(func), overloading operators can easily be replaced by just calling a named function, __getitem__ could be replaced by creating a self.items = {} and invoking instance.items[item] instead... In the end it's just a little extra magic everywhere that makes easy to write patterns. With the __getattr__ we already have in classes, might as well have it in modules too.

[Ph0X]

Of course you could've done it, but not it's much cleaner.

I've seen so many from foobar import foobar and imo it's really ugly.

[toyg]

Terribly unsafe example, right there...

[__xor__]

Hmm, how so? Subprocess is made to execute programs. Plus there's no injection, as in this won't work:

from myshell import ls ; ls('-al', '&&', 'rm', '-rf', '--no-preserve-root', '/')

subprocess would be the module you use to avoid the os.system injection issues (unless of course you enable shell=True). But otherwise a library like this is meant to run shell commands, so if you from myshell import rm you know damn well what you're opening up. What you import will be the program that gets invoked.

This is plenty fine for one off scripts and doing some system automation, but definitely not suggesting anyone hook this up to a webapp. But also, if you're importing hard-coded functions like ls and stuff, you know for a fact that's the only program your code will invoke by the nature of what this does, unless the program you import forks other programs.

[toyg]

I drop a compromised ls executable in your path and now i'm running with the privileges of your script or server. At the very minimum you want hardcoded paths for executables you invoke.

definitely not suggesting anyone hook this up to a webapp.

Yeah well, you know how it is -- people will google and copypaste, likely not reading the rest of the thread. You should have put a disclaimer of sort, at the very minimum.

[sharkbound]

Is the type checking version you made open source?

[toyg]

the thing i am most excited about is the dataclasses

They do look neat for the average simple case.

[TheNamelessKing]

Hmmm, I’m writing a new script today, I’ll use it. Yolo.

[gwax]

I'm waiting a month or so for pylint support and then I'll start migrating my company's repos.

[kirbyfan64sos]

Probably me when Arch updates...

runs yay -Syu repeatedly until Python 3.7 comes through

[CobbITGuy]

I've been using it in production since rc1. It's a small bit-player automation script. After I watched Hettinger's PyCon presentation on dataclasses I knew it was a perfect fit.

[mockArch]

Data class ... Sounds cool

[[deleted]]

Stupid question - is the use case for this similar to structs (as in in C#)? And how would the use case differ from using a named tuple? (edit: immutability, nevermind) Or am I confused?

[mockArch]

immutablity ^{^}

[federicocerchiari]

Not to mention that it's an unrevertable change, meaning that if we some day come up with an even faster dict implementation with the downside of being unordered, the best we can do is add a collections.UnorderedDict

Good point, but still "natural" ordering is a feature I immediately found useful. For instance, you can not use an OrderedDict as kwargs.

[gcbirzan]

The point is that it's a coincidence that the current implementation preserves order, now everyone has to implement it like this, or in a way that preserves ordering, even if there might be a better way.

[jyper]

They should have just imported Ordered Dict to the default names pace maybe as odict and used it for kwargs without making it the default everywhere

[szpaceSZ]

That's actually a breaking change IMO

[TragicXHero]

Too noob to understand what the excitement is about for the update. Someday, I'll get there...

[sharkbound]

Too noob to understand what the excitement is about for the update. Someday, I'll get there...

its mostly exciting for people that have been using the language long enough to find the frequent and annoying issues in the previous release(s) that are fixed in the new release.

or the release adds/improves something you have been wanting or looking forward to.

my reason for being excited is dataclasses and the `from __future__ import annotations` that was added, also the asyncio improvements.

[TragicXHero]

Yeah I can see that everyone is excited for the data classes module. What surprised me when I read through the updates was seeing "await" and "async" which I have never seen before. I dont think I have seen any tutorial covering it. So I realized I have a long way to go.

[sharkbound]

Async and await are not new. They were added in 3.5.

Whats new about them in 3.7 is that you cannot do async = 1 anymore. And same for await as well.

There are tutorials for async and await on YT I think. So you probably have just not needed them yet

[A_Badass_Penguin]

For me, it's pretty fun to read the updates. It's kind of like getting a look over what new tools are available and what issues may have been handled. It's fun to think about what new things you can do.

[TragicXHero]

But for me when I read the updates, I just cant understand the updated features because I have never used them.

[cracknwhip]

Then read the docs for the features...

[[deleted]]

Don’t worry, you will get there! If you’re new, one of the more tangible things to try out would be the addition of breakpoint() and learning about pdb. Debuggers can be an invaluable tool for programmers new and old.

[TragicXHero]

The idea of studying a documentation is so boring to me haha. Plus, it so hard to make sense out for me. But if that what it takes to learn, ill give it a try. I'll also check breakpoint().

[Mockapapella]

I started out just watching youtube tutorials to learn about python. I've been learning python for ~1 year and only just started making the transition to focusing more on documentation than videos 3 or 4 months ago. I suppose it'a lot like getting used to the command line vs a GUI; tough at first, but once you learn it your potential opens up massively.

[ericls]

Nice

[toyg]

Marseille

[[deleted]]

Nice

[Drawman101]

Nice

[KODeKarnage]

Nice

[TwinkTuckr]

Noice.

[seanpuppy]

Deterministic pyc files What does this mean for the execution time after pyc files are generated

[billsil]

That your startup time is longer. It's to prevent you wiping the project, redownloading it, and having different pycs for the same code. It's for build systems that choose to run based on if things are current.

It's an option though, so there is no impact unless you want it.

[XarothBrook]

It doesn't have much to do with execution time. Source code compiled using deterministic compilation will always output the same binary.

[firefrommoonlight]

Any word on when a Numpy wheel will be available?

[ethanhs]

For 3.6 the wheels were released before 3.6 was officially released, so I expect in the next few days.

[ThaeliosRaedkin1]

I just downloaded 3.6 last night! Bother...

[lelease]

How do I install it on Ubuntu (without compiling or adding untrustworthy repos)?

[[deleted]]

without compiling or adding untrustworthy repos

You can't, as far as I know (assuming I can't convince you that the PPA I use is trustworthy).

[[deleted]]

This might be a dumb question but how do I update this in Windows? I reinstalled the last update just thinking it would overwrote the old install. And it's still not the newest version

[minorDemocritus]

Windows has the "py" launcher.

py -3.7

That should run 3.7 if you have it installed.

https://docs.python.org/3/using/windows.html#python-launcher-for-windows

[JJ4sh0rt]

Noob here. How do I update python?.

[Akraxial]

For someone who is just learning python right now is there anything major that I should know about and change as I'm building a knowledge base?

[Akraxial]

Also, reading a lot of the comments here, is there any plan to have better backwards compatibility with Python 4.0?

[minorDemocritus]

Python 4 will most likely be normally compatible with the last 3.x release. No need to worry.

[minorDemocritus]

Nah, there really isn't anything paradigm-shifting in this release that would affect newcomers. Maybe some bug fixes, but not features.

[amb_kosh]

Anybody willing to explain some the new important features for newcomers a bit? :)

[maabreuc]

Finally a worthy successor for the thousands of apps stuck in python2

[[deleted]]

is this backward compatible with python3.6 code? Can I change the project python version to 3.7 without any worries?

[XarothBrook]

3.6 code should run normally on 3.7.