
Python 3.6.0 released - plq
https://mail.python.org/pipermail/python-list/2016-December/717624.html
======
chrisshroba
I absolutely LOVE format strings. Whereas before, you had to format strings in
one of these ways (among other more verbose ways):

    
    
      "My name is {} and I am {} years old".format(name, age)
    
      "My name is %s and I am %s years old" % (name, age)
    
      "My name is {name} and I am {age} years old".format(name=name, age=age)
    

Now, we can finally use f-strings, where anything in brackets is eval'ed, with
the result subbed in:

    
    
      f"My name is {name} and I am {age} years old."

~~~
makecheck
I’m curious actually why an f-string syntax is considered OK when a print-
statement is not.

I mean, there’s a precedent for short built-in functions like len(), and
apparently 'print "x"' as a statement was terrible so 'print("x")' replaced
it. If they wanted such consistency, shouldn’t they have used 'f("{a} {b}")'
or something? Or alternately, allow p-strings like 'p"hello, world"' to print?

~~~
sirtaj
As I understand it, print() was created not from a sense of consistency, but
because a few awkward cases could be simply solved by turning print from a
statement into an expression. Use in lambdas would be one example.

~~~
mixmastamyk
I don't like the extra parens, but I made an editor shortcut to alleviate
that.

Other cases such as redirecting to a file, and changing the line ending are
handled much more intuitively with the print function.

------
__s
I'd like to credit abarnert for starting the wordcode changes:
[https://github.com/abarnert/cpython/tree/wpy](https://github.com/abarnert/cpython/tree/wpy)
We were discussing for a bit & then he went silent. Haven't heard from him
since

I kind of stepped in, rewrote the peepholer, & then initiated the python dev
discussion earlier than he wanted to. He wanted to develop the idea &
benchmark it in a bubble, whereas I really felt that this should be developed
with feedback from core Python developers. Serhiy was very patient with me,
there was a lot of feedback it turns out

Fun little issue that thankfully got caught last month:
[http://bugs.python.org/issue28782](http://bugs.python.org/issue28782) (I had
thought about this error case, but at the time I had lasti being -2 & the
first byte of the bytecode is never 72. I forgot this constraint when having
lasti be -1 still)

~~~
sandGorgon
I didn't know what you meant...until I saw this

 _The Python interpreter now uses a 16-bit wordcode instead of bytecode which
made a number of opcode optimizations possible. (Contributed by Demur Rumed
with input and reviews from Serhiy Storchaka and Victor Stinner in issue 26647
and issue 28050.)_

------
happy-go-lucky
> PEP 515 adds the ability to use underscores in numeric literals for improved
> readability. For example:
    
    
        >>> 1_000_000_000_000_000
        1000000000000000
        >>> 0x_FF_FF_FF_FF
        4294967295
    

> Single underscores are allowed between digits and after any base specifier.
> Leading, trailing, or multiple underscores in a row are not allowed.

~~~
simonh
Nice. I really like the look of f-strings as well. All the power of
str.format() with none of the verbosity.

>>> name = "Fred"

>>> f"He said his name is {name}."

'He said his name is Fred.'

~~~
hyperbovine
Surprisingly these are very controversial. A bunch of people seem to hate
them. I don't understand why.

~~~
masklinn
I dislike them because not only are they one more string-formatting method
(they're similar to but not actually identical to format-strings as you can
use arbitrary expressions in f-string placeholders) and more importantly
they're the first one which does not work at all for i18n or more generally
for deferred interpolation (which is also used by `logging`)

~~~
JelteF
Not sure, why you think they cannot be used with defered interpolation. You,
can easily combine the two like this:

    
    
        >>> f'{"fstring"} and {{deferred}}'.format(deferred=1234)
        'fstring and 1234'

------
happy-go-lucky
Here comes type hinting.

> PEP 484 introduced the standard for type annotations of function parameters,
> a.k.a. type hints. This PEP adds syntax to Python for annotating the types
> of variables including class variables and instance variables:
    
    
      primes: List[int] = []
    
      captain: str  # Note: no initial value!
      
      class Starship:
          stats: Dict[str, int] = {}

~~~
squeaky-clean
Actually type hinting was released with 3.5. I've been using it for a while
now, and while there's occasional bugs, I love it (I was able to crash my
program at runtime because of a type declaration, which isn't supposed to
happen).

