
What’s New In Python 3.6 - orf
https://docs.python.org/3.6/whatsnew/3.6.html
======
fermigier
First of all, congratulation and a huge thank you to the core python
development team.

I know some of them have expressed frustration (or more negative feelings) at
the way some people have been reacting to their work. As the Python ecosystem
is progressively moving to Python 3 (according to some stats, the tipping
point should be reached in a few months), I hope that this trend of excellent
Python 3 releases will continue.

~~~
lima
Just as an anecdote: I haven't heard _any_ criticism about Python 3 outside of
the Hacker News community. In Germany, everyone loves it, if only for the
improved Unicode handling.

~~~
danso
Given that the HN community might represent a decent chunk of the overall
Python-using community, I wouldn't interpret that as HN being whiners for the
sake of whining.

For starters, Armin Ronacher has written thorough essays on his dislikes. He
comments on HN but his influence is obviously much bigger as a Python
developer (Flask, etc).

In academia/science, maybe people aren't ripping on 3.x explicitly, But that's
because they have the ability to control the work environment and stick with
2.x. They don't rip on 3.x because it's non-existent as far as they are
concerned.

Example:
[http://people.cs.umass.edu/~sheldon/teaching/cs335/](http://people.cs.umass.edu/~sheldon/teaching/cs335/)

> _Programming assignments will use Python, NumPy, and SciPy. The required
> Python environment is the Anaconda 4.1.1 distribution of Python 2.7. We will
> not help grade or debug work unless you are working in this environment._

------
devy

         Note Prerelease users should be aware that this document is currently in draft form. It will be updated substantially as Python 3.6 moves towards release, so it’s worth checking back even after reading earlier versions.
    

Although this document is dated today, but it bears the above note right below
editors.

Also according to PEP 464's Python 3.6 release schedule, Python 3.6.0 final
was scheduled on 2016-12-16.

So the title should be changed to "Python 3.6 release candidate 1 released"

------
module0000
The dict shrinkage(25% less!) in memory is pretty sweet! I'm not sure how many
of you abuse dicts to hold [just about] everything, but this is a big boost
for those of us that do.

~~~
Alex3917
I've been trying to break this habit and get into using namedtuples, but the
problem is I still need to look up the API every time I need to use them.

~~~
deniska
Be careful with named tuples:

    
    
        >>> from collections import namedtuple
        >>> Time = namedtuple('Time', ['hours', 'minutes'])
        >>> Point = namedtuple('Point', ['x', 'y'])
        >>> t = Time(hours=7, minutes=40)
        >>> p = Point(x=7, y=40)
        >>> p == t
        True
    

They're still tuples. They're meant more as a tool for making an already
existing tuple mess slightly more managable rather than creating a new mess.

For making plain data objects take less boilerplate to create have a look at
attrs: [https://attrs.readthedocs.io](https://attrs.readthedocs.io)

~~~
SEJeff
Strong +1 for attrs. It is a really nice library and quite easy to use.

~~~
tedmiston
Interesting find with attrs. My main use case for namedtuples is a class as a
data container which doesn't require any special methods. This might be a
better alternative.

------
kazagistar
I'm disappointed in the interpolated strings. We finally get them, but its
already behind the curve compared to Scala or C#, due to not being lazy and
allowing context sensitive string interpolation.

The better design binds the values to the string, but does not interpolate
into a string type fully. Then, the resulting object can be passed to a
consumer like an SQL engine (and appropriately escaped) or an
internationalization library (and swapped out for a translated string before
interpolation).

I mean, I appreciate what they did, but it seems like missing a massive
opportunity to provide a linguistic building block for library authors.

~~~
renzon
For i18n you can still do the same of _('your template here {foo}'), where _
is you gettext[1]. And once it has a lazy version, you will be covered.

[1] [https://docs.python.org/2/library/gettext.html#gnu-
gettext-a...](https://docs.python.org/2/library/gettext.html#gnu-gettext-api)

~~~
masklinn
That doesn't work, unless `_` is a gettext overlay which goes and reaches into
its caller stackframe and performs string interpolation itself. Otherwise you
mean that you can "still do the same of"

    
    
        _('your template here {foo}').format(foo=foo)
    

which is a step down from

    
    
        f'your template here {foo}'

------
herge
I do not know which feature I will miss the most whenever I have to use older
versions of python, either the f-string interpolation or the underscores in
numeric literals.

~~~
Animats
That's a joke, right?

~~~
baq
can you please go troll somewhere else?

------
underyx
It seems to be just 3.6.0 RC1 actually:
[https://mail.python.org/pipermail/python-announce-
list/2016-...](https://mail.python.org/pipermail/python-announce-
list/2016-December/011396.html)

------
jjwiseman
"The default console on Windows will now accept all Unicode characters and
provide correctly read str objects to Python code. sys.stdin, sys.stdout and
sys.stderr now default to utf-8 encoding."

Thank god.

------
wbond
My favorite bits include UTF-8 encoding support for Windows filesystems and
console, scrypt, and OpenSSL 1.1.0 support.

------
Animats
Well, the "type annotation" system, where you get to type variables but the
types don't do anything, was expanded again. It doesn't improve safety. It
doesn't improve performance. The hand-waving argument is "Just as for function
annotations, the Python interpreter does not attach any particular meaning to
variable annotations and only stores them in the __annotations__ attribute of
a class or module. In contrast to variable declarations in statically typed
languages, the goal of annotation syntax is to provide an easy way to specify
structured type metadata for third party tools and libraries via the abstract
syntax tree and the __annotations__ attribute." Whatever that's supposed to
mean.

I still suspect that was put in to screw over PyPy. If the type information
was enforced, PyPy could use it to generate hard-typed code and improve
performance. CPython, on the other hand, still represents everything as
CObject objects in C. Type checking adds run-time overhead.

~~~
jammycakes
The Python interpreter itself may not do anything with the annotations, but
static type checkers and linters can, and they will give you the safety that
you need.

The annotations also allow the development of better IntelliSense-like tools.

------
vosper
Maybe this should be obvious, but I don't have a computer to hand to try and
figure it out: In the example for f-string interpolation, why does value have
to be declared like this:

    
    
      value = decimal.Decimal("12.34567")
    

Why wouldn't this work?

    
    
      value = 12.34567

~~~
webmaven
Because that gives you a Float, not a Decimal.

~~~
vosper
Sure, I get the difference between float and Decimal, but why can't floats be
formatted with precision in the example? Are they using Decimal because it's
best practice, even though it adds more code to the string formatting example
?

~~~
webmaven
Floats can absolutely be formatted, but the result may be unexpected, because
it is basically a (hardware based) C binary float:

[https://en.wikipedia.org/wiki/IEEE_floating_point](https://en.wikipedia.org/wiki/IEEE_floating_point)

So, because users will typically be surprised that 2.2 + 3.1 results in
5.300000000000001, or that round(2.675, 2) gives 2.67 (instead of 2.68), best
practice is to use Decimal, which will give users the results they expect:

[https://docs.python.org/3/library/decimal.html](https://docs.python.org/3/library/decimal.html)

~~~
vosper
Makes sense. I guess what I was getting at is that introducing Decimal to the
example about f-string interpolation makes the example more complicated than
it absolutely needs to be, but I can see why they did it.

~~~
webmaven
I think some of that extra complexity could be papered over with either making
decimal() available like int() and float(), which would eliminate the import,
and/or implementing a decimal literal format, such as 0d2.675, analogous to
the format of Hexadecimal and Octal literals (0xCC00CC and 0o267,
respectively).

~~~
mixmastamyk
I like that second idea, perhaps a mention on the python-ideas mailing list?

~~~
webmaven
Perhaps. I need to mull it over a bit before I take that plunge (but thank you
for the encouragement!).

One possible objection is that while Decimal is in the standard library, it
_isn 't_ a built-in type, so either Decimals need to be elevated to built-ins,
or some magic needs to happen when importing the decimal module to add the
literal.

------
gigatexal
It's really neat to see async coming to things like generators and
comprehensions. Looking forward to trying it out.

------
d_theorist
This will probably be an unpopular thing to say, and I understand that people
have different opinions and preferences on this question.

However, for me, every time I see one of these Python 3 releases it makes me
appreciate Go's model of language maintenance and development more and more.

Compare the last few major Go releases to the last few Py3 releases. Go has
_so_ much more discipline about when it's appropriate to add things to the
language. Most of Go's changes are confined to bug fixes, performance
improvements, and toolchain improvements.

By comparison, it seems like Python is on a runaway train of core-language
additions.

~~~
paulddraper
In that comparison, Go is a homeless (or maybe "minimalist") guy with a
shopping cart.

------
tedmiston
> PEP 515: Underscores in Numeric Literals

> PEP 515 adds the ability to use underscores in numeric literals for improved
> readability. For example:
    
    
        >>>
        >>> 1_000_000_000_000_000
        1000000000000000
    

A small touch but this is quite nice.

------
RodericDay
Love interpolation, still shaking my head @ the typing syntax

    
    
        primes: List[int] = []
        
        captain: str  # Note: no initial value!
        
        class Starship:
            stats: Dict[str, int] = {}

~~~
_quick_q
Could you expand? This looks similar to how it is done in Rust.

~~~
RodericDay
It looks very ugly to me, particularly the trying to reverse the original
mistakes behind `int`, `list`, `dict` into `Int`, `List`, `Dict`.

If you want to fix that, you fix that first, then apply it to a subsequent
patch like this one.

Additionally, I think Rust community, since its inception, embraced the goal
of paying any up-front costs required for introspection.

Meanwhile, the Python community seems to be tearing between those who want
syntactical beauty and one-way-to-do-it, and those who are running big
production systems using IDEs like PyCharm and wanting to benefit them.

I'd prefer it if Python somehow warned people developing gigantic systems that
maybe it's time to use a different language, instead of deforming Python to
suit the people already running gigantic systems in a language unsuited to it.

~~~
orf
Type hints are completely optional. Nobody is getting torn, and both use cases
are equally valid.

~~~
RodericDay
see: "only one way to do it"

Well, I'm not going to stop using Python or anything. I just think they're bad
and ugly and I'm sad that more and more I'll open the source code of some
library I'm using and find those "hints" littered everywhere.

I would plea that people reconsider their inclusion, but it seems like that
ship set sail.

~~~
kjbflsudfb
This is probably one of the fairest criticisms I've read and, honestly, I
didn't even notice that when reading the PEP. Thanks for your insight.

------
pbiggar
I wonder if there's a way to make all strings be format strings?

~~~
majewsky
It would break _a lot_ of existing code.

~~~
pbiggar
Not by default. Just for me. Like "from format import default_strings" or
something.

------
crystalPalace
Really happy to see the secrets module being added to the standard library.
Now to make sure every Python developer knows of its existence.

------
orf
Hmm, the documentation seems to be updated to show 3.6 in the dropdown but
it's not on the release page yet.

~~~
iguessthislldo
It's only a release candidate for right now.

------
jscheel
Great, another release that python devs can refuse to use.

~~~
jscheel
Ouch, harsh downvoting :) Guess the 2.7-4-life folks are a little sensitive.
Anyways, it's great to see python continue to move forward. I just wish more
devs would admit that python 2 is not the future and move on to 3.

------
SixSigma
> On Linux, os.urandom() now blocks until the system urandom entropy pool is
> initialized to increase the security

I prefer to use the phrase "less insecure" than "more secure".

------
fogleman
I'll say it. Python 2: Stability. Python 3: Feature creep.

I've been doing a lot of Go lately and hugely appreciate the minimal syntax
and orthogonal features. Seems like the opposite is happening not just in
Python but many languages.

~~~
goatlover
Are you the same person who advocates switching to Go over Python 3 in every
single Python thread? Not everyone prefers the minimal approach, particularly
in a dynamic, higher level scripting language, where ease of use trumps other
considerations.

Go and Python occupy different niches, for the most part. So the design
considerations for Go are naturally different than those for Python.

~~~
fogleman
Nah that ain't me. I rarely comment on such matters actually. Like you said Go
and Python serve quite different purposes and each do their jobs well. I use
both on a regular basis and I've been using Python for over a decade. But I
still think there's something to be said for simplicity in any language.

~~~
goatlover
The vintage Scheme vs Common Lisp argument.

