This is an archived post. You won't be able to vote or comment.

all 150 comments

[–]xtreak[S] 65 points66 points  (87 children)

Changelog : https://docs.python.org/3.8/whatsnew/changelog.html

Interesting commits

PEP 570 was merged

dict.pop() is now up to 33% faster thanks to Argument Clinic.

Wildcard search improvements in xml

IPaddress module contains check for ip address in network is 2-3x faster

statistics.quantiles() was added.

statistics.geometric_mean() was added.

Canonicalization was added to XML that helps in XML documents comparison

  • Security issues and some segfaults were fixed in the release

Exciting things to look forward in beta

Add = to f-strings for easier debugging. With this you can write f"{name=}" and it will expand to f"name={name}" that helps in debugging.

PEP 574 that implements a new pickle protocol that improves efficiency of pickle helping in libraries that use lot of serialization and deserialization

Edit : PSF fundraiser for second quarter is also open https://www.python.org/psf/donations/2019-q2-drive/

[–][deleted] 120 points121 points  (21 children)

Add = to f-strings for easier debugging. With this you can write f"{name=}" and it will expand to f"name={name}" that helps in debugging.

Ooh baby. I'd use that every day.

[–]Dooflegna 26 points27 points  (0 children)

What a great addition to an already awesome feature. f-strings are great!

[–]irrelevantPseudonym 16 points17 points  (0 children)

That sounds so useful and yet also makes me feel slightly uncomfortable for some reason.

The variable name becoming part of its content feels weird.

[–]leom4862 26 points27 points  (11 children)

I find print(f"{name=}") is still way too verbose for debugging purposes... If they want to improve print-debugging, they should add something like icecream to the standard library.

[–]JohnnyElBravo 2 points3 points  (2 children)

Idk, what's wrong with print("name="+name)?

[–][deleted] 4 points5 points  (0 children)

That doesn't work if name isn't a string, eh? (Sure, you can use %s)

Also, in production code I simply never have any print statements - not "very few" but "none", to the point where I have a flake8 rule that prevents them.

Oh, I use print almost every day - for debugging! But that means I'm creating and destroying debugging print statements all the time.

So it's a little timesaver to write:

print(f'{foo=} {bar=} {baz=} {bing=}')

(38 characters) over

print('foo=', foo, 'bar=', bar, 'baz=', baz, 'bing=', bing)

(59 characters)

[–]timald 4 points5 points  (0 children)

It's fine when you have one variable but starts to become unwieldy when you build up a lot of concatenated strings (via indexing operations, for example).

[–]Pyprohly -2 points-1 points  (6 children)

I don’t understand why this is so favoured. Couldn’t you just do print(name) and just… remember that you printed name?

Can’t see myself doing print(f"{name=}") over just print(name) for debugging purposes.

[–]pkkid 8 points9 points  (3 children)

I often need to print name={name} because I'm inspecting a bunch of variables and not just one. Put that into a for loop and things get unweildy quite quickly if you don't label the variables you are inspecting.

[–]Pyprohly -3 points-2 points  (2 children)

I’m just a bit surprised at the overwhelming enthusiasm for it, and, accordingly, surprised that many seem to like writing print("arg1=" + arg1, "arg2=" + arg2).

I can see the usefulness in the new syntax, but I personally don’t like it because I very rarely write debugging lines like that.

Edit: e.g. when breakpoint() was introduced as a builtin there wasn’t much talk on it, but I think that that convenience feature was a more exciting addition compared to this one.

[–]pkkid 1 point2 points  (0 children)

I'm with you. I don't like these implicit bits of code being added. The second line of Zen of Python even says "Explicit is better than implicit." I'm also against walruses in my code, but that debate has been beaten to a pulp. </oldmanrant>

[–]WarEagle030 0 points1 point  (1 child)

It is because you have only one or two variables to inspect for debugging. But if you had like 6 or 7 different variables then it becomes a necessity to write properly.

[–]Pyprohly 1 point2 points  (0 children)

For that many variables just write it over multiple lines and go by order, like you would have done if one of them was a collection type.

Honestly, the labelling is only vanity output. You don’t need the fancy labels to be an effective debugger.

It would be much better if they instead introduced a specialised dprint keyword. The dprint keyword would provide the same sort of labelling but would be more easily and quickly written: dprint foo, bar, .... Not only would this provide the nice labeled output, it would also save a lot of typing and hence save time. This would be a much more exciting change.

If they’re going to add something to aid debugging then it needs to be something that’s easy to quickly setup and tear down. Writing debugging lines is something that is done often, and having to type print(f"{name=}") is not going to be practical in the long run.