The difference here is the ability to add type annotations to variables
without needing to use a comment to declare it.

I'm also pretty excited for the formatted string literals and secrets module!

[https://docs.python.org/3.6/whatsnew/3.6.html](https://docs.python.org/3.6/whatsnew/3.6.html)

~~~
happy-go-lucky
Interesting.

[https://www.python.org/dev/peps/pep-0484/](https://www.python.org/dev/peps/pep-0484/)

> It should also be emphasized that Python will remain a dynamically typed
> language, and the authors have no desire to ever make type hints mandatory,
> even by convention.

~~~
squeaky-clean
Yeah, the typing (in theory) makes no actual changes to the runtime code. It's
just for linters like mypy to warn you when you write code that goes against
your own type declarations. However because it's added directly into your
code, it does have a slight runtime effect. Casting types calls a function
(which should just be a no-op function), as well as defining TypeVars.

The crashes I got at runtime aren't because of the typing module preventing
code from running due to types, it was just a bug in the runtime part of
typing. I'll try to find the github issue to share, but iirc it was related to
using Generics with a TypeVar.

~~~
happy-go-lucky
OK. I'm wondering if this

    
    
      captain: str  # Note: no initial value!
    

changes the norm: Python's names don't have associated types but values do. I
know there's no such thing as variable declaration and variable initialization
in Python.

~~~
masklinn
> I know there's no such thing as variable declaration and variable
> initialization in Python.

That is not quite true, the first assignment is an implicit declaration, and
will set up a slot in the enclosing code object, which is why you get an
UnboundLocalError if you use a name before it's first assigned to:

    
    
        >>> def foo():
        ...     a
        ...     a = 3
        ... 
        >>> foo()
        Traceback (most recent call last):
          File "<stdin>", line 1, in <module>
          File "<stdin>", line 2, in foo
        UnboundLocalError: local variable 'a' referenced before assignment
    

but a NameError if you use a name which is not assigned to at all:

    
    
        >>> def foo():
        ...     a
        ... 
        >>> foo()
        Traceback (most recent call last):
          File "<stdin>", line 1, in <module>
          File "<stdin>", line 2, in foo
        NameError: name 'a' is not defined
    

In the latter case the slot doesn't exist at all in the lexical context, while
in the former there is a slot set up but it has no value associated to it.

~~~
happy-go-lucky
I agree, but these are problems with Python's implicit variable declaration.

~~~
masklinn
That's orthogonal to my demonstration that there is in fact "such a thing as
variable declaration and initialisation in Python", given that the cases of an
undeclared variable and a declared but unassigned to variable both exist with
very different errors.

------
jkbr
What's new in Python 3.6.0:
[https://docs.python.org/3.6/whatsnew/3.6.html](https://docs.python.org/3.6/whatsnew/3.6.html)

------
MrBingley
Dang, tau (τ = 2π), was added to the math module. I like tau, but I thought
for sure that wouldn't actually get accepted.

Issue 12345 -
[https://bugs.python.org/issue12345](https://bugs.python.org/issue12345)

PEP 628 -
[https://www.python.org/dev/peps/pep-0628/](https://www.python.org/dev/peps/pep-0628/)

~~~
mixmastamyk
Why dang if you like it?

------
gregn610
do async comprehensions (
[https://www.python.org/dev/peps/pep-0530/#asynchronous-
compr...](https://www.python.org/dev/peps/pep-0530/#asynchronous-
comprehensions) ) give you concurrency? Or are they a building block to
getting that in the future?

~~~
dbcurtis
async in general gets you concurrency. async def/await is syntactic sugar
around generators built with __iter__ and __next__. It is totally possible to
do cooperative multitasking with __iter__, __next__, yield, yield from.

What this is doing is painting in some of the missing corners of the syntax.
Anything you can do with a list comprehension can be done with a for loop,
less tersely, often but not always less readably (choose wisely). This new
syntax allows you to write comprehensions with asynchronous behavior that in
3.5 and earlier requires you to write a loop.

Progress is in the eye of the beholder. "Code is read more often than it is
written." Please chose the most readable form.

------
petters
Great to see even more support for type annotations. Having to specify the
type of variables in comments was never a good solution.

------
leojg
Anybody knows what´s the state of python 3 right now? I mean, are there
popular libraries and frameworks that still uses python 2?

Or this is no longer an issue?

~~~
msoucy
According to the Python 3 Wall of Superpowers[1], almost every commonly-used
library has adopted 3. Now the problem is getting people to realize that... I
was talking with someone just a month ago who said that there were no numeric
processing libraries on 3 and so they couldn't switch.

[1]: [https://python3wos.appspot.com/](https://python3wos.appspot.com/)

~~~
bendmorris
>Now the problem is getting people to realize that...

I realize it, but (1) even after large libraries support 3 there will still be
a long tail of libraries that aren't ported (and will never be), and (2) I see
very little value in porting our very large code bases to Python 3, with its
breaking changes and subtle behavioral differences that need to be thoroughly
tested. There's no must-have feature for us to justify that effort, so we
won't be making the switch for the foreseeable future.

IMO Python should have put a lot more effort into backwards compatibility when
releasing Python 3. I'm genuinely concerned that this release has killed
Python, and I'm not alone.

~~~
criddell
Isn't that the same argument that so many companies used to hang on to IE6 for
so long? There were a ton of in-house applications built on ActiveX and IE6
quirks and porting to something newer wasn't worth the cost.

Eventually, don't you think that you will start using a more modern version of
Python?

~~~
bendmorris
"Modern" for its own sake adds no value, so no, we won't port our existing
code bases to something "more modern." It's funny that string interpolation, a
port of a feature other languages like PHP have had for decades and the
_fourth_ way to do the same thing in Python, is being held up as something
modern.

~~~
mixmastamyk
How about "supported?"

You may have also missed the other features from 3.0 to 3.6. Cumulatively they
are substantial.

------
ruda
The most interesting parts are PYTHONMALLOC and Probes (DTrace and SystemTap).
Profiling and debugging are very important in production.

------
rcarmo
Hmmm. I'm curious. Alpine Linux 3.5.0 just came out, so I wonder - how long
will it take for this to be shipped with the next release?

(I maintain [https://github.com/rcarmo/alpine-
python](https://github.com/rcarmo/alpine-python), which saves me hours and
hours of deployment time)

~~~
fithisux
Please wait until Alpine Linux 3.6.0, Alpine Linux 3.5.0 is better served by
Python 3.5.x :-)

------
gigatexal
This is very exciting. Python got me into programming. So I watch its
development very closely.

------
tomhoward
Related discussion from a few weeks ago:

[https://news.ycombinator.com/item?id=13123156](https://news.ycombinator.com/item?id=13123156)

------
spraak
I recently started learning Python for using some machine learning libraries.
Professionally I mostly do Javascript (and a tiny bit of Go). Javascript is
often bashed for it's nonsensical choices.. but I actually find the latest
version of JS quite eloquent, most especially compared to Python.

~~~
actuallyalys
Can you name specific areas you think are better? (I'm not challenging your
statement; I'm just curious.)

------
mjhea0
major new features in the release:

[https://www.reddit.com/r/Python/comments/5jwf41/python_360_h...](https://www.reddit.com/r/Python/comments/5jwf41/python_360_has_now_been_officially_released/dbjhh0p/)

------
jjawssd
How can I install this (3.6.0) using Homebrew (brew.sh) alongside Python
3.5.2? (Not replacing it)

~~~
ruiseal
I would uninstall the homebrew Python versions and instead install pyenv [1],
via homebrew, and then install whatever Python versions you want. They will
run happily side-by-side.

[1]: [https://github.com/yyuu/pyenv](https://github.com/yyuu/pyenv)

~~~
jjawssd
Wow I can't believe I didn't find this earlier!

Well-organized virtual environments AND python versions. Simply amazing!

"brew install pyenv-virtualenv" has me up and running with everything I ever
wanted in one line

------
orblivion
I was wondering how the new `datetime.fold` attribute would avoid breaking old
code. From looking at the full PEP, it appears that there are new fold-aware
tzdatas that you have to choose to use.

------
kirkdouglas
Does anyone know dev team plans for version 3.7?

------
zo7
Are there any breaking or behavioral changes in this from 3.5? I'd love to
start using some of the new async features.

~~~
nhumrich
There aren't any breaking changes from 3.5 The only behavioral change is that
dictionaries now maintain insertion order. But that likely won't break
anything.

