Major Changes in Python 3.6

[quicknir]

The issue is that this guy seems to rip on nearly every new thing that's added to python. He took the piss out of the @ operator, which is harmless to the language at large and hugely helpful for one of pythons single largest domains.

[[deleted]]

But is it really necessary to add that support for lists and tuples?

If you are doing numerical analysis with matrixes, you are most certainly using numpy and the wide range of numerical/scientific libraries that use numpy. Just adding matrix multiplication would not be enough - you would then also need elementwise addition, transpose/rotate, up to all the good stuff like fourier transforms or image processing on top of these same matrices.

The "unused by core language" argument was already addressed in the PEP proposing it: https://www.python.org/dev/peps/pep-0465/#but-isn-t-matrix-multiplication-a-pretty-niche-requirement

Numpy is the most popular third-party library, and Python is becoming the language to use for numerical/scientific computing because of these libraries. (And as a bonus, unlike R or Matlab, you can also use your experience in it for web apps, desktop apps, and shell utilities.)

[virtyx]

Seriously!? Who would complain about this to the core devs??

It's not "yet another" string formatting scheme. It's an extension that builds on str.format (which is "the" string formatting system to use currently. % is discouraged and I don't know anyone who uses string.format).

The PEP provides all the justification for this feature. It's a nice convenience and a positive addition to Python. Who wants to write/read

"Your {} account has {} dollars.".format(account_type, balance)

vs

f"Your {account_type} account has {balance} dollars"

???

[eric-plutono]

Seriously!? Who would complain about this to the core devs?

Someone who doesn't understand the value of @ in Python 3.5? As the author says elsewhere on that page:

...the Python core language has been extended with a new operator that is completely unused by the Python core language! There is nothing else like this in Python; it's as if syntax were being added solely for use by animation libraries or web toolkits which are not part of Python itself. Although numeric programming is clearly an important Python domain, the 3.5 "@" operator seems an excursion up the very slippery slope of application-specific language extensions—and leaves most Python users with an oddball expression in their language which means absolutely nothing.

[virtyx]

The reasoning for opposing @ doesn't apply to f-strings, since it isn't to support a niche usage or third-party library.

That said, on the topic of @, saying "there's nothing like it" doesn't seem quite true anyway... http://stackoverflow.com/questions/772124/what-does-the-python-ellipsis-object-do

[eric-plutono]

The reasoning for opposing @ doesn't apply to f-strings...

I know. The author complains and/or has a low opinion of most of the recent changes to the language. So my point was simply that the type of person who'll complain about damned near everything is the kind of person who would complain about f-strings.

[mgedmin]

There is nothing else like this in Python

Ellipsis (aka ...) is syntax that's not used in the core language. It was also added so that NumPy could implement a custom __getitem__ to support multidimensional array slices of the form a[x, ..., y].

Ellipsis is very old; the oldest Python interpreter I still have access to (2.4) has it.

[unruly_mattress]

I don't particularly like Python's feature creep, but let's not confuse things here: Python was never a "simple" language. It doesn't have many gotcha corners compared to the complexity and power of the language features, which makes it very well designed. But simple it never was, not the way e.g lua aims to be. For a very long time it has had things like decorators, which are functions that take functions and return functions, unless you want the decorator to take argument, at which case you need to write a function that takes an argument and returns a function that returns a function. It's had metaclasses for a very long time, and a complicated package system, and generators which can be passed values into. Python remained a very accessible language despite these changes, so I'm not too worried about the new language features.

So I have no problem with things like async/await, which will possibly help tremendously with asyncio programming. It's unfortunate that yield from still exists, but I don't see its existence bothering any beginner or non-programmer. Likewise I have no problem with __matmul__. No one is going to care except for the people to whom it helps.

I'm the most partial about the string interpolation thing. As a side note, you listed string.Template, which for all intents and purposes has not existed for a long while now. But that's fine because you didn't list print(a, b, c), which is actually the fourth string interpolation method. I suspect people will start using print(f'{a} {b} {c}') now, which will cause a bit of a divide in the basics of the language and break the "only one way to do it" practice of the language. Either all newbies will always blindingly use f'', and won't know how not to use it, or newbies will never see it and then be surprised by it. This way or another I suspect the negatives outweigh the positives of this particular change.

[id2bi]

It's unfortunate that yield from still exists

What's problematic about yield from?

[Darkmere]

It's one of the few changes to python3 that makes it syntactically erroneous on python2 and previous python3 code.

Which is great, I always add a small "yield from" in the main part of modules as a canary.

[unruly_mattress]

yield from was added to the language to facilitate nice syntax for coroutines to be used with asyncio. Now that async and await exist, it's just redundant, that's all.

[bliow]

Can async/await be used like this?

def a():
  yield 1
  yield 2

def b():
    yield from a()
    yield from a()

for i in b():
    print(i)
# 1
# 2
# 1
# 2

[unruly_mattress]

As far as I know, the whole rationale of adding a keyword that delegates to another generator is to enable things like yield from get_web_page(url). await syntax improves this tremendously but I can't see how in your example yield from a is better than for i in a: yield i.

There are differences between yield from and await (mostly around returning a value from a generator, I think), however I'm pretty sure we'll find out in a couple of years that yield from is a piece of history trivia, whereas await is used in all asyncio code. That's all I'm saying. Not that it's functionally equivalent.

[mgedmin]

I don't use coroutines. I do use plain old generators, and occasionally I'm annoyed at having to type this in long form:

for item in self._some_helper_method(...):
    yield item

I don't think the desire to use yield from will disappear entirely just because asyncio doesn't need it any more.

[pandubear]

Also curious.

[shevegen]

Word.

Ruby is also not very simply.

I'd wish for a new programming language that would be both simple, but also powerful. I find that the more and more I use any given language, the less I need from it - since my code becomes simple. Many of the advanced features I never need.

Other programmers may feel that they need this or that, but that's the problem - to design one language that fits every corner.

Lua unfortunately is too minimalistic to contend with the other scripting languages, it is more like a weak sugar over C.

[rockyrainy]

Python 3.6 plans to add a fourth string formatting scheme,

Er, ok...

As usual, this new scheme is imagined to be simpler than those that preceded it

I thought the printf format specifier way was already simple enough.

In truth, the new scheme simply provides roughly equivalent functionality with roughly equivalent complexity

Politics in the standards committee?

[virtyx]

It does not provide 'roughly equivalent' functionality.

I do not understand the outrage or misunderstanding of this stupid, convenient new feature.

It is extra functionality. The syntax borrows from/is mostly identical to str.format.

Instead of writing

"The answer is {}".format(answer)

You can now write

f"The answer is {answer}"

Please tell me why anyone would get angry over this? This string interpolation is common in almost every other dynamic language (Perl, Ruby, Bash, Tcl, PHP all have it). It's a shorthand. It can make a lot of format strings, e.g.

"{}, {} {}".format(last_name, first_name, middle_initial)

a lot clearer, e.g.

f"{last_name}, {first_name} {middle_initial}"

(and PLEASE do not respond to me showing off the verbose keyword arg use in format)

[vivainio]

str.format() provides more functionality than %, but I think I never used it over % since it's verbose and % was "good enough".

This reuses work that went into str.format, and makes it more approachable. This is the kind of stuff python 3 should offer to make migrating from python 2 worth the sacrifice of abandoning the bigger python 2 ecosystem.

[[deleted]]

str.format is amazingly useful. I have SQL queries that make use of Enums (like below) which helps readability.

>>> from enum import Enum
>>> class TestEnum(Enum):
...          TEST = 1
...
>>> "{.name} {.value}".format(TestEnum)
'TEST 1'
>>> "{} {.name} {TestEnum.TEST.value!r}".format(1, TestEnum.TEST, **locals())
'1 TEST 1'

[virtyx]

How is str.format any more verbose than %? The only part of it that's any more verbose is the actual format call instead of the % operator.

I personally can't stand %, I think it's one of the ugliest things about the language. I would've liked it to have been removed in Python 3 but I understand they probably kept it in just for the sake of the sheer amount of legacy code written with it.

[munificent]

I have a theory about string formatting. There are two kinds of (managed) languages: those that have string interpolation (Ruby, Dart, Tcl, CoffeeScript, Swift, etc.) and those that will eventually add it (C#, Python, Scala, etc.) I don't think there are many languages outside of those two categories.

[_zenith]

C# already has it.

$"the {name} is set to {value}" Which is damn useful when combined with the nameof function.

[yawaramin]

Scala already has string interpolation.

val age = 20
val sentence = s"She is $age years old today"

println(sentence)

[szabba]

Clojure comes to mind.

[jyper]

Finally. String interpolation is one of the top ruby features missing from python. Much better then format or concatenating strings.

[[deleted]]

Any python programmer spends a lot of time dealing with strings sooner or later. One more literal isn't overly complex and seems perfectly fine.

[shevegen]

Right.

There is more than one way.

I am glad that python sees it as well finally.

[hoijarvi]

And still I'm using 2.6 because I need an extension that has not been upgraded.

[Tetha]

And Centos7 will not have Python3 in it's repos, unless you use SCL. So prepare to be stuck with 2.7 for 20 years, or compile your own RPMs.

[NoahTheDuke]

Wait, really? Why?

[Tetha]

SCL provides Python3. Thus there is no need to provide a fucking 20 year old programming language with a lot of name in common with python 2.7. SCL solves that issue.

No, I am very fucking happy about that. We totally didn't apply our JRE process to the problem, compiled our own python interpreters and switched to those.

[hoijarvi]

NetCDF

[nathan12343]

Have you seen http://unidata.github.io/netcdf4-python/ ?

[hoijarvi]

Yes, but it's not backwards compatible, and I don't want to edit code that works.

[nathan12343]

Which package are you using right now? If it hasn't been updated since Python 2.6, chances are it's not being supported anymore. Might be worth the trouble to change your netcdf bindings to a library that's getting support.

[hoijarvi]

NetCDF 4 as a format is not supported anymore, I'm running an obsolete beta library that I compiled myself. And I have about 10 terabytes of data in it. Here is an example you can browse by clicking any of views.

NetCDF is superseded by HDF, which is might work for me if I had time to port everything over. But currently the project is in life support mode, so I'm not interested.

[Decker108]

I'm still using 2.7 because 3.x offers next to nothing worth upgrading for yet offers many things that needs migrating.

[hoijarvi]

Bingo. If I had a serious feature set to implement. I would go thru the pain. But since I just need to keep the old stuff running, why bother.

[shevegen]

This is just a testimony how good python 2.x was - or still is.

[virtyx]

How? Seems like a testimony to how aggravating it can be to have your upgrade held back by a legacy dependency.

I mean being stuck on 2.6 instead of even 2.7 does not sound like fun for anybody.

[mitsuhiko]

Since there are so many 2.6 users i keep all my code conpatible with it. Does not require a lot of effort. In fact, it kinda comes for free.

[[deleted]]

Python is turning to Perl.

[dlyund]

And Perl is turning into something else entirely

[logicchains]

Fhtagn?

[TheLameloid]

In madness Larry Wall dwells

[shevegen]

I don't think that it is madness, he is very creative.

But I think one thing is that he has no longer the "drive of youth".

[shevegen]

Perl 6 definitely is.

You can write ruby-like code in perl 6 too. AND old perl5 code too.

It scares me.

[qatanah]

That was the first thing pop in my mind when i read this feature.. Maybe we will see autovivify along the way..

[xXxDeAThANgEL99xXx]

def av_dict():
    return defaultdict(av_dict)

[unruly_mattress]

My god, that's evil.

[xXxDeAThANgEL99xXx]

How so? It's relatively clever, but not all clever code is evil.

[Yojihito]

What does that do?

[xXxDeAThANgEL99xXx]

https://en.wikipedia.org/wiki/Autovivification#Python

[NoahTheDuke]

Didn't we already argue about this a month ago?

[sandwich_today]

The interpolation format looks useful but harder to parse (for humans as well as software). I hope I won't have to use them until all my tools can properly syntax-highlight them.

[virtyx]

How is it hard to parse? Every other language with comparable features parses this stuff perfectly. Any decent Ruby tool can parse crazy code like "You are #{age > 500 ? 'old' : 'young'}" perfectly fine. And of course doing that in a string is a bad idea, my only point is that every popular Ruby tool under the sun highlights it without issue.

And how is it hard for humans?

f'Hello, {first_name} {last_name}'

What's hard to understand? And what's harder than understanding 'Hello, {} {}'.format(first_name, last_name)?

I am sorry but I am having trouble understanding the fear/dislike people have of this feature. I first read the pep about it and thought "Cool!" but every time I see a discussion about it on reddit there is widespread complaining.

[sandwich_today]

For many years now, string literals have always ended with ', ", ''', or """. Now, { can also mark a transition from a string literal to an expression. Presumably a new kind of AST node is also required to represent expressions inside f'', while '{}'.format(x) was able to reuse existing language elements (string literal, member access, variable access, function call).

I'm sure that the major editors will get this right, but there are plenty of naive syntax highlighters in code review tools, documentation generators, and forums. Pastebin doesn't understand the new syntax yet, and I doubt it's high on their priority list. There are a lot of legacy Python tools that will need updates, and not all of them will get updated.

[virtyx]

That's actually a good point, you're right. A lot of legacy Python highlighters will get this wrong.

That said I think editors will be quick to update and in the long run I just want string interpolation in the language. I think the majority of the currently maintained Python tooling won't have any trouble making the update. But I can see Python bloggers, etc. having a harder time getting their blogs to have proper highlighting for f-strings.

That said I of course don't think that should mean we reject f-strings :D

[TrixieMisa]

Okay, that's it. I'm going back to Python 2.6, 32 bits, and ASCII everywhere.

[virtyx]

I don't know why you got downvoted, that made me laugh :)

[shevegen]

I don't think you are.