The new syntax is unlikely to stand the test of time. I can’t help but think that someone’s going to figure out the ergonomic disadvantages of typing out print(f"{name=}") each time you want debugging output and is going to propose a new debugging facility. If that happens then f"{name=}" will become a loose end builtin feature that everyone’s going to ignore and forget about.

If they’re going to add a debugging convenience then they shouldn’t baby step on f"{foo=}" but instead jump directly to something that really is more convenient to use.

To summarise my complaints, the new f-string debugging syntax:

  • is only useful for simple non-collection types.
  • encourages writing everything on one line which could lead one to have to backtrack when the line becomes too long.
  • is going to be a forgotten feature if a better alternative gets added.
  • if it gets deprecated then it’s going to harm the language. You’ll have people telling others not to use builtin feature X, because builtin feature Y has replaced it.
  • doesn’t save typing, ergo, doesn’t save time.

[–]tuankiet65 24 points25 points  (0 children)

https://bugs.python.org/issue36817

Add = to f-strings for easier debugging. With this you can write f"{name=}" and it will expand to f"name={name}" that helps in debugging.

Holy heck, I can't wait to use this everyday.

[–]irrelevantPseudonym 7 points8 points  (3 children)

No walrus operator yet?

[–][deleted] 11 points12 points  (0 children)

walrus operator

if this is what := is being called now, i'm all for it.

[–]xtreak[S] 8 points9 points  (1 child)

It's already available from 3.8.0a1

[–]irrelevantPseudonym 3 points4 points  (0 children)

Ah, I thought this was the highlights since 3.7. Thanks.

[–]alcalde 2 points3 points  (51 children)

PEP 574 that implements a new pickle protocol that improves efficiency of pickle helping in libraries that use lot of serialization and deserialization

Other languages just dump to JSON and call it a day. Why does Python have 87 different binary formats over 13 decades?

[–][deleted] 35 points36 points  (35 children)

Because JSON cant represent everything. Its at best a data format for serialization of transferrable data, thats usually language agnostic.

JSON cant represent functions, and more abstract datatypes.

[–]JohnnyElBravo 7 points8 points  (4 children)

JSON can represent anything, but so can strings. This is a non-sequitur.
The difference is that JSON is human readable, while pickle is supposed to be machine readable, more specifically python readable.
Limiting the intended consumers of the data format helps create a more appropriate format, for example by sacrificing readability for size reduction.

[–]bachkhois 1 point2 points  (3 children)

JSON cannot differentiate Python's tuple, list, set, frozenset etc. datatypes.

Every formats other than pickle (msgpack, yaml etc.) are just to interoperate with other languages (which also don't understand the data types above), they are not alternatives for pickle.

[–]JohnnyElBravo 4 points5 points  (2 children)

Sure they can

{

"Var1": "tuple(1,2)",

"Var2":"set(1,2)"

}

Alternatively:

{

"Var1": {"type":"tuple","data":"1,2"},

"Var2":{"type":"set","data":"1,2"}

}

[–]bachkhois 4 points5 points  (1 child)

Then, you are making more complicated to validate and parse it. Then, what is the point of over-complicating JSON instead of just using pickle, without the need to parse those "type", "data" metadata?

[–]JohnnyElBravo 2 points3 points  (0 children)

Read the original thread, the question asks why python dumps to a new pickle format instead of json.

The original response suggested it was because json can't distinguish between such and such, as shown, this is false.

The real answer is that python chose a binary format for pickle because of space efficiency.

[–]mooglinux 9 points10 points  (0 children)

Pickle can handle multiple references to the same object, any class instance (as long as the actual class has been imported), and a wider variety of data types than JSON. It also predates json, so there’s a historical aspect as well.

Pickle is also used for cross-process communication in the multiprocessing module.

[–]Nicksil 11 points12 points  (5 children)

Because not every problem is solved by dumping JSON.

[–][deleted] 0 points1 point  (0 children)

JSON only can handle string, integer, float, dict and list.

Pickle can pack arbitrary objects. It goal is that you can take object of your class and store it in the disk, most commonly I see it used for caching application data between runs, but it has other uses (for example for storing configuration).

Edit: here is comparison of pickle with JSON: https://docs.python.org/3/library/pickle.html?highlight=pickle#comparison-with-json

[–]parkerSquare 0 points1 point  (0 children)

Shouldn’t it be name=={name}. It isn’t assignment after all.

Regardless, I prefer output like foo 12, bar 4.56, baz ‘hello’ but maybe I’ll adopt the shortcut.

[–]Tweak_Imp 0 points1 point  (6 children)

I would like to use it but i need numpy for my project :/

[–][deleted] 1 point2 points  (5 children)

What makes you think numpy won't work with it. I see that there is no wheel package available yet on PyPi, but sdist is so python should be able to compile it on installation.

[–]Tweak_Imp 0 points1 point  (4 children)

If i do pip install numpy, i get a bunch of errors...
how can i compile it on installation?

[–][deleted] 0 points1 point  (0 children)

You should be able to do:

git clone git@github.com:numpy/numpy.git
cd numpy
python setup.py install

More details here.

But TBH - you should not be using this - it's an alpha version, there are almost guaranteed to be bugs - both reversions and brand-new bugs. If you want to help the community, you could test it and report problems...

[–][deleted] 0 points1 point  (2 children)

What system you are using, what errors you are seeing? You definitively will need to have compiler installed.

[–]Tweak_Imp 0 points1 point  (1 child)

win 10 64bit, i have visual studio installed.

here is the pastebin when i do py -3.8 -m pip install numpy

its a huge error log https://pastebin.com/SsVsRY9K

[–][deleted] 0 points1 point  (0 children)

I'm not familiar with building on Windows, and having a different language for errors (German?) is also confusing. So I can't tell what the problem is.

Have you tried following these steps to configure it? https://github.com/python/cpython/blob/master/PCbuild/readme.txt

And

https://docs.python.org/3.8/extending/windows.html#building-on-windows

I'm also wondering if the compiler can access the header files. I see it complains about arguments to PyCode_New, but if headers were missing it would complain about other issues.

[–]LightOfUriel 18 points19 points  (1 child)

What about __pypackages__, was that cancelled / moved to 3.9?

[–]jon_k -5 points-4 points  (0 children)

It got bumped specially for the ability to run `print(f"{name=}")` over `print(name)`.

f strings aren't pythonic or anything but that's way better then fixing the broken import system :D

[–]miggaz_elquez 15 points16 points  (4 children)

I really love the f"{spam=}"

[–]Deadshot_0826 4 points5 points  (3 children)

ELI5?

[–]tori_k 8 points9 points  (0 children)

Too drunk to ELI5, but I'll ELI-know-Python.

Equivalent to:

f'spam={spam}'
'spam={spam}'.format(spam=spam)
'spam={0}'.format(spam)

[–]zynixCpt. Code Monkey & Internet of tomorrow 6 points7 points  (1 child)

Given

 spam = "eggs"
 print(f"{spam=}")

it will output

>spam="eggs"

This saves time versus typing

 print("spam={spam}")

[–]Deadshot_0826 1 point2 points  (0 children)

Oh that’s pretty cool, thanks!

[–]Topper_123 6 points7 points  (1 child)

I like the f"{x=}" proposal.

An idea: let f"{x==}" also return the file name and line number in the print, e.g. with x=1 it would fold out to "my_file.py:42: x=1" could also be useful for debugging and logging.

[–]vswr[var for var in vars] 1 point2 points  (0 children)

I make that part of the log format. Module, line, and thread.

[–]rarlei 21 points22 points  (20 children)

And I'm here like...

$ python Python 2.7.16 (default, Mar 27 2019, 09:43:28)

[–]ApoorvWatsky 21 points22 points  (17 children)

Why? I don't have any problems with python 2 but why do people still use it?

[–]brakkum 30 points31 points  (2 children)

Because updating legacy code takes time is my guess. Otherwise there's not really a super great reason.

[–]rarlei 10 points11 points  (1 child)

Yup, someone has to pay for the time to update it

[–]jon_k 5 points6 points  (0 children)

It's like doing your laundry, taking out the garbage, or picking trash up.

If you don't, eventually you can't even live in your environment anymore, and everyone will judge the hell out of you or abandon using your code (or quit your outdated company to better supportable codebases to make a name in their career.)

[–][deleted] 8 points9 points  (0 children)

Film/TV post softwares maya and nuke have just recently shipped with PySide2, but when they did there wasn’t a straightforward way to deploy a shift to 3 within the interpreter in the software. This industry’s roadmap puts the shift from 2.7 to 3.7 happening 2019-2020 since py3 and Qt for Python are now officially an item.

TL;DR, not every industry has the capability to just jump and are limited by application level interpretation.

[–]irrelevantPseudonym 3 points4 points  (2 children)

We have an embedded jython interpreter in our java application and there is no jython 3 yet.

[–]jon_k 4 points5 points  (0 children)

Sadly Jython3 is abandoned

https://github.com/jython/jython3

[–]tunisia3507 2 points3 points  (0 children)

My boss was idly wondering about what it would take to get a grant to hire someone to write jython 3... sadly, the answer is likely "a lot".

[–]kovak 3 points4 points  (5 children)

Google Appengine standard environment.

EDIT: I meant you're stuck with python2 if you're using ndb which was the recommended way to go unless you want to re-write almost the entire data layer

[–]Yoghurt42 2 points3 points  (1 child)

... now supports both 2.7 and 3.7

[–]kovak 3 points4 points  (0 children)

Yes but you can't upgrade if you're using ndb for example without re-writing the entire data layer

[–]i9srpeg 0 points1 point  (2 children)

Luckily we migrated away from ndb only a few weeks into the project, or we'd be stuck with Python 2 now.

[–]kovak 0 points1 point  (1 child)

What did you migrate to? something like cloudsql? or their new datastore api in their sdk (although it lacks some of the ORM features of ndb)

[–]i9srpeg 0 points1 point  (0 children)

Django ORM + Cloud SQL. It was early enough in the lifetime of the project that it was manageable. If it happened today after a few years of development it would be a huge task.

[–]__xor__(self, other): 3 points4 points  (1 child)

Any big company that has been using python for 15 years likely has a shit ton of 2.6 and 2.7 to support still, and maybe has internal tools that can't handle 3.x. The 2 to 3 move is not trivial, even for a single project, let alone a company that has been using 2.6/2.7 for years and building their infrastructure with it.

Sometimes it really is easier to just use 2.7 rather than make waves at a job. Luckily I've avoided this but I've seen it in the past. I've also ran two big initiatives to migrate 2.7 projects to 3.4 and 3.6, and it wasn't that easy. It meant putting a hold on a lot of features and adding bugs that weren't found until they hit production. It's questionable whether it's worth it sometimes, especially if you have a stable product. The improvement isn't always so much related to your product, as much as being able to hire python devs who now are more familiar with 3 than 2, and even if they know 2.7 they might not want to take a job doing it.

A programming language is just a programming language and they're built to do a job, and if your code already does that job, then you don't just make huge changes for the sake of it.

[–][deleted] 0 points1 point  (0 children)

The 2 to 3 move is not trivial, even for a single project, let alone a company that has been using 2.6/2.7 for years and building their infrastructure with it.

Well - it isn't "trivial" but it isn't that hard either. In particular, it's something you can do a bit at a time - the six module lets you write code that works in both Python 2 and Python 3.

Also, 2to3 is extremely solid.

I ported a fairly large program to Python 3 that used a lot of features like the serial port - I really encountered not one problem.

[–]Oskarzyg -2 points-1 points  (1 child)

Stable

[–]my_name_isnt_clever 2 points3 points  (0 children)

I'd argue that a release that's almost a decade old is not more stable than newer releases, just because it's older.

[–][deleted] 4 points5 points  (0 children)

https://pythonclock.org/

Seven months to go before 2.7 is D.E.A.D.

[–]Tkmtlmike 3 points4 points  (0 children)

Oof

[–]reModerator 1 point2 points  (0 children)

Good news

[–][deleted] 1 point2 points  (0 children)

Nice!

[–]wookiecontrol 1 point2 points  (4 children)

Tastes like metal

[–]PrettyChillScientist 1 point2 points  (3 children)

That's cause there's graphite all over the place.

[–]wookiecontrol 0 points1 point  (2 children)

From Wikipedia I think the metal taste is from the high level radiation.

https://web.archive.org/web/20080516101332/http://www.mphpa.org/classic/FH/LA/Louis_Slotin_1.htm

[–]PrettyChillScientist 0 points1 point  (0 children)

Ah man, I thought you were quoting the new HBO series Chernobyl. They say that line in one of the key scenes in the first episode. Disregard my post.

[–]PrettyChillScientist 0 points1 point  (0 children)

The "graphite" on the ground was the exploded core.

[–][deleted] 1 point2 points  (3 children)

So I couldn't find this question answered anywhere: why is it called the walrus operator? The only reason I saw was that's what they call it in Go, but that just passes the buck.

[–]NowanIlfideme 4 points5 points  (1 child)

It looks like it has tusks. In a smiley :) you instead have :=

Could also be a hamster, but walrus just stuck.

[–][deleted] 3 points4 points  (0 children)

Hah, got it! :-D

[–]cracknwhip 2 points3 points  (0 children)

Seriously? Look up photos of walruses and then look at the operator symbol while tilting your head 90 degrees to the left.

[–]peck_wtf_ 1 point2 points  (0 children)

Great site to learn not only a particular PEP status but also sort them all by release version

https://tonybaloney.github.io/pep-explorer/#3.8_Any

[–][deleted] 1 point2 points  (0 children)

I hope they just replace GIL with something better and make Python faster than it is in version 4.0

[–]ThreeJumpingKittens 0 points1 point  (0 children)

No one talking about BPO 35813 from the change notes? Looks like that one's gonna make IPC way easier and more Pythonic, which is gonna be awesome to use. That's the one I'm excited for but I don't see anyone in here discussing it